Received: from cnri by ietf.org id aa06066; 2 Sep 97 9: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 JAA23498 for ; Tue, 2 Sep 1997 09:23:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA01961 for ; Tue, 2 Sep 1997 09:20:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 09:12:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA01453 for ipp-outgoing; Tue, 2 Sep 1997 09:04: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>SEC - Sun's SunConnect architecture Message-Id: <5030100007398629000002L092*@MHS> Date: Tue, 2 Sep 1997 09:05:27 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Check out Sun's security architecture at http://www.sun.com/finance/connect. Roger K deBry Senior Technical 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 aa15724; 2 Sep 97 12: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 NAA24410 for ; Tue, 2 Sep 1997 13:02:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA02844 for ; Tue, 2 Sep 1997 12:58:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 12:54:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02362 for ipp-outgoing; Tue, 2 Sep 1997 12:46:02 -0400 (EDT) From: Roger K Debry To: scott_isaacson@novell.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: 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 - suggestions for Model document Message-Id: <5030100007417743000002L032*@MHS> Date: Tue, 2 Sep 1997 12:46:50 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Scott, you asked for some suggestions on security for the model document. Currently you have two sections on security, one on conformance (5.4) and the other on security considerations (7). I'd recommend something like the following: Section 5.4: Security Conformance Requirements The security mechanisms for IPP fall outside the scope of the application layer protocol itself, and are described in detail in the Internet Draft "Internet Printing Protocol/1.0: Security". It is required that the Internet Printing Protocol be able to operate in a secure environment. A conforming IPP implementation SHOULD provide a range of security services which can be tailored to meet the individual needs of a specific installation. These MUST include HTTP 1.1 basic and digest authentication, and SHOULD in addition support a secure communication channel, such as Transport Layer Security (TLS) and/or IP Security (IPSec). Section 7: Security Considerations The Internet Draft "Internet Printing Protocol/1.0: Security" provides a detailed discussion of the security considerations for IPP. Every time a new connection is established with a Printer object or with a job Object, a new security context must be established. However, it is up to the site administrator to determine the specific security requirements for any given IPP operation. This will be established through implementation specific means which are outside the scope of this standard. When a Job object is created, a security token MUST be associated with the Job which defines the most authenticated name of the user creating the job. When required by administratively established policy, this token MUST match the authenticated name provided on any subsequent operation on that job. Roger K deBry Senior Technical 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 aa16631; 2 Sep 97 13: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 NAA24522 for ; Tue, 2 Sep 1997 13:20:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA03468 for ; Tue, 2 Sep 1997 13:17:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 13:13:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02957 for ipp-outgoing; Tue, 2 Sep 1997 13:05:45 -0400 (EDT) Message-Id: <3.0.1.32.19970902095126.00ae2740@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Sep 1997 09:51:26 PDT To: Roger K Debry , scott_isaacson@novell.com MMDF-Warning: Parse error in original version of preceding line at ietf.org From: Carl-Uno Manros Subject: IPP> Re: IPP SEC - suggestions for Model document Cc: Ipp@pwg.org, cmanros@cp10.es.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org In-Reply-To: <5030100007417743000002L032*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Roger, I think that you probably missed the point on this. The recommendation out of Munich was to split the text in the Security document and integrate part of in into the Model document and part of into the Protocol document, and hence do away with the Security document in the final editing round. Your proposal seems to assume that the Security document will stay. Carl-Uno At 09:46 AM 9/2/97 PDT, Roger K Debry wrote: >Scott, you asked for some suggestions on security for the model document. > >Currently you have two sections on security, one on conformance (5.4) and the >other on security considerations (7). > >I'd recommend something like the following: > >Section 5.4: Security Conformance Requirements > >The security mechanisms for IPP fall outside the scope of the application layer >protocol itself, and are described in detail in the Internet Draft "Internet >Printing >Protocol/1.0: Security". It is required that the Internet Printing Protocol be >able to >operate in a secure environment. A conforming IPP implementation SHOULD >provide a range of security services which can be tailored to meet the >individual >needs of a specific installation. These MUST include HTTP 1.1 basic and >digest authentication, and SHOULD in addition support a secure communication >channel, such as Transport Layer Security (TLS) and/or IP Security (IPSec). > >Section 7: Security Considerations > >The Internet Draft "Internet Printing Protocol/1.0: Security" provides a >detailed >discussion of the security considerations for IPP. Every time a new connection >is established with a Printer object or with a job Object, a new security >context >must be established. However, it is up to the site administrator to determine >the >specific security requirements for any given IPP operation. This will be >established >through implementation specific means which are outside the scope of this >standard. When a Job object is created, a security token MUST be associated >with the Job which defines the most authenticated name of the user creating the >job. When required by administratively established policy, this token MUST >match >the authenticated name provided on any subsequent operation on that job. > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa17247; 2 Sep 97 13: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 NAA24554 for ; Tue, 2 Sep 1997 13:33:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04067 for ; Tue, 2 Sep 1997 13:30:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 13:26:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03545 for ipp-outgoing; Tue, 2 Sep 1997 13:18:04 -0400 (EDT) Message-Id: <3.0.1.32.19970902100633.00bfa700@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Sep 1997 10:06:33 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Fax - E-Mail - Ifax Identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Worried about junk mail on your IPP printer? The IFAX people are currently looking at the following proposed texts for US legislation. With some minor modifications it might cover IPP printers as well. Anybody wants to get your company lawyers involved? Carl-Uno >Date: Sat, 30 Aug 1997 09:22:55 PDT >To: ietf-fax@imc.org >From: Richard Shockey >Subject: Fax - E-Mail - Ifax Identification >Cc: jrafferty@worldnet.att.net >Sender: owner-ietf-fax@imc.org > > >In a recent posting I mentioned that there is pending legislation >in congress that extends USC Title 47 (Junk FAX) to e-mail. > >The legislation H.R. 1748 as been introduced by House Rep Chris Smith (R-NJ) > >The relevant language as it applies to Identification is excerpted >below: > >It is clear that it has a direct bearing on our work since this legislation >a pretty good chance of moving along due to public outrage about spamming. > >############ > > > (d) Technical and procedural standards > > (1) Prohibition > > It shall be unlawful for any person within the United > States - > > (A) to initiate any communication using a > telephone facsimile machine, or to make any > telephone call using any automatic telephone > dialing system, that does not comply with the > technical and procedural standards prescribed > under this subsection, or to use any telephone > facsimile machine or automatic telephone dialing > system in a manner that does not comply with such > standards; or > > (B) to use a computer or other electronic device > to send any message via a telephone facsimile > machine unless such person clearly marks, in a > margin at the top or bottom of each transmitted > page of the message or on the first page of the > transmission, the date and time it is sent and an > identification of the business, other entity, or > individual sending the message and the telephone > number of the sending machine or of such business, > other entity, or individual. > >NEW LANGUAGE>>>> > (C) TO USE A COMPUTER OR OTHER ELECTRONIC DEVICE > TO DIRECT ANY COMMERCIAL MESSAGE TO A COMPUTER OR > COMPUTER NETWORK ADDRESS UNLESS SUCH PERSON > CLEARLY MARKS, AT THE TOP OR BOTTOM OF THE > MESSAGE, THE DATE AND TIME IT IS SENT, THE NAME OF > THE BUSINESS, OTHER ENTITY, OR INDIVIDUAL SENDING > THE MESSAGE AND AN ELECTRONIC MAIL ADDRESS OF SUCH > BUSINESS, OTHER ENTITY, OR INDIVIDUAL. > >END EXCERPT > >####################### > >Full text of the amendment is at: > >http://thomas.loc.gov/cgi-bin/query/z?c105:H.R.1748: > >OR > >http://www.cauce.org/amendment.html > >an excellent page describing a number of the legislative options is at > >http://www.csn.net/%7Efelbel/jmemail.html#leg > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey >8045 Big Bend Blvd. Suite 110 >St. Louis, MO 63119 >Voice 314.918.9020 >Fax 314.918.9015 >INTERNET Mail: rshockey@ix.netcom.com > OR rshockey@stlnet.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 aa18809; 2 Sep 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 OAA24891 for ; Tue, 2 Sep 1997 14:40:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA04738 for ; Tue, 2 Sep 1997 14:37:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 14:33:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04251 for ipp-outgoing; Tue, 2 Sep 1997 14:25:27 -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>SEC - getting rid of the security document Message-Id: <5030100007424400000002L002*@MHS> Date: Tue, 2 Sep 1997 14:26:18 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Carl-Uno, Sorry that I missed the point of the Munich discussion. I had thought at our last IPP meeting we discussed perhaps keeping the security document as an Informational RFC. If we don't do this, we end up copying many pages to the model document, or losing a lot of the background on security considerations. I'm willing to go either way, but want to be sure we all agree on moving significant content from the security document to the model document. Then I think we have to settle on moving sections over in bulk, or cutting it up and dispersing it throughout the model document in various sections where it applies. Roger K deBry Senior Technical 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 aa21145; 2 Sep 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 PAA25129 for ; Tue, 2 Sep 1997 15:44:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05397 for ; Tue, 2 Sep 1997 15:41:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 15:37:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04899 for ipp-outgoing; Tue, 2 Sep 1997 15:29:12 -0400 (EDT) Message-Id: <3.0.1.32.19970902121608.00b9fad0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Sep 1997 12:16:08 PDT To: Roger K Debry , cmanros@cp10.es.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org From: Carl-Uno Manros Subject: Re: IPP>SEC - getting rid of the security document Cc: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org In-Reply-To: <5030100007424400000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Roger, the notion that the security document be an informational one and the simultanous requirement to have security in all documents that go for the standards track do not mix well. As there is a special section required for security considerations in the standards track documents, my assumption was that we could move most of the text in bulk, mainly deciding what goes where between the Model and Protocol documents. We might consider moving some of the background security stuff into the Requirements document, which also needs some updating before we are done. Carl-Uno At 11:26 AM 9/2/97 PDT, Roger K Debry wrote: >Carl-Uno, > >Sorry that I missed the point of the Munich discussion. I had thought at our >last IPP meeting we discussed perhaps keeping the security document as an >Informational RFC. If we don't do this, we end up copying many pages to the >model document, or losing a lot of the background on security considerations. > >I'm willing to go either way, but want to be sure we all agree on moving >significant >content from the security document to the model document. Then I think we have >to >settle on moving sections over in bulk, or cutting it up and dispersing it >throughout >the model document in various sections where it applies. > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa21471; 2 Sep 97 15: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 PAA25186 for ; Tue, 2 Sep 1997 15:58:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05999 for ; Tue, 2 Sep 1997 15:55:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 15:52:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05489 for ipp-outgoing; Tue, 2 Sep 1997 15:43: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>MOD Message-Id: <0038300008745008000002L082*@MHS> Date: Tue, 2 Sep 1997 15:44:40 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I've had a request from one of our operating system folks to see if we could add a job attribute for a phone number. This would allow me to send a job to a server that called the number to deliver the output on a fax machine. Any thoughts??? Roger K deBry Senior Technical 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 aa21880; 2 Sep 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 QAA25268 for ; Tue, 2 Sep 1997 16:19:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06654 for ; Tue, 2 Sep 1997 16:16:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 16:12:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06141 for ipp-outgoing; Tue, 2 Sep 1997 16:04:24 -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 Message-Id: <5030100007433065000002L052*@MHS> Date: Tue, 2 Sep 1997 16:05:23 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I've had a request from one of our operating system folks to see if we could add a job attribute for a phone number. This would allow me to send a job to a server that called the number to deliver the output on a fax machine. Any thoughts??? Roger K deBry Senior Technical 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 aa22262; 2 Sep 97 16: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 QAA25304 for ; Tue, 2 Sep 1997 16:31:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07226 for ; Tue, 2 Sep 1997 16:27:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 16:24:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06548 for ipp-outgoing; Tue, 2 Sep 1997 16:15:18 -0400 (EDT) Message-Id: <3.0.1.32.19970902130314.009b59f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Sep 1997 13:03:14 PDT To: Roger K Debry , ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org From: Carl-Uno Manros Subject: Re: IPP>MOD - Phone Number? In-Reply-To: <0038300008745008000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:44 PM 9/2/97 PDT, Roger K Debry wrote: >I've had a request from one of our operating system folks to >see if we could add a job attribute for a phone number. This >would allow me to send a job to a server that called the number >to deliver the output on a fax machine. > >Any thoughts??? > >Roger K deBry Roger, so far, we have avoided stepping on the toes of the IFAX group, which is what I think this would lead up to. Also, I do not see the real need for this. If your output device happens to be a fax machine, your IPP Printer should know how to contact the fax machine; it could even be sneaky enough to include it a part of the Printer URI. I know that this would require a unique IPP Printer id for every fax machine, but if you want to start defining a fax off ramp (in IFAX terminology) as part of IPP, you are going to need a lot more than just the phone number, apart from making enemies in the IFAX camp. In summary, I think we should leave this for implementors that might like to provide bridges between IPP and IFAX (or current fax) in their products. 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 aa22728; 2 Sep 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 QAA25342 for ; Tue, 2 Sep 1997 16:47:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07871 for ; Tue, 2 Sep 1997 16:44:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 16:41:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07334 for ipp-outgoing; Tue, 2 Sep 1997 16:32:59 -0400 (EDT) Message-Id: <3.0.1.32.19970902132133.00bba210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Sep 1997 13:21:33 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda Topics for the PWG IPP Phone Conference on September 3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, at long last, I am back in my office for a while and trying to catch up on various things, one of which is to get on top on what still needs to be done to wrap up the technical work on the IPP project by the end of the month. Here are the subjects that I believe needs further discussion in tomorrow's phone call: - Discuss our understanding of what additional work the Munich meeting produced. - Look at the further editing tasks and make sure that we have people working on them to get stable documents for sending to the IESG by the end of September. Do we need one more set of intermediate drafts? - Make sure that we have correctly identified any remaining issues and set dead lines for resolving them. - Do we have full agreement on the use of MIME for document types vs. using enums? - Do we have full agreement on whether to use a separate URI for Jobs or do we stay with the current draft which recommends using Printer URI + 32-bit integer? - Provide a short report on the outcome of the Analyst meeting in Waltham on August 27. - What subjects do we expect to discuss in the Atlanta PWG meeting September 17-18? Looks like we will be quite busy. 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 aa22916; 2 Sep 97 16: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 QAA25392 for ; Tue, 2 Sep 1997 16:59:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08247 for ; Tue, 2 Sep 1997 16:55:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 16:51:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07990 for jmp-outgoing; Tue, 2 Sep 1997 16:49:37 -0400 (EDT) Message-Id: <199709022048.QAA00161@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: Harald.T.Alvestrand@uninett.no cc: Harry Lewis , Moore , pmp , ipp , jmp Subject: JMP> Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-reply-to: Your message of "Tue, 19 Aug 1997 08:46:58 +0200." <9470.871973218@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 1997 16:48:52 -0400 Sender: jmp-owner@pwg.org A followup to this note from Harald: Harald explained the issues well. However, I do want to personally apologize for my poor choices of words at the Munich meeting re: the Printer MIB and the Job MIB. Keith > Oops control, as usual.... > > The Applications Area Directors do not think that the Printer MIB is > broken. > > The Apps ADs think that one particular decision was mistaken: > To establish a register of print languages (the prtInterpreterLangFamily) > and not to register those as MIME types. > > We also have doubts about the use of integers rather than names for > character sets (the CodedCharSet textual convention), but since this > is just 2 pointers into the same registry, and the IANA appears to be > maintaining this double registry, it is less harmful overall. > > We think the Right Thing is that the IPP group or the PrinterMIB group > should register all the currently unregistered printer formats as MIME > types, and that the IPP group should use the MIME types to indicate the > content of their MIME objects. > > With regard to the Job MIB, it seems clear that: > > - The IETF has no consensus position that it is a Good Thing to deploy > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the idea > that all users need MIB access; we do not want to bring this idea into > that process, for fear of delaying it further. > > - The IETF has consensus that there is no need for all MIBs to be > Internet standards. Informational MIBs, or MIBs developed by other > organizations, are Good Things; the IETF can sometimes assist in their > reviews, without necessarily taking responsibility. > > - Given the two positions above, we think that it's better for the > Job MIB to be submitted to the IETF as an external document and given > Informational status as a protocol under PWG control. > > There was some unfortunate fumbling of balls in the handover of this > group from the NM area to the Apps area, where the status of this request > for revised charter seemed to have been lost; I had hoped that we had > agreement on the positions above, but it seems that we didn't. > > (this discussion should be moved to the Printer MIB list only, but since > it seems I've fallen off it, please keep me in the CC line....) > > Harald Tveit Alvestrand > Apps AD > > > > >   Received: from cnri by ietf.org id aa22952; 2 Sep 97 16: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 RAA25407 for ; Tue, 2 Sep 1997 17:01:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08345 for ; Tue, 2 Sep 1997 16:57:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 16:54:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07982 for pmp-outgoing; Tue, 2 Sep 1997 16:49:27 -0400 (EDT) Message-Id: <199709022048.QAA00161@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: Harald.T.Alvestrand@uninett.no cc: Harry Lewis , Moore , pmp , ipp , jmp Subject: Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-reply-to: Your message of "Tue, 19 Aug 1997 08:46:58 +0200." <9470.871973218@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 1997 16:48:52 -0400 Sender: pmp-owner@pwg.org A followup to this note from Harald: Harald explained the issues well. However, I do want to personally apologize for my poor choices of words at the Munich meeting re: the Printer MIB and the Job MIB. Keith > Oops control, as usual.... > > The Applications Area Directors do not think that the Printer MIB is > broken. > > The Apps ADs think that one particular decision was mistaken: > To establish a register of print languages (the prtInterpreterLangFamily) > and not to register those as MIME types. > > We also have doubts about the use of integers rather than names for > character sets (the CodedCharSet textual convention), but since this > is just 2 pointers into the same registry, and the IANA appears to be > maintaining this double registry, it is less harmful overall. > > We think the Right Thing is that the IPP group or the PrinterMIB group > should register all the currently unregistered printer formats as MIME > types, and that the IPP group should use the MIME types to indicate the > content of their MIME objects. > > With regard to the Job MIB, it seems clear that: > > - The IETF has no consensus position that it is a Good Thing to deploy > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the idea > that all users need MIB access; we do not want to bring this idea into > that process, for fear of delaying it further. > > - The IETF has consensus that there is no need for all MIBs to be > Internet standards. Informational MIBs, or MIBs developed by other > organizations, are Good Things; the IETF can sometimes assist in their > reviews, without necessarily taking responsibility. > > - Given the two positions above, we think that it's better for the > Job MIB to be submitted to the IETF as an external document and given > Informational status as a protocol under PWG control. > > There was some unfortunate fumbling of balls in the handover of this > group from the NM area to the Apps area, where the status of this request > for revised charter seemed to have been lost; I had hoped that we had > agreement on the positions above, but it seems that we didn't. > > (this discussion should be moved to the Printer MIB list only, but since > it seems I've fallen off it, please keep me in the CC line....) > > Harald Tveit Alvestrand > Apps AD > > > > >   Received: from cnri by ietf.org id aa23452; 2 Sep 97 17: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 RAA25461 for ; Tue, 2 Sep 1997 17:19:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09381 for ; Tue, 2 Sep 1997 17:16:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 17:09:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08004 for ipp-outgoing; Tue, 2 Sep 1997 16:51:14 -0400 (EDT) Date: Tue, 2 Sep 1997 13:50:17 -0700 From: Robert Herriot Message-Id: <199709022050.NAA19136@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: IPP> Re: Why not use URI for Jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that the decision on Job-URI versus Job-Id all boils down to a decision about one of two directions: 1) The solution should solve today's problems easily while potentially making tomorrow's problem harder. 2) The solution is allowed to make today's problems harder to solve in order to allow for the possiblity that tomorrow's problems be easier to solve. I favor direction #1 which implies Job-Id because I believe that new technology is most successful when it carries along existing technology easily. I also believe that it is not wise to make solving existing problems substantially harder in order to achieve a payback that is not well understood and may never happen. In my experience, when a feature is added for some poorly understood future requirement, it is frequently never used. Bob Herriot > From cmanros@cp10.es.xerox.coM Sat Aug 30 05:22:08 1997 > > OK, > > ask Bob Herriot from Sun or Scott Isaacson from Novell about the details. > > I have actually asked that somebody posts a reply to Randy's comments, so > that we can get the thing out of the world. > > Carl-Uno > > At 10:20 PM 8/29/97 PDT, you wrote: > >> I tried to sell exactly the compromise that you just suggested in your > >> previous message, but people who are closer to implementation told me that > >> it would not work. > > > >Am I still toe-ing the line if I ask you who they are, so I can ask them > >why it won't work? It would be good to get this resolved to the point > >that there aren't any technical questions about it being the right path, > >and I can't figure out why it doesn't work. > > > >That is, there are two gateway cases: > > LPR client -(gw)-> IPP printer > > new printer, just support LPR too > > If you really need to map, well, you have to make up > > LPR job IDs and keep track of the ID->URL mapping, but > > it's a small table. > > > > IPP client -(gw)-> LPR printer > > make Job URLs of the form "http://printer/LPRJOBNUMBER/nnnnn" > > where nnnnnn is the LPR job number. > > > >This doesn't need any auxiliary tables. > > > >Larry > > > > > 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 aa23459; 2 Sep 97 17: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 RAA25468 for ; Tue, 2 Sep 1997 17:19:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09393 for ; Tue, 2 Sep 1997 17:16:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 17:09:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07974 for ipp-outgoing; Tue, 2 Sep 1997 16:49:20 -0400 (EDT) Message-Id: <199709022048.QAA00161@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: Harald.T.Alvestrand@uninett.no cc: Harry Lewis , Moore , pmp , ipp , jmp Subject: Re: IPP> Re: PMP> IETF concerns regarding the Printer MIB draft? In-reply-to: Your message of "Tue, 19 Aug 1997 08:46:58 +0200." <9470.871973218@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 1997 16:48:52 -0400 Sender: ipp-owner@pwg.org A followup to this note from Harald: Harald explained the issues well. However, I do want to personally apologize for my poor choices of words at the Munich meeting re: the Printer MIB and the Job MIB. Keith > Oops control, as usual.... > > The Applications Area Directors do not think that the Printer MIB is > broken. > > The Apps ADs think that one particular decision was mistaken: > To establish a register of print languages (the prtInterpreterLangFamily) > and not to register those as MIME types. > > We also have doubts about the use of integers rather than names for > character sets (the CodedCharSet textual convention), but since this > is just 2 pointers into the same registry, and the IANA appears to be > maintaining this double registry, it is less harmful overall. > > We think the Right Thing is that the IPP group or the PrinterMIB group > should register all the currently unregistered printer formats as MIME > types, and that the IPP group should use the MIME types to indicate the > content of their MIME objects. > > With regard to the Job MIB, it seems clear that: > > - The IETF has no consensus position that it is a Good Thing to deploy > MIBs as a means of users' access to information (as opposed to an > administrator's access). In particular, the access control models > currently being defined in the SNMPv3 group are not based on the idea > that all users need MIB access; we do not want to bring this idea into > that process, for fear of delaying it further. > > - The IETF has consensus that there is no need for all MIBs to be > Internet standards. Informational MIBs, or MIBs developed by other > organizations, are Good Things; the IETF can sometimes assist in their > reviews, without necessarily taking responsibility. > > - Given the two positions above, we think that it's better for the > Job MIB to be submitted to the IETF as an external document and given > Informational status as a protocol under PWG control. > > There was some unfortunate fumbling of balls in the handover of this > group from the NM area to the Apps area, where the status of this request > for revised charter seemed to have been lost; I had hoped that we had > agreement on the positions above, but it seems that we didn't. > > (this discussion should be moved to the Printer MIB list only, but since > it seems I've fallen off it, please keep me in the CC line....) > > Harald Tveit Alvestrand > Apps AD > > > > >   Received: from cnri by ietf.org id aa00986; 3 Sep 97 3: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 DAA27793 for ; Wed, 3 Sep 1997 03:23:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA11647 for ; Wed, 3 Sep 1997 03:20:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 03:11:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA11051 for ipp-outgoing; Wed, 3 Sep 1997 03:00:42 -0400 (EDT) Message-Id: <9709030700.AA20067@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Sep 1997 23:57:55 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - Proposal to add 'dictionary' attribute syntax Sender: ipp-owner@pwg.org Here is the action item that Roger and I had from the last meeting to propose explicit text for a 'dictionary' attribute to be added to the model and protocol documents. I've posted the .pdf and .doc files in: ftp://ftp.pwg.org/pub/pwg/new_MOD/ -rw-r--r-- 1 pwg pwg 24576 Sep 3 06:55 ipp-dict.doc -rw-r--r-- 1 pwg pwg 18152 Sep 3 06:56 ipp-dict.pdf -rw-r--r-- 1 pwg pwg 11511 Sep 3 06:56 ipp-dict.txt Attached is the .txt file as well (but the .pdf file is much easier to read, especially the long example). Also the .pdf file has line numbers and is four pages long. If possible, I'd like to discuss this proposal at the Wed, 9/3, IPP telecon. Tom Subj: Proposal for adding a 'dictionary' attribute syntax to IPP Model From: Tom Hastings and Roger deBry Date: 9/02/97, version 0.5 File: ipp-dict.doc 1. Problem Statement There is no good way to add attribute syntaxes that contain several fields, whether the fields are mandatory or optional. Instead of each new attribute that needs more than one field (struct), requiring an ad hoc attribute syntax, such as we have done for the 'resolution' attribute syntax for use in the "printer-resolution" attribute, it would be desirable to have a simple, general mechanism for representing multi-field values. It would also be desirable to allow fields to be omitted, when the attribute specification allows that. This mechanism would be useful for both new attributes that we might add to IPP standard, that might be registered, or that implementors might implement as private extensions. 2. Suggested solution Add a 'dictionary' attribute syntax, in which the attribute value is a set of attributes. Then each 'field' that is present in the attribute value would be self identifying by its attribute name. An attribute with an attribute syntax could be single valued ('dictionary'), i.e., with one dictionary value, or could be multi-valued ('1SetOf dictionary'). As with all attribute values, the dictionary value has a length of the entire value. If the dictionary attribute is multi-valued, as with any multi-valued attribute, each dictionary value has a length. Thus implementations that did not support the specified attribute could skip over the entire value to get to the next attribute (or to the next dictionary value, if the dictionary attribute is multi-valued). The syntax of each dictionary value is the same as a set of attributes, so each attribute has its keyword name, its attribute syntax code, and its value. An attribute in a dictionary can be single valued or multi-valued as well. For example, the new "printer-resolution" attribute was defined using a very ad hoc 'resolution' attribute syntax. Had we had the dictionary attribute syntax, we might have chosen to use it here, though we wouldn't have had to either. If we did use the 'dictionary' attribute syntax for the "printer-resolution", the attribute value would contain the following attributes: "cross-feed-resolution", "feed- resolution", "units". However, we can also keep resolution as it is, even if we add the 'dictionary' attribute syntax. As a second example, an attribute could represent the fields that the submitter wishes to be printed on the job-start page. The name of the attribute might be: "job-start-page- contents". The dictionary value might include: "job-name", "user-name", "job-comment", "account-name", etc. where the values of the attributes in the dictionary are printed after each attribute name on the job-start-page. As a third example, an attribute could represent a person's address using a dictionary that contains the following attributes where each attribute has a simple 'text' attribute syntax: "addressee-name" required "company-name" optional "internal-mail-stop" optional "apartment-number optional "street-address" required "city-or-town required "state" required "postal-zone required "country" optional "phone-numbers optional The "address" attribute could be specified to be single- valued ('dictionary'), or could be multi-valued ('1setOf dictionary'). Also the specification for the "address" attribute could require that the constituent attributes be in the above order or that they could be in any order. For this example, it would make sense for the specification of the "address" attribute to require that the dictionary be ordered, with only the optional attributes being permitted to be omitted. It seems unnecessary to consider ordered and unordered dictionaries as separate attribute syntaxes. Some attribute specifications might allow additional attributes to be included (open-ended) and other attribute specifications might specify that only the attributes specified in the standard or registration may be used in the dictionary value (closed-ended). As a fourth example, a dictionary attribute syntax would be a much better way for the Printer to represent its capabilities, rather than the ad hoc naming conventions: "xxx" Printer attribute to represent default and the "xxx- supported" Printer attribute to represent the supported values. So the client would request the "xxx" attribute of the Printer and get back the "xxx" attribute whose dictionary values would be the "default" and "supported- values" attributes whose values would indicate the default and supported values, respectively of the "xxx" job template attribute. Adding additional attributes to indicate future capabilities, such as "ready-values", "multi-valued", etc. could be done by adding additional attributes in the dictionary value that is returned. 3. Suggested Text Add to section 4.1 Attribute Syntaxes of the IPP Model specification: dictionary: a set or sequence of attributes, where each attribute MAY be single-valued or multi-valued as specified for the dictionary attribute. As in the attribute sets that are passed in operations, no attribute SHALL occur more than once in a dictionary. However, if the same attribute does occur more than once in a dictionary, the recipient SHALL use the later occuring one, ignoring any earlier occurrences of the same attribute. The specification of the attribute that uses the 'dictionary' attribute syntax SHALL specify: 1. as with any attribute, whether the attribute is single- valued (attribute syntax = 'dictionary) or multi-valued (attribute-syntax = '1SetOf dictionary'). 2. whether the attributes in the dictionary value are ordered or unordered. 3. for each attribute in the dictionary value, whether the attribute's presence is required or optional. 4. for each attribute permitted in the dictionary value, the completed specification of that attribute shall be included or inferred by reference to the specification of that attribute elsewhere. 5. whether additional attributes not specified with the dictionary attribute specification may be included (open- ended) in a dictionary value or not (closed-ended). For open-ended dictionary attributes, there MAY be some requirements on what kind of attributes may be included, including restrictions on attribute syntaxes. A dictionary may contain another dictionary, if the specification of the dictionary attribute allows. Add to section 9, Appendix A: Protocol Examples of the IPP Protocol specification 9.2 Print-Job Request with an "address" dictionary attribute, including two address dictionary values and two phone numbers in the first address dictionary value. Octets Symbolic Protocol comments Value field 0x0100 1.0 version 0x0002 PrintJob operation 0x02 start attribute attributes tag 0x42 name type value-tag "job-name" attribute 0x0008 name- length job-name job-name name 0x0006 value- length foobar foobar value 0x?? dictionary value-tag "addresses" type attribute 0x0007 name- length address address name 0x009c value- 156 octets in 1st length dict value 0x41 text type value-tag start of 1st dictionary value 0x000e name- length addressee- addressee- name "addresses-name" name name attribute 0x0009 value- length Tom Jones Tom Jones value 0x41 text type value-tag "street-address" attribute 0x000e name- length street- street- name address address 0x000c value- length 100 Main St. 100 Main value St. 0x41 text type value-tag "city-or-town" attribute 0x000c name- length city-or-town city-or- name town 0x0008 value- length New York New York value 0x41 text type value-tag "state" attribute 0x0005 name- length state state name 0x0002 value- length NY NY value 0x41 text type value-tag "postal-zone" attribute 0x000b name- length postal-zone postal-zone name 0x0005 value- length 10200 10200 value 0x41 text type value-tag "phone-numbers" attribute 0x000d name- length phone- phone- name numbers numbers 0x08 value- length 312-1234 312-1234 value 0x41 text type value-tag start of 2nd phone-numbers value 0x0000 name- 0 length means length next multiple value 0x0008 value- length 372-8432 372-8432 value end of 1st dictionary value 0x?? dictionary- value-tag start of 2nd type dictionary value 0x0000 name- 0 length mean length next multple value 0xnnnn 0xnnnn value- nnnn octets in 2nd length dict value 0x41 text type value-tag start of 2nd dictionary value 0x000e name- length addressee- addressee- name "addresses-name" name name attribute 0x000a value- length Bill Smith Bill Smith value ... nnnn octets of the next dict value 0x03 start-data data-tag %!PS...   Received: from cnri by ietf.org id aa01057; 3 Sep 97 3: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 DAA27798 for ; Wed, 3 Sep 1997 03:27:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA12181 for ; Wed, 3 Sep 1997 03:24:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 03:20:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA11074 for ipp-outgoing; Wed, 3 Sep 1997 03:06:44 -0400 (EDT) Message-ID: <340D0BAD.15323EF4@sharplabs.com> Date: Wed, 03 Sep 1997 00:03:10 -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> Re: Why not use URI for Jobs? X-Priority: 3 (Normal) References: <199709022050.NAA19136@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org These "direction" statements proceed from a false assumption, that today's problems are not solved. I say that they are solved. The bulk of the features in the model document have come from vendor specification and not from customer requirements. Originally, we just wanted to "send a document over the web" to a printer. And Paul Moore's original statement from a previous PWG meeting was something like "we are just using the web to locate printers...". SWP was really very simple. I thought we were looking at the bigger picture with regards to what advantages the web could bring to deployment of distributed printing environments. The way I read the direction #1 statement is: 1. Lets just concentrate on writing gateways to existing implementations and not allow native IPP implementations; basically preventing other printer vendors from implementing a more powerful job identifier mechanism than our current systems' 4-byte integer. Along with the scalability advantages of Job URIs, the information contained in URIs can assist security, job accounting, and could even assist in job scheduling and/or spooling. We at Sharp are even exploring the future format of IPP outside of HTTP, and the use of IPP: URI schemes, which would be automatically supported by the IPP model in the environment I am proposing. I am hoping that with IPP we can not only provide a platform for advanced printing today but providing a spring board into future scalable printing solutions that are created as a result of what we are doing (if we do our jobs right). I think alot of the decisions that have been to date have been severely compromised for questionably technical reasons. I just think at our current rate of "feature culling" that we really are going to end up with nothing new to offer customers. Just another way to do what is already being done. I think we need to carefully consider the environment (the "web") in which we are planning on deploying IPP (over HTTP). Basically, if are just going to use HTTP and the web environment as a tunnel for existing printing systems, then we are not providing anything new. In fact, if we proceed down that path, there's nothing that we are doing that HP "JetSend" can't do, and possibly better. If we need to somehow support legacy printing environments job identification, then just add a "helper" job identification or other type of attribute that also can be used by legacy implementations to identify a job. It doesn't have to be one or the other. Why can't we explore the idea of supporting both types of environments? Robert Herriot wrote: > I think that the decision on Job-URI versus Job-Id all boils down to a > > decision about one of two directions: > > 1) The solution should solve today's problems easily while > potentially > making tomorrow's problem harder. > > 2) The solution is allowed to make today's problems harder to solve > in > order to allow for the possiblity that tomorrow's problems be > easier to solve. > > I favor direction #1 which implies Job-Id because I believe that new > technology is most successful when it carries along existing > technology > easily. I also believe that it is not wise to make solving existing > problems substantially harder in order to achieve a payback that is > not > well understood and may never happen. In my experience, when a feature > > is added for some poorly understood future requirement, it is > frequently > never used. > > Bob Herriot > > > From cmanros@cp10.es.xerox.coM Sat Aug 30 05:22:08 1997 > > > > OK, > > > > ask Bob Herriot from Sun or Scott Isaacson from Novell about the > details. > > > > I have actually asked that somebody posts a reply to Randy's > comments, so > > that we can get the thing out of the world. > > > > Carl-Uno > > > > At 10:20 PM 8/29/97 PDT, you wrote: > > >> I tried to sell exactly the compromise that you just suggested in > your > > >> previous message, but people who are closer to implementation > told me that > > >> it would not work. > > > > > >Am I still toe-ing the line if I ask you who they are, so I can ask > them > > >why it won't work? It would be good to get this resolved to the > point > > >that there aren't any technical questions about it being the right > path, > > >and I can't figure out why it doesn't work. > > > > > >That is, there are two gateway cases: > > > LPR client -(gw)-> IPP printer > > > new printer, just support LPR too > > > If you really need to map, well, you have to make up > > > LPR job IDs and keep track of the ID->URL mapping, but > > > it's a small table. > > > > > > IPP client -(gw)-> LPR printer > > > make Job URLs of the form "http://printer/LPRJOBNUMBER/nnnnn" > > > > where nnnnnn is the LPR job number. > > > > > >This doesn't need any auxiliary tables. > > > > > >Larry > > > > > > > > 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 aa15431; 3 Sep 97 14: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 OAA29878 for ; Wed, 3 Sep 1997 14:18:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14034 for ; Wed, 3 Sep 1997 14:15:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 14:09:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13519 for ipp-outgoing; Wed, 3 Sep 1997 14:01:30 -0400 (EDT) Message-Id: <9709031801.AA03794@viper.cp10.es.xerox.com> X-Mailer: exmh version 1.6.7 5/3/96 To: ipp@pwg.org Cc: moore@cs.utk.edu Subject: IPP> IPP-Security comments and clarifications from the 39th IETF. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 3 Sep 1997 11:01:09 PDT From: "Daniel W. Manchala" Sender: ipp-owner@pwg.org Recently some comments were brought up at the 39th IETF meeting held in Munich related to security. Some of the questions, and my clarifications are written below. Q: Why not start a secure session and then drop to an insecure level. A: You could have two separate sessions - first secure - then drop the session - and then start a new insecure session. You cannot drop to an insecure level in one session. However, once a secure session has been started, it is not advisable to drop to an insecure level or session. First, it is usually not a security practice. Second, security protocols do not allow such a transition. For example, such a thing does not exist in SSL, nor can Netscape visualize having such a feature in SSL in the near future. Third, customers or clients who have security would continue to make use of that session rather than switch to an insecure session immediately following a secure session. Fourth, you may find certain customers or clients not to have security features (i.e., the relevent certificates, browsers or software) on their system and hence may want to start an insecure session first and then discover that they require certificates to continue with the print request. This essentially means that they may want to start off in an insecure inquistive mode, but move over to a secure exchange later on. Finally, the very purpose of having a secure session is lost if you want to drop to an insecure level later on. This may give rise to other questions: a. Don't you think that SSL encrypts data, and this is time consuming? Users may want to switch to a lower level just for that reason. The answer is simple, there is nothing you can do about it in the current version of SSL. If you do not want to encrypt, the best you can do is use the fetch-and-print feature where you can fetch a document without encryption and print it off. This is the print-by-reference feature. Then, this is how we need to design this. b. Then how about starting an insecure session and then moving over to a secure session? The answer is again simple, one cannot do the transition in a single step. First, one will discover that the print request requires a secure session by looking at the HTTP 403 error message. Then, one should use https or provide the required and necessary certificates (in case you are already using https) to make a secure session. I demo'ed this to you on Monday. c. So, what do you think? should I use an LDAP server to know if a printer can communicate securely? No. It is not necessary to use LDAP to discover the printer's secure capabilities. As explained above, the server to which the printer is tied has the capability of notifying the client that it needs to use a secure SSL exchange. Q: I am not sure if a client can connect to a https port when it uses a http URL. A: Again, I showed this to you. The client will get an error message. Ah - now we need IPP to interpret this message - Is the client using http instead of https or is it just that the client does not have the right certificates or is due to something else? The error message is - "Access Forbidden Secure Channel Required - This ... requires a browser that supports the configured encryption options". By looking at this error message, one is not sure if the encryption options are correctly used (as one sets it up in netscape browser) or if it is just the wrong use of http instead of https. This is something that HTTP or HTTP-NG needs to look into, and probably pass on a different error for different things. This is not IPP's task. I do remember that we need to participate in HTTP-NG efforts for security too. Q: Why don't we start with SSL2 and then transition to SSL3? A: Remember, TLS supports servers that can talk either SSL2 or SSL3. This transition should be transparent though it should be verified. However, we do not have an implementation of TLS available at this time. It is hard to check this with current implementations of SSL2 and SSL3 separately. We probably need changes to SSL client software. Dan.   Received: from cnri by ietf.org id aa17939; 3 Sep 97 15: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 PAA00218 for ; Wed, 3 Sep 1997 15:37:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14649 for ; Wed, 3 Sep 1997 15:34:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 15:29:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14171 for ipp-outgoing; Wed, 3 Sep 1997 15:21:33 -0400 (EDT) Message-Id: <9709031921.AA20276@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, 3 Sep 1997 12:18:42 PDT To: Carl-Uno Manros From: Tom Hastings Subject: Re: IPP>MOD - Phone Number? Cc: Roger K Debry , ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Sender: ipp-owner@pwg.org I suggest that we explore how an IPP printer could interface to the phone network for FAX and to the Internet for IFAX as a registration after IPP V1.0 is done, by adding one or more attributes as registration. Some IPP people may wish to discuss whether this is a proper extension of our IPP Printer model or not or whether using URI with parameters is a better way to go, etc. etc. Any proposal would take working with these other groups to get it right. Including it now would delay getting IPP V1.0 out. But I think it is someting that we definitely want to do with IPP. Tom At 13:03 09/02/97 PDT, Carl-Uno Manros wrote: >At 12:44 PM 9/2/97 PDT, Roger K Debry wrote: >>I've had a request from one of our operating system folks to >>see if we could add a job attribute for a phone number. This >>would allow me to send a job to a server that called the number >>to deliver the output on a fax machine. >> >>Any thoughts??? >> >>Roger K deBry > >Roger, > >so far, we have avoided stepping on the toes of the IFAX group, which is >what I think this would lead up to. Also, I do not see the real need for >this. If your output device happens to be a fax machine, your IPP Printer >should know how to contact the fax machine; it could even be sneaky enough >to include it a part of the Printer URI. I know that this would require a >unique IPP Printer id for every fax machine, but if you want to start >defining a fax off ramp (in IFAX terminology) as part of IPP, you are going >to need a lot more than just the phone number, apart from making enemies in >the IFAX camp. > >In summary, I think we should leave this for implementors that might like >to provide bridges between IPP and IFAX (or current fax) in their products. > >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 aa19650; 3 Sep 97 16: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 QAA00421 for ; Wed, 3 Sep 1997 16:34:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA16130 for ; Wed, 3 Sep 1997 16:30:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 16:27:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15614 for ipp-outgoing; Wed, 3 Sep 1997 16:19: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: Re: IPP>MOD - Phone Number? Message-Id: <5030100007536267000002L072*@MHS> Date: Wed, 3 Sep 1997 16:19:56 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Thanks Tom. I agree that this could be postponed, but I think it is worth approaching the IFAX group with a proposal for how the two standards might work together. Roger K deBry Senior Technical 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 09/03/97 02:05 PM --------------------------- ipp-owner @ pwg.org 09/03/97 01:31 PM Please respond to ipp-owner@pwg.org @ internet To: cmanros @ cp10.es.xerox.com @ internet cc: ipp @ pwg.org @ internet, Roger K Debry/Boulder/IBM Subject: Re: IPP>MOD - Phone Number? I suggest that we explore how an IPP printer could interface to the phone network for FAX and to the Internet for IFAX as a registration after IPP V1.0 is done, by adding one or more attributes as registration. Some IPP people may wish to discuss whether this is a proper extension of our IPP Printer model or not or whether using URI with parameters is a better way to go, etc. etc. Any proposal would take working with these other groups to get it right. Including it now would delay getting IPP V1.0 out. But I think it is someting that we definitely want to do with IPP. Tom At 13:03 09/02/97 PDT, Carl-Uno Manros wrote: >At 12:44 PM 9/2/97 PDT, Roger K Debry wrote: >>I've had a request from one of our operating system folks to >>see if we could add a job attribute for a phone number. This >>would allow me to send a job to a server that called the number >>to deliver the output on a fax machine. >> >>Any thoughts??? >> >>Roger K deBry > >Roger, > >so far, we have avoided stepping on the toes of the IFAX group, which is >what I think this would lead up to. Also, I do not see the real need for >this. If your output device happens to be a fax machine, your IPP Printer >should know how to contact the fax machine; it could even be sneaky enough >to include it a part of the Printer URI. I know that this would require a >unique IPP Printer id for every fax machine, but if you want to start >defining a fax off ramp (in IFAX terminology) as part of IPP, you are going >to need a lot more than just the phone number, apart from making enemies in >the IFAX camp. > >In summary, I think we should leave this for implementors that might like >to provide bridges between IPP and IFAX (or current fax) in their products. > >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 aa22004; 3 Sep 97 18: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 SAA00711 for ; Wed, 3 Sep 1997 18:14:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16949 for ; Wed, 3 Sep 1997 18:11:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 18:07:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16420 for ipp-outgoing; Wed, 3 Sep 1997 17:59:13 -0400 (EDT) From: Roger K Debry To: Masinter@parc.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: Re: IPP>MOD - fax Message-Id: <5030100007544579000002L092*@MHS> Date: Wed, 3 Sep 1997 18:00:06 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I believe this is a reasonable thing to do. Roger K deBry Senior Technical 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 09/03/97 03:49 PM --------------------------- masinter @ parc.xerox.com 09/03/97 03:52 PM Please respond to masinter@parc.xerox.com @ internet To: Roger K Debry/Boulder/IBM cc: Subject: Re: IPP>MOD How about asking that Internet Printing and Internet Faxing be aligned to the point where it might be possible to gateway between the two. That doesn't mean that the protocol should be the same, but does ask that you consider 'fax' along with 'legacy LPR printers'. Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa22611; 3 Sep 97 18: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 SAA00769 for ; Wed, 3 Sep 1997 18:36:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA17541 for ; Wed, 3 Sep 1997 18:33:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 18:29:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17056 for ipp-outgoing; Wed, 3 Sep 1997 18:21:31 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 03 Sep 1997 16:19:19 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> ADM - 9/3/97 Telecon minutes Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org IPP Teleconference 9/3/97 Moderator: Carl-Uno Manros Note taker: Scott I. Attendees: Scott Isaacson, Steve Zilles, Roger deBry, Lee Farrell, Ron Bergman, Peter Zehler, Randy Turner, Harry Lewis, Bob Herriot, Tom Hastings, Ira McDonald, David Kellerman Start 2:05 PM Mountain Agenda: 1. Review Munich - Carl-Uno with edit and produce the minutes - Break up of the Security Doc: Roger, Scott, and Bob to get together an editors meetings early the week of 8/9/97. - New Issues There was talk that IPP must start in a secure mode and negotiate down to a unsecure mode - Keith suggested mandatory use of TLS, but TLS is not deployed yet - Should we include security attributes in IPP itself since TLS is not deployed. - Is it possible to force TLS framing with NULL parameters for all IPP implementations? Not practically given that TLS is still not deployed on the first round of HTTP/1.1 servers. - Use of TLS under HTTP is an HTTP problem. Keith might say that a statement such as "we will do whatever HTTP does" however a statement such as "we will do something different than HTTP" is also unacceptable. - SEC action item to see if TLS backward compatibility for SSL3. Xerox people are working on this. - Randy will contact TLS working group about SSL backwards compatibility and proposed use with HTTP. - Carl-Uno will contact Larry Masinter - Carl-Uno will set up a security call 2. Editing Issues - Re-edit requirements document. Don will do this. Peter Z will email a reminder to Don. - Scott will reissue Model document by 9/3/97 - Bob will reissue Protocol document by 9/5/97 - Directory should be standards track. Hopefully Scott can get to this by the end of September - Steve will update rationale document - Bob will put LPD mapping document on lower priority as an informational RFC 3. Review outstanding Issue 3.a MIME types - IPP will use MIME. Who will register? PWG or the vendor? There is huge pain in having two systems. We ought to update IANA registry for Printer Document Format Enums to point to the MIME type. - Don or Lloyd should add the issue of Printer MIB support for MIME types to the PMP working group. Suggest: keep the same Printer MIB registry, do not deprecate it, add a new optional, printerLangMIMEType - MIME types can optionally contain the language and char set - Harold and Keith need to be advised as to the problem with char set registry (the registry has more than 1 for each char set) Steve Z will do this. - Job MIB allows for both MIME type and Printer ENUM - IANA has a double registry right now (MIME and Printer MIB) If we don't add a new MIME type object to the Printer MIB, we will not be able to transition very easily. 3b. URI for Jobs or ID for Jobs - Point of order: final discussion on the mailing list - Reading of the minutes from Redmond about Job URI - Deciding on Job URI or Job ID there are issues with 1) APIs for exiting practice and 2) Gateways If the Printer or the Gateway which generates the Job URI choose to do /, that is ok. However, what if the client side expects IDs not URIs and the Printer or Gateway only generates URIs? This is true for most APIs. Even in most DPA implementations, they implemented 32bit integer rather than OCTET STRING. - What about redirect (DPA resubmit). If the ID is just a Job ID, it is always in context of a Printer URI and so if you redirect Job requests you also have to redirect the Printer requests which is not desired. - Scalability issues: Central IPP Printer for security , access control, validation etc., but then multiple back end IPP Printers for Job processing and Job status. - Can we explore a way to do both (Job URI and Job ID)? - There might be mapping being done already with Job Handles for writing vs Job IDs at the client anyway - Bob to write down reasons for Job ID - Randy to reformat reasons for Job URL 4. Other issues: a. Semantics of time out b. Semantics of walk-up user vs network users c. Why protocols shouldn't have version numbers? d. Why is "printer-up-time" MANDATORY? e. What is the value of "Get-Jobs" without order? 5. Waltham Review - It went reasonably well - Some people are actually beginning to write stuff (mostly positive about the direction, a little weak on details) - Wait and see if we need another one - Perhaps a west coast version around December IETF. 6. Agenda items for Atlanta a. Dictionary Syntax b. Fax number c. Interoperability Testing End: 4:10 PM Mountain   Received: from cnri by ietf.org id aa23969; 3 Sep 97 20: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 UAA01027 for ; Wed, 3 Sep 1997 20:12:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18228 for ; Wed, 3 Sep 1997 20:08:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 20:05:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17742 for ipp-outgoing; Wed, 3 Sep 1997 19:56:58 -0400 (EDT) Message-Id: <3.0.1.32.19970903164507.00ae4bb0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 3 Sep 1997 16:45:07 PDT To: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: IPP> SEC - IPP Security Requirements Cc: ipp@pwg.org, masinter@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Keith and Harald, I want to verify with you what I interpreted to be new additional security requirements from our Munich discussions: 1) You are expecting that every new IPP session starts up with a security negotiation. 2) You are expecting that every IPP Client and Printer has the capability to support more than the security defined by RFCs 2068 and 2069, e.g. features corresponding to SSL2 in TLS. We have started looking into this and are running into the following issues: 1) We have identified several scenarios where security is not needed and where the overhead of security negotiation and mandatory support for unnecessary security features is a useless extra burden. 2) TLS is not yet really stable and furthermore does not provide a lot of security negotiation features. 3) SASL could potentially offer a better negotiation package, but does not work well with TLS; actually according to recent discussions on the security DLs, it seems that they are almost totally incompatible. SASL on its own does not provide what we need. 4) It is also not clear how TLS and HTTP can be made to work together. 5) In the Munich IPP meeting we stated that we thought this was really a problem for HTTP, and that we could live with most any solution that worked for HTTP. We are still of that opinion. We are still digging around to see if we can come up with some half baked solution that might approximately meet your requirements, but we recent the idea that we have to develop a separate and special security solution for IPP just because the appropriate security standardization projects are still working on their specs. I am looking for some constructive advice from you as Area Directors. Is our only option to wait until the security WGs have sorted themselves out, or are you prepared to relax the requirements? We have been prepared to let IPP use existing implemented (proprietary) security features and products for the Internet as an intermediate step, until the IETF security groups can provide us with standardized and implemented security solutions. It seems to us that the overall IETF requirement that application standards include security features before they are fully specified, stable and implemented is putting up an artificial barrier to application area projects being able to finish their specifications. Regards, Carl-Uno for the IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa24932; 3 Sep 97 21: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 VAA01144 for ; Wed, 3 Sep 1997 21:31:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA19265 for ; Wed, 3 Sep 1997 21:28:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 21:24:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA18775 for ipp-outgoing; Wed, 3 Sep 1997 21:16:32 -0400 (EDT) Message-Id: <199709040114.VAA28210@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> Re: SEC - IPP Security Requirements In-reply-to: Your message of "Wed, 03 Sep 1997 16:45:07 PDT." <3.0.1.32.19970903164507.00ae4bb0@garfield> Date: Wed, 03 Sep 1997 21:14:12 -0400 Sender: ipp-owner@pwg.org > I want to verify with you what I interpreted to be new additional security > requirements from our Munich discussions: > > 1) You are expecting that every new IPP session starts up with a security > negotiation. > > 2) You are expecting that every IPP Client and Printer has the capability > to support more than the security defined by RFCs 2068 and 2069, e.g. > features corresponding to SSL2 in TLS. We probably haven't fully articulated the requirements but, no, I don't think the requirements are so severe. Rather, I'd say: 1) the security considerations section should analyze known attcks and possible countermeasures 2) if the protocol needs authentication (as IPP almost certainly does) you need to provide better authentication than plain-text passwords. And offhand, I see several ways in which the requirement could be met: + Since IPP is using HTTP/1.1, I would expect that digest access authentication would pass the "no plain-text passwords" test. This would meet the minimum authentication requirement, but shared secrets don't scale very well. Nor can this be used to provide confidentiality. Still, for a small printer that can't handle large volumes anyway (and this wouldn't be expected to serve a large user community), this might be just fine. + IPP could be specified to *always* use TLS (and always on a port assigned to IPP - no separate IPP/TLS port), but allow use of the anonymous and/or NULL encryption ciphersuites for those cases where authentication and/or privacy were not required. + IPP could also use SASL along with TLS by defining a STARTTLS method for HTTP when used with IPP, and an AUTH EXTERNAL-like mechanism for HTTP. This would allow TLS to be negotiated on an open connection. HTTP's security is of course a real mess, given that HTTP is itself a lot of hacks glued together. And as you observe, SSL/TLS (which was designed with a very narrow view of HTTP in mind) doesn't really provide the flexibility needed to mutually authenticate clients and printers and effectively administer those credentials. My advice would be for IPP to specify TLS 1.0 for now, but to also make recommendations about additional features/flexibility needed in TLS 1.1. > We have started looking into this and are running into the following issues: > > 1) We have identified several scenarios where security is not needed and > where the overhead of security negotiation and mandatory support for > unnecessary security features is a useless extra burden. Here's a question: do you expect that people should be able to submit a print job without some prior arrangement -- say to set up a print queue on the client machine, or to install a "driver", or to exchange security credentials between client and IPP server? If no, then the "security negotiation" can be part of this "prior arrangement" -- e.g. the authentication method (though perhaps not the credentials) can be incorporated into the IPP URL that's given to the client. But if you want to be able to print with no prior arrangements, then you need to be able to negotiate different authentication and/or privacy algorithms. My guess is that you do expect to make prior arrangements before actually printing, so this isn't a problem. This is a contrast to the normal web browser / http server situation, where the necessity to make prior arrangements (i.e. to know whether to use http: or https:) means that users have to make decisions that they don't understand... and discourages use of security even where it is needed. > 2) TLS is not yet really stable and furthermore does not provide a lot of > security negotiation features. Agreed. But it's probably the best we have for now. > 3) SASL could potentially offer a better negotiation package, but does not > work well with TLS; actually according to recent discussions on the > security DLs, it seems that they are almost totally incompatible. SASL on > its own does not provide what we need. Last I knew, this had all been figured out. Use a STARTTLS method to push a TLS layer on top of an existing connection; HTTP could certainly do this. Then either use a special HTTP request header to indicate that the server should use authentication credentials from the TLS negotiation, or use some other kind of HTTP authentication header (basic or digest) over the TLS channel. (If the encryption were good enough, even basic authentication would be sufficient, but good luck getting the US goverment to grant permission to export it) I'm not sure which security DLs you're referring to, so I don't know whether they've identified new issues that would prevent this from working. > 4) It is also not clear how TLS and HTTP can be made to work together. Details need to be worked out, but I don't see any insurmountable barriers. > 5) In the Munich IPP meeting we stated that we thought this was really a > problem for HTTP, and that we could live with most any solution that worked > for HTTP. We are still of that opinion. Part of the problem is that HTTP and IPP really have different security needs. Authenticating clients and printers is very different than authenticating clients and web servers, at least for the scenarios for which SSL/TLS was desgined. Web browsers that use SSL typically do not authenticate the client at all; this would not be acceptable for a printer. Web servers that use SSL authenticate themselves to clients by having their keys signed by one of a few well-known CAs, but this doesn't scale very well to mass market printers. etc. > We are still digging around to see if we can come up with some half baked > solution that might approximately meet your requirements, but we recent the > idea that we have to develop a separate and special security solution for > IPP just because the appropriate security standardization projects are > still working on their specs. That's certainly not the intention, and we haven't done this with other protocols. The only requirement that has been imposed recently, is that you can't authenticate with plain text passwords. (believe me, we don't want APPS groups trying to design security protocols...) Keith   Received: from cnri by ietf.org id aa25627; 3 Sep 97 22: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 WAA01199 for ; Wed, 3 Sep 1997 22:23:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA19922 for ; Wed, 3 Sep 1997 22:20:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 22:16:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA19405 for ipp-outgoing; Wed, 3 Sep 1997 22:08:26 -0400 (EDT) Message-Id: <3.0.1.32.19970903185650.009af8c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 3 Sep 1997 18:56:50 PDT To: Keith Moore , Carl-Uno Manros From: Carl-Uno Manros Subject: IPP> Re: SEC - IPP Security Requirements Cc: Harald.T.Alvestrand@uninett.no, ipp@pwg.org, masinter@parc.xerox.com In-Reply-To: <199709040114.VAA28210@spot.cs.utk.edu> 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 Keith, thanks for the constructive advice that you have given us. I think that I might have interpreted your requirements as more strict than you actually intended to. As for scenarios where no security is needed: 1) Public printers that provide a similar service to fax machines today (with the calculated risk that you might get spammed). 2) Clients and servers that both sit behind the same firewall. Again thanks for your advice. Carl-Uno At 06:14 PM 9/3/97 PDT, Keith Moore wrote: >> I want to verify with you what I interpreted to be new additional security >> requirements from our Munich discussions: >> >> 1) You are expecting that every new IPP session starts up with a security >> negotiation. >> >> 2) You are expecting that every IPP Client and Printer has the capability >> to support more than the security defined by RFCs 2068 and 2069, e.g. >> features corresponding to SSL2 in TLS. > >We probably haven't fully articulated the requirements but, no, I don't >think the requirements are so severe. Rather, I'd say: > > >1) the security considerations section should analyze known attcks > and possible countermeasures > >2) if the protocol needs authentication (as IPP almost certainly does) > you need to provide better authentication than plain-text passwords. > >And offhand, I see several ways in which the requirement could be met: > >+ Since IPP is using HTTP/1.1, I would expect that digest access > authentication would pass the "no plain-text passwords" test. > This would meet the minimum authentication requirement, but shared > secrets don't scale very well. Nor can this be used to provide > confidentiality. Still, for a small printer that can't handle > large volumes anyway (and this wouldn't be expected to serve a > large user community), this might be just fine. > >+ IPP could be specified to *always* use TLS (and always on a port > assigned to IPP - no separate IPP/TLS port), but allow use of > the anonymous and/or NULL encryption ciphersuites for those cases > where authentication and/or privacy were not required. > >+ IPP could also use SASL along with TLS by defining a STARTTLS method > for HTTP when used with IPP, and an AUTH EXTERNAL-like mechanism for > HTTP. This would allow TLS to be negotiated on an open connection. > > >HTTP's security is of course a real mess, given that HTTP is itself >a lot of hacks glued together. And as you observe, SSL/TLS (which >was designed with a very narrow view of HTTP in mind) doesn't really >provide the flexibility needed to mutually authenticate clients >and printers and effectively administer those credentials. > >My advice would be for IPP to specify TLS 1.0 for now, but to also >make recommendations about additional features/flexibility needed >in TLS 1.1. > > >> We have started looking into this and are running into the following issues: >> >> 1) We have identified several scenarios where security is not needed and >> where the overhead of security negotiation and mandatory support for >> unnecessary security features is a useless extra burden. > >Here's a question: do you expect that people should be able to submit >a print job without some prior arrangement -- say to set up a print >queue on the client machine, or to install a "driver", or to exchange >security credentials between client and IPP server? > >If no, then the "security negotiation" can be part of this "prior >arrangement" -- e.g. the authentication method (though perhaps not >the credentials) can be incorporated into the IPP URL that's given >to the client. > >But if you want to be able to print with no prior arrangements, >then you need to be able to negotiate different authentication >and/or privacy algorithms. > >My guess is that you do expect to make prior arrangements before >actually printing, so this isn't a problem. This is a contrast >to the normal web browser / http server situation, where the necessity >to make prior arrangements (i.e. to know whether to use http: or >https:) means that users have to make decisions that they don't >understand... and discourages use of security even where >it is needed. > > >> 2) TLS is not yet really stable and furthermore does not provide a lot of >> security negotiation features. > >Agreed. But it's probably the best we have for now. > >> 3) SASL could potentially offer a better negotiation package, but does not >> work well with TLS; actually according to recent discussions on the >> security DLs, it seems that they are almost totally incompatible. SASL on >> its own does not provide what we need. > >Last I knew, this had all been figured out. Use a STARTTLS method >to push a TLS layer on top of an existing connection; HTTP could >certainly do this. Then either use a special HTTP request header to >indicate that the server should use authentication credentials from >the TLS negotiation, or use some other kind of HTTP authentication >header (basic or digest) over the TLS channel. (If the encryption >were good enough, even basic authentication would be sufficient, >but good luck getting the US goverment to grant permission to export it) > >I'm not sure which security DLs you're referring to, so I don't know >whether they've identified new issues that would prevent this from >working. > >> 4) It is also not clear how TLS and HTTP can be made to work together. > >Details need to be worked out, but I don't see any insurmountable >barriers. > >> 5) In the Munich IPP meeting we stated that we thought this was really a >> problem for HTTP, and that we could live with most any solution that worked >> for HTTP. We are still of that opinion. > >Part of the problem is that HTTP and IPP really have different security needs. >Authenticating clients and printers is very different than authenticating >clients and web servers, at least for the scenarios for which SSL/TLS >was desgined. Web browsers that use SSL typically do not authenticate the >client at all; this would not be acceptable for a printer. Web servers >that use SSL authenticate themselves to clients by having their keys signed >by one of a few well-known CAs, but this doesn't scale very well to mass >market printers. etc. > >> We are still digging around to see if we can come up with some half baked >> solution that might approximately meet your requirements, but we recent the >> idea that we have to develop a separate and special security solution for >> IPP just because the appropriate security standardization projects are >> still working on their specs. > >That's certainly not the intention, and we haven't done this with >other protocols. The only requirement that has been imposed recently, >is that you can't authenticate with plain text passwords. >(believe me, we don't want APPS groups trying to design security protocols...) > >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 aa27693; 3 Sep 97 22: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 XAA01237 for ; Wed, 3 Sep 1997 23:00:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA20529 for ; Wed, 3 Sep 1997 22:57:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Sep 1997 22:53:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA20039 for ipp-outgoing; Wed, 3 Sep 1997 22:44:53 -0400 (EDT) Message-Id: <199709040243.WAA28454@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , Harald.T.Alvestrand@uninett.no, ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> Re: SEC - IPP Security Requirements In-reply-to: Your message of "Wed, 03 Sep 1997 18:56:50 PDT." <3.0.1.32.19970903185650.009af8c0@garfield> Date: Wed, 03 Sep 1997 22:43:14 -0400 Sender: ipp-owner@pwg.org > thanks for the constructive advice that you have given us. I think that I > might have interpreted your requirements as more strict than you actually > intended to. I'm sorry if I wasn't clear in Munich. (I botched several things in that meeting -- must have been a bad day for me!) For the most part, it's up to the IPP working group to determine the minimum security needs for the IPP protocol -- and then to document the level of protection provided, threats, etc. in the security section. The group will need to establish some minimum security level -- what minimum degree of authentication and/or confidentiality should be required for all clients and/or servers (the two could be different), to ensure that all clients and servers can interoperate "out of the box", once they are given the necessary credentials, and with a degree of security that is appropriate for *most* (not just some) uses of the protocol. (The group could argue that the minimum security level is "none" for both clients and servers, but it would have to convince IESG that this is adequate for most installations....) Note that a implementation requiremnt is not a requirement of any particular installation -- any installation can disable authentication and/or require stronger authentication than the default, according to that installation's policy. Keith   Received: from cnri by ietf.org id aa10330; 4 Sep 97 11: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 LAA02435 for ; Thu, 4 Sep 1997 11:27:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22476 for ; Thu, 4 Sep 1997 11:24:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 11:18:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21961 for ipp-outgoing; Thu, 4 Sep 1997 11:10:31 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 04 Sep 1997 09:08:05 -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-970903-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970903-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970903.pdf There have been many changes, take the time to look through it. I would like to review this at the next teleconference. 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 aa10845; 4 Sep 97 11: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 LAA02542 for ; Thu, 4 Sep 1997 11:52:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23060 for ; Thu, 4 Sep 1997 11:49:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 11:46:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22579 for ipp-outgoing; Thu, 4 Sep 1997 11:37:54 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 04 Sep 1997 09:35:35 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - text version of new mod document posted Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I just posted a text version of the new model document. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970903.txt Happy ASCII reading. Scott   Received: from cnri by ietf.org id aa15985; 4 Sep 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 PAA03387 for ; Thu, 4 Sep 1997 15:44:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24457 for ; Thu, 4 Sep 1997 15:41:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 15:37:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23941 for ipp-outgoing; Thu, 4 Sep 1997 15:29:20 -0400 (EDT) Date: Thu, 4 Sep 1997 12:28:17 -0700 From: Robert Herriot Message-Id: <199709041928.MAA21538@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I just downloaded the latest version of the procotol document to ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO: The documents are: ipp-pro-970904-rev.doc (MS Word V6 with revisions) ipp-pro-970904.doc (MS Word V6 with no revisions) ipp-pro-970904.txt (text with no revisions) Tom will produce the PDF files. Bob Herriot   Received: from cnri by ietf.org id aa17062; 4 Sep 97 16: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 QAA03627 for ; Thu, 4 Sep 1997 16:35:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25081 for ; Thu, 4 Sep 1997 16:31:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 16:28:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24593 for ipp-outgoing; Thu, 4 Sep 1997 16:20:13 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES Phone conference info Date: Thu, 4 Sep 1997 13:22:38 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Sep4.131949pdt."52495(5)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, I have set up a phone conference for Tuesday September 9. The time is 1pm eastern. The number is 1-800-857-5608 (8*535-6000 for Xerox people). The passcode is 4858. Agenda to follow. Pete   Received: from cnri by ietf.org id aa18011; 4 Sep 97 17: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 RAA03867 for ; Thu, 4 Sep 1997 17:13:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25733 for ; Thu, 4 Sep 1997 17:09:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 17:04:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25245 for ipp-outgoing; Thu, 4 Sep 1997 16:56:36 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7036073A0@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> JobID in Win32 Date: Thu, 4 Sep 1997 13:53:59 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org Just to clarify what the JobID is used for in Windows. When a job is created in the spooler it is assigned a unique number that identifies it for its life time. This ID is returned when the job is created (depending on the API you use). It is safe to persist it. All APIs that get or set job attributes or state require this ID. It is also returned when you enumerate the jobs in a queue. Without this ID it will be very complex to build the client side so that it can be slotted into the Windows architecture. The way this would be done is via a 'print provider'. This is the plug-in component that services all the client-side Win32 print management APIs (EnumJobs, GetJob, Setjob, etc.) - the signature of these APIs is defined and imuttable. If we are unable to do this then none of the existing clients of these APIs will work, this includes the Windows shell itself.   Received: from cnri by ietf.org id aa18595; 4 Sep 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 RAA03977 for ; Thu, 4 Sep 1997 17:43:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26393 for ; Thu, 4 Sep 1997 17:40:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 17:36:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25871 for ipp-outgoing; Thu, 4 Sep 1997 17:28:24 -0400 (EDT) Date: Thu, 4 Sep 1997 14:27:25 -0700 From: Robert Herriot Message-Id: <199709042127.OAA21675@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I will try to explain why the Job-URI is harder to support than the Job-Id for an LPD gateway. I will also explain why the requirements that call for a Job-URI are not well enough understood to be requirements. ANALYSIS OF JOB-URI VS JOB-ID For the gateway, there are two directions: IPP-to-LPD and LPD-to-IPP. I have two goals for these gateways. They should 1) be stateless: which means that gateways get all their information from the downstream server rather than storing information about jobs in the gateway. 2) provide values to the client that are the same (possibly after a conversion algorithm) as the client could get from bypassing the gateway, which means gateways pass information without converting it or converting it in an algorithmic fashion that a client can apply an inverse function to. This provision is important because some applications on a client may use the gateway and others may bypass it. The Job-URI is hardest to support in the LPD-to-IPP direction because it fails to meet goal #1 above (it requires state). There is no simple way to algorithmically map the IPP Job-URI to an LPD Job-Id because the Job-URI is opaque. The Job-URI solution for both directions fails to meet goal #2 because it has the problem of exposing both Job-Ids and Job-URIs to a user for the same set of jobs and there is no conversion algorithm. Now for the two gateway directions for both Job-Id and Job-URI. First let's examine the IPP-to-LPD gateway where the gateway returns a Job-Id. The gateway creates the job-Id for LPD when it receives a Print-Job operation. It then returns the LPD job-Id to the IPP client as the value of the Job-Id. This Job-Id is the same one that Cancel-Job uses to specify the job to cancel. When a client performs Get-Jobs, the Job-Ids in the lpq reply to the gateway become the values of the Job-Id attribute in the Get-Jobs response. If the client sends an lpq directly to the printer, bypassing the gateway, it sees the same values for Job-Ids. Next, let's examine the IPP-to-LPD gateway where the gateway returns a Job-URI. The gateway creates the job-Id for LPD when it receives a Print-Job operation. It then returns to the IPP client the Job-URI which consists of the printer-URI and the LPD Job-Id. This Job-URI is the same one that Cancel-Job uses to specify the job to cancel. Because the gateway composed the Job-URI, it can parse it into the printer-URI and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq response to the gateway are composed with the printer-URI to form the value of each Job-URI in the Get-Jobs response. If the client sends an lpq directly to the printer, bypassing the gateway, it sees the job's Job-Ids rather than their Job-URIs. So the client gets different values for identifying the jobs and the client cannot convert between Job-URI values and Job-Id values because the rules for composing Job-URIs are not specified. Next, let's examine the LPD-to-IPP gateway where the gateway returns a Job-Id. The gateway client creates an job-Id which the gateway ignores because the IPP server creates its own Job-Id. Existing LPD servers sometimes ignore the Job-Id value requested by the client. LPD provides no mechanism for the gateway to inform the client of the Job-Id. The client must use the lpq command to get Job-Ids. When a client performs an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the values of the lpq response. This Job-Id from lpq is the same one that lprm command uses to specify the job to cancel. If the client sends a Get-Jobs directly to the printer, bypassing the gateway, it sees the same values for Job-Ids. Finally, let's examine the LPD-to-IPP gateway where the gateway returns a Job-URI. The gateway client creates a job-Id. The gateway either remembers this Job-Id or creates its own because the IPP server creates a Job-URI which has no direct relationship to the integer Job-Id required by LPD. When a client performs an lpq, the Job-URIs in the Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq response. When the gateway receives an lprm command, it must map the received Job-Id to the IPP Job-URI required for Cancel-Job. If the client sends a Get-Jobs directly to the printer, bypassing the gateway, it sees Job-URIs which have no relation to the Job-Id's that it sees via the gateway. There are two ways to handle the mapping. Either the gateway maintains its own internal table which it must update when jobs complete or it needs a scratch-pad attribute in the job where it can store the Job-Id. The latter case would require that servers not throw away unsupported attributes and a search of the mapping would require that the gateway perform a Get-Jobs. QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION Now that I have presented the problems that the Job-URI presents, I now would like to question its touted advantages. I have heard two. 1) It allows for redirection more easily 2) It allows for better load balancing I address both below and conclude that Job-URI's aren't necessary with our current understanding of requirements. I also wonder if Job-URIs that are unrelated to the Printer-URI containing the job will confuse users who are exposed to them. A user thinks of a job as belonging to a printer. So if a Job is identified by the Printer-URI that the user selected and some number, that seems to me like a simpler concept. REDIRECTION Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), either of these "names" references some host somewhere and when a job moves, that host has to keep track of where is has moved to, and when to delete the reference. It would seem to me that either Job-URI or (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even when they move. So either should suffice in this case and since Job-Id is easier for legacy connections, Job-Id is the better solution. In my opinion, the redirection of print jobs is a research area that is not well enough understood for us to be creating requirements for a standard. LOAD BALANCING The idea is that the Job-URI may reference a different host than the Printer-URI references so that references to the job don't load the print server. There may be other solutions, such as clustering of Web servers, which solve the problem without the added complexity of Job-URIs. This problem is way beyond the 80% solution we are striving for and is also a research area that is not well enough understood for us to be creating requirements for a standard.   Received: from cnri by ietf.org id aa19158; 4 Sep 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 SAA04115 for ; Thu, 4 Sep 1997 18:16:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27011 for ; Thu, 4 Sep 1997 18:13:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 18:09:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26513 for ipp-outgoing; Thu, 4 Sep 1997 18:01:02 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 04 Sep 1997 15:58:07 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD/PRO - Proposal to add 'dictionary' attribute syntax Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have read through Tom's proposal, and I like it. I plan to add it to the model document as is. I would also like to propose that "resolution" be modified to be of syntax type "dictionary". I am sure that there will be more comments, but I don't see why we can't do that just a component of the document itself, rather than a stand alone email message. I know this is on the agenda for next week, but I expect it to eventually go in the model doc. Scott >>> Tom Hastings 09/03 12:57 AM >>> Here is the action item that Roger and I had from the last meeting to propose explicit text for a 'dictionary' attribute to be added to the model and protocol documents. I've posted the .pdf and .doc files in: ftp://ftp.pwg.org/pub/pwg/new_MOD/ -rw-r--r-- 1 pwg pwg 24576 Sep 3 06:55 ipp-dict.doc -rw-r--r-- 1 pwg pwg 18152 Sep 3 06:56 ipp-dict.pdf -rw-r--r-- 1 pwg pwg 11511 Sep 3 06:56 ipp-dict.txt Attached is the .txt file as well (but the .pdf file is much easier to read, especially the long example). Also the .pdf file has line numbers and is four pages long. If possible, I'd like to discuss this proposal at the Wed, 9/3, IPP telecon. Tom Subj: Proposal for adding a 'dictionary' attribute syntax to IPP Model From: Tom Hastings and Roger deBry Date: 9/02/97, version 0.5 File: ipp-dict.doc 1. Problem Statement There is no good way to add attribute syntaxes that contain several fields, whether the fields are mandatory or optional. Instead of each new attribute that needs more than one field (struct), requiring an ad hoc attribute syntax, such as we have done for the 'resolution' attribute syntax for use in the "printer-resolution" attribute, it would be desirable to have a simple, general mechanism for representing multi-field values. It would also be desirable to allow fields to be omitted, when the attribute specification allows that. This mechanism would be useful for both new attributes that we might add to IPP standard, that might be registered, or that implementors might implement as private extensions. 2. Suggested solution Add a 'dictionary' attribute syntax, in which the attribute value is a set of attributes. Then each 'field' that is present in the attribute value would be self identifying by its attribute name. An attribute with an attribute syntax could be single valued ('dictionary'), i.e., with one dictionary value, or could be multi-valued ('1SetOf dictionary'). As with all attribute values, the dictionary value has a length of the entire value. If the dictionary attribute is multi-valued, as with any multi-valued attribute, each dictionary value has a length. Thus implementations that did not support the specified attribute could skip over the entire value to get to the next attribute (or to the next dictionary value, if the dictionary attribute is multi-valued). The syntax of each dictionary value is the same as a set of attributes, so each attribute has its keyword name, its attribute syntax code, and its value. An attribute in a dictionary can be single valued or multi-valued as well. For example, the new "printer-resolution" attribute was defined using a very ad hoc 'resolution' attribute syntax. Had we had the dictionary attribute syntax, we might have chosen to use it here, though we wouldn't have had to either. If we did use the 'dictionary' attribute syntax for the "printer-resolution", the attribute value would contain the following attributes: "cross-feed-resolution", "feed- resolution", "units". However, we can also keep resolution as it is, even if we add the 'dictionary' attribute syntax. As a second example, an attribute could represent the fields that the submitter wishes to be printed on the job-start page. The name of the attribute might be: "job-start-page- contents". The dictionary value might include: "job-name", "user-name", "job-comment", "account-name", etc. where the values of the attributes in the dictionary are printed after each attribute name on the job-start-page. As a third example, an attribute could represent a person's address using a dictionary that contains the following attributes where each attribute has a simple 'text' attribute syntax: "addressee-name" required "company-name" optional "internal-mail-stop" optional "apartment-number optional "street-address" required "city-or-town required "state" required "postal-zone required "country" optional "phone-numbers optional The "address" attribute could be specified to be single- valued ('dictionary'), or could be multi-valued ('1setOf dictionary'). Also the specification for the "address" attribute could require that the constituent attributes be in the above order or that they could be in any order. For this example, it would make sense for the specification of the "address" attribute to require that the dictionary be ordered, with only the optional attributes being permitted to be omitted. It seems unnecessary to consider ordered and unordered dictionaries as separate attribute syntaxes. Some attribute specifications might allow additional attributes to be included (open-ended) and other attribute specifications might specify that only the attributes specified in the standard or registration may be used in the dictionary value (closed-ended). As a fourth example, a dictionary attribute syntax would be a much better way for the Printer to represent its capabilities, rather than the ad hoc naming conventions: "xxx" Printer attribute to represent default and the "xxx- supported" Printer attribute to represent the supported values. So the client would request the "xxx" attribute of the Printer and get back the "xxx" attribute whose dictionary values would be the "default" and "supported- values" attributes whose values would indicate the default and supported values, respectively of the "xxx" job template attribute. Adding additional attributes to indicate future capabilities, such as "ready-values", "multi-valued", etc. could be done by adding additional attributes in the dictionary value that is returned. 3. Suggested Text Add to section 4.1 Attribute Syntaxes of the IPP Model specification: dictionary: a set or sequence of attributes, where each attribute MAY be single-valued or multi-valued as specified for the dictionary attribute. As in the attribute sets that are passed in operations, no attribute SHALL occur more than once in a dictionary. However, if the same attribute does occur more than once in a dictionary, the recipient SHALL use the later occuring one, ignoring any earlier occurrences of the same attribute. The specification of the attribute that uses the 'dictionary' attribute syntax SHALL specify: 1. as with any attribute, whether the attribute is single- valued (attribute syntax = 'dictionary) or multi-valued (attribute-syntax = '1SetOf dictionary'). 2. whether the attributes in the dictionary value are ordered or unordered. 3. for each attribute in the dictionary value, whether the attribute's presence is required or optional. 4. for each attribute permitted in the dictionary value, the completed specification of that attribute shall be included or inferred by reference to the specification of that attribute elsewhere. 5. whether additional attributes not specified with the dictionary attribute specification may be included (open- ended) in a dictionary value or not (closed-ended). For open-ended dictionary attributes, there MAY be some requirements on what kind of attributes may be included, including restrictions on attribute syntaxes. A dictionary may contain another dictionary, if the specification of the dictionary attribute allows. Add to section 9, Appendix A: Protocol Examples of the IPP Protocol specification 9.2 Print-Job Request with an "address" dictionary attribute, including two address dictionary values and two phone numbers in the first address dictionary value. Octets Symbolic Protocol comments Value field 0x0100 1.0 version 0x0002 PrintJob operation 0x02 start attribute attributes tag 0x42 name type value-tag "job-name" attribute 0x0008 name- length job-name job-name name 0x0006 value- length foobar foobar value 0x?? dictionary value-tag "addresses" type attribute 0x0007 name- length address address name 0x009c value- 156 octets in 1st length dict value 0x41 text type value-tag start of 1st dictionary value 0x000e name- length addressee- addressee- name "addresses-name" name name attribute 0x0009 value- length Tom Jones Tom Jones value 0x41 text type value-tag "street-address" attribute 0x000e name- length street- street- name address address 0x000c value- length 100 Main St. 100 Main value St. 0x41 text type value-tag "city-or-town" attribute 0x000c name- length city-or-town city-or- name town 0x0008 value- length New York New York value 0x41 text type value-tag "state" attribute 0x0005 name- length state state name 0x0002 value- length NY NY value 0x41 text type value-tag "postal-zone" attribute 0x000b name- length postal-zone postal-zone name 0x0005 value- length 10200 10200 value 0x41 text type value-tag "phone-numbers" attribute 0x000d name- length phone- phone- name numbers numbers 0x08 value- length 312-1234 312-1234 value 0x41 text type value-tag start of 2nd phone-numbers value 0x0000 name- 0 length means length next multiple value 0x0008 value- length 372-8432 372-8432 value end of 1st dictionary value 0x?? dictionary- value-tag start of 2nd type dictionary value 0x0000 name- 0 length mean length next multple value 0xnnnn 0xnnnn value- nnnn octets in 2nd length dict value 0x41 text type value-tag start of 2nd dictionary value 0x000e name- length addressee- addressee- name "addresses-name" name name attribute 0x000a value- length Bill Smith Bill Smith value ... nnnn octets of the next dict value 0x03 start-data data-tag %!PS...   Received: from cnri by ietf.org id aa22389; 4 Sep 97 21: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 VAA04531 for ; Thu, 4 Sep 1997 21:48:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA27932 for ; Thu, 4 Sep 1997 21:45:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Sep 1997 21:41:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27408 for ipp-outgoing; Thu, 4 Sep 1997 21:33:20 -0400 (EDT) Date: Thu, 4 Sep 1997 18:31:46 -0700 From: Robert Herriot Message-Id: <199709050131.SAA22043@woden.eng.sun.com> To: papowell@astart.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From papowell@astart.com Thu Sep 4 17:52:06 1997 > > Umm... you are assuming that the LPD gateway would need to use > job numbers? I just checked the RFC1179 and it appears that > the term 'number' is really 'identifier'. Thus the URI could be > the identifier. Now classically we have been using the > "numerical portion of the control/data identifier" as the job number. Yes, I am assuming a gateway which talks to REAL LPD print systems, which all use integer identifiers. I don't believe I need to plan for hypothetical RFC1179 gateways which might use something else.   Received: from cnri by ietf.org id aa01690; 5 Sep 97 0: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 AAA04779 for ; Fri, 5 Sep 1997 00:09:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA28776 for ; Fri, 5 Sep 1997 00:06:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 00:01:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA28266 for ipp-outgoing; Thu, 4 Sep 1997 23:53:21 -0400 (EDT) Message-ID: <340F821E.38BE9F60@underscore.com> Date: Thu, 04 Sep 1997 23:53:02 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709042127.OAA21675@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob, Thanks for the rebuttal info on this issue. You continually point out this basic desire/premise/goal: IPP job id == LPD job id You gave lots of good examples, paying particular attention to exposure issues with end users. In fact, my reading of your message makes me come away believing that consistent end user visibility is extremely high on the priority list...maybe even #1. This may be. (I'm not sure, myself.) However, if the exposure of job ids is so critical, then why don't we also insist on: IPP printer name == LPD printer name I've been assuming all along that an IPP printer name would appear to an end user as something like: http://host.domain/printer/ (Or any one of five bazillion permutations on the URL theme.) However, in LPD land, a "printer" is almost always a "simple" name, such as: laser1, plot3, mkt, lp3, etc. Simple sequences of just letters and numbers (usually), with possibly a sprinking of hyphens, underscores, etc. However, almost never is the name constructed as a series of sub-tokens assembled in a hierarchical fashion. (Sure, it can be done...but it just *isn't* commonly done in real practice.) Aren't you concerned with that kind of shift in visibility, too? Of course, one can always assume some sort of standard (de facto) mapping mechanism, whereby the "simple" name is always the last token of the URL string: http:://host.domain/printer/laser1 == laser1 If this is good enough, then why can't the same be true for job ids, eg: http://somewhere.net.domain/subsys/server3/345 == 345 If nothing else, then such a simple job id mapping mechanism can be standardized for IPP "printers" front-ending LPD queues. Even in the non-LPD case, this kind of job identification looks pretty clean: http:://host.domain/printer/laser1/345 This kind of approach looks real clean to me, but maybe I'm just a bit too close to the code, if you know what I mean. I must be missing something, right? Thanks for your insights. ...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 -- ---------------------------------------------------------------------- Robert Herriot wrote: > > I will try to explain why the Job-URI is harder to support than the > Job-Id for an LPD gateway. I will also explain why the requirements > that call for a Job-URI are not well enough understood to be > requirements. > > ANALYSIS OF JOB-URI VS JOB-ID > > For the gateway, there are two directions: IPP-to-LPD and LPD-to-IPP. > > I have two goals for these gateways. They should > 1) be stateless: which means that gateways get all their information > from the downstream server rather than storing information about > jobs in the gateway. > 2) provide values to the client that are the same (possibly after a > conversion algorithm) as the client could get from bypassing the > gateway, which means gateways pass information without converting > it or converting it in an algorithmic fashion that a client can > apply an inverse function to. This provision is important because > some applications on a client may use the gateway and others may > bypass it. > > The Job-URI is hardest to support in the LPD-to-IPP direction because > it fails to meet goal #1 above (it requires state). There is no simple > way to algorithmically map the IPP Job-URI to an LPD Job-Id because the > Job-URI is opaque. > > The Job-URI solution for both directions fails to meet goal #2 because > it has the problem of exposing both Job-Ids and Job-URIs to a user for > the same set of jobs and there is no conversion algorithm. > > Now for the two gateway directions for both Job-Id and Job-URI. > > First let's examine the IPP-to-LPD gateway where the gateway returns a > Job-Id. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns the LPD job-Id to the IPP client > as the value of the Job-Id. This Job-Id is the same one that Cancel-Job > uses to specify the job to cancel. When a client performs Get-Jobs, > the Job-Ids in the lpq reply to the gateway become the values of the > Job-Id attribute in the Get-Jobs response. If the client sends an lpq > directly to the printer, bypassing the gateway, it sees the same > values for Job-Ids. > > Next, let's examine the IPP-to-LPD gateway where the gateway returns a > Job-URI. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns to the IPP client the Job-URI > which consists of the printer-URI and the LPD Job-Id. This Job-URI is > the same one that Cancel-Job uses to specify the job to cancel. Because > the gateway composed the Job-URI, it can parse it into the printer-URI > and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq > response to the gateway are composed with the printer-URI to form the > value of each Job-URI in the Get-Jobs response. If the client sends an > lpq directly to the printer, bypassing the gateway, it sees the job's > Job-Ids rather than their Job-URIs. So the client gets different values > for identifying the jobs and the client cannot convert between Job-URI > values and Job-Id values because the rules for composing Job-URIs are > not specified. > > Next, let's examine the LPD-to-IPP gateway where the gateway returns a > Job-Id. The gateway client creates an job-Id which the gateway ignores > because the IPP server creates its own Job-Id. Existing LPD servers > sometimes ignore the Job-Id value requested by the client. LPD provides no > mechanism for the gateway to inform the client of the Job-Id. The > client must use the lpq command to get Job-Ids. When a client performs > an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the > values of the lpq response. This Job-Id from lpq is the same one that lprm > command uses to specify the job to cancel. If the client sends a > Get-Jobs directly to the printer, bypassing the gateway, it sees the > same values for Job-Ids. > > Finally, let's examine the LPD-to-IPP gateway where the gateway returns > a Job-URI. The gateway client creates a job-Id. The gateway either > remembers this Job-Id or creates its own because the IPP server creates > a Job-URI which has no direct relationship to the integer Job-Id > required by LPD. When a client performs an lpq, the Job-URIs in the > Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq > response. When the gateway receives an lprm command, it must map the > received Job-Id to the IPP Job-URI required for Cancel-Job. If the > client sends a Get-Jobs directly to the printer, bypassing the gateway, > it sees Job-URIs which have no relation to the Job-Id's that it sees via > the gateway. There are two ways to handle the mapping. Either the > gateway maintains its own internal table which it must update when jobs > complete or it needs a scratch-pad attribute in the job where it can store > the Job-Id. The latter case would require that servers not throw away > unsupported attributes and a search of the mapping would require that the > gateway perform a Get-Jobs. > > QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION > > Now that I have presented the problems that the Job-URI presents, I > now would like to question its touted advantages. I have heard two. > > 1) It allows for redirection more easily > 2) It allows for better load balancing > > I address both below and conclude that Job-URI's aren't necessary with > our current understanding of requirements. > > I also wonder if Job-URIs that are unrelated to the Printer-URI > containing the job will confuse users who are exposed to them. A user > thinks of a job as belonging to a printer. So if a Job is identified by > the Printer-URI that the user selected and some number, that seems to > me like a simpler concept. > > REDIRECTION > > Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), > either of these "names" references some host somewhere and when a job > moves, that host has to keep track of where is has moved to, and when > to delete the reference. It would seem to me that either Job-URI or > (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even > when they move. So either should suffice in this case and since Job-Id > is easier for legacy connections, Job-Id is the better solution. > > In my opinion, the redirection of print jobs is a research area > that is not well enough understood for us to be creating requirements > for a standard. > > LOAD BALANCING > > The idea is that the Job-URI may reference a different host than the > Printer-URI references so that references to the job don't load the > print server. > > There may be other solutions, such as clustering of Web servers, which > solve the problem without the added complexity of Job-URIs. > > This problem is way beyond the 80% solution we are striving for and is > also a research area that is not well enough understood for us to be > creating requirements for a standard. > > >   Received: from cnri by ietf.org id aa02438; 5 Sep 97 4: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 EAA05104 for ; Fri, 5 Sep 1997 04:31:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA29825 for ; Fri, 5 Sep 1997 04:28:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 04:23:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA29345 for ipp-outgoing; Fri, 5 Sep 1997 04:15:45 -0400 (EDT) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: Keith Moore , ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> Re: SEC - IPP Security Requirements In-reply-to: Your message of "Wed, 03 Sep 1997 18:56:50 PDT." <3.0.1.32.19970903185650.009af8c0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 1997 20:26:28 +0200 Message-ID: <28287.873397588@dale.uninett.no> Sender: ipp-owner@pwg.org Keith is doing fine..... two things: 1) IPP has to ANALYZE risks of using IPP on the open Internet (NOT behind firewalls or in "spammable" environments) IPP must then DEFINE how a reasonable number of these risks can be defended against using security mechanisms, and REQUIRE that valid IPP implementations implement at least a minimum set of these The USER of an IPP device can then decide to use or not to use those security mechanisms. 2) I'd like you to tell me which security lists are discussing SASL; it seems that the list set up to discuss SASL is either totally dead or I've fallen off it. We need to know! Thanks for your help! Harald A   Received: from cnri by ietf.org id aa09786; 5 Sep 97 9: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 JAA05580 for ; Fri, 5 Sep 1997 09:26:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA00672 for ; Fri, 5 Sep 1997 09:23:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 09:14:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA00119 for ipp-outgoing; Fri, 5 Sep 1997 09:06: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 Why use Job-Id instead of Job-URI for Jobs? Message-Id: <5030100007685982000002L022*@MHS> Date: Fri, 5 Sep 1997 09:06:54 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I agree with Jay that this seems like a clean approach. However, if I've understood all of the arguments, I thought that dictating the form of the URL was a no-no. On the other hand, if a PARTICULAR IMPLEMENTATION, such as NT, requires a 32-bit integer job ID to be consistent with its existing APIs, then there should be no reason why THAT implementation could not use the approach that Jay suggests to easily map to an internal integer job identifier. I know that this may not solve the problem for a gateway somwhere in the middle, but it does seem to me that for a particular server implementation this works fairly well. Roger K deBry Senior Technical 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 09/05/97 06:56 AM --------------------------- ipp-owner @ pwg.org 09/04/97 10:06 PM Please respond to ipp-owner@pwg.org @ internet To: Robert.Herriot @ Eng.Sun.COM @ internet cc: ipp @ pwg.org @ internet Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Bob, Thanks for the rebuttal info on this issue. You continually point out this basic desire/premise/goal: IPP job id == LPD job id You gave lots of good examples, paying particular attention to exposure issues with end users. In fact, my reading of your message makes me come away believing that consistent end user visibility is extremely high on the priority list...maybe even #1. This may be. (I'm not sure, myself.) However, if the exposure of job ids is so critical, then why don't we also insist on: IPP printer name == LPD printer name I've been assuming all along that an IPP printer name would appear to an end user as something like: http://host.domain/printer/ (Or any one of five bazillion permutations on the URL theme.) However, in LPD land, a "printer" is almost always a "simple" name, such as: laser1, plot3, mkt, lp3, etc. Simple sequences of just letters and numbers (usually), with possibly a sprinking of hyphens, underscores, etc. However, almost never is the name constructed as a series of sub-tokens assembled in a hierarchical fashion. (Sure, it can be done...but it just *isn't* commonly done in real practice.) Aren't you concerned with that kind of shift in visibility, too? Of course, one can always assume some sort of standard (de facto) mapping mechanism, whereby the "simple" name is always the last token of the URL string: http:://host.domain/printer/laser1 == laser1 If this is good enough, then why can't the same be true for job ids, eg: http://somewhere.net.domain/subsys/server3/345 == 345 If nothing else, then such a simple job id mapping mechanism can be standardized for IPP "printers" front-ending LPD queues. Even in the non-LPD case, this kind of job identification looks pretty clean: http:://host.domain/printer/laser1/345 This kind of approach looks real clean to me, but maybe I'm just a bit too close to the code, if you know what I mean. I must be missing something, right? Thanks for your insights. ...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 -- ---------------------------------------------------------------------- Robert Herriot wrote: > > I will try to explain why the Job-URI is harder to support than the > Job-Id for an LPD gateway. I will also explain why the requirements > that call for a Job-URI are not well enough understood to be > requirements. > > ANALYSIS OF JOB-URI VS JOB-ID > > For the gateway, there are two directions: IPP-to-LPD and LPD-to-IPP. > > I have two goals for these gateways. They should > 1) be stateless: which means that gateways get all their information > from the downstream server rather than storing information about > jobs in the gateway. > 2) provide values to the client that are the same (possibly after a > conversion algorithm) as the client could get from bypassing the > gateway, which means gateways pass information without converting > it or converting it in an algorithmic fashion that a client can > apply an inverse function to. This provision is important because > some applications on a client may use the gateway and others may > bypass it. > > The Job-URI is hardest to support in the LPD-to-IPP direction because > it fails to meet goal #1 above (it requires state). There is no simple > way to algorithmically map the IPP Job-URI to an LPD Job-Id because the > Job-URI is opaque. > > The Job-URI solution for both directions fails to meet goal #2 because > it has the problem of exposing both Job-Ids and Job-URIs to a user for > the same set of jobs and there is no conversion algorithm. > > Now for the two gateway directions for both Job-Id and Job-URI. > > First let's examine the IPP-to-LPD gateway where the gateway returns a > Job-Id. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns the LPD job-Id to the IPP client > as the value of the Job-Id. This Job-Id is the same one that Cancel-Job > uses to specify the job to cancel. When a client performs Get-Jobs, > the Job-Ids in the lpq reply to the gateway become the values of the > Job-Id attribute in the Get-Jobs response. If the client sends an lpq > directly to the printer, bypassing the gateway, it sees the same > values for Job-Ids. > > Next, let's examine the IPP-to-LPD gateway where the gateway returns a > Job-URI. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns to the IPP client the Job-URI > which consists of the printer-URI and the LPD Job-Id. This Job-URI is > the same one that Cancel-Job uses to specify the job to cancel. Because > the gateway composed the Job-URI, it can parse it into the printer-URI > and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq > response to the gateway are composed with the printer-URI to form the > value of each Job-URI in the Get-Jobs response. If the client sends an > lpq directly to the printer, bypassing the gateway, it sees the job's > Job-Ids rather than their Job-URIs. So the client gets different values > for identifying the jobs and the client cannot convert between Job-URI > values and Job-Id values because the rules for composing Job-URIs are > not specified. > > Next, let's examine the LPD-to-IPP gateway where the gateway returns a > Job-Id. The gateway client creates an job-Id which the gateway ignores > because the IPP server creates its own Job-Id. Existing LPD servers > sometimes ignore the Job-Id value requested by the client. LPD provides no > mechanism for the gateway to inform the client of the Job-Id. The > client must use the lpq command to get Job-Ids. When a client performs > an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the > values of the lpq response. This Job-Id from lpq is the same one that lprm > command uses to specify the job to cancel. If the client sends a > Get-Jobs directly to the printer, bypassing the gateway, it sees the > same values for Job-Ids. > > Finally, let's examine the LPD-to-IPP gateway where the gateway returns > a Job-URI. The gateway client creates a job-Id. The gateway either > remembers this Job-Id or creates its own because the IPP server creates > a Job-URI which has no direct relationship to the integer Job-Id > required by LPD. When a client performs an lpq, the Job-URIs in the > Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq > response. When the gateway receives an lprm command, it must map the > received Job-Id to the IPP Job-URI required for Cancel-Job. If the > client sends a Get-Jobs directly to the printer, bypassing the gateway, > it sees Job-URIs which have no relation to the Job-Id's that it sees via > the gateway. There are two ways to handle the mapping. Either the > gateway maintains its own internal table which it must update when jobs > complete or it needs a scratch-pad attribute in the job where it can store > the Job-Id. The latter case would require that servers not throw away > unsupported attributes and a search of the mapping would require that the > gateway perform a Get-Jobs. > > QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION > > Now that I have presented the problems that the Job-URI presents, I > now would like to question its touted advantages. I have heard two. > > 1) It allows for redirection more easily > 2) It allows for better load balancing > > I address both below and conclude that Job-URI's aren't necessary with > our current understanding of requirements. > > I also wonder if Job-URIs that are unrelated to the Printer-URI > containing the job will confuse users who are exposed to them. A user > thinks of a job as belonging to a printer. So if a Job is identified by > the Printer-URI that the user selected and some number, that seems to > me like a simpler concept. > > REDIRECTION > > Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), > either of these "names" references some host somewhere and when a job > moves, that host has to keep track of where is has moved to, and when > to delete the reference. It would seem to me that either Job-URI or > (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even > when they move. So either should suffice in this case and since Job-Id > is easier for legacy connections, Job-Id is the better solution. > > In my opinion, the redirection of print jobs is a research area > that is not well enough understood for us to be creating requirements > for a standard. > > LOAD BALANCING > > The idea is that the Job-URI may reference a different host than the > Printer-URI references so that references to the job don't load the > print server. > > There may be other solutions, such as clustering of Web servers, which > solve the problem without the added complexity of Job-URIs. > > This problem is way beyond the 80% solution we are striving for and is > also a research area that is not well enough understood for us to be > creating requirements for a standard. > > >   Received: from cnri by ietf.org id aa11961; 5 Sep 97 10: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 KAA05863 for ; Fri, 5 Sep 1997 10:44:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA01329 for ; Fri, 5 Sep 1997 10:41:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 10:37:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00817 for ipp-outgoing; Fri, 5 Sep 1997 10:28:59 -0400 (EDT) Message-Id: <1.5.4.32.19970905142551.00673e24@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: Fri, 05 Sep 1997 07:25:51 -0700 To: Harald.T.Alvestrand@uninett.no, Carl-Uno Manros From: Carl-Uno Manros Subject: Re: IPP> Re: SEC - IPP Security Requirements Cc: Keith Moore , ipp@pwg.org, masinter@parc.xerox.com Sender: ipp-owner@pwg.org At 08:26 PM 9/4/97 +0200, Harald.T.Alvestrand@uninett.no wrote: >Keith is doing fine..... > >two things: > >1) IPP has to ANALYZE risks of using IPP on the open Internet (NOT behind > firewalls or in "spammable" environments) Done that already! > > IPP must then DEFINE how a reasonable number of these risks can be defended > against using security mechanisms, and REQUIRE that valid IPP >implementations > implement at least a minimum set of these > This is where we need to firm up on our design. > The USER of an IPP device can then decide to use or not to use those > security mechanisms. > Yep. Question is only how - by negotiation outside the security protocols? >2) I'd like you to tell me which security lists are discussing SASL; it > seems that the list set up to discuss SASL is either totally dead or > I've fallen off it. We need to know! > Check the TLS list for the last couple of weeks. >Thanks for your help! > > Harald A > Regards, Carl-Uno   Received: from cnri by ietf.org id aa13072; 5 Sep 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 LAA06060 for ; Fri, 5 Sep 1997 11:31:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA01983 for ; Fri, 5 Sep 1997 11:28:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 11:21:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01468 for ipp-outgoing; Fri, 5 Sep 1997 11:11:02 -0400 (EDT) Date: Fri, 5 Sep 1997 08:12:31 -0700 (PDT) From: papowell@astart.com Message-Id: <199709051512.IAA01592@astart2.astart.com> To: jkm@underscore.com, Robert.Herriot@eng.sun.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org > Of course, one can always assume some sort of standard (de facto) > mapping mechanism, whereby the "simple" name is always the last token > of the URL string: > > http:://host.domain/printer/laser1 == laser1 > > If this is good enough, then why can't the same be true for job > ids, eg: > > http://somewhere.net.domain/subsys/server3/345 == 345 > > If nothing else, then such a simple job id mapping mechanism can be > standardized for IPP "printers" front-ending LPD queues. Even in the > non-LPD case, this kind of job identification looks pretty clean: > > http:://host.domain/printer/laser1/345 > > This kind of approach looks real clean to me, but maybe I'm just a > bit too close to the code, if you know what I mean. > > I must be missing something, right? Thanks for your insights. > > ...jay This looks like the right way to handle this. If you want to have control, then you will have to enforce this in the specification. I would suggest that you restrict the 'printer name' to 32 characters, and the job number to a value represented by a 32 bit number. Patrick Powell   Received: from cnri by ietf.org id aa13213; 5 Sep 97 11: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 LAA06102 for ; Fri, 5 Sep 1997 11:37:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA02537 for ; Fri, 5 Sep 1997 11:34:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 11:30:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01486 for ipp-outgoing; Fri, 5 Sep 1997 11:17: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>MOD Why use Job-Id instead of Job-URI for Jobs? Message-Id: <5030100007694047000002L072*@MHS> Date: Fri, 5 Sep 1997 11:18:16 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Bob, can you clarify a few things for me please? It would help me understand your write-up. My questions noted with First let's examine the IPP-to-LPD gateway where the gateway returns a Job-Id. The gateway creates the job-Id for LPD when it receives a Print-Job operation. It then returns the LPD job-Id to the IPP client as the value of the Job-Id. This Job-Id is the same one that Cancel-Job uses to specify the job to cancel. When a client performs Get-Jobs, the Job-Ids in the lpq reply to the gateway become the values of the Job-Id attribute in the Get-Jobs response. If the client sends an lpq directly to the printer, bypassing the gateway, it sees the same values for Job-Ids. Why would the IPP client bypass the gateway and send an lpq directly to the printer? It seems to me that an IPP client would always use IPP. Are you describing a pathological case here? Why would an IPP client (or and end user for that matter) even suspect that the real printer would even understand lpq? Next, let's examine the IPP-to-LPD gateway where the gateway returns a Job-URI. The gateway creates the job-Id for LPD when it receives a Print-Job operation. It then returns to the IPP client the Job-URI which consists of the printer-URI and the LPD Job-Id. This Job-URI is the same one that Cancel-Job uses to specify the job to cancel. Because the gateway composed the Job-URI, it can parse it into the printer-URI and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq response to the gateway are composed with the printer-URI to form the value of each Job-URI in the Get-Jobs response. If the client sends an lpq directly to the printer, bypassing the gateway, it sees the job's Job-Ids rather than their Job-URIs. So the client gets different values for identifying the jobs and the client cannot convert between Job-URI values and Job-Id values because the rules for composing Job-URIs are not specified. ditto the above question. Next, let's examine the LPD-to-IPP gateway where the gateway returns a Job-Id. The gateway client creates an job-Id which the gateway ignores because the IPP server creates its own Job-Id. Existing LPD servers sometimes ignore the Job-Id value requested by the client. LPD provides no mechanism for the gateway to inform the client of the Job-Id. The following is to clarify normal lpr/lpd operation ... So, an lpr request always generates a job-id on the client, but sometimes it gets ignored (I assume then that the server assigns the job-id. But there is no way for the server to tell the client what id it assigned. Did I get it right? How does the client know whether or not the id it assigned is valid? What happens if it cnacels the job with the client assigned id? Does it get told that the id is invalid? This seems pretty flaky to me. The client must use the lpq command to get Job-Ids. When a client performs an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the values of the lpq response. This Job-Id from lpq is the same one that lprm command uses to specify the job to cancel. If the client sends a Get-Jobs directly to the printer, bypassing the gateway, it sees the same values for Job-Ids. Again, I don't understand this mixed mode of operation. Why would an lpr client assume that the printer on the other end would understand IPP? For that matter, why would the client speak IPP? For that matter, if it did speak IPP, why would it need a gateway? Finally, let's examine the LPD-to-IPP gateway where the gateway returns a Job-URI. The gateway client creates a job-Id. The gateway either remembers this Job-Id or creates its own because the IPP server creates a Job-URI which has no direct relationship to the integer Job-Id required by LPD. In the previous case, it sounded like the client could never depend on the job id it assigned anyway. Why does it do so here? Why doesn't the gateway ignore the client assigned id as in the previous case, and force the client to do an lpq? When a client performs an lpq, the Job-URIs in the Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq response. When the gateway receives an lprm command, it must map the received Job-Id to the IPP Job-URI required for Cancel-Job. If the client sends a Get-Jobs directly to the printer, bypassing the gateway, it sees Job-URIs which have no relation to the Job-Id's that it sees via the gateway. Once again I question why a client would operate in this mixed mode. Why would an lpr client EVER use an IPP Get-Jobs??? There are two ways to handle the mapping. Either the gateway maintains its own internal table which it must update when jobs complete or it needs a scratch-pad attribute in the job where it can store the Job-Id. The latter case would require that servers not throw away unsupported attributes and a search of the mapping would require that the gateway perform a Get-Jobs. QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION Now that I have presented the problems that the Job-URI presents, I now would like to question its touted advantages. I have heard two. 1) It allows for redirection more easily 2) It allows for better load balancing I address both below and conclude that Job-URI's aren't necessary with our current understanding of requirements. I also wonder if Job-URIs that are unrelated to the Printer-URI containing the job will confuse users who are exposed to them. A user thinks of a job as belonging to a printer. So if a Job is identified by the Printer-URI that the user selected and some number, that seems to me like a simpler concept. Actually, I NEVER think of the job as belonging to the printer. Most of the shared printers we use here in IBM are in printer pools. I never know which one it will print on. I think of my job as an object that (hopefully) the system knows how to handle. When I cancel or query a job, I tell the client, and let it worry about everything from there on. As a user I don't care. REDIRECTION Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), either of these "names" references some host somewhere and when a job moves, that host has to keep track of where is has moved to, and when to delete the reference. It would seem to me that either Job-URI or (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even when they move. So either should suffice in this case and since Job-Id is easier for legacy connections, Job-Id is the better solution. Certainly you can remember either a URI or a job-id. I think Randy's point was that using a URI, HTTP provides an easy way to do redirection. Using a job-id, we would have to invent a scheme that was IPP specific. In my opinion, the redirection of print jobs is a research area that is not well enough understood for us to be creating requirements for a standard. Why don't you think it is well understood? LOAD BALANCING The idea is that the Job-URI may reference a different host than the Printer-URI references so that references to the job don't load the print server. There may be other solutions, such as clustering of Web servers, which solve the problem without the added complexity of Job-URIs. This problem is way beyond the 80% solution we are striving for and is also a research area that is not well enough understood for us to be creating requirements for a standard. One last question ... if we take the course of adopting a job-id, how do we rationalize the notion of the job being an object? In my mind, the only object we are left with is the printer object, because now all operations are on the printer. For example, we no longer provide the URI of the job and tell it to cancel itself. We send the operation to the printer and tell it to cancel the job. Ditto for querying job attributes. The operation goes to the printer. In my mind, this very fundamental change forever dictates the way IPP will deal with jobs. If we ever want to imagine the job as a real object with a life of its own, that can be moved around the network (whether it be for load balancing, recovery, etc.), queried, cancelled, indepdendent of where it lives, then we ought not to bind it now to a printer and lose it's identity as an object. I think that Jay's suggestion to allow an implementation to create job URI's by cleverly using the integer job id's currently supported by existing system API's is a fine way to solve the problem for most cases. The standard doesn't require URLs to be created that way, but neither should it dis-allow it if it makes life easier for a particular implementation. does it   Received: from cnri by ietf.org id aa14894; 5 Sep 97 12: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 MAA06382 for ; Fri, 5 Sep 1997 12:47:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA03232 for ; Fri, 5 Sep 1997 12:44:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 12:40:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02745 for ipp-outgoing; Fri, 5 Sep 1997 12:32:27 -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-sheet-content attribute Message-Id: <5030100007699359000002L092*@MHS> Date: Fri, 5 Sep 1997 12:33:04 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org At the last PWG meeting, I suggested the definition of a new attribute, based on the proposed dictionary attribute, to allow an admisnistrator to collect end-user suuplied information to be printed on a job-sheet. I was asked to generate a formal write-up. Here it is: Job-Sheet-Content attribute Problem Statement Today the model document allows the end user to select whether or not a job sheet should be printed, but there is no mechanism for a user to specify what should be printed on the job sheet. In many cases, an administrator will establish the content of the job sheet, using information that comes from the print job request itself, such as job-name, or job-originating-user. However, these values are somewhat limited, and an administrator may want to use other information not available as a standard job attribute. Suggested Solution Using the proposed dictionary attribute (Hastings-deBry proposal), provide a means for the administrator to collect additional job-sheet information. This could incidentally be used for other purposes, such as accounting. This would be done with a new job template attributes called "Job-Sheet-Content". To help the client, each field to be printed on the job sheet is represented by a pair of attributes: 1. The first attribute in the pair is of the form "prompt-n", where n is a digit starting with 1. 2. The second attribute is of the form "prompt-n-response". This attribute provides a means for an administrator to collect additional user information to be printed on a job sheet. There is no standard set of semantics associated with the text data supplied by the administrator or the end user. Text is assumed to be in the language of the end-user. ISSUE: How does one associate the end-user's language with a set of text dictionary attributes? In a multi-lingual configuration, it must be possible for the server to select the dictionary entries based on the end user's language. For example, an administrator defines the job-sheet-content attribute as the following text attributes: "Prompt-1" = 'Last Name' "Prompt-1-response" = ' ' "Prompt-2" = 'Department' "Prompt-2-response" = ' ' "Prompt-3" = 'Building' "Prompt-3-response" = ' ' In this example, the default values for the prompt-n-response attributes were set to a strings of ASCII blanks. They could have been any text string, perhaps a default name, or a string saying "enter text here". A client application, getting the job-sheet-content-supported attribute, would receive the above dictionary. Since there is no semantic associated with the actual text data, the client simply puts up the prompt and collects the response from the end-user in the associated response field. These fields are passed back to the IPP Printer with the print request where the data input by the end user is printed on the job-sheet in a format defined by the administrator. Roger K deBry Senior Technical 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 aa16141; 5 Sep 97 13: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 NAA06638 for ; Fri, 5 Sep 1997 13:41:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA03928 for ; Fri, 5 Sep 1997 13:38:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 13:34:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03426 for ipp-outgoing; Fri, 5 Sep 1997 13:26:05 -0400 (EDT) Message-ID: <341040B6.18802DAC@underscore.com> Date: Fri, 05 Sep 1997 13:26:14 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP>MOD - job-sheet-content attribute References: <5030100007699359000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger, I really like this proposal. Granted, it extends our reach yet another step (in that we're not "going interactive"), but this mechanism can be very, very useful in large environments, and may be usable in billing situations, etc. Regarding the language issue, couldn't we just add (yet another) property to specify the language? This property would be set and returned by the client at job submission time. I was thinking that this would involve a list-selection mechanism, where the list entries are the set of valid languages for which the Printer can handle. Just my $0.02 worth. Nice job on the write-up. ...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 -- ---------------------------------------------------------------------- Roger K Debry wrote: > > At the last PWG meeting, I suggested the definition of a new attribute, > based on the proposed dictionary attribute, to allow an admisnistrator > to collect end-user suuplied information to be printed on a job-sheet. > I was asked to generate a formal write-up. Here it is: > > Job-Sheet-Content attribute > > Problem Statement > > Today the model document allows the end user to select whether or not a > job sheet should be printed, but there is no mechanism for a user to > specify what should be printed on the job sheet. In many cases, an > administrator will establish the content of the job sheet, using > information that comes from the print job request itself, such as > job-name, or job-originating-user. However, these values are somewhat > limited, and an administrator may want to use other information not > available as a standard job attribute. > > Suggested Solution > > Using the proposed dictionary attribute (Hastings-deBry proposal), > provide a means for the administrator to collect additional job-sheet > information. This could incidentally be used for other purposes, such > as accounting. This would be done with a new job template attributes > called "Job-Sheet-Content". > > To help the client, each field to be printed on the job sheet is > represented by a pair of attributes: > > 1. The first attribute in the pair is of the form "prompt-n", > where n is a digit starting with 1. > > 2. The second attribute is of the form "prompt-n-response". > > This attribute provides a means for an administrator to collect > additional user information to be printed on a job sheet. There > is no standard set of semantics associated with the text data > supplied by the administrator or the end user. Text is assumed to > be in the language of the end-user. > > ISSUE: How does one associate the end-user's language with a set > of text dictionary attributes? In a multi-lingual configuration, > it must be possible for the server to select the dictionary entries > based on the end user's language. > > For example, an administrator defines the job-sheet-content attribute > as the following text attributes: > > "Prompt-1" = 'Last Name' > "Prompt-1-response" = ' ' > "Prompt-2" = 'Department' > "Prompt-2-response" = ' ' > "Prompt-3" = 'Building' > "Prompt-3-response" = ' ' > > In this example, the default values for the prompt-n-response attributes > were set to a strings of ASCII blanks. They could have been any text > string, perhaps a default name, or a string saying "enter text here". > > A client application, getting the job-sheet-content-supported attribute, > would receive the above dictionary. Since there is no semantic associated > with the actual text data, the client simply puts up the prompt and > collects the response from the end-user in the associated response field. > These fields are passed back to the IPP Printer with the print request > where the data input by the end user is printed on the job-sheet in a > format defined by the administrator. > > Roger K deBry > Senior Technical 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 aa17029; 5 Sep 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 OAA06837 for ; Fri, 5 Sep 1997 14:14:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA04605 for ; Fri, 5 Sep 1997 14:10:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 14:05:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04076 for ipp-outgoing; Fri, 5 Sep 1997 13:56:58 -0400 (EDT) Message-Id: <199709051756.KAA01614@bulletin> To: ipp@pwg.org Subject: IPP> Article on IPP written by Adina Levin of CAPV Date: Fri, 05 Sep 1997 10:56:06 PDT From: Steve Zilles Sender: ipp-owner@pwg.org FYI, here is the text of the article on IPP written by Adina Levin of CAPV. She was gracious enough to send a copy for distribution to the PWG/IPP mailing list. Steve Zilles ------- Forwarded Message Steve, thanks for the kind words. Here's the boilerplate and the article, for distribution to the members of the Printer Working Group. - - ASL This article is excerpted from the Weekly Analysis electronic mail publication of the Document Software Strategies consulting service of CAP Ventures. This is a regular, weekly service for our clients. If you have questions or comments about the article, or for more information about CAP Ventures and the Document Software Service, call Adina Levin at 617-871-9000 x 145, or e-mail at Adina_Levin@capv.com. - ---------------------------------------------------------------------- Adina Levin ... - ---------------------------------------------------------------------- Internet Printing Protocol: The Promise of Internet Printing Yesterday Jim Hamilton, of the Print on Demand group of CAP Ventures, and I attended a briefing on the Internet Printing Protocol. The result of a year's worth of negotiations among industry powerhouses including Adobe, Hewlett-Packard, IBM, Microsoft, Netscape, Novell, Sun, and Xerox, the draft standard defines the method of sending a print job over the Internet. This standard is going to be a key nexus over the next 5 years at the intersection between document software and hardcopy output, enabling and accelerating opportunities for document delivery and on- demand printing software and services. WHAT IS THE INTERNET PRINTING PROTOCOL? In the simplest terms, the Internet printing protocol is a protocol that enables printing over the Internet. It combines and supersedes early non-standard work on Internet printing by HP and Microsoft (Simple Web Printing), Novell (LDPA), IBM (HPPP) and probably Adobe (Web-Ready Printing). Internet printing can work in one of three ways. 1) The user can print as usual through the operating system, but is able to access printers that are on Internet, not just on the local area network. 2) The user can send a print-formatted file (such as a PostScript or PDF file) to a printer. 3) The user can send a URL, and the printer will fetch the document and print it. The IPP defines a list of printer capabilities, and print job submission and feedback commands. It uses a client-server architecture. The client, which can be a web browser or desktop client can submit, query, or cancel a print job, and query the status of a printer. The server can be implemented inside a network- connected printer, or at the print-server or network-server level. The server identifies the printer or printers with a unique URL, and a database of each printers capabilities (color, duplex). The server can then accept print requests from the Internet, perform simple negotiations (I cannot print that document since I am not a color printer), and provide feedback about status (I am processing a job, I have a paper jam.) The IPP uses HTTP 1.1 for the negotiation between client and server. The standard was developed by the Printer Working Group (www.pwg.org), an alliance of printer, print networking, and infrastructure software vendors. It is not formally part of the IETF but is commissioned by the IETF to develop this standard. WHAT IS IT GOOD FOR? The Internet Printing Protocol adds an important level of infrastructure capability that makes some network printing tasks much easier to do. In the 8 years or so that I've been following this market, there have been numerous ill-fated schemes for managing printers on networks, starting with closed-system utopias from Digital Equipment, to LAN/WAN based solutions proposed by Novell, to international standards-based systems that tried to abstract and define every printer feature in the universe. These early solutions based on closed systems or international standards languished; one reason is that in order to develop working print management software, you needed to write low-level networking code that had little value to the printer vendor or infrastructure vendor. In reality, network print management solutions were based on a single printer vendor's products or a single network environment. With IP as a universal network, enterprise-wide printer management becomes much easier. Printers become visible on the corporate intranet; users and administrators can see that the printers are working, measure usage, and conduct software upgrades. These capabilities will be quickly implemented by vendors of network printers, such as Hewlett-Packard, Lexmark, and Tektronix. But if printer management were the whole story, this article would not be that interesting. Customers will appreciate enterprise-wide, network-independent, printer-independent network print management when it is available, but they will probably expect it for free. Internet printing has some more interesting applications that will create or facilitate profitable business opportunities that builds on the IPP base. 1) Internet printing will be extremely useful for distributed on- demand production printing. It will become much easier to send printed documents to corporate branch offices in London, Tokyo, and Singapore. This kind of distributed printing has been slow to take off because of the work required to tie together the pieces of a heterogeneous network. With the Internet as a universal network, users will be able to print to the corners of far-flung organizations. Companies that make various types of print server products, such as TR Systems, NEPS, EFI, and Dazel, are likely to integrate this quickly. Vendors and users wishing to implement distributed on-demand printing will still need to cope with complex device negotiation issues. IPP has built in a basic level of device specification - is the device color or monochrome, US letter-size or A4? IPP also includes a basic level of negotiation - print it only the way that I want, or print the job as best you can. The real world is much more complicated, particularly in a production environment. IPP alone can't specify that yellow paper goes in paper tray 3. However, the IPP leaves the way open for vendor or user-level extensions to the standard. Successful distributed printing may also require a certain level of process co-ordination and discipline. Even if a site's IPP application states that the yellow paper goes in paper tray 3, humans must make sure that orange paper doesn't get put into paper tray 3 by mistake. 2) The second, related example in the production printing environment is remote job submission to for-profit printers. There are networks of for-profit printers that have begun to do this already, including networks of for-profit print chains: Kinkos and Sir Speedy; networks of independent printers: PagePath, WEPN, IPN; and networks of large, multi-location commercial printers: Uarco Impressions, Standard Register StanFast. These networks provide software that allows an end user to find the printer in the desired geographical area with the desired capabilities, to fill out the requirements of the job and payment information, and to submit the print file. The Internet printing protocol will not replace the services and networks that exist. The Internet printing protocol does not include all of the features you would need in a job ticketing system - it just includes a basic method of identifying a printer and sending a print job. Moreover, networks of printers will provide a variety of value-added services and customer service capabilities that distinguish them, above and beyond basic job ticketing. The Internet printing protocol is likely to make remote job submission easier, and will popularize the process of remote printing in general. 3) The previous two examples involved "push" printing. The customer has the document in hand, and would like to print it at a location far away. Another potentially valuable application is just-in-time printing from a database of print files. This is "pull" printing, and it would work in the following manner: an organization would create a database of print files - sales collateral, or brochures, or CAP Ventures published reports. A sales person or customer would be able to locate the file, or the URL of the file, and send that to a local printer. The user would be able to order and print the documents where and when they were needed. 4) The previous three examples dealt with production printing - the printing of documents designed to be distributed to multiple people in some formal way. Internet printing will also be useful in the day- to-day business world. Ordinary users will be able to use Internet printing to print a document to some printer someplace else. The big challenges here are discovery and security. How can I find one small printer in the great wide world? And how can I make sure random people aren't sending me junk prints, in addition to junk faxes and spam e-mails? The IPP standard does not specify any particular security method. Instead, it allows infrastructure software developers and user organizations to use the security methods they have in place. Solving the discovery problem will require additional development at the network infrastructure level, using LDAP and other standards, to build software for resource discovery. In the mean time, people will have to give out their printer's URL deliberately, in the same way that they give out their fax number. Another problem is print drivers. IPP can generate a feedback message about the driver needed to print to a distant printer. This process sounds awkward and is likely to give MIS staff headaches. Companies in the fax business should be afraid, since remote printing avoids telephone charges and creates a clean, original document rather than a fuzzy bitmapped fax. However, it will take some time before IPP printing capability is anywhere near as common as faxing. 5) The promise of remote printing adds hardcopy output into the matrix of electronic document delivery solutions. After all, it will enable users to deliver formatted electronic documents to a remote location. Electronic document delivery can be tied into specific horizontal or vertical applications, in extranet electronic commerce, financial publishing, health care, and so on. Providers of electronic delivery products and services, from Tumbleweed to Diffusion to Adobe, are likely to add support for remote printing to the capabilities of their products. WHAT IT WILL TAKE TO MAKE THIS A REALITY None of these scenarios will happen overnight. A number of steps need to happen first, starting with finalization and adoption of the IPP standard. The draft standard is expected to be finalized over the next few months and submitted to IETF by the end of the year, and approved by IETF, probably early next year. Next, IPP capability needs to be added to infrastructure software (Microsoft, Novell, Sun, Netscape). Depending on the decisions of infrastructure software providers, IPP will be included as a free add-on, or part of a next-generation revision of network software. The infrastructure software upgrade cycle will add another six months to several years to reach a critical mass of deployment, depending on how aggressive the software vendors are and how popular the feature is among users. IPP can also be built into a network printer itself, and it probably will be, starting as early as late `98. Many network printers, and most printers in the production environment, are software- upgradable, so upgrades can happen fairly quickly. It is important to note that it won't be necessary to upgrade the installed base of printers to take advantage of IPP. The IPP intelligence can live at the level of the print server or network print service. This is very important for the potential speed of proliferation. If you needed to replace existing printers, it would take many years to make a small dent in the installed base of existing LaserJets. CONCLUSION IPP won't happen overnight, and there are many problems that the Internet printing protocol won't solve by itself. That said, we believe that IPP will serve as a critical enabling technology that will make many kinds of network printing applications easier to build, will create or facilitate opportunities for network printing and document delivery systems, and will set the stage for more rapid adoption of useful network printing applications. -- Adina Levin ------- End of Forwarded Message   Received: from cnri by ietf.org id aa17545; 5 Sep 97 14:26 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 OAA06909 for ; Fri, 5 Sep 1997 14:29:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA05222 for ; Fri, 5 Sep 1997 14:25:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 14:19:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04595 for ipp-outgoing; Fri, 5 Sep 1997 14:10:42 -0400 (EDT) Message-ID: <34104B31.BA7A31E0@underscore.com> Date: Fri, 05 Sep 1997 14:10:57 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD - job-sheet-content attribute References: <5030100007699359000002L092*@MHS> <341040B6.18802DAC@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Oops... I meant to say that we are _now_ going interactive in this paragraph (instead of "not"): > I really like this proposal. Granted, it extends our reach yet > another step (in that we're not "going interactive"), but this ^^^ > mechanism can be very, very useful in large environments, and may > be usable in billing situations, etc. ...jay   Received: from cnri by ietf.org id aa17831; 5 Sep 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 OAA06959 for ; Fri, 5 Sep 1997 14:40:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA05826 for ; Fri, 5 Sep 1997 14:37:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 14:32:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05054 for ipp-outgoing; Fri, 5 Sep 1997 14:22:14 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7036073C8@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'Roger K Debry' , ipp@pwg.org Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Date: Fri, 5 Sep 1997 11:03:53 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org We discussed this at the august meeting. You cannot extract the jobid from the job-URI. Remember a 'particluar implmentation' has no meaning for things visible in a wire protocol. There is both the client and the server - if the url is to be in a specifc format then both sides must agree to this. The only way that this would work is if we mandated the url format (which we discussed doing and voted against) > -----Original Message----- > From: Roger K Debry [SMTP:rdebry@us.ibm.com] > Sent: Friday, September 05, 1997 6:07 AM > To: ipp@pwg.org > Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > I agree with Jay that this seems like a clean approach. However, > if I've understood all of the arguments, I thought that dictating the > form > of the URL was a no-no. On the other hand, if a PARTICULAR > IMPLEMENTATION, > such as NT, requires a 32-bit integer job ID to be consistent with its > existing > APIs, then there should be no reason why THAT implementation could not > use the approach that Jay suggests to easily map to an internal > integer job > identifier. > > I know that this may not solve the problem for a gateway somwhere in > the > middle, but it does seem to me that for a particular server > implementation > this works fairly well. > > > Roger K deBry > Senior Technical 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 > 09/05/97 06:56 > AM --------------------------- > > ipp-owner @ pwg.org > 09/04/97 10:06 PM > Please respond to ipp-owner@pwg.org @ internet > > To: Robert.Herriot @ Eng.Sun.COM @ internet > cc: ipp @ pwg.org @ internet > Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > Bob, > > Thanks for the rebuttal info on this issue. You continually point > out this basic desire/premise/goal: > > IPP job id == LPD job id > > You gave lots of good examples, paying particular attention to > exposure issues with end users. In fact, my reading of your message > makes me come away believing that consistent end user visibility is > extremely high on the priority list...maybe even #1. > > This may be. (I'm not sure, myself.) However, if the exposure of > job ids is so critical, then why don't we also insist on: > > IPP printer name == LPD printer name > > I've been assuming all along that an IPP printer name would appear > to an end user as something like: > > http://host.domain/printer/ > > (Or any one of five bazillion permutations on the URL theme.) > > However, in LPD land, a "printer" is almost always a "simple" name, > such as: laser1, plot3, mkt, lp3, etc. Simple sequences of just > letters and numbers (usually), with possibly a sprinking of hyphens, > underscores, etc. However, almost never is the name constructed as > a series of sub-tokens assembled in a hierarchical fashion. (Sure, > it can be done...but it just *isn't* commonly done in real practice.) > > Aren't you concerned with that kind of shift in visibility, too? > > Of course, one can always assume some sort of standard (de facto) > mapping mechanism, whereby the "simple" name is always the last token > of the URL string: > > http:://host.domain/printer/laser1 == laser1 > > If this is good enough, then why can't the same be true for job > ids, eg: > > http://somewhere.net.domain/subsys/server3/345 == 345 > > If nothing else, then such a simple job id mapping mechanism can be > standardized for IPP "printers" front-ending LPD queues. Even in the > non-LPD case, this kind of job identification looks pretty clean: > > http:://host.domain/printer/laser1/345 > > This kind of approach looks real clean to me, but maybe I'm just a > bit too close to the code, if you know what I mean. > > I must be missing something, right? Thanks for your insights. > > ...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 -- > ---------------------------------------------------------------------- > > > Robert Herriot wrote: > > > > I will try to explain why the Job-URI is harder to support than the > > Job-Id for an LPD gateway. I will also explain why the requirements > > that call for a Job-URI are not well enough understood to be > > requirements. > > > > ANALYSIS OF JOB-URI VS JOB-ID > > > > For the gateway, there are two directions: IPP-to-LPD and > LPD-to-IPP. > > > > I have two goals for these gateways. They should > > 1) be stateless: which means that gateways get all their > information > > from the downstream server rather than storing information > about > > jobs in the gateway. > > 2) provide values to the client that are the same (possibly after > a > > conversion algorithm) as the client could get from bypassing > the > > gateway, which means gateways pass information without > converting > > it or converting it in an algorithmic fashion that a client > can > > apply an inverse function to. This provision is important > because > > some applications on a client may use the gateway and others > may > > bypass it. > > > > The Job-URI is hardest to support in the LPD-to-IPP direction > because > > it fails to meet goal #1 above (it requires state). There is no > simple > > way to algorithmically map the IPP Job-URI to an LPD Job-Id because > the > > Job-URI is opaque. > > > > The Job-URI solution for both directions fails to meet goal #2 > because > > it has the problem of exposing both Job-Ids and Job-URIs to a user > for > > the same set of jobs and there is no conversion algorithm. > > > > Now for the two gateway directions for both Job-Id and Job-URI. > > > > First let's examine the IPP-to-LPD gateway where the gateway returns > a > > Job-Id. The gateway creates the job-Id for LPD when it receives a > > Print-Job operation. It then returns the LPD job-Id to the IPP > client > > as the value of the Job-Id. This Job-Id is the same one that > Cancel-Job > > uses to specify the job to cancel. When a client performs Get-Jobs, > > the Job-Ids in the lpq reply to the gateway become the values of the > > Job-Id attribute in the Get-Jobs response. If the client sends an > lpq > > directly to the printer, bypassing the gateway, it sees the same > > values for Job-Ids. > > > > Next, let's examine the IPP-to-LPD gateway where the gateway returns > a > > Job-URI. The gateway creates the job-Id for LPD when it receives a > > Print-Job operation. It then returns to the IPP client the Job-URI > > which consists of the printer-URI and the LPD Job-Id. This Job-URI > is > > the same one that Cancel-Job uses to specify the job to cancel. > Because > > the gateway composed the Job-URI, it can parse it into the > printer-URI > > and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq > > response to the gateway are composed with the printer-URI to form > the > > value of each Job-URI in the Get-Jobs response. If the client sends > an > > lpq directly to the printer, bypassing the gateway, it sees the > job's > > Job-Ids rather than their Job-URIs. So the client gets different > values > > for identifying the jobs and the client cannot convert between > Job-URI > > values and Job-Id values because the rules for composing Job-URIs > are > > not specified. > > > > Next, let's examine the LPD-to-IPP gateway where the gateway returns > a > > Job-Id. The gateway client creates an job-Id which the gateway > ignores > > because the IPP server creates its own Job-Id. Existing LPD servers > > sometimes ignore the Job-Id value requested by the client. LPD > provides no > > mechanism for the gateway to inform the client of the Job-Id. The > > client must use the lpq command to get Job-Ids. When a client > performs > > an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the > > values of the lpq response. This Job-Id from lpq is the same one > that lprm > > command uses to specify the job to cancel. If the client sends a > > Get-Jobs directly to the printer, bypassing the gateway, it sees the > > same values for Job-Ids. > > > > Finally, let's examine the LPD-to-IPP gateway where the gateway > returns > > a Job-URI. The gateway client creates a job-Id. The gateway either > > remembers this Job-Id or creates its own because the IPP server > creates > > a Job-URI which has no direct relationship to the integer Job-Id > > required by LPD. When a client performs an lpq, the Job-URIs in the > > Get-Jobs reply to the gateway must be mapped to the Job-Id for the > lpq > > response. When the gateway receives an lprm command, it must map > the > > received Job-Id to the IPP Job-URI required for Cancel-Job. If the > > client sends a Get-Jobs directly to the printer, bypassing the > gateway, > > it sees Job-URIs which have no relation to the Job-Id's that it sees > via > > the gateway. There are two ways to handle the mapping. Either the > > gateway maintains its own internal table which it must update when > jobs > > complete or it needs a scratch-pad attribute in the job where it can > store > > the Job-Id. The latter case would require that servers not throw > away > > unsupported attributes and a search of the mapping would require > that the > > gateway perform a Get-Jobs. > > > > QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION > > > > Now that I have presented the problems that the Job-URI presents, I > > now would like to question its touted advantages. I have heard two. > > > > 1) It allows for redirection more easily > > 2) It allows for better load balancing > > > > I address both below and conclude that Job-URI's aren't necessary > with > > our current understanding of requirements. > > > > I also wonder if Job-URIs that are unrelated to the Printer-URI > > containing the job will confuse users who are exposed to them. A > user > > thinks of a job as belonging to a printer. So if a Job is identified > by > > the Printer-URI that the user selected and some number, that seems > to > > me like a simpler concept. > > > > REDIRECTION > > > > Whether a job is represented uniquely by Job-URI or > (Printer-URI,Job-Id), > > either of these "names" references some host somewhere and when a > job > > moves, that host has to keep track of where is has moved to, and > when > > to delete the reference. It would seem to me that either Job-URI or > > (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even > > when they move. So either should suffice in this case and since > Job-Id > > is easier for legacy connections, Job-Id is the better solution. > > > > In my opinion, the redirection of print jobs is a research area > > that is not well enough understood for us to be creating > requirements > > for a standard. > > > > LOAD BALANCING > > > > The idea is that the Job-URI may reference a different host than the > > Printer-URI references so that references to the job don't load the > > print server. > > > > There may be other solutions, such as clustering of Web servers, > which > > solve the problem without the added complexity of Job-URIs. > > > > This problem is way beyond the 80% solution we are striving for and > is > > also a research area that is not well enough understood for us to be > > creating requirements for a standard. > > > > > > >   Received: from cnri by ietf.org id aa19852; 5 Sep 97 16: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 QAA07361 for ; Fri, 5 Sep 1997 16:06:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06667 for ; Fri, 5 Sep 1997 16:02:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 15:58:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06150 for ipp-outgoing; Fri, 5 Sep 1997 15:49:56 -0400 (EDT) Date: Fri, 5 Sep 1997 12:50:41 -0700 (PDT) From: papowell@astart.com Message-Id: <199709051950.MAA01967@astart2.astart.com> To: ipp@pwg.org, paulmo@microsoft.com, rdebry@us.ibm.com Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Sender: ipp-owner@pwg.org One of the ways that problems such as format for URI's for printing can be handled is to issue an 'Informational' RFC that describes a 'Best Practices' type of condition. I do not see a conflict with the IPP RFC in doing this. It would, in fact, probably be a good way to handle the issues of 'particular URI formats for portability'. Also, an informational RFC and 'Best Practices' is not binding... just gentle hints. Patrick Powell > From ipp-owner@pwg.org Fri Sep 5 11:39:50 1997 > From: Paul Moore > To: "'Roger K Debry'" , ipp@pwg.org > Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > Date: Fri, 5 Sep 1997 11:03:53 -0700 > > We discussed this at the august meeting. You cannot extract the jobid > from the job-URI. Remember a 'particluar implmentation' has no meaning > for things visible in a wire protocol. There is both the client and the > server - if the url is to be in a specifc format then both sides must > agree to this. The only way that this would work is if we mandated the > url format (which we discussed doing and voted against)   Received: from cnri by ietf.org id aa21633; 5 Sep 97 17: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 RAA07737 for ; Fri, 5 Sep 1997 17:17:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07445 for ; Fri, 5 Sep 1997 17:14:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 17:10:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06938 for ipp-outgoing; Fri, 5 Sep 1997 17:01:45 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7036073D1@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'papowell@astart.com'" , ipp@pwg.org, rdebry@us.ibm.com Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Date: Fri, 5 Sep 1997 14:01:36 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org this is not an Informational RFC thing - either the client code can depend on the jobid being derivable from the URL or it cannot. There is no halfway house. > -----Original Message----- > From: papowell@astart.com [SMTP:papowell@astart.com] > Sent: Friday, September 05, 1997 12:51 PM > To: ipp@pwg.org; Paul Moore; rdebry@us.ibm.com > Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > One of the ways that problems such as format for URI's for printing > can be handled is to issue an 'Informational' RFC that describes > a 'Best Practices' type of condition. > > I do not see a conflict with the IPP RFC in doing this. It would, > in fact, probably be a good way to handle the issues of 'particular > URI formats for portability'. > > Also, an informational RFC and 'Best Practices' is not binding... > just gentle hints. > > Patrick Powell > > > From ipp-owner@pwg.org Fri Sep 5 11:39:50 1997 > > From: Paul Moore > > To: "'Roger K Debry'" , ipp@pwg.org > > Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > Date: Fri, 5 Sep 1997 11:03:53 -0700 > > > > We discussed this at the august meeting. You cannot extract the > jobid > > from the job-URI. Remember a 'particluar implmentation' has no > meaning > > for things visible in a wire protocol. There is both the client and > the > > server - if the url is to be in a specifc format then both sides > must > > agree to this. The only way that this would work is if we mandated > the > > url format (which we discussed doing and voted against)   Received: from cnri by ietf.org id aa22432; 5 Sep 97 17: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 RAA07855 for ; Fri, 5 Sep 1997 17:54:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08181 for ; Fri, 5 Sep 1997 17:50:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 17:47:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07641 for ipp-outgoing; Fri, 5 Sep 1997 17:38:54 -0400 (EDT) Date: Fri, 5 Sep 1997 14:37:08 -0700 From: Robert Herriot Message-Id: <199709052137.OAA22774@woden.eng.sun.com> To: jkm@underscore.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Thu Sep 4 20:52:37 1997 > > Bob, > This may be. (I'm not sure, myself.) However, if the exposure of > job ids is so critical, then why don't we also insist on: > > IPP printer name == LPD printer name I have assumed that IPP printer-name == LPD printer name, but that IPP printer-name differs from IPP printer-URI. That is IPP printer-name might be "killtree" and IPP printer-URI might be "http://foobar.bigcorp.com/printer/killtree" > If this is good enough, then why can't the same be true for job > ids, eg: > > http://somewhere.net.domain/subsys/server3/345 == 345 The translation between printer-name (LPD or IPP) and printer-URI is easy because of the two IPP attributes and because a name service is likely to have both. On the other hand, jobs won't be in the name service because they are transient, and the syntax of a job-URI is opaque so there is no way to determine a Job-Id from a Job-URI.   Received: from cnri by ietf.org id aa22868; 5 Sep 97 18: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 SAA07944 for ; Fri, 5 Sep 1997 18:14:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA08842 for ; Fri, 5 Sep 1997 18:10:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 18:07:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08298 for ipp-outgoing; Fri, 5 Sep 1997 17:59:02 -0400 (EDT) Date: Fri, 5 Sep 1997 14:58:02 -0700 From: Robert Herriot Message-Id: <199709052158.OAA22800@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Sep 5 06:16:30 1997 > > I agree with Jay that this seems like a clean approach. However, > if I've understood all of the arguments, I thought that dictating the form > of the URL was a no-no. On the other hand, if a PARTICULAR IMPLEMENTATION, > such as NT, requires a 32-bit integer job ID to be consistent with its existing > APIs, then there should be no reason why THAT implementation could not > use the approach that Jay suggests to easily map to an internal integer job > identifier. But Microsoft clients cannot assume that all IPP servers will be Microsoft servers. Thus the client has no sure way to parse the Job-URI. Bob Herriot   Received: from cnri by ietf.org id aa23435; 5 Sep 97 18: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 SAA08006 for ; Fri, 5 Sep 1997 18:39:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA09564 for ; Fri, 5 Sep 1997 18:35:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 18:25:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08947 for ipp-outgoing; Fri, 5 Sep 1997 18:15:10 -0400 (EDT) Message-ID: <34108450.9219A7AD@underscore.com> Date: Fri, 05 Sep 1997 18:14:40 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: IPP mailing list Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <5030100007694047000002L072*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger has done an outstanding job (pun intended?) in asking all the right questions. I hope everyone takes the time to read his message to understand that the LPD gateway scenario as presented has a number of flaws in both its assumptions and philosophical statements. The two key points Roger mentions that I find to be worthy of serious analysis/understanding by the IPP group: - Perhaps most folks don't know this, but an LPD client has NO WAY OF LEARNING THE JOB ID ASSIGNED BY THE LPD SERVER for a job the client has submitted to the server. (Sad, but very true.) This is where I believe some of the assumptions presented by Bob kinda fall apart real fast. - Why on earth would a given client want to switch between using LPD and IPP? Somehow Bob makes one believe this is commonly desired functionality, but I just don't get it. Again, the presented assumptions appear to fall short. (Paraphrasing an age-old verse, "Give unto IPP what is IPP's, and give unto LPD what is LPD's"... ;-) Right now I'm sitting on the fence on which "side" to take on this issue. I fully understand Roger's desire for elegance in casting the Job as a real object; I also understand Randy's desire to use URI's for Job object references to facilitate distributed operation. Both of these desires seem like Good Things to me...as long as developers don't have to pay too high a price for them. I'm probably not the only one in the PWG having this simple #1 goal: Ship products to make MONEY. (No altruism here, mind you... ;-) To that end, I almost always prefer simplicity, PARTICULARLY when we're talking about version 1.0 of any given spec. It seems to me that the Job ID approach is inherently simpler. However, digging deeper down leads me to believe that the Job URI approach is just plain simple, too...as long as reasonable constraints are placed on URI construction. Maybe I'm missing something in my understanding of certain legacy technologies, but I just don't understand the various messages claiming that Job IDs *must* be used to facilitate legacy systems; the arguments in those messages just don't describe enough of the inherent problems in dealing with URI's on those systems. Sorry for the long post, but one last question (since I couldn't make the Redmond meeting): What is wrong with defining a common URI syntax, either for Printers or Jobs? After working four long years with the PWG, it has become pretty obvious to me that some people just have to insist on a "no bounds" approach to specifications. I've found that the best standards (ie, those readily accepted and widely deployed) are usually wrought with all kinds of constraints. Such contraints tend to both facilitate development AND improve interoperability. Sorry, but I think IPP needs a healthy dose of constraints to get this animal under control. ...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 -- ---------------------------------------------------------------------- Roger K Debry wrote: > > Bob, can you clarify a few things for me please? It would help me understand > your write-up. > > My questions noted with > > First let's examine the IPP-to-LPD gateway where the gateway returns a > Job-Id. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns the LPD job-Id to the IPP client > as the value of the Job-Id. This Job-Id is the same one that Cancel-Job > uses to specify the job to cancel. When a client performs Get-Jobs, > the Job-Ids in the lpq reply to the gateway become the values of the > Job-Id attribute in the Get-Jobs response. If the client sends an lpq > directly to the printer, bypassing the gateway, it sees the same > values for Job-Ids. > > Why would the IPP client bypass the gateway and send an lpq > directly to the printer? It seems to me that an IPP client > would always use IPP. Are you describing a pathological case > here? Why would an IPP client (or and end user for that matter) > even suspect that the real printer would even understand lpq? > > Next, let's examine the IPP-to-LPD gateway where the gateway returns a > Job-URI. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns to the IPP client the Job-URI > which consists of the printer-URI and the LPD Job-Id. This Job-URI is > the same one that Cancel-Job uses to specify the job to cancel. Because > the gateway composed the Job-URI, it can parse it into the printer-URI > and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq > response to the gateway are composed with the printer-URI to form the > value of each Job-URI in the Get-Jobs response. If the client sends an > lpq directly to the printer, bypassing the gateway, it sees the job's > Job-Ids rather than their Job-URIs. So the client gets different values > for identifying the jobs and the client cannot convert between Job-URI > values and Job-Id values because the rules for composing Job-URIs are > not specified. > > ditto the above question. > > Next, let's examine the LPD-to-IPP gateway where the gateway returns a > Job-Id. The gateway client creates an job-Id which the gateway ignores > because the IPP server creates its own Job-Id. Existing LPD servers > sometimes ignore the Job-Id value requested by the client. LPD provides no > mechanism for the gateway to inform the client of the Job-Id. > > The following is to clarify normal lpr/lpd operation ... > So, an lpr request always generates a job-id on the client, > but sometimes it gets ignored (I assume then that the server > assigns the job-id. But there is no way for the server to tell > the client what id it assigned. Did I get it right? > > How does the client know whether or not the id it assigned > is valid? What happens if it cnacels the job with the client > assigned id? Does it get told that the id is invalid? This > seems pretty flaky to me. > > The client must use the lpq command to get Job-Ids. When a client performs > an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the > values of the lpq response. This Job-Id from lpq is the same one that lprm > command uses to specify the job to cancel. If the client sends a > Get-Jobs directly to the printer, bypassing the gateway, it sees the > same values for Job-Ids. > > Again, I don't understand this mixed mode of operation. Why > would an lpr client assume that the printer on the other end > would understand IPP? For that matter, why would the client > speak IPP? For that matter, if it did speak IPP, why would > it need a gateway? > > Finally, let's examine the LPD-to-IPP gateway where the gateway returns > a Job-URI. The gateway client creates a job-Id. The gateway either > remembers this Job-Id or creates its own because the IPP server creates > a Job-URI which has no direct relationship to the integer Job-Id > required by LPD. > > In the previous case, it sounded like the client could never > depend on the job id it assigned anyway. Why does it do so here? > Why doesn't the gateway ignore the client assigned id as in > the previous case, and force the client to do an lpq? > > When a client performs an lpq, the Job-URIs in the > Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq > response. When the gateway receives an lprm command, it must map the > received Job-Id to the IPP Job-URI required for Cancel-Job. If the > client sends a Get-Jobs directly to the printer, bypassing the gateway, > it sees Job-URIs which have no relation to the Job-Id's that it sees via > the gateway. > > Once again I question why a client would operate in this mixed > mode. Why would an lpr client EVER use an IPP Get-Jobs??? > > There are two ways to handle the mapping. Either the > gateway maintains its own internal table which it must update when jobs > complete or it needs a scratch-pad attribute in the job where it can store > the Job-Id. The latter case would require that servers not throw away > unsupported attributes and a search of the mapping would require that the > gateway perform a Get-Jobs. > > QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION > > Now that I have presented the problems that the Job-URI presents, I > now would like to question its touted advantages. I have heard two. > > 1) It allows for redirection more easily > 2) It allows for better load balancing > > I address both below and conclude that Job-URI's aren't necessary with > our current understanding of requirements. > > I also wonder if Job-URIs that are unrelated to the Printer-URI > containing the job will confuse users who are exposed to them. A user > thinks of a job as belonging to a printer. So if a Job is identified by > the Printer-URI that the user selected and some number, that seems to > me like a simpler concept. > > Actually, I NEVER think of the job as belonging to the printer. > Most of the shared printers we use here in IBM are in printer > pools. I never know which one it will print on. I think of my > job as an object that (hopefully) the system knows how to > handle. When I cancel or query a job, I tell the client, and > let it worry about everything from there on. As a user I don't > care. > > REDIRECTION > > Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), > either of these "names" references some host somewhere and when a job > moves, that host has to keep track of where is has moved to, and when > to delete the reference. It would seem to me that either Job-URI or > (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even > when they move. So either should suffice in this case and since Job-Id > is easier for legacy connections, Job-Id is the better solution. > > Certainly you can remember either a URI or a job-id. > I think Randy's point was that using a URI, HTTP provides an > easy way to do redirection. Using a job-id, we would have to > invent a scheme that was IPP specific. > > In my opinion, the redirection of print jobs is a research area > that is not well enough understood for us to be creating requirements > for a standard. > > Why don't you think it is well understood? > > LOAD BALANCING > > The idea is that the Job-URI may reference a different host than the > Printer-URI references so that references to the job don't load the > print server. > > There may be other solutions, such as clustering of Web servers, which > solve the problem without the added complexity of Job-URIs. > > This problem is way beyond the 80% solution we are striving for and is > also a research area that is not well enough understood for us to be > creating requirements for a standard. > > One last question ... if we take the course of adopting a job-id, > how do we rationalize the notion of the job being an object? In > my mind, the only object we are left with is the printer object, > because now all operations are on the printer. For example, we > no longer provide the URI of the job and tell it to cancel itself. > We send the operation to the printer and tell it to cancel the job. > Ditto for querying job attributes. The operation goes to the printer. > In my mind, this very fundamental change forever dictates the way > IPP will deal with jobs. If we ever want to imagine the job as a > real object with a life of its own, that can be moved around the > network (whether it be for load balancing, recovery, etc.), queried, > cancelled, indepdendent of where it lives, then we ought not to > bind it now to a printer and lose it's identity as an object. > > I think that Jay's suggestion to allow an implementation to create > job URI's by cleverly using the integer job id's currently supported > by existing system API's is a fine way to solve the problem for most > cases. The standard doesn't require URLs to be created that way, > but neither should it dis-allow it if it makes life easier for a > particular implementation. > does it   Received: from cnri by ietf.org id aa23797; 5 Sep 97 18: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 SAA08059 for ; Fri, 5 Sep 1997 18:56:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10210 for ; Fri, 5 Sep 1997 18:52:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 18:42:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08979 for ipp-outgoing; Fri, 5 Sep 1997 18:21:42 -0400 (EDT) Message-ID: <341085E2.915794F@underscore.com> Date: Fri, 05 Sep 1997 18:21:22 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709052158.OAA22800@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > But Microsoft clients cannot assume that all IPP servers will be > Microsoft servers. Thus the client has no sure way to parse the > Job-URI. So again I ask: exactly why can't (or shouldn't) we standardize on a Job URI syntax? (I really regret not being able to have made the Redmond meeting.) ...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 aa24165; 5 Sep 97 19: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 TAA08088 for ; Fri, 5 Sep 1997 19:11:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA11306 for ; Fri, 5 Sep 1997 19:07:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 18:57:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09369 for ipp-outgoing; Fri, 5 Sep 1997 18:31:15 -0400 (EDT) Date: Fri, 5 Sep 1997 15:30:21 -0700 From: Robert Herriot Message-Id: <199709052230.PAA22843@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rdebry@us.ibm.com Fri Sep 5 08:31:46 1997 > > Bob, can you clarify a few things for me please? It would help me understand > your write-up. > > My questions noted with > > First let's examine the IPP-to-LPD gateway where the gateway returns a > Job-Id. The gateway creates the job-Id for LPD when it receives a > Print-Job operation. It then returns the LPD job-Id to the IPP client > as the value of the Job-Id. This Job-Id is the same one that Cancel-Job > uses to specify the job to cancel. When a client performs Get-Jobs, > the Job-Ids in the lpq reply to the gateway become the values of the > Job-Id attribute in the Get-Jobs response. If the client sends an lpq > directly to the printer, bypassing the gateway, it sees the same > values for Job-Ids. > > Why would the IPP client bypass the gateway and send an lpq > directly to the printer? It seems to me that an IPP client > would always use IPP. Are you describing a pathological case > here? Why would an IPP client (or and end user for that matter) > even suspect that the real printer would even understand lpq? RGH: It is more a matter that an end-user may be printing from many RGH: different applications, some using IPP and others using LPD to RGH: the same printer. The user may not even be aware of the route each RGH: application takes to the printer. But the user may look at all RGH: jobs through a single print queue window. RGH: This answer applies to all of your questions that pertain to this RGH: issue. > > Next, let's examine the LPD-to-IPP gateway where the gateway returns a > Job-Id. The gateway client creates an job-Id which the gateway ignores > because the IPP server creates its own Job-Id. Existing LPD servers > sometimes ignore the Job-Id value requested by the client. LPD provides no > mechanism for the gateway to inform the client of the Job-Id. > > The following is to clarify normal lpr/lpd operation ... > So, an lpr request always generates a job-id on the client, > but sometimes it gets ignored (I assume then that the server > assigns the job-id. But there is no way for the server to tell > the client what id it assigned. Did I get it right? RGH: Yes, you got it right, the server may use the client's job-Id or it RGH: may create its own job-Id. When the server changes the job-Id, the RGH: client can determine this only by using heuristics with the 'lpq' RGH: to match the queued jobs with jobs known to have been submitted. RGH: Yes, LPD has its problems. > > How does the client know whether or not the id it assigned > is valid? What happens if it cancels the job with the client > assigned id? Does it get told that the id is invalid? This > seems pretty flaky to me. RGH: If the client uses its job-Id, the server will assume that the job-Id RGH: is the server's Job-Id. Yes, it is flaky. That's one of the reasons RGH: for IPP. > > Finally, let's examine the LPD-to-IPP gateway where the gateway returns > a Job-URI. The gateway client creates a job-Id. The gateway either > remembers this Job-Id or creates its own because the IPP server creates > a Job-URI which has no direct relationship to the integer Job-Id > required by LPD. > > In the previous case, it sounded like the client could never > depend on the job id it assigned anyway. Why does it do so here? > Why doesn't the gateway ignore the client assigned id as in > the previous case, and force the client to do an lpq? RGH: The issue is that the gateway has to use some integer Job-Id and the RGH: Job-URI does not satisfy the requirement. So the gateway either RGH: creates a Job_Id or uses the client one. In either case, the gateway RGH: must associate that Job-Id with the Job-URI and it is a number that RGH: bears no relation to the Job-URI assigned by the IPP server. > > QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION > > Now that I have presented the problems that the Job-URI presents, I > now would like to question its touted advantages. I have heard two. > > 1) It allows for redirection more easily > 2) It allows for better load balancing > > I address both below and conclude that Job-URI's aren't necessary with > our current understanding of requirements. > > I also wonder if Job-URIs that are unrelated to the Printer-URI > containing the job will confuse users who are exposed to them. A user > thinks of a job as belonging to a printer. So if a Job is identified by > the Printer-URI that the user selected and some number, that seems to > me like a simpler concept. > > Actually, I NEVER think of the job as belonging to the printer. > Most of the shared printers we use here in IBM are in printer > pools. I never know which one it will print on. I think of my > job as an object that (hopefully) the system knows how to > handle. When I cancel or query a job, I tell the client, and > let it worry about everything from there on. As a user I don't > care. > > REDIRECTION > > Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), > either of these "names" references some host somewhere and when a job > moves, that host has to keep track of where is has moved to, and when > to delete the reference. It would seem to me that either Job-URI or > (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even > when they move. So either should suffice in this case and since Job-Id > is easier for legacy connections, Job-Id is the better solution. > > Certainly you can remember either a URI or a job-id. > I think Randy's point was that using a URI, HTTP provides an > easy way to do redirection. Using a job-id, we would have to > invent a scheme that was IPP specific. RGH: In the teleconference we discussed that fact that if a client RGH: accesses a Job-URI which requires redirection, the server RGH: needs to know when to delete the mapping between the old and the RGH: new job-URI. Is it immediately after the first query? Is it after RGH: the job has completed? Each of these strategies has problems. RGH: In other words, the Job-URI solves only one small piece of the RGH: problem. > > > In my opinion, the redirection of print jobs is a research area > that is not well enough understood for us to be creating requirements > for a standard. > > Why don't you think it is well understood? RGH: Because of the problems I cite above and because it has not been RGH: fully implemented in DPA implementations. > > LOAD BALANCING > > The idea is that the Job-URI may reference a different host than the > Printer-URI references so that references to the job don't load the > print server. > > There may be other solutions, such as clustering of Web servers, which > solve the problem without the added complexity of Job-URIs. > > This problem is way beyond the 80% solution we are striving for and is > also a research area that is not well enough understood for us to be > creating requirements for a standard. > > > One last question ... if we take the course of adopting a job-id, > how do we rationalize the notion of the job being an object? In > my mind, the only object we are left with is the printer object, > because now all operations are on the printer. For example, we > no longer provide the URI of the job and tell it to cancel itself. > We send the operation to the printer and tell it to cancel the job. > Ditto for querying job attributes. The operation goes to the printer. > In my mind, this very fundamental change forever dictates the way > IPP will deal with jobs. If we ever want to imagine the job as a > real object with a life of its own, that can be moved around the > network (whether it be for load balancing, recovery, etc.), queried, > cancelled, indepdendent of where it lives, then we ought not to > bind it now to a printer and lose it's identity as an object. RGH: I see no reason why an object cannot be named by the pair RGH: (printer-URI, job-Id). The name and the object are separate RGH: concepts. The name is just a way to reference the object. > > I think that Jay's suggestion to allow an implementation to create > job URI's by cleverly using the integer job id's currently supported > by existing system API's is a fine way to solve the problem for most > cases. The standard doesn't require URLs to be created that way, > but neither should it dis-allow it if it makes life easier for a > particular implementation. > does it RGH: In Redmond, we considered and rejected the idea of having a Job-URI RGH: that could be parsed into its constituent printer-URI and Job-Id. RGH: It is certainly OK for a gateway to parse Job-URIs that it created, RGH: but according to our decision, it is not OK for a client to parse RGH: the job-URI from some server because they syntax of a Job-URI is RGH: unspecified. > > > > > >   Received: from cnri by ietf.org id aa24184; 5 Sep 97 19: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 TAA08091 for ; Fri, 5 Sep 1997 19:11:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA11351 for ; Fri, 5 Sep 1997 19:08:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 18:58:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09389 for ipp-outgoing; Fri, 5 Sep 1997 18:31:31 -0400 (EDT) Message-ID: <34108823.431912C2@underscore.com> Date: Fri, 05 Sep 1997 18:30:59 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709052137.OAA22774@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > The translation between printer-name (LPD or IPP) and printer-URI is > easy because of the two IPP attributes and because a name service is > likely to have both. Ok, I think I understand your position more clearly in this scenario. > On the other hand, jobs won't be in the name service because they are > transient, and the syntax of a job-URI is opaque so there is no way > to determine a Job-Id from a Job-URI. So let's not make Job-URI's opaque! (Starting to sound like a broken record here, I know...) Maybe I'm exposing my lack of web technology here, but why can't we just specify that the Job ID is always the last token of the URI and just be done with it? (for example: printsrv.corp.com/abc/xyz/123) Or is this to constraining for some people? If so, then I'd really appreciate someone explaining to everyone why this approach would be too constraining. ...jay   Received: from cnri by ietf.org id aa24366; 5 Sep 97 19: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 TAA08107 for ; Fri, 5 Sep 1997 19:18:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12035 for ; Fri, 5 Sep 1997 19:15:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 19:12:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10188 for ipp-outgoing; Fri, 5 Sep 1997 18:52:33 -0400 (EDT) Date: Fri, 5 Sep 1997 15:50:52 -0700 From: Robert Herriot Message-Id: <199709052250.PAA22871@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Fri Sep 5 15:20:56 1997 > > > But Microsoft clients cannot assume that all IPP servers will be > > Microsoft servers. Thus the client has no sure way to parse the > > Job-URI. > > So again I ask: exactly why can't (or shouldn't) we standardize on > a Job URI syntax? (I really regret not being able to have made the > Redmond meeting.) > I don't recollect a lot of reasons given on why there should not a standard syntax. I think there was a general philosophy that we shouldn't specify the syntax of URIs and, as I recollect, the people in Munich had the same reaction when we discussed this topic. Even if we did specify the syntax for a Job-URI, there is still the problem that its printer-URI constituent might be different from the printer-URI to which the job was submitted. That is also a problem for a gateway because a gateway assumes that a job is named by the printer to which the job was submitted plus a job-Id. If the job-printer is different, the gateway would have to "remember" that.   Received: from cnri by ietf.org id aa24822; 5 Sep 97 19: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 TAA08148 for ; Fri, 5 Sep 1997 19:37:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12716 for ; Fri, 5 Sep 1997 19:34:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 19:30:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12152 for ipp-outgoing; Fri, 5 Sep 1997 19:22:12 -0400 (EDT) Message-ID: <341093F3.9897195E@underscore.com> Date: Fri, 05 Sep 1997 19:21:23 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709052250.PAA22871@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > > > From jkm@underscore.com Fri Sep 5 15:20:56 1997 > > > > So again I ask: exactly why can't (or shouldn't) we standardize on > > a Job URI syntax? (I really regret not being able to have made the > > Redmond meeting.) > > > > I don't recollect a lot of reasons given on why there should not a > standard syntax. I think there was a general philosophy that we > shouldn't specify the syntax of URIs and, as I recollect, the people in > Munich had the same reaction when we discussed this topic. I think the IPP mailing list deserves a posting citing the reasons why URI specification is undesirable. Is anyone else out there interested in hearing the reasons? Or am I the only one believing that standard URI syntaxes would benefit IPP? > Even if we did specify the syntax for a Job-URI, there is still the > problem that its printer-URI constituent might be different from > the printer-URI to which the job was submitted. That is also a > problem for a gateway because a gateway assumes that a job is named by > the printer to which the job was submitted plus a job-Id. If the > job-printer is different, the gateway would have to "remember" that. I believe this is a different issue that should not be confused with the issue of standard URI syntax definitions. ...jay   Received: from cnri by ietf.org id aa26138; 5 Sep 97 20: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 UAA08266 for ; Fri, 5 Sep 1997 20:32:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14063 for ; Fri, 5 Sep 1997 20:29:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 20:17:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12944 for ipp-outgoing; Fri, 5 Sep 1997 19:57:26 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D7036073D9@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: 'Jay Martin' , Robert Herriot Cc: ipp@pwg.org Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Date: Fri, 5 Sep 1997 16:19:06 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org It was felt that a URl syntax would be highly specifc to a server implementation - ISAPI, ASP, CGI, ..... Specifying it would constrain the implementation > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, September 05, 1997 3:21 PM > To: Robert Herriot > Cc: ipp@pwg.org > Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > > But Microsoft clients cannot assume that all IPP servers will be > > Microsoft servers. Thus the client has no sure way to parse the > > Job-URI. > > So again I ask: exactly why can't (or shouldn't) we standardize on > a Job URI syntax? (I really regret not being able to have made the > Redmond meeting.) > > ...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 aa26265; 5 Sep 97 20: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 UAA08270 for ; Fri, 5 Sep 1997 20:37:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14828 for ; Fri, 5 Sep 1997 20:34:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 20:26:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12988 for ipp-outgoing; Fri, 5 Sep 1997 20:01:02 -0400 (EDT) Date: Fri, 5 Sep 1997 16:59:31 -0700 From: Robert Herriot Message-Id: <199709052359.QAA22965@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Fri Sep 5 16:21:30 1997 > > Robert Herriot wrote: > > > > > > Even if we did specify the syntax for a Job-URI, there is still the > > problem that its printer-URI constituent might be different from > > the printer-URI to which the job was submitted. That is also a > > problem for a gateway because a gateway assumes that a job is named by > > the printer to which the job was submitted plus a job-Id. If the > > job-printer is different, the gateway would have to "remember" that. > > I believe this is a different issue that should not be confused with > the issue of standard URI syntax definitions. > I disagree. A parseable Job-URI would still be a problem for gateways. That is, they would still need a job submitted to Printer P to have a job identification of (P,n) where n is some integer. >   Received: from cnri by ietf.org id aa26293; 5 Sep 97 20: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 UAA08273 for ; Fri, 5 Sep 1997 20:38:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14976 for ; Fri, 5 Sep 1997 20:35:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 20:27:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12977 for ipp-outgoing; Fri, 5 Sep 1997 20:00:46 -0400 (EDT) Date: Fri, 5 Sep 1997 16:59:56 -0700 From: Robert Herriot Message-Id: <199709052359.QAA22975@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org It was suggested at the last teleconference that we should have both Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. I want to make it clear at the outset of this email, that I am not taking a position on whether we should have both. Rather I want to explore what the ramifications are if we have both. The following are what I think the characteristics of such a solution are. If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST support both; otherwise, we are in worse shape than with just one of them from all servers. Client MUST be free to use whichever they want. For Print-Job, it doesn't matter whether a client specifies whether it wants a Job-URI or Job-ID, or whether the server returns both. In both cases, the server has to deal with both and the client has to be aware of the choice. So for this discussion, let's assume that the server would return both. For Get-Attributes and Cancel-Job, a server must implement these operations for both Job-URIs and Job-Ids. The target may be a Job-URI or the target may be a Printer-URI with a Job-Id attribute. Both Job-URI and Job-Id attributes are mandatory. Thus a client can query for either via Get-Jobs or Get-Attributes. The following discusses how this solution works with various gateways. This solution works well in Win32 because it would use the Job-Id only. It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. The IPP-to-LPD gateways work well because the Job-Id and Job-URL are both easy to support. So, acting as an IPP server, the gateway can easily support both together. The LPD-to-IPP gateway is easy to support with Job-Ids, so such a gateway, as a client of a IPP server, would use only the Job-Id and would ignore the Job-URL. So from a legacy point of view, the solution with both Job-URIs and Job-Ids is as good as the Job-Id solution only. But now we need to examine what this change means for server implementations. With this change servers would have a bit more work to do because they would have to offer two ways to do the same thing. Moreover, it is mandatory that if they support a particular operation, they must support both Job-URIs and Job-Id. That may be a burden that some implementors won't like -- more code for some abstract future payback. I expect that for most IPP servers its Job-URIs will always consists of its Printer-URI and a Job-Id so the server can easily convert between Job-URIs and Job-Ids with no architectural additions. But for servers that want the Job-URI to reference some remote host, the solution is more complicated because operations, such as Get-Attributes and Cancel-Job will go to the remote host when the client uses the Job-URI and these same operations will go to the Printer when the client uses the Printer-URI and Job-Id. Such servers will have to deal with forwarding issues and the fact that a Job-URI that references a remote host does not guarantee that all traffic goes there because client that use the Job-Id will still come to the original printer. As I said at the beginning of this email, I take no position on this proposal. Rather I offer it as the beginning of a discussion. I would like others to comment on whether this proposal solves the problem, or adds too much complexity to servers for the payback. Bob Herriot   Received: from cnri by ietf.org id aa27321; 5 Sep 97 21: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 VAA08323 for ; Fri, 5 Sep 1997 21:22:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16222 for ; Fri, 5 Sep 1997 21:19:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 21:12:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15196 for ipp-outgoing; Fri, 5 Sep 1997 20:56:26 -0400 (EDT) Message-Id: <9709060056.AA21288@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Sep 1997 17:53:46 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO latest protocol document - .pdf files stored Sender: ipp-owner@pwg.org I've stored red and black revision marks and no revision marks .pdf files. Tom -rw-r--r-- 1 pwg pwg 87469 Sep 6 00:53 ipp-pro-970904-rev-black.pdf -rw-r--r-- 1 pwg pwg 88902 Sep 6 00:53 ipp-pro-970904-rev-red.pdf -rw-r--r-- 1 pwg pwg 101888 Sep 4 19:18 ipp-pro-970904-rev.doc -rw-r--r-- 1 pwg pwg 90112 Sep 4 19:17 ipp-pro-970904.doc -rw-r--r-- 1 pwg pwg 70962 Sep 6 00:52 ipp-pro-970904.pdf -rw-r--r-- 1 pwg pwg 55887 Sep 4 19:27 ipp-pro-970904.txt >Return-Path: >Date: Thu, 4 Sep 1997 12:28:17 PDT >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO latest protocol document >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I just downloaded the latest version of the procotol document to > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO: > >The documents are: > > ipp-pro-970904-rev.doc (MS Word V6 with revisions) > ipp-pro-970904.doc (MS Word V6 with no revisions) > ipp-pro-970904.txt (text with no revisions) > >Tom will produce the PDF files. > > >Bob Herriot > > >   Received: from cnri by ietf.org id aa27342; 5 Sep 97 21: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 VAA08326 for ; Fri, 5 Sep 1997 21:23:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16348 for ; Fri, 5 Sep 1997 21:20:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 21:13:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15207 for ipp-outgoing; Fri, 5 Sep 1997 20:57:58 -0400 (EDT) Message-ID: <3410AB5A.D9CA3BD2@sharplabs.com> Date: Fri, 05 Sep 1997 18:01:14 -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: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? X-Priority: 3 (Normal) References: <199709052359.QAA22975@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob, Some of your discussion assumes that the use of the integer job-id and printer-uri combination would be included in operations to the original printer-uri. What if we included the integer job-id as an attribute within the operation, and after job submission and assignment, all operations were directed at the job-URI. The server handling the job-URI would then notice that the request is specifying an integer job-ID and it would use that instead of the information derived from the URI string? Randy Robert Herriot wrote: > > It was suggested at the last teleconference that we should have both > Job-URIs and Job-Ids. This email looks at the pros and cons of that > idea. > > I want to make it clear at the outset of this email, that I am not > taking > a position on whether we should have both. Rather I want to explore > what > the ramifications are if we have both. > > The following are what I think the characteristics of such a solution > are. > > If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST > support both; otherwise, we are in worse shape than with just one of > them from all servers. Client MUST be free to use whichever they want. > > For Print-Job, it doesn't matter whether a client specifies whether it > wants a Job-URI or Job-ID, or whether the server returns both. In > both > cases, the server has to deal with both and the client has to be aware > of the choice. So for this discussion, let's assume that the server > would return both. > > For Get-Attributes and Cancel-Job, a server must implement these > operations for both Job-URIs and Job-Ids. The target may be a Job-URI > or the target may be a Printer-URI with a Job-Id attribute. > > Both Job-URI and Job-Id attributes are mandatory. Thus a client can > query for either via Get-Jobs or Get-Attributes. > > The following discusses how this solution works with various gateways. > This solution works well in Win32 because it would use the Job-Id > only. > It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > > The IPP-to-LPD gateways work well because the Job-Id and Job-URL > are both easy to support. So, acting as an IPP server, the gateway can > easily support both together. > > The LPD-to-IPP gateway is easy to support with Job-Ids, so such a > gateway, as a client of a IPP server, would use only the Job-Id and > would ignore the Job-URL. > > So from a legacy point of view, the solution with both Job-URIs and > Job-Ids > is as good as the Job-Id solution only. > > But now we need to examine what this change means for server > implementations. > > With this change servers would have a bit more work to do because they > would have to offer two ways to do the same thing. Moreover, it is > mandatory that if they support a particular operation, they must > support both Job-URIs and Job-Id. That may be a burden that some > implementors won't like -- more code for some abstract future payback. > > I expect that for most IPP servers its Job-URIs will always consists > of > its Printer-URI and a Job-Id so the server can easily convert between > Job-URIs and Job-Ids with no architectural additions. > > But for servers that want the Job-URI to reference some remote host, > the solution is more complicated because operations, such as > Get-Attributes and Cancel-Job will go to the remote host when the > client uses the Job-URI and these same operations will go to the > Printer when the client uses the Printer-URI and Job-Id. Such servers > will have to deal with forwarding issues and the fact that a Job-URI > that references a remote host does not guarantee that all traffic goes > there because client that use the Job-Id will still come to the > original > printer. > > As I said at the beginning of this email, I take no position on this > proposal. Rather I offer it as the beginning of a discussion. > > I would like others to comment on whether this proposal solves the > problem, or adds too much complexity to servers for the payback. > > Bob Herriot   Received: from cnri by ietf.org id aa27850; 5 Sep 97 21: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 VAA08361 for ; Fri, 5 Sep 1997 21:44:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA17102 for ; Fri, 5 Sep 1997 21:41:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 21:36:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16510 for ipp-outgoing; Fri, 5 Sep 1997 21:28:07 -0400 (EDT) Date: Fri, 5 Sep 1997 18:24:06 -0700 From: Robert Herriot Message-Id: <199709060124.SAA23154@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, rturner@sharplabs.com Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rturner@sharplabs.com Fri Sep 5 18:15:34 1997 > > Bob, > > Some of your discussion assumes that the use of the integer job-id > and printer-uri combination would be included in operations to the > original printer-uri. > > What if we included the integer job-id as an attribute within the > operation, and after job submission and assignment, all operations > were directed at the job-URI. The server handling the job-URI would > then notice that the request is specifying an integer job-ID and > it would use that instead of the information derived from the > URI string? > > Randy > Your suggestion wouldn't work for the LPD-to-IPP gateway because it assumes that the target for all operations is the Printer specified by the LPD operation. The gateway can easily take the LPD (printer-name,Job-Id) and produce an IPP (Printer-URI,Job-Id), but it cannot produce an IPP Job-URI. I suspect the same problem exists for the win32 library. It is necessary that the Job-URI and the (Printer-URI,Job-Id) be separate interfaces at potentially different hosts in order for this proposal to work. Bob Herriot > > > > Robert Herriot wrote: > > > > It was suggested at the last teleconference that we should have both > > Job-URIs and Job-Ids. This email looks at the pros and cons of that > > idea. > > > > I want to make it clear at the outset of this email, that I am not > > taking > > a position on whether we should have both. Rather I want to explore > > what > > the ramifications are if we have both. > > > > The following are what I think the characteristics of such a solution > > are. > > > > If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST > > support both; otherwise, we are in worse shape than with just one of > > them from all servers. Client MUST be free to use whichever they want. > > > > For Print-Job, it doesn't matter whether a client specifies whether it > > wants a Job-URI or Job-ID, or whether the server returns both. In > > both > > cases, the server has to deal with both and the client has to be aware > > of the choice. So for this discussion, let's assume that the server > > would return both. > > > > For Get-Attributes and Cancel-Job, a server must implement these > > operations for both Job-URIs and Job-Ids. The target may be a Job-URI > > or the target may be a Printer-URI with a Job-Id attribute. > > > > Both Job-URI and Job-Id attributes are mandatory. Thus a client can > > query for either via Get-Jobs or Get-Attributes. > > > > The following discusses how this solution works with various gateways. > > This solution works well in Win32 because it would use the Job-Id > > only. > > It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > > > > The IPP-to-LPD gateways work well because the Job-Id and Job-URL > > are both easy to support. So, acting as an IPP server, the gateway can > > easily support both together. > > > > The LPD-to-IPP gateway is easy to support with Job-Ids, so such a > > gateway, as a client of a IPP server, would use only the Job-Id and > > would ignore the Job-URL. > > > > So from a legacy point of view, the solution with both Job-URIs and > > Job-Ids > > is as good as the Job-Id solution only. > > > > But now we need to examine what this change means for server > > implementations. > > > > With this change servers would have a bit more work to do because they > > would have to offer two ways to do the same thing. Moreover, it is > > mandatory that if they support a particular operation, they must > > support both Job-URIs and Job-Id. That may be a burden that some > > implementors won't like -- more code for some abstract future payback. > > > > I expect that for most IPP servers its Job-URIs will always consists > > of > > its Printer-URI and a Job-Id so the server can easily convert between > > Job-URIs and Job-Ids with no architectural additions. > > > > But for servers that want the Job-URI to reference some remote host, > > the solution is more complicated because operations, such as > > Get-Attributes and Cancel-Job will go to the remote host when the > > client uses the Job-URI and these same operations will go to the > > Printer when the client uses the Printer-URI and Job-Id. Such servers > > will have to deal with forwarding issues and the fact that a Job-URI > > that references a remote host does not guarantee that all traffic goes > > there because client that use the Job-Id will still come to the > > original > > printer. > > > > As I said at the beginning of this email, I take no position on this > > proposal. Rather I offer it as the beginning of a discussion. > > > > I would like others to comment on whether this proposal solves the > > problem, or adds too much complexity to servers for the payback. > > > > Bob Herriot >   Received: from cnri by ietf.org id aa28100; 5 Sep 97 21: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 VAA08381 for ; Fri, 5 Sep 1997 21:57:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA17709 for ; Fri, 5 Sep 1997 21:53:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 21:49:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16888 for ipp-outgoing; Fri, 5 Sep 1997 21:39:08 -0400 (EDT) Message-ID: <3410B4FF.D6A487F6@sharplabs.com> Date: Fri, 05 Sep 1997 18:42:23 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Job-URI discussion X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------BAC48DC27EEA630E5822BCF5" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------BAC48DC27EEA630E5822BCF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The attachment is a synopsis of my thinking on the current job-URI/job-ID issue. Let me know if you can't read the attachment. Randy --------------BAC48DC27EEA630E5822BCF5 Content-Type: text/plain; charset=us-ascii; name="ipprat.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipprat.txt" I have looked into the Microsoft spooler API over the last 2 days and have come up with the following conclusions. The Microsoft Spooler architecture (at least for Win95) contains an AddJob() function that, along with other information, returns a job identification value (DWORD) which is a 32-bit value. This value is instantiated internal to the spooling subsystem. This DWORD value (job-ID) is what is used to refer to the job in other API calls. When you request an IPP server to create a job, it allocates resources and also assigns a unique job-ID to reference that job. This job-id can either be a URI or an INTEGER. Regardless of the choice of a job-id format, it looks like a win95 IPP client will always need to maintain a mapping between the win95-created job-id and the IPP server-created job-id. As far as LPD gateways, much of the "bypass" logic mentioned in Bob's earlier message, where an LPD client bypasses the gateway for some reason is pathological and references a very high-sigma case. I don't think the architecture of legacy gateways should severely impact the nature and flexibility of what we are designing. It might seem hard to believe, but more than one vendor I know of is planning on native IPP support for distributed internet/intranet printing. Alot of what we have in the model as far as negotiation of features and best-effort philosophies is not supported by legacy print systems but we have included it because someone "might" want to do this type of print-feature verification. The capabilities of legacy systems should not dictate the architecture of what we are doing, unless what we are proposing absolutely breaks existing print systems, and IMHO, nothing that we have proposed does this. The flexibility of job URIs with regards to server design and protocol scalability are not "difficult to understand". If we are designing a printing protocol what will be constrained to a particular size environment, then alot of the rationale for scalability disappears. But if what we are proposing is to allow IPP to scale from small departmental environments all the way up to enterprise internetworks, then we need to consider scalability, and server-generated job URIs are a really good way to do this. Some examples of the type of flexibility and scalability follow: The syntax of a URI/URL is: scheme: For an HTTP scheme URL, the following syntax is observed: HTTP://:/path-name-to-resource;parameters?query For flexibility and scalability, the IPP server may elect to vary any of the HTTP scheme fields (host, port, pathname, parameters) depending upon IPP server policy. An authenticating IPP server may distribute jobs to different hosts for load balancing depending upon what value the "host" field is set to on the returned job-URI. These jobs may not only be distributed to different physical host machines, but possibly differently configured IPP servers running on the same host, but at different port numbers. These multiple server threads can either be started at boot time or dynamically spawned by a particular master IPP server thread so the IPP service burden floats with the actual amount of job load being handled. For a particular centralized IPP server, the URL might be: HTTP://ipp.kinkos.com/main This URL would be the target of initial print job requests by potential clients. Also, in a directory services environment, an administrator might only want to maintain very few entries in the directory for key IPP servers, then let those servers distribute jobs as needed to other secondary servers. This eases the burden of maintaining directory entries for every possible IPP-capable printer on the network. Some other types of job distribution can occur when a particular site has IPP servers installed on large file servers or enterprise servers, as well as IPP services embedded in some subset of printers on the network. The server-based IPP implementation might be very robust and support all the features of IPP (both mandatory and optional), and provide spooling services. This key IPP server might handle all of the complex negotiation and other features of IPP, while a much lighter weight version of IPP exists in the printer. This would allow access to the printer by complex printing clients that fully utilize IPP (through the master server), as well as simple clients that only want to do very basic printing (they can use IPP to print directly to the printer if they so desire). Along with the job-URI, the authenticating IPP server may elect to embed into the parameters section some key information regarding the job owner, or possibly some type of server-dependent job-index or key that facilitates easy access to job accounting or other job managment information. Again, these fields are basically opaque to the IPP client. There was also rationale in my previous comments to the fact that URI specifications and HTTP allow dynamic redirection of print jobs. The redirection of print jobs may be a result of administrative operator intervention, or used to provide some level of fault tolerance if a particular job is redirected due to some printing device becoming unavailable. Again, using HTTP redirects allows the client to follow this redirection easily. In practice, any caching of the previous job URI by the client, or by a gateway, would have to be refreshed. This is less of an issue with clients than it might be for a gateway. But IMHO this solution is far better than designing an entirely new solution of our own, just for IPP. Getting back to the LPD gateway problem, while I am writing this, Jay's mail message stating that "there is no way for an LPD client to know what job id was created on job submission" echoes a conversation Jay and I had on the phone earlier. RFC 1179 states that the only way an LPD client knows how to reference a job is by executing a subsequent LPQ request and obtaining a list of jobs and hoping that the LPD server's job list contains enough unique information for the end user to pick out his or her job from the list. Note that the design of this protocol was that a human end user would be doing this. LPD servers can return whatever format they want for the job list, and human intuition can easily parse the returned information to pick out the correct job ID (hopefully). But when a machine has to do this, it becomes a much more difficult task. I always thought that the only time we would be gateway'ing between LPD and IPP would be in the case of a server-based implementation of IPP; wherein an IPP server takes requests from an IPP client and possibly converts the user's request into an equivalent LPR request to some legacy server (or printer). I don't consider the scenario of an LPD client talking over the network to a IPP server to be a viable scenario. For transitional purposes, administrators should not be tearing down their existing printing environments, in this case, we don't have to worry about actually converting LPD control file attributes to IPP equivalents; because each site's existing LPD environment works fine as it is. I think what we have to worry about are server-based IPP implementations that have to map IPP client requests to whatever existing legacy print environment is in use for a particular OS environment, whether it be the Microsoft spooler interface, or a Unix LP or LPD environment. Let me know if I'm missing a key scenario here...(I'm sure you will :) I am hoping that IPP<->LPD gateway philosophy is geared towards providing some type of "transition" to native IPP. I am also trying to figure out if Jay's proposal to at least add one "known" field to the job-URI string, that being the last field in the string is the "job-index", is violating too much of the idea of client opacity to the job-URI syntax. --------------BAC48DC27EEA630E5822BCF5--   Received: from cnri by ietf.org id aa07000; 5 Sep 97 23: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 XAA08495 for ; Fri, 5 Sep 1997 23:20:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA18735 for ; Fri, 5 Sep 1997 23:17:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Sep 1997 23:13:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA18167 for ipp-outgoing; Fri, 5 Sep 1997 23:04:31 -0400 (EDT) Message-ID: <3410C80D.78BBFA54@underscore.com> Date: Fri, 05 Sep 1997 23:03:41 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: IPP mailing list Subject: IPP> Job-URI vs. Job-Id: How would you handle moving jobs? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Since the Job-Id approach implicitly uses the Printer-URL, then how would you handle moving jobs between Printers? Wouldn't this present something of a showstopping problem? How would the client keep track of the change in Job-Id, much less the change in Printer? For printing systems using IPP, it would seem that the Job-URL approach would suffice quite nicely due to the inherent opacity of the job identification. Comments? ...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 aa08279; 7 Sep 97 13: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 NAA10811 for ; Sun, 7 Sep 1997 13:37:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23222 for ; Sun, 7 Sep 1997 13:34:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Sep 1997 13:26:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22724 for ipp-outgoing; Sun, 7 Sep 1997 13:18:06 -0400 (EDT) Date: Sun, 7 Sep 1997 10:21:18 PDT From: Ira Mcdonald x10962 Message-Id: <9709071721.AA07389@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, ipp@pwg.org Subject: IPP> My comments on IPP Model draft of 3 Sept Sender: ipp-owner@pwg.org Scott Isaacson and IPP folks, Sunday (7 September 1997) Below are my comments on the latest draft IPP Model, using the plaintext I-D form, 'ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970903.txt'. I have stated section numbers and page numbers from the plaintext I-D. Hope these are helpful. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------------------------------------------------------ 1) Global - conformance keywords - change all 'must' to uppercase 'MUST' - change all 'shall' and 'SHALL' to uppercase 'MUST' - reference for 'NEED NOT' is POSIX.2 (ISO 9945-2) - please add 2) Global - directories - I suggest folding the IPP Directory document into the body of the IPP Model document (for clarity, same as for IPP Security) - IPP documents are generally fuzzy about directories and names, saying that a 'printer-name' is NOT necessarily unique, but also saying that directories may be used to find printers by name - NO directory contains 'URLs' (some may contain 'URNs') - see comment (3) below 3) Global - URIs, URLs, and URNs - RFC 1738 and RFC 1808 do NOT define URIs - they define ONLY the location-dependent URLs (Uniform Resource Locators) - All IPP usage of URIs implies location-dependence, so that 'URI' (which may also refer to a 'URN', location-independent Uniform Resource Name, defined in RFC 2141) should NOT be used in IPP - change 'Universal Resource Identifier' throughout document to 'Uniform Resource Locator' (universality NOT stated by RFC 1738) - change 'uri' and 'URI' throughout document to 'url' and 'URL' (to make clear that location-dependent IDs and NOT names are used) - lastly, parsing URLs is perfectly reasonable - RFC 1808 specifies rules for parsing all 'well-formed' URLs 4) Section 3.2.6 'Get-Jobs Operation', page 25 - change 'retrieve the list of jobs' to 'retrieve the ordered list of jobs' - add a forward reference to ordering details in section 3.2.6.1 'Get-Jobs Response' on page 26 5) Section 4 'Object Attributes', page 31 - change 'Printer MIB (Draft Standard in progress...' to 'Printer MIB (work-in-progress...' (the possible future state of the Printer MIB should NOT be speculated on in an I-D) - remove all references to the 'Job Monitoring MIB' (there is no IETF charter and Harald A has recommended the Job Mon MIB be published as an Informational RFC, if at all) 6) Section 4.1 'Attribute Syntaxes', page 31 '1' - 'text': - why is length of 'text' up to '4095' and NOT '255' (same as 'name' and 'keyword')?? - IETF SMIv1 and SMIv2 rules limit OCTET STRING in MIBs to 255 - if you permit greater than 255, then you need to make trunctation rules explicit (for export by MIB or other limited interfaces) 7) Section 4.1 'Attribute Syntaxes', page 32 '5' - 'uri': - see comment (3) above 8) Section 4.1 'Attribute Syntaxes', page 33 '11' - 'dateTime': - reference the correct name in RFC 1514/1903, ie, 'DateAndTime' 9) Section 4.2 'Job Template Attributes', page 34 Section 4.2.4 'job-priority', page 39 - description of range and use of 'job-priority' does NOT agree with DPA and Job Mon MIB (which say that ALL systems support 1 to 100 as an APPARENT range, with equal spacing between legal values, for less fine-grained local priority schemes) - from ISO 10175, section 9.2.4.6 'Job-priority' "Priority is expected to be evenly or 'normally' distrbuted across this range." 10) Section 4.2.2.1 'Event Notification Content', page 38-39 - restriction to 'US ASCII' for 'message' is unreasonable, given IPP mandate of 'ISO 10646 w/ UTF-8 encoding', and NOT human-friendly - the idea that application programs will process the content of 'message' (reliably) is implausible - it is MAINLY for humans - this is NOT aligned with section 4.3.10 'job-state-message' which uses 'text' (any language, in UTF-8) - why doesn't the 'user-human-language' attribute apply to messages? - see comment (12) below 11) Section 4.2.16 'document-format', page 45 - section 13 should NOT list MIME types explicitly - IPP documents should supply pointers to the MIME registry at IANA 12) Section 4.3.7 'user-human-language', page 49 - rename to 'job-user-human-language' for clarity (and distinction from the similar Printer object attribute) 13) Section 4.3.12-14 'time-since-pending/processing/completed', page 53 - change names to 'time-at-...', per table in section 4.3, page 47 and section 4.5.21 'printer-up-time', page 65 - change units to 'seconds', per table in section 4.3, page 47 and section 4.5.21 'printer-up-time', page 65 14) Section 4.5.19 'pdl-override', page 64 - change type to 'boolean' - 'attempted' and 'not-attempted' are obscure, with no benefit 15) Section 7. 'Internationalization Considerations', page 70 - the sentence 'Since these are optional...specific to a given site' is meaningless - 'xxx-human-language' attributes need to be MANDATORY (per August IETF Plenary in Munich) - Harald Alvestrand's I-D 'Charset Policy' (June 1997, reviewed in Munich in August), section 4.3 'Considerations for negotiation': "Protocols that transfer human-readable text MUST provide for multiple languages... Negotiating a language should be regarded as a PERMANENT requirement of the protocol that will not go away at any time in the future." 16) Section 13 'Appendix C: "document-format" values', page 87 - delete entire appendix, add reference to IANA MIME registry   Received: from cnri by ietf.org id aa01317; 8 Sep 97 3: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 DAA11983 for ; Mon, 8 Sep 1997 03:47:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA24764 for ; Mon, 8 Sep 1997 03:44:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 03:39:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA24265 for ipp-outgoing; Mon, 8 Sep 1997 03:31:06 -0400 (EDT) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: Carl-Uno Manros , Keith Moore , ipp@pwg.org, masinter@parc.xerox.com Subject: Re: IPP> Re: SEC - IPP Security Requirements In-reply-to: Your message of "Fri, 05 Sep 1997 07:25:51 PDT." <1.5.4.32.19970905142551.00673e24@pop3.holonet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Sep 1997 09:30:22 +0200 Message-ID: <2634.873703822@dale.uninett.no> Sender: ipp-owner@pwg.org Seems I've fallen off the ietf-tls list too. I'll try resubscribing. Harald A   Received: from cnri by ietf.org id aa10388; 8 Sep 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 NAA13560 for ; Mon, 8 Sep 1997 13:50:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA26233 for ; Mon, 8 Sep 1997 13:47:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 13:39:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA25715 for ipp-outgoing; Mon, 8 Sep 1997 13:31:00 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES Phone conference agenda Date: Mon, 8 Sep 1997 10:33:36 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Sep8.103046pdt."52075(3)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, I thought about an agenda. No one sent any suggested items. I thought we might as well keep it simple. Our first teleconference will be a brainstorming session to help set the objectives and direction for the TES group. I expect our conversations will wander a bit. 1) First Steps. a) What are we trying to accomplish? b) Are there any barriers that must be resoled to accomplish our goal? 2) Next Steps. a) What are some proposals on accomplishing our goal? b) How do we get started? Once again, I have set up a phone conference for Tuesday September 9. The time is 1pm eastern. The number is 1-800-857-5608 (8*535-6000 for Xerox people). The passcode is 4858. Pete By the way, here is the list of individuals that have expressed interest in IPP prototyping. Bob Chansler (Adobe) Kurt Werle (Apple Computer, Inc.) Ashok Maniam (Byas Systems) Lee Farrell (Cannon) Dan Cogswell (IBM) Steve Gebert (IBM) Ted Tronson (Novell) Randy Turner (Sharp) Peter Michalek (Shinesoft) Jay Martin (Underscore) Zhi-Hong Huang (Zenographics) Rick Yardumian (Xerox) Peter Zehler (Xerox) Jasper Wong (Xionics)   Received: from cnri by ietf.org id aa12517; 8 Sep 97 16: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 QAA14207 for ; Mon, 8 Sep 1997 16:10:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26995 for ; Mon, 8 Sep 1997 16:06:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 15:58:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA26432 for ipp-outgoing; Mon, 8 Sep 1997 15:49:56 -0400 (EDT) Message-ID: <3413FCB2.8FB39603@parc.xerox.com> Date: Mon, 8 Sep 1997 06:25:06 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP>MOD - job-sheet-content attribute X-Priority: 3 (Normal) References: <5030100007699359000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org It would be much better for the server to send back a _form_ to the client for presentation to the user, rather than creating yet another ad-hoc representation for a form with such a weak semantics. There are lots of details of your proposal that are incomplete (ASCII instead of UTF-8, no constraints on length or data types of input, questions about the requested language for prompts, etc.) Larry   Received: from cnri by ietf.org id aa12636; 8 Sep 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 QAA14258 for ; Mon, 8 Sep 1997 16:17:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA27559 for ; Mon, 8 Sep 1997 16:14:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 16:10:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA26464 for ipp-outgoing; Mon, 8 Sep 1997 15:58:29 -0400 (EDT) Date: Mon, 8 Sep 1997 12:56:41 -0700 From: Robert Herriot Message-Id: <199709081956.MAA25338@woden.eng.sun.com> To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Fri Sep 5 20:13:55 1997 > > Since the Job-Id approach implicitly uses the Printer-URL, then > how would you handle moving jobs between Printers? Wouldn't this > present something of a showstopping problem? How would the client > keep track of the change in Job-Id, much less the change in Printer? > > For printing systems using IPP, it would seem that the Job-URL > approach would suffice quite nicely due to the inherent opacity > of the job identification. > > Comments? > It seems to me that there are two solutions to this problem. Either a) a job has a constant identification for its life or b) an identification that changes when it moves. In case a, it doesn't matter whether a job has a job-URI or a (printer-URI,job-Id), the same server manages the job for its duration regardless of the location of the job Case b may seem simpler because of the redirection that can be applied to Job-URI. But this apparent simplicity hides the complexity of how long the forwarding-server keeps a record of a job that it no longer controls. The simplest solution for this case may be the same as for case a, namely the server keeps a forwarding record for the duration of the job. I stand by my previous statements, that the cited advantages of a job-URI are based on speculation. I have not seen anyone provide enough detail for us to understand the full solution for the move-job problem. I have no problem with a design that might make the solution of future problems easy as long as it doesn't affect the solution to current well-understood problems. Bob Herriot   Received: from cnri by ietf.org id aa12958; 8 Sep 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 QAA14371 for ; Mon, 8 Sep 1997 16:37:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28173 for ; Mon, 8 Sep 1997 16:34:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 16:30:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27678 for ipp-outgoing; Mon, 8 Sep 1997 16:21:53 -0400 (EDT) Date: Mon, 8 Sep 1997 13:21:03 -0700 From: Robert Herriot Message-Id: <199709082021.NAA25368@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Job-URI discussion X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rturner@sharplabs.com Fri Sep 5 18:50:19 1997 > I don't consider the scenario of an LPD client talking over the network > to a IPP server to be a viable scenario. For transitional purposes, > administrators should not be tearing down their existing printing > environments, in this case, we don't have to worry about actually > converting LPD control file attributes to IPP equivalents; because each > site's existing LPD environment works fine as it is. You forgot about the very important case of new IPP servers having to take jobs from existing LPD clients. This will require LPD-to-IPP gateways on such servers in order to allow for an orderly transition of customers. Those clients expect job-Ids which are INTEGERS. Otherwise, they break. > Getting back to the LPD gateway problem, while I am writing this, Jay's > mail message stating that "there is no way for an LPD client to know > what job id was created on job submission" echoes a conversation Jay > and I had on the phone earlier. RFC 1179 states that the only way an > LPD client knows how to reference a job is by executing a subsequent > LPQ request and obtaining a list of jobs and hoping that the LPD server's > job list contains enough unique information for the end user to pick out > his or her job from the list. It is true that a client does not get the job-Id from lpr, but there is still the round trip problem where the client gets a job-Id via lpq and then returns it via lprm. The LPD-to-IPP gateway has to know which IPP job-ID/job-URI is associated with the LPD job-ID received with the lprm command. That is the hard part when IPP supports only job-URI; and it is a real problem, not an imagined one. Bob Herriot   Received: from cnri by ietf.org id aa13276; 8 Sep 97 16: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 QAA14438 for ; Mon, 8 Sep 1997 16:59:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28846 for ; Mon, 8 Sep 1997 16:56:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 16:52:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28318 for ipp-outgoing; Mon, 8 Sep 1997 16:43:59 -0400 (EDT) Message-ID: <34146458.3486CA87@sharplabs.com> Date: Mon, 08 Sep 1997 13:47:20 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Job-URI discussion X-Priority: 3 (Normal) References: <199709082021.NAA25368@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > > > From rturner@sharplabs.com Fri Sep 5 18:50:19 1997 > > > I don't consider the scenario of an LPD client talking over the > network > > to a IPP server to be a viable scenario. For transitional purposes, > > administrators should not be tearing down their existing printing > > environments, in this case, we don't have to worry about actually > > converting LPD control file attributes to IPP equivalents; because > each > > site's existing LPD environment works fine as it is. > > You forgot about the very important case of new IPP servers having to > take jobs from existing LPD clients. This will require LPD-to-IPP > gateways > on such servers in order to allow for an orderly transition of > customers. This is the case I was talking about, I don't think this is a prevalent case. The currently existing base of LPR clients currently use LPR/LPD to print, and these systems work. When transitioning to IPP, I don't expect these systems to be torn down. Rather, I expect client to slowly be configured with IPP clients. You could even have a hybrid case where the LPR/remote-LP (SYSV) system has their respective "printcap" file entries for certain IPP-enabled servers point to shell scripts that automatically launch a real IPP client to do the "over-the-wire" stuff. Overall, I don't consider this particular gateway problem to be worthy of altering the original model. The real value in getting IPP to users is not enabling LPR clients, its enabling IPP clients being able to locate IPP printers via the WEB and subsequently printing to them. I think we're spending too much time trying to save gateway writers a few lines of code. Randy > > Those clients expect job-Ids which are INTEGERS. Otherwise, they > break. > > > Getting back to the LPD gateway problem, while I am writing this, > Jay's > > mail message stating that "there is no way for an LPD client to know > > what job id was created on job submission" echoes a conversation Jay > > and I had on the phone earlier. RFC 1179 states that the only way an > > LPD client knows how to reference a job is by executing a subsequent > > LPQ request and obtaining a list of jobs and hoping that the LPD > server's > > job list contains enough unique information for the end user to pick > out > > his or her job from the list. > > It is true that a client does not get the job-Id from lpr, but there > is > still the round trip problem where the client gets a job-Id via lpq > and > then returns it via lprm. The LPD-to-IPP gateway has to know which IPP > job-ID/job-URI is associated with the LPD job-ID received with the > lprm > command. That is the hard part when IPP supports only job-URI; and it > is a real problem, not an imagined one. > > Bob Herriot   Received: from cnri by ietf.org id aa14368; 8 Sep 97 18: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 SAA14731 for ; Mon, 8 Sep 1997 18:12:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA29551 for ; Mon, 8 Sep 1997 18:09:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 18:01:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29021 for ipp-outgoing; Mon, 8 Sep 1997 17:52:26 -0400 (EDT) Date: Mon, 8 Sep 1997 14:51:32 -0700 From: Robert Herriot Message-Id: <199709082151.OAA25431@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Job-URI discussion X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that you are missing a piece in the transition story. Customers will install print servers that run IPP servers, but printers acessible via these servers must also be accessible via LPD protocol for those client still running older systems. Thus these new IPP servers will also have to support LPD as well, either directly or via an LPD-to-IPP gateway. Bob Herriot > From rturner@sharplabs.com Mon Sep 8 13:53:38 1997 > > Robert Herriot wrote: > > > > > From rturner@sharplabs.com Fri Sep 5 18:50:19 1997 > > > > > I don't consider the scenario of an LPD client talking over the > > network > > > to a IPP server to be a viable scenario. For transitional purposes, > > > administrators should not be tearing down their existing printing > > > environments, in this case, we don't have to worry about actually > > > converting LPD control file attributes to IPP equivalents; because > > each > > > site's existing LPD environment works fine as it is. > > > > You forgot about the very important case of new IPP servers having to > > take jobs from existing LPD clients. This will require LPD-to-IPP > > gateways > > on such servers in order to allow for an orderly transition of > > customers. > > This is the case I was talking about, I don't think this is a > prevalent case. The currently existing base of LPR clients currently > use LPR/LPD to print, and these systems work. When transitioning > to IPP, I don't expect these systems to be torn down. Rather, I > expect client to slowly be configured with IPP clients. You could > even have a hybrid case where the LPR/remote-LP (SYSV) system has > their respective "printcap" file entries for certain IPP-enabled > servers point to shell scripts that automatically launch a real > IPP client to do the "over-the-wire" stuff. > > Overall, I don't consider this particular gateway problem to be > worthy of altering the original model. The real value in getting > IPP to users is not enabling LPR clients, its enabling IPP clients > being able to locate IPP printers via the WEB and subsequently > printing to them. I think we're spending too much time trying to > save gateway writers a few lines of code. > > Randy > > > > > > Those clients expect job-Ids which are INTEGERS. Otherwise, they > > break. > > > > > Getting back to the LPD gateway problem, while I am writing this, > > Jay's > > > mail message stating that "there is no way for an LPD client to know > > > what job id was created on job submission" echoes a conversation Jay > > > and I had on the phone earlier. RFC 1179 states that the only way an > > > LPD client knows how to reference a job is by executing a subsequent > > > LPQ request and obtaining a list of jobs and hoping that the LPD > > server's > > > job list contains enough unique information for the end user to pick > > out > > > his or her job from the list. > > > > It is true that a client does not get the job-Id from lpr, but there > > is > > still the round trip problem where the client gets a job-Id via lpq > > and > > then returns it via lprm. The LPD-to-IPP gateway has to know which IPP > > job-ID/job-URI is associated with the LPD job-ID received with the > > lprm > > command. That is the hard part when IPP supports only job-URI; and it > > is a real problem, not an imagined one. > > > > Bob Herriot >   Received: from cnri by ietf.org id aa14566; 8 Sep 97 18: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 SAA14788 for ; Mon, 8 Sep 1997 18:27:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00163 for ; Mon, 8 Sep 1997 18:24:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 18:17:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29055 for ipp-outgoing; Mon, 8 Sep 1997 18:00:36 -0400 (EDT) Message-ID: <34147595.DBA4F2E2@underscore.com> Date: Mon, 08 Sep 1997 18:00:53 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: IPP mailing list Subject: Re: IPP> Job-URI discussion References: <199709082021.NAA25368@woden.eng.sun.com> <34146458.3486CA87@sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Randy wrote something that I think a lot of us seem to overlook: > Overall, I don't consider this particular gateway problem to be > worthy of altering the original model. The real value in getting > IPP to users is not enabling LPR clients, its enabling IPP clients > being able to locate IPP printers via the WEB and subsequently > printing to them. I think we're spending too much time trying to > save gateway writers a few lines of code. Randy's right (IMHO), that the REAL challenge is to get IPP clients out in the field. Printers and print server systems will probably support LPR/LPD long into the future, and Randy makes a good point that existing clients will continue to use that infrastructure. Bob has made some good points in the last few messages, but I think Randy has really hit the nail on the head...at least with respect to LPR/LPD. Windows may be a different animal to deal with, though... ...jay   Received: from cnri by ietf.org id aa14661; 8 Sep 97 18: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 SAA14823 for ; Mon, 8 Sep 1997 18:33:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00927 for ; Mon, 8 Sep 1997 18:30:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 18:24:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29570 for ipp-outgoing; Mon, 8 Sep 1997 18:09:21 -0400 (EDT) Message-ID: <34147851.D494AAED@sharplabs.com> Date: Mon, 08 Sep 1997 15:12:33 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Job-URI discussion X-Priority: 3 (Normal) References: <199709082151.OAA25431@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 you are missing a piece in the transition story. > Customers will install print servers that run IPP servers, but > printers > acessible via these servers must also be accessible via LPD protocol > for those client still running older systems. Thus these new IPP > servers > will also have to support LPD as well, either directly or via an > LPD-to-IPP gateway. I'm assuming that you're talking about the installation of a new print server box, since existing print server boxes would be running LPD already for the existing LPR clients. In the case of a new print server being installed that will host IPP services, if the administrator also wants LPD support, why can't he/she enable LPD as well and run LPD<->LPD? Maybe we should be exchanging graphical pictures ... Randy > > Bob Herriot > > > > From rturner@sharplabs.com Mon Sep 8 13:53:38 1997 > > > > Robert Herriot wrote: > > > > > > > From rturner@sharplabs.com Fri Sep 5 18:50:19 1997 > > > > > > > I don't consider the scenario of an LPD client talking over the > > > network > > > > to a IPP server to be a viable scenario. For transitional > purposes, > > > > administrators should not be tearing down their existing > printing > > > > environments, in this case, we don't have to worry about > actually > > > > converting LPD control file attributes to IPP equivalents; > because > > > each > > > > site's existing LPD environment works fine as it is. > > > > > > You forgot about the very important case of new IPP servers having > to > > > take jobs from existing LPD clients. This will require LPD-to-IPP > > > gateways > > > on such servers in order to allow for an orderly transition of > > > customers. > > > > This is the case I was talking about, I don't think this is a > > prevalent case. The currently existing base of LPR clients currently > > use LPR/LPD to print, and these systems work. When transitioning > > to IPP, I don't expect these systems to be torn down. Rather, I > > expect client to slowly be configured with IPP clients. You could > > even have a hybrid case where the LPR/remote-LP (SYSV) system has > > their respective "printcap" file entries for certain IPP-enabled > > servers point to shell scripts that automatically launch a real > > IPP client to do the "over-the-wire" stuff. > > > > Overall, I don't consider this particular gateway problem to be > > worthy of altering the original model. The real value in getting > > IPP to users is not enabling LPR clients, its enabling IPP clients > > being able to locate IPP printers via the WEB and subsequently > > printing to them. I think we're spending too much time trying to > > save gateway writers a few lines of code. > > > > Randy > > > >   Received: from cnri by ietf.org id aa15099; 8 Sep 97 19: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 TAA14899 for ; Mon, 8 Sep 1997 19:07:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01717 for ; Mon, 8 Sep 1997 19:03:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 19:01:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01321 for jmp-outgoing; Mon, 8 Sep 1997 18:59:04 -0400 (EDT) From: don@lexmark.com Message-Id: <199709082258.AA27950@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, fin@pwg.org, p1394@pwg.org Date: Mon, 8 Sep 1997 18:53:41 -0400 Subject: JMP> Atlanta Ping List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org I have created a list on the Web site of those who have pinged for the Atlanta meeting. It is available off the Atlanta meeting page or directly at http://www.pwg.org/chair/atl-ping.html. If you didn't ping me and show up --- well I'll figure out what the penalty is later. Conversely, if you pinged me and no show, the price is your share of the meeting cost anyway!!! 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 aa15251; 8 Sep 97 19: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 TAA14930 for ; Mon, 8 Sep 1997 19:19:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02424 for ; Mon, 8 Sep 1997 19:15:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 19:09:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01358 for pwg-outgoing; Mon, 8 Sep 1997 18:59:31 -0400 (EDT) From: don@lexmark.com Message-Id: <199709082258.AA27950@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, fin@pwg.org, p1394@pwg.org Date: Mon, 8 Sep 1997 18:53:41 -0400 Subject: PWG> Atlanta Ping List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org I have created a list on the Web site of those who have pinged for the Atlanta meeting. It is available off the Atlanta meeting page or directly at http://www.pwg.org/chair/atl-ping.html. If you didn't ping me and show up --- well I'll figure out what the penalty is later. Conversely, if you pinged me and no show, the price is your share of the meeting cost anyway!!! 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 aa15301; 8 Sep 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 TAA14937 for ; Mon, 8 Sep 1997 19:22:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02848 for ; Mon, 8 Sep 1997 19:19:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 19:14:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01338 for ipp-outgoing; Mon, 8 Sep 1997 18:59:14 -0400 (EDT) From: don@lexmark.com Message-Id: <199709082258.AA27950@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, fin@pwg.org, p1394@pwg.org Date: Mon, 8 Sep 1997 18:53:41 -0400 Subject: IPP> Atlanta Ping List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I have created a list on the Web site of those who have pinged for the Atlanta meeting. It is available off the Atlanta meeting page or directly at http://www.pwg.org/chair/atl-ping.html. If you didn't ping me and show up --- well I'll figure out what the penalty is later. Conversely, if you pinged me and no show, the price is your share of the meeting cost anyway!!! 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 aa16484; 8 Sep 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 UAA15089 for ; Mon, 8 Sep 1997 20:48:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04162 for ; Mon, 8 Sep 1997 20:45:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 20:41:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03671 for ipp-outgoing; Mon, 8 Sep 1997 20:32:37 -0400 (EDT) Date: Mon, 8 Sep 1997 17:31:48 -0700 From: Robert Herriot Message-Id: <199709090031.RAA25647@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD PRO Dictionary type X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org If Tom's proposal for dictionary is accepted, then I suggest that it be described a) in the model document: "a dictionary consists of a collection zero or more attributes (name and value pairs)" b) in the protocol document: "an octet string whose syntax is 'attribute-sequence'. The value-length is number of octets in the entire attribute-sequence contained in the value" I think that this language suffices to define it. The protocol document should also contain an example. Bob Herriot   Received: from cnri by ietf.org id aa17213; 8 Sep 97 21: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 VAA15162 for ; Mon, 8 Sep 1997 21:46:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA04871 for ; Mon, 8 Sep 1997 21:43:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Sep 1997 21:39:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA04363 for ipp-outgoing; Mon, 8 Sep 1997 21:30:42 -0400 (EDT) Message-Id: <9709090130.AA21777@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, 8 Sep 1997 18:27:56 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Terminology: "Internet media type" vs. "MIME-type" Sender: ipp-owner@pwg.org >Return-Path: >Date: Wed, 3 Sep 1997 12:48:29 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Cc: cmanros@cp10.es.xerox.com >Subject: Re: IPP> MOD - document-format-supported using MIME types and > 'automatic' >References: <9709031827.AA20260@zazen.cp10.es.xerox.com> > >"Internet media type" is the official name of what is informally >known as a "MIME-type"; they're the same. > >Larry >-- >http://www.parc.xerox.com/masinter > >   Received: from cnri by ietf.org id aa25687; 9 Sep 97 0: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 AAA15488 for ; Tue, 9 Sep 1997 00:41:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA06019 for ; Tue, 9 Sep 1997 00:38:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 00:34:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA05515 for ipp-outgoing; Tue, 9 Sep 1997 00:25:40 -0400 (EDT) Date: Mon, 8 Sep 1997 21:27:23 -0700 (PDT) From: papowell@astart.com Message-Id: <199709090427.VAA07816@astart2.astart.com> To: jkm@underscore.com, Robert.Herriot@eng.sun.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org > From ipp-owner@pwg.org Fri Sep 5 17:37:43 1997 > Date: Fri, 5 Sep 1997 16:59:31 -0700 > From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) > To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com > Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > Cc: ipp@pwg.org > > > > From jkm@underscore.com Fri Sep 5 16:21:30 1997 > > > > Robert Herriot wrote: > > > > > > > > > > Even if we did specify the syntax for a Job-URI, there is still the > > > problem that its printer-URI constituent might be different from > > > the printer-URI to which the job was submitted. That is also a > > > problem for a gateway because a gateway assumes that a job is named by > > > the printer to which the job was submitted plus a job-Id. If the > > > job-printer is different, the gateway would have to "remember" that. > > > > I believe this is a different issue that should not be confused with > > the issue of standard URI syntax definitions. > > > > I disagree. A parseable Job-URI would still be a problem for gateways. > That is, they would still need a job submitted to Printer P to have > a job identification of (P,n) where n is some integer. > > > Actually, there would need (P,s) where s is a STRING or even a set of tokens. Most implementations assume that s is either the user name or a job 'number' but that is purely a matter of implementation. Patrick Powell   Received: from cnri by ietf.org id aa05123; 9 Sep 97 8: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 JAA16047 for ; Tue, 9 Sep 1997 09:01:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA07657 for ; Tue, 9 Sep 1997 08:57:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 08:51:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA07147 for ipp-outgoing; Tue, 9 Sep 1997 08:42: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: Re: IPP> Job-URI discussion Message-ID: <5030100007910693000002L032*@MHS> Date: Tue, 9 Sep 1997 08:43:25 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org <> I Agree!!! >The real value in getting IPP to users is not >enabling LPR clients, its enabling IPP clients >being able to locate IPP printers via the WEB >and subsequently printing to them. I think >we're spending too much time trying to >save gateway writers a few lines of code.   Received: from cnri by ietf.org id aa10208; 9 Sep 97 11: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 LAA16913 for ; Tue, 9 Sep 1997 11:52:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA08343 for ; Tue, 9 Sep 1997 11:49:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 11:44:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07857 for ipp-outgoing; Tue, 9 Sep 1997 11:36:24 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 09 Sep 1997 09:34:33 -0600 From: Scott Isaacson To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Job-URI discussion Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Below are my thoughts on all of the Job URI/Job ID discussions recently. Even though I have just been a lurker lately, I hope my possition for support for Job URIs is well known. I endorse 100% of what Randy has offered. My ideas: 1) Gateways issues are not the real issue. I agree with Randy's comments about the IPP model not being constrained by gateway implementation issues (agreeing with see Randy's comments below). Gateways, by definition, do impedence matching between two different systems (models). Gateways are necessary but not front runner cases. 2) The real issue is support for existing client access (API). One of the most critical features of IPP is that all existing (unmodified applications and print drivers) can be used with an IPP print provider. We call this "application printing" (print from any application once the printer has been "installed" to the desktop). In the Windows enviroments this means writing an IPP print provider under the EXISTING printing interfaces. In other environments it means basically the same thing (writing a modular piece that can slip in under EXISTING interfaces). So the real question is "Can exiting client printing models and APIs be supported by the new IPP model?" and remember that I mean all client printing models, not just "one particular vendor". Again, after all the discussion I am convinced the answer is YES. The reasons often associated with a NO answer is only that it would be MORE DIFFICULT, not impossible. I have never seen a "it can not be done" argument? Did I miss it? This is software, we can do anything! However, we do need to be pragmatic. What is the exact perfomance vs future potential tradeoffs? Too bad that is far too unknown right now. 3) In other Internet (non IPP specific circles) there is much theoretical debate over the difference between URNs (location transparent names) and URIs (often location dependent IDs). If often wonder if the same principles in those arguments do not apply to this Job URI vs Job ID discussion (just up one more layer of abstraction). Scott Isaacson >>> Randy Turner 09/08 2:47 PM >>> > Overall, I don't consider this particular gateway problem to be > worthy of altering the original model. The real value in getting > IPP to users is not enabling LPR clients, its enabling IPP clients > being able to locate IPP printers via the WEB and subsequently > printing to them. I think we're spending too much time trying to > save gateway writers a few lines of code.   Received: from cnri by ietf.org id aa10602; 9 Sep 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 MAA17004 for ; Tue, 9 Sep 1997 12:12:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA09142 for ; Tue, 9 Sep 1997 12:09:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 12:05:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08448 for ipp-outgoing; Tue, 9 Sep 1997 11:55:21 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 09 Sep 1997 09:53:36 -0600 From: Scott Isaacson To: Robert.Herriot@eng.sun.com, ipp@pwg.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Bob did a good job at introducing and summarizing the issues associated with the "open minded" idea of having both Job IDs and Job URIs. I am really trying to have an open mind and think new thoughts, but my gut reaction and continued perception (even after reading Bob's message) is that it is too cumbersome, and not very elegant. It does not really solve the problems unless we force ALL Printer implementation to support the passing in and then passing back out of this helper attribute. That seems ok, but when implementations must support operations either being addressed to a Printer (P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs etc with both (J) and (P,s), that sounds very un-ok. Let's either fish or cut bait. 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 ************************************************************ >>> Robert Herriot 09/05 5:59 PM >>> It was suggested at the last teleconference that we should have both Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. I want to make it clear at the outset of this email, that I am not taking a position on whether we should have both. Rather I want to explore what the ramifications are if we have both. The following are what I think the characteristics of such a solution are. If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST support both; otherwise, we are in worse shape than with just one of them from all servers. Client MUST be free to use whichever they want. For Print-Job, it doesn't matter whether a client specifies whether it wants a Job-URI or Job-ID, or whether the server returns both. In both cases, the server has to deal with both and the client has to be aware of the choice. So for this discussion, let's assume that the server would return both. For Get-Attributes and Cancel-Job, a server must implement these operations for both Job-URIs and Job-Ids. The target may be a Job-URI or the target may be a Printer-URI with a Job-Id attribute. Both Job-URI and Job-Id attributes are mandatory. Thus a client can query for either via Get-Jobs or Get-Attributes. The following discusses how this solution works with various gateways. This solution works well in Win32 because it would use the Job-Id only. It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. The IPP-to-LPD gateways work well because the Job-Id and Job-URL are both easy to support. So, acting as an IPP server, the gateway can easily support both together. The LPD-to-IPP gateway is easy to support with Job-Ids, so such a gateway, as a client of a IPP server, would use only the Job-Id and would ignore the Job-URL. So from a legacy point of view, the solution with both Job-URIs and Job-Ids is as good as the Job-Id solution only. But now we need to examine what this change means for server implementations. With this change servers would have a bit more work to do because they would have to offer two ways to do the same thing. Moreover, it is mandatory that if they support a particular operation, they must support both Job-URIs and Job-Id. That may be a burden that some implementors won't like -- more code for some abstract future payback. I expect that for most IPP servers its Job-URIs will always consists of its Printer-URI and a Job-Id so the server can easily convert between Job-URIs and Job-Ids with no architectural additions. But for servers that want the Job-URI to reference some remote host, the solution is more complicated because operations, such as Get-Attributes and Cancel-Job will go to the remote host when the client uses the Job-URI and these same operations will go to the Printer when the client uses the Printer-URI and Job-Id. Such servers will have to deal with forwarding issues and the fact that a Job-URI that references a remote host does not guarantee that all traffic goes there because client that use the Job-Id will still come to the original printer. As I said at the beginning of this email, I take no position on this proposal. Rather I offer it as the beginning of a discussion. I would like others to comment on whether this proposal solves the problem, or adds too much complexity to servers for the payback. Bob Herriot   Received: from cnri by ietf.org id aa12209; 9 Sep 97 13: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 NAA17256 for ; Tue, 9 Sep 1997 13:31:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09833 for ; Tue, 9 Sep 1997 13:28:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 13:24:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09342 for ipp-outgoing; Tue, 9 Sep 1997 13:15:45 -0400 (EDT) Message-Id: <9709091715.AA21977@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 10:13:00 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute Sender: ipp-owner@pwg.org I'm resending the proposal that I made on 8/20 which was my action item from the 8/20 IPP telecon. The action item was to provide a Printer description attribute that lists the document-formats that the printer can automatically detect/sense. In other words, to provide a Printer description attribute that specifies which document-formats that the Printer can detect when the document-format is either (1) unspecified or (2) specified as 'application/octet-stream' or whatever we specify in IPP (or the registry) is the equivalent of the 'langAutomatic' Printer MIB enum. Harald suggested that we could use 'application/octet-stream' MIME-type to indicate automatic document-format sensing or we might want to register a MIME-type expoicitly for that purpose. So one of the justfications for this new attribute: that we couldn't have a MIME-type for automatic sensing goes away. However, I still believe that we still need the attribute so that the client and end-users can determine which document-formats are automatically sensed and which ones require that the end-user or client specify the document-format as an IPP input attribute. Here is the proposal again. As before I've included several different attribute names and values for us to pick from, depending on what gets the idea across the most clearly. (Also I removed the first justification for the attribute). I hope we could discuss it at the Wed 8/10 telecon. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 20 Aug 1997 15:09:18 PDT >To: ipp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - document-format-supported using MIME types and > 'automatic' >Cc: jmp@pwg.org, pmp@pwg.org >Sender: ipp-owner@pwg.org > >We had an IPP telecon today and discussed the issue of changing IPP from >using Printer MIB enums for document-format to using MIME-types. > >Attending: Steve Zilles, Ira McDonald, Lee Farrell, Roger deBry, Tom Hastings > >I took the action item to write up the discussion on this point. > snip.. From the Printer MIB enum description: >langAutomatic(37), > -- Automatic PDL sensing. Automatic > -- sensing of the interpreter > -- language family by the printer > -- examining the document content. > -- Which actual interpreter language > -- families are sensed depends on > -- the printer implementation. > > >The solution that we came up with today [8/20] for IPP is to add a >Printer description attribute called: "document-formats-detected" (or >"document-formats-auto-sensed"?). This new IPP attribute solves the problem: > >Make it clear to the client which of the document-formats-supported >can be auto-sensed. Some implementations support more document-formats >than can be automatically sensed. For example, some implementation support >PostScript, PJL, and some document format that cannot be reliabilbly sensed. > >The "document-formats-detected" Printer attribute would be multi-valued >that parallels the "document-formats-supporter Printer attribute and >has a value for each of the values of the "document-formats-supported" >Printer attribute. Each value would be a keyword that indicates whether the >corresponding document format is auto-sensed or not. Perhaps, we can even >have more than two keyword values depending on the degree or reliability >that the PDL can be sensed. The keyword values might be: > > 'auto-detected' > 'auto-detected-best-effort' > 'not-auto-detected' > >or using the Printer MIB terminology of 'sense', instead of 'detect': > > 'auto-sensed' > 'auto-sensed-best-effort' > 'not-auto-sensed' > >Alternatively, the same values could indicate whether the >client needs to supply the "document-format" attribute when submitting >each document or not, so that the following keyword values might be better >names for the corresponding semantics: > > 'document-format-not-required' > 'document-format-recommended' > 'document-format-required' > For example, the MIME-type for simpleText (whatever that is) would be indicated with the value: 'document-format-required'. Then it would be to the clear to the client/end-user that the client must explicitly supply the IPP attribute: "document-format"='application/simpleText' to force simple text, such as a PostScript programmer dumping a PostScript program as simple text, in order to prevent the Printer from autosensing the file and interpreting it as PostScript. snip... >Comments? > >Tom   Received: from cnri by ietf.org id aa12847; 9 Sep 97 14: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 OAA17454 for ; Tue, 9 Sep 1997 14:05:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10491 for ; Tue, 9 Sep 1997 14:02:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 13:58:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09967 for ipp-outgoing; Tue, 9 Sep 1997 13:49:47 -0400 (EDT) Message-Id: <9709091749.AA22006@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 10:46:55 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: Send-Document MUST be supported if Create-Job is, only Send-URI is OPTIONAL Sender: ipp-owner@pwg.org The new current text for the Create-Job operation is: Create-Job Operation This operation is similar to the Print-Job operation (section 3.2.1) except that a client supplies no document data or any reference to document data in the Create-Job request. This operation is followed by one or more Send-Document or Send-URI operations. If a Printer object supports the Create-Job operation, it MUST also support either the Send-Document operation or the Send-URI operation or both. Since a client can query the Printer's "operations-supported" attribute, a client SHOULD NOT attempt to use an unsupported optional operation. I think that if the Print-Job operation is supported, then the Send-Document operation MUST be supported, but the Send-URI is still OPTIONAL. Otherwise, the client has a problem if it has the document data but the Printer only supports Send-URI. Suggested re-wording of the sentence: If a Printer object supports the Create-Job operation, it MUST also support the Send-Document operation and it MAY support the Send-URI operation. Tom   Received: from cnri by ietf.org id aa15285; 9 Sep 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 PAA17928 for ; Tue, 9 Sep 1997 15:52:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11151 for ; Tue, 9 Sep 1997 15:48:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 15:42:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10633 for ipp-outgoing; Tue, 9 Sep 1997 15:33:52 -0400 (EDT) From: Peter Zehler To: "Redirector IPP (E-mail)" Subject: IPP> TES Meeting Minutes Date: Tue, 9 Sep 1997 12:36:28 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Sep9.123335pdt."52692(3)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, The first TES teleconference was held. Here is the notes I took. Participants: Steve Gebert Xavier Riley Ira McDonald Lee Farrell Rick Yardumiun Patrick Powell Peter Zehler We began by talking about what we are working on and (at a high level) our approach. All who participated have some type of client to get the bits on the wire. The objective of these clients is to drive the development of the IPP Printer. One approach is to have a server-based IPP Printer implemented as a JAVA servlet. Another approach is an embedded IPP Printer. This printer is bound tightly to the device and its native print system/MIB implementation. HTTP protocols are provided by an embedded web server. Another approach is a gateway to LPD. This gateway is in PEARL. We also discussed what is required to move from an Internet Draft to a Proposed Standard. It is my understanding that we need 2 interoperable implementations. This would mean 2 clients and 2 IPP Printers that interoperate with each other. The implementations should be on a product tract. This is the part that is not very clear. Hopefully the area director will make the requirements explicit for moving from Internet Draft to Proposed Standard. I expect the area director to specify what proof of interoperability must be supplied. We discussed the availability of IPP clients. It is not clear when a Microsoft IPP redirector or Netscape IPP component will be available. In order to provide interopeable IPP Printer implementations the availability of a public domain UNIX based IPP client was discussed. It was suggested that a TCP port be allocated for IPP(516 was suggested). Some of us use 3rd party embedded HTTP servers. We need to find out from these companies is supporting IPP on a port other than port 80 is a problem. Ira will check with SpyGlass and I will see if I can get input from other vendors. This issue will be brought to the full IPP group. We discussed pairwise and blanket IPP interop testing. An IPP Bakeoff would have to be arranged to handle the blanket test. We are not ready for this at this time. (How much lead time will we need to prepare?) Pairwise testing seem to be a sticky point. 1) Can an implementer place his IPP Printer on the public side of their firewall? 2) Are we worried about security issues for initial tests? 3) Would a proxy server using SSL or TLS help security? 4) Can we work with a firewall vendor to prototype modifications necessary for IPP support? 5) Would a publicly available IPP client make the across the Internet pairwise testing unnecessary? The way it stands right now is that any two individuals are encouraged to arrange a pairwise test. Groupwide IPP pairwise testing is not ruled out. We still have obstacles in the way. There are two main roadblocks to the IPP TES group. One is the IPP JobId/JobURI issue. The next is the security issue. These issues will be passed on to the IPP chair   Received: from cnri by ietf.org id aa15474; 9 Sep 97 15: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 QAA17971 for ; Tue, 9 Sep 1997 16:02:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11718 for ; Tue, 9 Sep 1997 15:58:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 15:54:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10773 for ipp-outgoing; Tue, 9 Sep 1997 15:43:29 -0400 (EDT) From: Peter Zehler To: "Carl-Uno Manros (E-mail)" Cc: "Redirector IPP (E-mail)" Subject: IPP> Issues from the TES sub-group Date: Tue, 9 Sep 1997 12:46:05 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Sep9.124315pdt."52979(4)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Carl-Uno, There are 2 issues at this time that the TES group views as roadblocks. 1) JobId/JobURI debate 2) Security I expect the first issue will be resolved soon. We wish to amplify that the second issue is not just a issue with the IETF approval of IPP. This needs to be resolved to allow the implementers to test the plausibility of the solution. 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 aa15829; 9 Sep 97 16: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 QAA18070 for ; Tue, 9 Sep 1997 16:19:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12350 for ; Tue, 9 Sep 1997 16:16:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 16:12:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11824 for ipp-outgoing; Tue, 9 Sep 1997 16:04:12 -0400 (EDT) Message-Id: <3415AC4C.97D06195@dazel.com> Date: Tue, 09 Sep 1997 15:06:36 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Job-URI discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I personally feel that the Job-URL (sic) is the *only* way to go. From my persepective, any solution that associates a job with a specific printer is immediately broken. The existing URL model can be supported in my existing client environment, whereas the proposed model would be a severe obstacle. In our environment, a job is an object in and of itself; it may be easily moved from one printer to another. so there... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa16161; 9 Sep 97 16: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 QAA18164 for ; Tue, 9 Sep 1997 16:34:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12971 for ; Tue, 9 Sep 1997 16:31:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 16:27:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12427 for ipp-outgoing; Tue, 9 Sep 1997 16:19:15 -0400 (EDT) Message-Id: <3415AFC4.2E3196C4@dazel.com> Date: Tue, 09 Sep 1997 15:21:24 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Robert Herriot , jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs? References: <199709081956.MAA25338@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Jay Martin wrote: > > Since the Job-Id approach implicitly uses the Printer-URL, then > how would you handle moving jobs between Printers? Wouldn't this > present something of a showstopping problem? How would the client > keep track of the change in Job-Id, much less the change in Printer? > > For printing systems using IPP, it would seem that the Job-URL > approach would suffice quite nicely due to the inherent opacity > of the job identification. > > Comments? Jay, I think that this is a very good question. In our system, jobs are independent of printers, and moving jobs is a simple operation (from the client's perspective). The "job identifier" remains the same, the job is just directed to another printer. I believe that by associating the job with the printer (by identifying it with a tuple) you would make this problem very difficult. Also, > Robert Herriot wrote: > > It seems to me that there are two solutions to this problem. Either > a) a job has a constant identification for its life or > b) an identification that changes when it moves. > > In case a, it doesn't matter whether a job has a job-URI or a > (printer-URI,job-Id), the same server manages the job for its duration > regardless of the location of the job I think that you are glossing over a subtle, but very important point, here. It is true that, if the job has a constant identification for its life, the "same server manages the job ... regardless of the location of the job". HOWEVER, there is a difference, in my mind, between having an independent job object referred to by an opaque URL, and a (printer-URL,job-ID) tuple where the job is by definition tied to that particular printer. In the case of the former, the job can be managed by a server that is independent of the printer (cf, DAZEL). > Case b may seem simpler because of the redirection that can > be applied to Job-URI. But this apparent simplicity hides the complexity > of how long the forwarding-server keeps a record of a job that it no > longer controls. The simplest solution for this case may be the same > as for case a, namely the server keeps a forwarding record for the duration > of the job. > > I stand by my previous statements, that the cited advantages of a > job-URI are based on speculation. I have not seen anyone provide enough > detail for us to understand the full solution for the move-job > problem. I can point you to a print system that is in use today that uses the concept of an independent job object (akin to a job-URL), and it is successful in solving the move-job problem. The job is managed independent of the printer, making it very easy to move the job, and retain its identity. > I have no problem with a design that might make the solution of future > problems easy as long as it doesn't affect the solution to current > well-understood problems. future problems solved today... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa17574; 9 Sep 97 17: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 RAA18456 for ; Tue, 9 Sep 1997 17:32:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13840 for ; Tue, 9 Sep 1997 17:29:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:01:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13048 for ipp-outgoing; Tue, 9 Sep 1997 16:34:52 -0400 (EDT) Message-Id: <199709092021.QAA04530@devnix.agranat.com> To: Peter Zehler cc: "Redirector IPP (E-mail)" Subject: Re: IPP> TES Meeting Minutes In-reply-to: <97Sep9.123335pdt."52692(3)"@alpha.xerox.com> Date: Tue, 09 Sep 1997 16:21:50 -0400 From: Scott Lawrence Sender: ipp-owner@pwg.org >>>>> "PZ" == Peter Zehler writes: PZ> It was suggested that a TCP port be allocated for IPP(516 was PZ> suggested). Some of us use 3rd party embedded HTTP servers. We need to PZ> find out from these companies is supporting IPP on a port other than PZ> port 80 is a problem. The EmWeb server can operate over any TCP port of combination of ports (with different content on different ports, if you want it that way). You may send any other queries direct to me. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/   Received: from cnri by ietf.org id aa18255; 9 Sep 97 18: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 SAA18590 for ; Tue, 9 Sep 1997 18:08:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16084 for ; Tue, 9 Sep 1997 18:05:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:43:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13107 for ipp-outgoing; Tue, 9 Sep 1997 16:43:07 -0400 (EDT) Date: Tue, 9 Sep 1997 13:40:57 -0700 From: Robert Herriot Message-Id: <199709092040.NAA26643@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com, walker@dazel.com Subject: Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From walker@dazel.com Tue Sep 9 13:20:06 1997 > > I can point you to a print system that is in use today that uses > the concept of an independent job object (akin to a job-URL), > and it is successful in solving the move-job problem. The job is > managed independent of the printer, making it very easy to move > the job, and retain its identity. > In DAZEL does a job have a single invariant identity for the duration of the job, even if it is moved? If so, does that imply that the server that acts as the handle for job when it is created continues to act as this handle throughout the life of the job, and that this server may or may not be the server for the original printer? Bob Herriot   Received: from cnri by ietf.org id aa18272; 9 Sep 97 18: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 SAA18594 for ; Tue, 9 Sep 1997 18:10:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16296 for ; Tue, 9 Sep 1997 18:06:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:45:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13118 for ipp-outgoing; Tue, 9 Sep 1997 16:43:46 -0400 (EDT) Message-Id: <3415B194.E9E4FFF2@dazel.com> Date: Tue, 09 Sep 1997 15:29:08 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP>MOD - job-sheet-content attribute References: <5030100007699359000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger, I like your goal here... the idea of being able to have variable information substituted into the job sheets. However, let me offer a little bit of a different twist on the solution. In our system, we can reference attribute values from the document, job, or printer object themselves. For example, I can substitute the value of job-owner, submission-time, printer-name, etc. Obviously, any value that you would want to have available, would have to be available as an attribute of one of the objects. This, however, has not been an obstacle for our customers. The one thing that I do like in your scheme is that it *shows* the user what information is necessary for the job sheet. Perhaps there is some synergy between these two solutions? For example, we could have a job-sheet-content attribute that lists the other attributes that will be used on the job sheet? food for thought... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa18322; 9 Sep 97 18: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 SAA18614 for ; Tue, 9 Sep 1997 18:13:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16687 for ; Tue, 9 Sep 1997 18:10:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:47:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13147 for ipp-outgoing; Tue, 9 Sep 1997 16:47:31 -0400 (EDT) Date: Tue, 9 Sep 1997 13:45:52 -0700 From: Robert Herriot Message-Id: <199709092045.NAA26654@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, walker@dazel.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From walker@dazel.com Tue Sep 9 13:37:45 1997 > > We have a gateway > that has been in existence for four years now that solves this > exact problem: it maps from the LPD job identifiers to an opaque > printer-independent job identifier. > > And folks, it wasn't that hard to do. Can you give a few details? Do you maintain a mapping table? If so, what triggers the removal of entries? Or do you use an extended attribute in the print job to hold the mapping? Bob Herriot   Received: from cnri by ietf.org id aa18339; 9 Sep 97 18: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 SAA18623 for ; Tue, 9 Sep 1997 18:14:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16816 for ; Tue, 9 Sep 1997 18:11:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:48:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13164 for ipp-outgoing; Tue, 9 Sep 1997 16:49:52 -0400 (EDT) Message-Id: <3415B6EA.3AD8BE68@dazel.com> Date: Tue, 09 Sep 1997 15:51:54 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Robert Herriot Cc: jkm@underscore.com, ipp@pwg.org Subject: Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs? References: <199709092040.NAA26643@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > In DAZEL does a job have a single invariant identity for the duration > of the job, even if it is moved? If so, does that imply that the > server that acts as the handle for job when it is created continues to act > as this handle throughout the life of the job, and that this server > may or may not be the server for the original printer? yes... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa18355; 9 Sep 97 18: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 SAA18629 for ; Tue, 9 Sep 1997 18:15:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16953 for ; Tue, 9 Sep 1997 18:12:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 17:49:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13082 for ipp-outgoing; Tue, 9 Sep 1997 16:38:25 -0400 (EDT) Message-Id: <3415B447.76E124D5@dazel.com> Date: Tue, 09 Sep 1997 15:40:39 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Robert Herriot Cc: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709042127.OAA21675@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Some comments on these IPP<->LPD gateway discussions... ... I agree with Scott that the gateway between IPP and legacy systems should *not* be the driving force behind our design. ... There seems to be a base assumption that mapping a from a LPD job identifier (integer) to an IPP job URL is a difficult problem. I would assert that it is not. We have a gateway that has been in existence for four years now that solves this exact problem: it maps from the LPD job identifiers to an opaque printer-independent job identifier. And folks, it wasn't that hard to do. later... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa18450; 9 Sep 97 18: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 SAA18638 for ; Tue, 9 Sep 1997 18:21:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA17695 for ; Tue, 9 Sep 1997 18:18:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 18:07:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13193 for ipp-outgoing; Tue, 9 Sep 1997 16:54:41 -0400 (EDT) Message-Id: <3415B809.A1309F7C@dazel.com> Date: Tue, 09 Sep 1997 15:56:41 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Robert Herriot Cc: ipp@pwg.org Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? References: <199709092045.NAA26654@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > Can you give a few details? Do you maintain a mapping table? If so, > what triggers the removal of entries? Or do you use an extended attribute > in the print job to hold the mapping? Uhhh... I believe that I will leave it as an exercise for the user. Let's just say that there is a variety of ways that one might do it; certainly either of the solutions that you hint to above might work. I could even imagine one or two more. I do not mean to be too mysterious, but it seems sufficient to me that there are implementations in the field today that solve a similar problem. later... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa18500; 9 Sep 97 18: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 SAA18648 for ; Tue, 9 Sep 1997 18:24:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18015 for ; Tue, 9 Sep 1997 18:20:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 18:15:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13527 for ipp-outgoing; Tue, 9 Sep 1997 17:12:23 -0400 (EDT) Date: Tue, 9 Sep 1997 14:10:27 -0700 From: Robert Herriot Message-Id: <199709092110.OAA26719@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, walker@dazel.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From walker@dazel.com Tue Sep 9 13:53:49 1997 > > > Can you give a few details? Do you maintain a mapping table? If so, > > what triggers the removal of entries? Or do you use an extended attribute > > in the print job to hold the mapping? > > Uhhh... I believe that I will leave it as an exercise for the user. > Let's just say that there is a variety of ways that one might do it; > certainly either of the solutions that you hint to above might work. > I could even imagine one or two more. > > I do not mean to be too mysterious, but it seems sufficient to me > that there are implementations in the field today that solve a > similar problem. > I ask these questions because the two most obvious solutions that I cite above have problems in the IPP context. The gateway cannot use some extended attribute to store the LPD Job-Id in because an IPP server would discard attributes it doesn't support. The gateway has difficulty using a mapping table because the IPP notification is weak (email only). A gateway would have to resort to polling in order to determine what jobs can be removed from its mapping table. This works, but its not a nice solution, and it doesn't scale well. I assume that DAZEL doesn't have these restrictions. Bob Herriot   Received: from cnri by ietf.org id aa18909; 9 Sep 97 18: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 SAA18748 for ; Tue, 9 Sep 1997 18:51:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18751 for ; Tue, 9 Sep 1997 18:48:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 18:44:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18236 for ipp-outgoing; Tue, 9 Sep 1997 18:36:09 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D703878C8A@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> jobid (one more time) Date: Tue, 9 Sep 1997 15:35:57 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org The new job MIB defines a 32-bit job identifier that persists as a way of identifying a job. The Win32 API does the same - used on the vast majority of the world's desktops. Bob H says that UNIX uses a 32 bit job ID in the same way. It's not like I am suggesting that we use something obscure, non-published or only used by 1% of the world. I am suggesting that we may want to leverage some of the exisiting software in the world.   Received: from cnri by ietf.org id aa19947; 9 Sep 97 20: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 UAA18896 for ; Tue, 9 Sep 1997 20:18:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19561 for ; Tue, 9 Sep 1997 20:15:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 20:11:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA19059 for ipp-outgoing; Tue, 9 Sep 1997 20:02:58 -0400 (EDT) Message-ID: <3415E430.76394476@sharplabs.com> Date: Tue, 09 Sep 1997 17:05:04 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> jobid (one more time) X-Priority: 3 (Normal) References: <41135C785691CF11B73B00805FD4D2D703878C8A@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 new job MIB defines a 32-bit job identifier that persists as a way > of identifying a job. > > The Win32 API does the same - used on the vast majority of the world's > desktops. > > Bob H says that UNIX uses a 32 bit job ID in the same way. > > It's not like I am suggesting that we use something obscure, > non-published or only used by 1% of the world. I am suggesting that we > may want to leverage some of the exisiting software in the world. From my research, you can't use the job-id returned by an IPP server to access the Win95 print spooler. You have to use the job-id (DWORD value) returned by the AddJob() API call. You will then have to maintain a mapping between this Win95-derived job-id and the job-id/job-uri returned by a remote IPP server. We are not proposing replacing the existing software in the world, just supplementing it. I think the job MIB also specifies an octet string for supplemental job identification (is this right Tom H.?) Randy   Received: from cnri by ietf.org id aa20094; 9 Sep 97 20: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 UAA18937 for ; Tue, 9 Sep 1997 20:32:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20201 for ; Tue, 9 Sep 1997 20:28:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 20:25:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA19668 for ipp-outgoing; Tue, 9 Sep 1997 20:16:27 -0400 (EDT) Message-Id: <3.0.1.32.19970909170432.00b65970@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Sep 1997 17:04:32 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference - September 10 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, these are the subjects that I believe should be covered in tomorrows phone conference: 1) Dictionary syntax 2) MIME types for documents and autodetection 3) Cancel - Job state changes and security 4) Job URI vs Job ID (we can spend hours on this one alone, but I feel that we need to reach conclusion on this soon. I believe that by now we have been over the arguments so many times that we just need to decide whether we want go for short term compatibility or longer term flexibility). I would also like to hear a report on the prototyping activity. --- Numbers for tomorrow as last week: Time: 4PM EDT or 1PM PDT Number: 1-423-523-7162 Access: 190148 ---- 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 aa20756; 9 Sep 97 21: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 VAA19021 for ; Tue, 9 Sep 1997 21:24:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA21125 for ; Tue, 9 Sep 1997 21:20:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 21:15:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA20599 for ipp-outgoing; Tue, 9 Sep 1997 21:06:45 -0400 (EDT) Message-Id: <9709100106.AA22214@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 18:04:03 PDT To: walker@dazel.com From: Tom Hastings Subject: Re: IPP> Job-URI discussion Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Jim, One of the arguments in favor of Job-URI has been that the HTTP redirect can be used if the job is moved. However, why can't server notification be used when a job is moved. The client can indicate an interest if the job is moved as a job event and can update its tables with the new location? So notification would be an alternative for allowing jobs to move even if we didn't have job-URI for jobs. I'm still catching up on this job-URI vs. job-id debate and have not formed a final opinion. Tom At 13:06 09/09/97 PDT, Jim Walker wrote: >I personally feel that the Job-URL (sic) is the *only* way to go. >>From my persepective, any solution that associates a job with a >specific printer is immediately broken. The existing URL model >can be supported in my existing client environment, whereas the >proposed model would be a severe obstacle. >In our environment, a job is an object in and of itself; it may >be easily moved from one printer to another. > >so there... >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX > >   Received: from cnri by ietf.org id aa21075; 9 Sep 97 21: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 VAA19054 for ; Tue, 9 Sep 1997 21:51:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA22028 for ; Tue, 9 Sep 1997 21:48:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 21:34:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA20893 for ipp-outgoing; Tue, 9 Sep 1997 21:17:24 -0400 (EDT) Message-Id: <9709100117.AA22222@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 18:14:40 PDT To: Paul Moore From: Tom Hastings Subject: Re: IPP> jobid (one more time) Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Paul, I'm still catching up on this job-URI vs. job-id debate, so I haven't formed a final opinion. I'm certainly want to be able to put IPP under existing Print APIs that have the concept of a 32-bit job-id, because there are so many of them like that. On the other hand, if IPP did have a job-URI instead of a job-id, gateways and clients would have to map from the job-URI to a 32-bit integer for use in the existing Print API. You convinced me (and most others) at the Redmond meeting that the problem of keeping the map was knowing when to remove the entry. Suppose such an implementation used IPP notification to be told by the IPP server when the job had completed? Then you could remove the map entry from the table. Would that work? Actually, we would probably have to add another IPP notification-event: 'job-removed' to cover the state transition from 'completed', 'aborted', or 'canceled' to not being kept in the system at all. We probably should add that event anyway. Comments? Tom P.S. Hope you can join us for the telecon, this Wed, 9/10, 1-3pm PDT, since this will be a hot topic for that call. At 15:35 09/09/97 PDT, Paul Moore wrote: >The new job MIB defines a 32-bit job identifier that persists as a way >of identifying a job. > >The Win32 API does the same - used on the vast majority of the world's >desktops. > >Bob H says that UNIX uses a 32 bit job ID in the same way. > >It's not like I am suggesting that we use something obscure, >non-published or only used by 1% of the world. I am suggesting that we >may want to leverage some of the exisiting software in the world.   Received: from cnri by ietf.org id aa21291; 9 Sep 97 22: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 WAA19073 for ; Tue, 9 Sep 1997 22:09:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA23255 for ; Tue, 9 Sep 1997 22:06:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 21:56:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21244 for ipp-outgoing; Tue, 9 Sep 1997 21:25:27 -0400 (EDT) Message-ID: <41135C785691CF11B73B00805FD4D2D703878C98@RED-17-MSG.dns.microsoft.com> From: Paul Moore To: "'rturner@sharplabs.com'" , ipp@pwg.org Subject: RE: IPP> jobid (one more time) Date: Tue, 9 Sep 1997 18:25:16 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: ipp-owner@pwg.org My research (with the people who have written the code) shows that this is not the case > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Tuesday, September 09, 1997 5:05 PM > To: ipp@pwg.org > Subject: Re: IPP> jobid (one more time) > > Paul Moore wrote: > > > > The new job MIB defines a 32-bit job identifier that persists as a > way > > of identifying a job. > > > > The Win32 API does the same - used on the vast majority of the > world's > > desktops. > > > > Bob H says that UNIX uses a 32 bit job ID in the same way. > > > > It's not like I am suggesting that we use something obscure, > > non-published or only used by 1% of the world. I am suggesting that > we > > may want to leverage some of the exisiting software in the world. > > > From my research, you can't use the job-id returned by an IPP > server to access the Win95 print spooler. You have to use the > job-id (DWORD value) returned by the AddJob() API call. You will > then have to maintain a mapping between this Win95-derived job-id > and the job-id/job-uri returned by a remote IPP server. We are not > proposing replacing the existing software in the world, just > supplementing it. > > I think the job MIB also specifies an octet string for supplemental > job identification (is this right Tom H.?) > > Randy   Received: from cnri by ietf.org id aa21303; 9 Sep 97 22: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 WAA19076 for ; Tue, 9 Sep 1997 22:10:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA23371 for ; Tue, 9 Sep 1997 22:07:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 21:57:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21274 for ipp-outgoing; Tue, 9 Sep 1997 21:26:43 -0400 (EDT) Message-Id: <9709100126.AA22239@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Sep 1997 18:23:53 PDT To: Robert Herriot From: Tom Hastings Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: Robert.Herriot@eng.sun.com, walker@dazel.com, ipp@pwg.org Sender: ipp-owner@pwg.org At 14:10 09/09/97 PDT, Robert Herriot wrote: > >> From walker@dazel.com Tue Sep 9 13:53:49 1997 >> >> > Can you give a few details? Do you maintain a mapping table? If so, >> > what triggers the removal of entries? Or do you use an extended attribute >> > in the print job to hold the mapping? >> >> Uhhh... I believe that I will leave it as an exercise for the user. >> Let's just say that there is a variety of ways that one might do it; >> certainly either of the solutions that you hint to above might work. >> I could even imagine one or two more. >> >> I do not mean to be too mysterious, but it seems sufficient to me >> that there are implementations in the field today that solve a >> similar problem. >> > >I ask these questions because the two most obvious solutions that I cite >above have problems in the IPP context. > >The gateway cannot use some extended attribute to store the LPD Job-Id in >because an IPP server would discard attributes it doesn't support. Well, we certainly could add a "job-client-id" attribute to IPP, so that gateways would have a place to store an opaque "handle" in an IPP job. That seems a simple solution to help gateways and is something we have in DPA as the "job-client-id" and the Job MIB as the jobSubmissionID table which is a map from the client's id to the server's jmJobIndex. > >The gateway has difficulty using a mapping table because the IPP >notification is weak (email only). A gateway would have to resort to >polling in order to determine what jobs can be removed from its mapping >table. This works, but its not a nice solution, and it doesn't scale >well. The current Model document has more than 'mailto' scheme. It has 'http' and 'ftp'. (Where is SENSE when we need it?). I agree that polling isn't a nice solution, but lets make notification work. > >I assume that DAZEL doesn't have these restrictions. > >Bob Herriot > >   Received: from cnri by ietf.org id aa21347; 9 Sep 97 22: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 WAA19081 for ; Tue, 9 Sep 1997 22:13:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA23777 for ; Tue, 9 Sep 1997 22:10:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 22:03:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21357 for ipp-outgoing; Tue, 9 Sep 1997 21:35:27 -0400 (EDT) Message-ID: <3415FA1C.14A8EF42@sharplabs.com> Date: Tue, 09 Sep 1997 18:38:36 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> jobid (one more time) X-Priority: 3 (Normal) References: <41135C785691CF11B73B00805FD4D2D703878C98@RED-17-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Could you elaborate on your statement a little? Randy Paul Moore wrote: > > My research (with the people who have written the code) shows that > this > is not the case > > > -----Original Message----- > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > Sent: Tuesday, September 09, 1997 5:05 PM > > To: ipp@pwg.org > > Subject: Re: IPP> jobid (one more time) > > > > Paul Moore wrote: > > > > > > The new job MIB defines a 32-bit job identifier that persists as a > > way > > > of identifying a job. > > > > > > The Win32 API does the same - used on the vast majority of the > > world's > > > desktops. > > > > > > Bob H says that UNIX uses a 32 bit job ID in the same way. > > > > > > It's not like I am suggesting that we use something obscure, > > > non-published or only used by 1% of the world. I am suggesting > that > > we > > > may want to leverage some of the exisiting software in the world. > > > > > > From my research, you can't use the job-id returned by an IPP > > server to access the Win95 print spooler. You have to use the > > job-id (DWORD value) returned by the AddJob() API call. You will > > then have to maintain a mapping between this Win95-derived job-id > > and the job-id/job-uri returned by a remote IPP server. We are not > > proposing replacing the existing software in the world, just > > supplementing it. > > > > I think the job MIB also specifies an octet string for supplemental > > job identification (is this right Tom H.?) > > > > Randy   Received: from cnri by ietf.org id aa23480; 9 Sep 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 WAA19123 for ; Tue, 9 Sep 1997 22:58:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA24464 for ; Tue, 9 Sep 1997 22:55:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Sep 1997 22:51:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA23976 for ipp-outgoing; Tue, 9 Sep 1997 22:43:02 -0400 (EDT) Message-Id: <1.5.4.32.19970910023952.006de89c@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, 09 Sep 1997 19:39:52 -0700 To: Peter Zehler , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> TES Meeting Minutes Sender: ipp-owner@pwg.org At 12:36 PM 9/9/97 PDT, you wrote: >We also discussed what is required to move from an Internet Draft to a >Proposed Standard. It is my understanding that we need 2 interoperable >implementations. This would mean 2 clients and 2 IPP Printers that >interoperate with each other. The implementations should be on a >product tract. This is the part that is not very clear. Hopefully the >area director will make the requirements explicit for moving from >Internet Draft to Proposed Standard. I expect the area director to >specify what proof of interoperability must be supplied. This is a misunderstanding. It is not until we want to move the documents from Proposed to Draft standards that we actually have to give proof of interworking implementations. Our ambition was to have this already before the Proposed Standard was published, but that is not a requirement to get it out. So we can relax a little on that point, which however should not be a reason to get on with the prototyping.. >It was suggested that a TCP port be allocated for IPP(516 was >suggested). Some of us use 3rd party embedded HTTP servers. We need to >find out from these companies is supporting IPP on a port other than >port 80 is a problem. Ira will check with SpyGlass and I will see if I >can get input from other vendors. This issue will be brought to the >full IPP group. We have discussed this earlier and came to the conclusion that there was no obvious advantage in having a separate port as part of the standard. Do we have any new compelling arguments now? >We discussed pairwise and blanket IPP interop testing. An IPP Bakeoff >would have to be arranged to handle the blanket test. We are not ready >for this at this time. (How much lead time will we need to prepare?) >Pairwise testing seem to be a sticky point. > 1) Can an implementer place his IPP Printer on the public side of >their firewall? We are prepared to do this. > 2) Are we worried about security issues for initial tests? Suggest that we can start without worrying too much about security, as long as we only gove our Printer URIs to other vselected testers. > 3) Would a proxy server using SSL or TLS help security? It probably would, but this seems to be more work than putting a printer outside the firewall initially. > 4) Can we work with a firewall vendor to prototype modifications >necessary for IPP support? Let us see if we can find one. > 5) Would a publicly available IPP client make the across the >Internet pairwise testing unnecessary? >The way it stands right now is that any two individuals are encouraged >to arrange a pairwise test. Groupwide IPP pairwise testing is not ruled >out. We still have obstacles in the way. > >There are two main roadblocks to the IPP TES group. One is the IPP >JobId/JobURI issue. The next is the security issue. These issues will >be passed on to the IPP chair. You are right, that we definately need to settle on the JOB URI decision quickly. The same goes for security, but I think we can do quite a lot of testing also without security at this stage. Carl-Uno   Received: from cnri by ietf.org id aa10028; 10 Sep 97 11: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 LAA20446 for ; Wed, 10 Sep 1997 11:09:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25984 for ; Wed, 10 Sep 1997 11:05:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 10:56:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA25473 for ipp-outgoing; Wed, 10 Sep 1997 10:47:55 -0400 (EDT) Message-Id: <9709101448.AA22425@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, 10 Sep 1997 07:45:20 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Allow more JT attributes to be document attributes Sender: ipp-owner@pwg.org Subj: Simple proposal to allow more Job Template attributes to be per-document From: Tom Hastings File: per-doc.doc Date: 9/9/97 The latest draft Model document OPTIONALLY allows 5 job template attributes to be document attributes when Create-Job/Send-Document and Send-URI operations are implemented: document-format compression document-k-octets document-impressions document-media-sheets as agreed in Redmond. See the table in section 4.2 and the list in section 4.4. The table in section 4.2 is divided into two parts, with the above 5 attributes being last in the table. I talked with Roger yesterday and we'd like to make the following proposal: 1. We'd like to move the boundary up to include the attributes from "media" down through "page-range" as well. Thus the following job template attributes would become optional document attributes along with the above 5: "media", "number-up", "sides", "printer-resolution", "print-quality" and "page-range". The "finishing" and "copies" attributes already have the "multiple-document-handling attribute to control their semantics, so maybe they should remain as job level only. Then move them up next to "multiple-document-handling in section 4.2 so that it will be easier for readers to understand their interaction. With the above changes, all of the job template attributes that make sense for being per-document MAY be supported with Send-Document and Send-URI operations. 2. Since section 3.3.1.1 indicates that these job template attributes are OPTIONAL as document attributes, a client needs to be able to tell which are supported as per-document attributes and which are supported only as job attributes. Therefore, we propose adding a "document-attributes-supported" Printer description attribute in which the Printer returns the keyword names of the Job Template attributes that it supports as document attributes in the Send-Document and Send-URI operations. 3. We need to clarify what happens when a client supplies a job template attribute at the job level in a Create-Job operation and then also specifies the same attribute (with a different value) as a document attribute in the Send-Document or Send-URI operation. We think that the attribute specified at the document level should override the value of the attribute specified at the job level, but only for the documents to which the document attribute is specified. Thus the job level attribute specifies for any documents that don't have that attribute specified. For the three attributes that are counts: "document-k-octets", "document-impressions", and "document-media-sheets", the value at the job level, if supplied SHALL be the sum for the entire job, while the value at the document level, if supplied SHALL be for that document alone. So for these three (extensive) attributes, the document level doesn't overide the job level attribute, but, instead complements it. 4. On Get Attributes, we need to clarify that, depending on implemenation, the Printer MAY either: (1) factor out common document attributes and report them as job attributes, instead of document attributes (2) return all document attributes at the document level, regardless of how the client has specified them or (3) preserve the job versus document attributes as supplied by the client, since the semantic interpretation of all three representations of a job SHALL be the same.   Received: from cnri by ietf.org id aa11178; 10 Sep 97 11: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 LAA20664 for ; Wed, 10 Sep 1997 11:57:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26363 for ; Wed, 10 Sep 1997 11:53:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa11562; 10 Sep 97 12: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 MAA20719 for ; Wed, 10 Sep 1997 12:08:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26896 for ; Wed, 10 Sep 1997 12:05:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 12:01:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26197 for ipp-outgoing; Wed, 10 Sep 1997 11:50:31 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics Sender: ipp-owner@pwg.org There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa12989; 10 Sep 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 NAA20903 for ; Wed, 10 Sep 1997 13:09:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27303 for ; Wed, 10 Sep 1997 13:06:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 13:02:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27099 for jmp-outgoing; Wed, 10 Sep 1997 13:00:48 -0400 (EDT) Message-Id: <9709101700.AA22492@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) Date: Wed, 10 Sep 1997 09:57:52 PDT To: jmp@pwg.org From: Tom Hastings Subject: JMP> Clarifications, additions and movements of some job-state-reasons Cc: ipp@pwg.org Sender: jmp-owner@pwg.org Subj: Clarifications, additions and movements of some job-state-reasons From: Tom Hastings and Harry Lewis Date: 9/10/97 File: reasons.doc On the JMP DL, Harry has made the following proposals for movement of some job state reasons to jmJobStateReason1 object and clarifications. Some of these may want to be added to IPP (but IPP can remain a subset of JMP, since JMP is attempting to cover other job submission protocols as well as IPP). 1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that the server has timed out the job and closed it. Should be added to IPP as well. 2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the service has been disabled, so that all pending jobs are not going to be processed. 3. Distinguish between canceling by (authenicate) operator and canceled at local (unauthenticated) op panel, by adding 'canceled-at-device'. 4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the semantics. 5. Clarify 'canceled-by-operator' to mean authenticated as a privileged user in some way. 6. Add 'canceled-by-non-owner' for those systems that have more comprehensive security mechanisms, such as group privileges in POSIX. If we add these to JMP, Harry has indicated that we could put them in their logical place in the order of likely occurrence, but only we need to agree quickly. If we can't agree quickly, then we should put them at the end of the bit assignments in JMP. (Fortunately, in IPP, we use keywords, instead of bits, so there is no problem with ordering). I've indicated the new bit assignements below for the JMP spec. The proposed specs for each of these job state reasons becomes: For JMP: submissionInterrupted 0x8 Indicates that the job was not completely submitted for some unforeseen reason, such as: (1) the server has crashed before the job was closed by the client, (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server, (3) the client crashed or failed to close the job before the time-out period. jobCanceledByOwner 0x1000 The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's jmJobOwner object. jobCanceledByOperator 0x2000 The job was canceled by the operator, i.e., by a user whose has been authenticated as having operator privileges (whether local or remote). jobCanceledAtDevice 0x4000 The job was canceled by an unidentified local user, i.e., a user at a walkup console or operator's panel. jobCanceledByNonOwner 0x8000 The job was canceled by an authenticated user that is not the owner of the job. This reason may be used in systems that have the concept of group or other security mechanisms that allow jobs to be canceled by users other than the job owner but that are not operators. serviceOffLine 0x40000 The service or document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This situation could be true if the service's or document transform's input is impaired or broken. NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use the 3 other 32-bit job state reasons attributes. IPP: For IPP, the names change to all lower case with hyphens to follow keyword syntax. 'submission-interrupted': The job was not completely submitted for some unforeseen reason, such as: (1) the Printer has crashed before the job was closed by the client, (2) the Printer or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the Printer, (3) the client crashed or failed to close the job before the time-out period. 'job-canceled-by-owner': The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's "job-originating-user" attribute. 'job-canceled-by-operator': The job was canceled by the operator using the CancelJob request, i.e., by a user who has been granted special privileges. 'job-canceled-at-device': The job was canceled by an unidentified local user, i.e., i.e., a user at a walkup console or operator's panel. 'serviceoff-line': The Printer is off-line and accepting no jobs. All pending jobs are put into the 'pending-held' state. This situation could be true if the Printer's input is impaired or broken. Comments? Tom   Received: from cnri by ietf.org id aa13341; 10 Sep 97 13: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 NAA20940 for ; Wed, 10 Sep 1997 13:12:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27454 for ; Wed, 10 Sep 1997 13:08:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 13:05:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27145 for jmp-outgoing; Wed, 10 Sep 1997 13:02:36 -0400 (EDT) Date: Wed, 10 Sep 1997 10:05:48 PDT From: Ira Mcdonald x10962 Message-Id: <9709101705.AA08446@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: Re: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa13976; 10 Sep 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 NAA21042 for ; Wed, 10 Sep 1997 13:32:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28495 for ; Wed, 10 Sep 1997 13:28:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 13:21:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27091 for ipp-outgoing; Wed, 10 Sep 1997 13:00:42 -0400 (EDT) Message-Id: <9709101700.AA22492@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) Date: Wed, 10 Sep 1997 09:57:52 PDT To: jmp@pwg.org From: Tom Hastings Subject: IPP> Clarifications, additions and movements of some job-state-reasons Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Subj: Clarifications, additions and movements of some job-state-reasons From: Tom Hastings and Harry Lewis Date: 9/10/97 File: reasons.doc On the JMP DL, Harry has made the following proposals for movement of some job state reasons to jmJobStateReason1 object and clarifications. Some of these may want to be added to IPP (but IPP can remain a subset of JMP, since JMP is attempting to cover other job submission protocols as well as IPP). 1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that the server has timed out the job and closed it. Should be added to IPP as well. 2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the service has been disabled, so that all pending jobs are not going to be processed. 3. Distinguish between canceling by (authenicate) operator and canceled at local (unauthenticated) op panel, by adding 'canceled-at-device'. 4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the semantics. 5. Clarify 'canceled-by-operator' to mean authenticated as a privileged user in some way. 6. Add 'canceled-by-non-owner' for those systems that have more comprehensive security mechanisms, such as group privileges in POSIX. If we add these to JMP, Harry has indicated that we could put them in their logical place in the order of likely occurrence, but only we need to agree quickly. If we can't agree quickly, then we should put them at the end of the bit assignments in JMP. (Fortunately, in IPP, we use keywords, instead of bits, so there is no problem with ordering). I've indicated the new bit assignements below for the JMP spec. The proposed specs for each of these job state reasons becomes: For JMP: submissionInterrupted 0x8 Indicates that the job was not completely submitted for some unforeseen reason, such as: (1) the server has crashed before the job was closed by the client, (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server, (3) the client crashed or failed to close the job before the time-out period. jobCanceledByOwner 0x1000 The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's jmJobOwner object. jobCanceledByOperator 0x2000 The job was canceled by the operator, i.e., by a user whose has been authenticated as having operator privileges (whether local or remote). jobCanceledAtDevice 0x4000 The job was canceled by an unidentified local user, i.e., a user at a walkup console or operator's panel. jobCanceledByNonOwner 0x8000 The job was canceled by an authenticated user that is not the owner of the job. This reason may be used in systems that have the concept of group or other security mechanisms that allow jobs to be canceled by users other than the job owner but that are not operators. serviceOffLine 0x40000 The service or document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This situation could be true if the service's or document transform's input is impaired or broken. NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use the 3 other 32-bit job state reasons attributes. IPP: For IPP, the names change to all lower case with hyphens to follow keyword syntax. 'submission-interrupted': The job was not completely submitted for some unforeseen reason, such as: (1) the Printer has crashed before the job was closed by the client, (2) the Printer or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the Printer, (3) the client crashed or failed to close the job before the time-out period. 'job-canceled-by-owner': The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's "job-originating-user" attribute. 'job-canceled-by-operator': The job was canceled by the operator using the CancelJob request, i.e., by a user who has been granted special privileges. 'job-canceled-at-device': The job was canceled by an unidentified local user, i.e., i.e., a user at a walkup console or operator's panel. 'serviceoff-line': The Printer is off-line and accepting no jobs. All pending jobs are put into the 'pending-held' state. This situation could be true if the Printer's input is impaired or broken. Comments? Tom   Received: from cnri by ietf.org id aa13973; 10 Sep 97 13: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 NAA21039 for ; Wed, 10 Sep 1997 13:32:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28489 for ; Wed, 10 Sep 1997 13:28:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 13:21:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27128 for ipp-outgoing; Wed, 10 Sep 1997 13:02:21 -0400 (EDT) Date: Wed, 10 Sep 1997 10:05:48 PDT From: Ira Mcdonald x10962 Message-Id: <9709101705.AA08446@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: ipp-owner@pwg.org Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa14589; 10 Sep 97 13: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 NAA21196 for ; Wed, 10 Sep 1997 13:57:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29214 for ; Wed, 10 Sep 1997 13:54:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 13:50:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28697 for ipp-outgoing; Wed, 10 Sep 1997 13:41:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 10 Sep 1997 11:41:34 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - RTF version of the 970903 model doc Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Tom pointed out that the .doc file I posted was a Word97 version of the model document. I have since posted a .rtf version for anyone that needs it. I only posted the revision marks version "ipp-model-970903-rev.rtf" 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 aa15436; 10 Sep 97 14: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 OAA21378 for ; Wed, 10 Sep 1997 14:27:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29857 for ; Wed, 10 Sep 1997 14:24:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 14:20:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29355 for ipp-outgoing; Wed, 10 Sep 1997 14:11:50 -0400 (EDT) Date: Wed, 10 Sep 1997 11:07:08 -0700 From: Robert Herriot Message-Id: <199709101807.LAA27691@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, hastings@cp10.es.xerox.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: walker@dazel.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From hastings@cp10.es.xerox.com Tue Sep 9 19:01:45 1997 > > At 14:10 09/09/97 PDT, Robert Herriot wrote: > > > > > >The gateway cannot use some extended attribute to store the LPD Job-Id in > >because an IPP server would discard attributes it doesn't support. > > Well, we certainly could add a "job-client-id" attribute to IPP, so that > gateways would have a place to store an opaque "handle" in an IPP job. > That seems a simple solution to help gateways and is something we > have in DPA as the "job-client-id" and the Job MIB as the jobSubmissionID > table which is a map from the client's id to the server's jmJobIndex. > I have specifically avoided suggesting that we add a job-client-id job attribute because it would have to be mandatory in order to offer a solution to an LPD-to-IPP gateway. I don't think it is reasonable for all implementations to support such an attribute, and I don't want to support it for an IPP-to-LPD gateway because the gateway would then have to maintain state for a client that sends it to the IPP-to-LPD gateway.   Received: from cnri by ietf.org id aa16447; 10 Sep 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 PAA21478 for ; Wed, 10 Sep 1997 15:04:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00557 for ; Wed, 10 Sep 1997 15:01:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 14:57:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29973 for ipp-outgoing; Wed, 10 Sep 1997 14:49:10 -0400 (EDT) Message-Id: <3.0.1.32.19970910113649.00c46480@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Sep 1997 11:36:49 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference September 11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org We will hold a short phone conference at 1:00 - 2:00 PST The main subject for discussion is how to meet the IETF requirements for security in IPP without dragging out the process. There are two possible approaches: 1) Dodge the issue, by requiring a very limited set of manadatory secueirty features, basically limited to RFC 2068 and RFC 2069, with the risk of being shot down during the IESG review. 2) Working with the IETF security groups to help find a solution that they would accept. The number to dial is: 1-800-857 5607 passcode: cmanros ----- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa16801; 10 Sep 97 15: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 PAA21527 for ; Wed, 10 Sep 1997 15:13:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00813 for ; Wed, 10 Sep 1997 15:09:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 15:07:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00634 for jmp-outgoing; Wed, 10 Sep 1997 15:06:06 -0400 (EDT) From: Harry Lewis To: jmp@pwg.org, ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: JMP> IPP> MOD - 'canceled' and 'aborted' job state semantics Message-ID: <5030300010269757000002L072*@MHS> Date: Wed, 10 Sep 1997 15:10:56 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Tom, I support the "e-mail" conclusion in favor of changing STATE when the CANCEL or ABORT is completed and associated attributes (ex. sheets used) are at their final value. >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* This has been discussed openly for a significant duration on JMP, so I feel agreement has been reached there (unless someone objects). Yes, we do need better IPP coverage of this topic. You are correct ... >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. I would see this as a late change and overly complex, at this point. Harry Lewis   Received: from cnri by ietf.org id aa17302; 10 Sep 97 15: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 PAA21572 for ; Wed, 10 Sep 1997 15:23:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01314 for ; Wed, 10 Sep 1997 15:20:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 15:16:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00658 for ipp-outgoing; Wed, 10 Sep 1997 15:06:14 -0400 (EDT) From: Harry Lewis To: jmp@pwg.org, ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics Message-ID: <5030300010269757000002L072*@MHS> Date: Wed, 10 Sep 1997 15:10:56 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Tom, I support the "e-mail" conclusion in favor of changing STATE when the CANCEL or ABORT is completed and associated attributes (ex. sheets used) are at their final value. >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* This has been discussed openly for a significant duration on JMP, so I feel agreement has been reached there (unless someone objects). Yes, we do need better IPP coverage of this topic. You are correct ... >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. I would see this as a late change and overly complex, at this point. Harry Lewis   Received: from cnri by ietf.org id aa18279; 10 Sep 97 15: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 PAA21670 for ; Wed, 10 Sep 1997 15:48:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02156 for ; Wed, 10 Sep 1997 15:45:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 15:38:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01433 for ipp-outgoing; Wed, 10 Sep 1997 15:23:36 -0400 (EDT) Date: Wed, 10 Sep 1997 12:27:14 PDT From: Ira Mcdonald x10962 Message-Id: <9709101927.AA08610@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: Re: IPP> TES Meeting Minutes Sender: ipp-owner@pwg.org Hi Carl-Uno and IPP folks, Wednesday (10 Sept 1997) Carl-Uno, you are right that interoperable implementations are not REQUIRED for publication as an IETF 'Proposed Standard'. Nonetheless, interoperable implementations are RECOMMENDED (see the excerpt below), and are common practice in protocols submitted as 'Proposed Standards' for intermediate systems (routers, hubs, bridges, etc). Cheers, - Ira McDonald (outside consultant at Xerox) 906-494-2434 From IETF 'Internet Official Protocol Standards' (RFC 2200, June 1997), page 8: 4.1.2. Draft Standard Protocol The IESG is actively considering this protocol as a possible >> Standard Protocol. Substantial and widespread testing and comment >> are desired. Comments and test results should be submitted to the >> IESG. There is a possibility that changes will be made in a Draft Standard Protocol before it becomes a Standard Protocol. 4.1.3. Proposed Standard Protocol These are protocol proposals that may be considered by the IESG >> for standardization in the future. Implementation and testing by >> several groups is desirable. Revision of the protocol specification is likely.   Received: from cnri by ietf.org id aa18382; 10 Sep 97 15: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 PAA21680 for ; Wed, 10 Sep 1997 15:51:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02564 for ; Wed, 10 Sep 1997 15:48:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 15:42:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01459 for ipp-outgoing; Wed, 10 Sep 1997 15:27:35 -0400 (EDT) Date: Wed, 10 Sep 1997 12:26:46 -0700 From: Robert Herriot Message-Id: <199709101926.MAA27785@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Allow more JT attributes to be document attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org As we add more attributes to the document level, we are making validation more difficult. With document level attributes it is possible for CreateJob to succeed and for a later SendDocument to fail because of an unsupported attribute. Thus the success of CreateJob is no longer an indicator of success and ValidateJob isn't either because it assumes that all attributes are job level. An attribute supported at the job level may fail at the document level. So I ask, are we starting down another slippery slope that should best wait for some version after IPP Version 1.0? When we just had document-format, we could mandate that it must be the same for all documents, as required by some print systems. We could do the same for compression. But now with document-k-octets, and additional proposed attributes, things are getting more difficult. The real issue is whether ALL attributes, even document ones, should be in the PrintJob/CreateJob operation so that a job can be fully validated during the initial operation, or should document level attributes be in the SendDocument operation where it may be more convenient to send them. There are pros and cons. I think that we may find it hard to make an irrevocable commitment at this late hour. Bob Herriot > From hastings@cp10.es.xerox.com Wed Sep 10 07:58:34 1997 > > Subj: Simple proposal to allow more Job Template attributes to be per-document > From: Tom Hastings > File: per-doc.doc > Date: 9/9/97 > > The latest draft Model document OPTIONALLY allows 5 job template attributes > to be document attributes when Create-Job/Send-Document and Send-URI > operations are implemented: > > document-format > compression > document-k-octets > document-impressions > document-media-sheets > > as agreed in Redmond. > > See the table in section 4.2 and the list in section 4.4. > > The table in section 4.2 is divided into two parts, with the above 5 > attributes being last in the table. > > > I talked with Roger yesterday and we'd like to make the following proposal: > > > 1. We'd like to move the boundary up to include the attributes from "media" > down through "page-range" as well. Thus the following job template > attributes would become optional document attributes along with the above 5: > "media", "number-up", "sides", "printer-resolution", "print-quality" and > "page-range". > > The "finishing" and "copies" attributes already have the > "multiple-document-handling attribute to control their semantics, so maybe > they should remain as job level only. Then move them up next to > "multiple-document-handling in section 4.2 so that it will be easier for > readers to understand their interaction. > > With the above changes, all of the job template attributes that make sense > for being per-document MAY be supported with Send-Document and Send-URI > operations. > > > 2. Since section 3.3.1.1 indicates that these job template attributes are > OPTIONAL as document attributes, a client needs to be able to tell which are > supported as per-document attributes and which are supported only as job > attributes. Therefore, we propose adding a "document-attributes-supported" > Printer description attribute in which the Printer returns the keyword names > of the Job Template attributes that it supports as document attributes in > the Send-Document and Send-URI operations. > > > 3. We need to clarify what happens when a client supplies a job template > attribute at the job level in a Create-Job operation and then also specifies > the same attribute (with a different value) as a document attribute in the > Send-Document or Send-URI operation. We think that the attribute specified > at the document level should override the value of the attribute specified > at the job level, but only for the documents to which the document attribute > is specified. Thus the job level attribute specifies for any documents that > don't have that attribute specified. > > For the three attributes that are counts: "document-k-octets", > "document-impressions", and "document-media-sheets", the value at the job > level, if supplied SHALL be the sum for the entire job, while the value at > the document level, if supplied SHALL be for that document alone. So for > these three (extensive) attributes, the document level doesn't overide the > job level attribute, but, instead complements it. > > > 4. On Get Attributes, we need to clarify that, depending on implemenation, > the Printer MAY either: > (1) factor out common document attributes and report them as job attributes, > instead of document attributes > (2) return all document attributes at the document level, regardless of how > the client has specified them > or > (3) preserve the job versus document attributes as supplied by the client, > since the semantic interpretation of all three representations of a job > SHALL be the same. > >   Received: from cnri by ietf.org id aa19066; 10 Sep 97 16: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 QAA21744 for ; Wed, 10 Sep 1997 16:18:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03200 for ; Wed, 10 Sep 1997 16:15:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 16:11:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02697 for ipp-outgoing; Wed, 10 Sep 1997 16:02:46 -0400 (EDT) Date: Wed, 10 Sep 1997 13:00:25 -0700 From: Robert Herriot Message-Id: <199709102000.NAA27839@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Allow more JT attributes to be document attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org If we want to go down the slippery slope that Tom proposes, I have an alternate proposal to Tom's which avoids some of the problems in his proposal. My proposal is that the default behavior of a server be for it to support NO document attributes, but that a server implementation can support any attribute on a document basis. This allows servers to conform to the standard and ignore this whole thorny problem of document attributes. If we have the attribute document-attributes-supported that Tom proposes, an implementation that doesn't support document attributes need not support this attribute either. If an attribute-name is a member of the document-attributes-supported, then the server supports that attribute with either its standard type, e.g. key-word or with a dictionary value where that dictionary contains an attribute named "default" for the job level behavior and one additional attribute for each document which is different. Such an attribute could be named '1' for the first document, '2' for the second one, etc. This leaves all information in the PrintJob/CreateJob operation for easy validation. For example, if media is letter for all documents in a job, then its value is "letter". If documents 1,2 and 4 four are letter but document 3 is legal, then media is a dictionary with two sub-attributes: "default" has the value of "letter" and "3" has the value of "legal". If "media" is not a member of document-attributes-supported or document-attributes-supported is not a supported attribute in the printer, the server treats a dictionary type for media as an unsupported value and either rejects the job (fidelity is true) or does substitution (fidelity is false). Should we want to move ahead with Tom's proposal, and I don't know that we do, then I think that my proposal offers a better way for different levels of support. My 2 cents. Bob Herriot > From hastings@cp10.es.xerox.com Wed Sep 10 07:58:34 1997 > > Subj: Simple proposal to allow more Job Template attributes to be per-document > From: Tom Hastings > File: per-doc.doc > Date: 9/9/97 > > The latest draft Model document OPTIONALLY allows 5 job template attributes > to be document attributes when Create-Job/Send-Document and Send-URI > operations are implemented: > > document-format > compression > document-k-octets > document-impressions > document-media-sheets > > as agreed in Redmond. > > See the table in section 4.2 and the list in section 4.4. > > The table in section 4.2 is divided into two parts, with the above 5 > attributes being last in the table. > > > I talked with Roger yesterday and we'd like to make the following proposal: > > > 1. We'd like to move the boundary up to include the attributes from "media" > down through "page-range" as well. Thus the following job template > attributes would become optional document attributes along with the above 5: > "media", "number-up", "sides", "printer-resolution", "print-quality" and > "page-range". > > The "finishing" and "copies" attributes already have the > "multiple-document-handling attribute to control their semantics, so maybe > they should remain as job level only. Then move them up next to > "multiple-document-handling in section 4.2 so that it will be easier for > readers to understand their interaction. > > With the above changes, all of the job template attributes that make sense > for being per-document MAY be supported with Send-Document and Send-URI > operations. > > > 2. Since section 3.3.1.1 indicates that these job template attributes are > OPTIONAL as document attributes, a client needs to be able to tell which are > supported as per-document attributes and which are supported only as job > attributes. Therefore, we propose adding a "document-attributes-supported" > Printer description attribute in which the Printer returns the keyword names > of the Job Template attributes that it supports as document attributes in > the Send-Document and Send-URI operations. > > > 3. We need to clarify what happens when a client supplies a job template > attribute at the job level in a Create-Job operation and then also specifies > the same attribute (with a different value) as a document attribute in the > Send-Document or Send-URI operation. We think that the attribute specified > at the document level should override the value of the attribute specified > at the job level, but only for the documents to which the document attribute > is specified. Thus the job level attribute specifies for any documents that > don't have that attribute specified. > > For the three attributes that are counts: "document-k-octets", > "document-impressions", and "document-media-sheets", the value at the job > level, if supplied SHALL be the sum for the entire job, while the value at > the document level, if supplied SHALL be for that document alone. So for > these three (extensive) attributes, the document level doesn't overide the > job level attribute, but, instead complements it. > > > 4. On Get Attributes, we need to clarify that, depending on implemenation, > the Printer MAY either: > (1) factor out common document attributes and report them as job attributes, > instead of document attributes > (2) return all document attributes at the document level, regardless of how > the client has specified them > or > (3) preserve the job versus document attributes as supplied by the client, > since the semantic interpretation of all three representations of a job > SHALL be the same. > >   Received: from cnri by ietf.org id aa22884; 10 Sep 97 19: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 TAA22325 for ; Wed, 10 Sep 1997 19:19:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA03998 for ; Wed, 10 Sep 1997 19:16:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 19:12:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03480 for ipp-outgoing; Wed, 10 Sep 1997 19:03:53 -0400 (EDT) Date: Wed, 10 Sep 1997 16:03:05 -0700 From: Robert Herriot Message-Id: <199709102303.QAA28041@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD new attributes, such as orientation X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I assume that today's decision to roll back some attributes to pre-Redmond includes eliminating "orientation". It is not suitable as currently defined in the model document. Orientation has many uses. But as defined in the model document, it is only for unpaginated document formats, such as text. We originally had many attributes for text, such as margins, header-text, footer-text, etc. We got rid of these many months ago. It doesn't make sense to bring back just one of these. When Roger described the reason for wanting this attribute, it was to control 2-up so that the orientation would be right. Portrait page images rotate 90 degrees counterclockwise and landscape page-images rotate 90 degress clockwise. There is no issue for 1-up or 4-up because they don't rotate. So, if this is the problem he is solving, he should instead ask for an additional value called 2-up-landscape or 2-up-counter-rotate, whatever is his choice. Bob Herriot   Received: from cnri by ietf.org id aa23390; 10 Sep 97 19: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 TAA22372 for ; Wed, 10 Sep 1997 19:44:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA04280 for ; Wed, 10 Sep 1997 19:41:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 19:38:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04120 for jmp-outgoing; Wed, 10 Sep 1997 19:37:25 -0400 (EDT) From: Harry Lewis To: ipp@pwg.org, jmp@pwg.org, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema Message-ID: <5030300010287025000002L052*@MHS> Date: Wed, 10 Sep 1997 19:42:09 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Ira, I could live with a new state if we were in the early stages of this MIB. In the beginning I argued for a succinct list of STATES rather than a caboodle of catagorized state reasons. But, long ago, we landed on a limited set of states and many, many reasons. We're in the tweaking stage, now, just trying to lay down some interoperability regarding use of what we have. I think adding a state at this point is too big a change. I believe we're expending a lot of energy to solve a very transient condition - the admittedly short time between a CANCEL request and a CANCEL (completed) state change. I don't think it's necessary, especially in light of the fact that we have state reasons such as... canceledByOwner, canceledByOperator, porcessingToStopPoint etc. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- ipp-owner@pwg.org on 09/10/97 02:23:54 PM Please respond to ipp-owner@pwg.org @ internet To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com @ internet cc: Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa23611; 10 Sep 97 19: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 UAA22388 for ; Wed, 10 Sep 1997 20:01:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA04860 for ; Wed, 10 Sep 1997 19:57:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 19:49:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04112 for ipp-outgoing; Wed, 10 Sep 1997 19:37:18 -0400 (EDT) From: Harry Lewis To: ipp@pwg.org, jmp@pwg.org, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema Message-ID: <5030300010287025000002L052*@MHS> Date: Wed, 10 Sep 1997 19:42:09 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Ira, I could live with a new state if we were in the early stages of this MIB. In the beginning I argued for a succinct list of STATES rather than a caboodle of catagorized state reasons. But, long ago, we landed on a limited set of states and many, many reasons. We're in the tweaking stage, now, just trying to lay down some interoperability regarding use of what we have. I think adding a state at this point is too big a change. I believe we're expending a lot of energy to solve a very transient condition - the admittedly short time between a CANCEL request and a CANCEL (completed) state change. I don't think it's necessary, especially in light of the fact that we have state reasons such as... canceledByOwner, canceledByOperator, porcessingToStopPoint etc. Harry Lewis - IBM Printing Systems ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- ipp-owner@pwg.org on 09/10/97 02:23:54 PM Please respond to ipp-owner@pwg.org @ internet To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com @ internet cc: Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema Hi Tom, After reading all that (excellent writeup, by the way), I begin to like adding the clean and unambiguous 'terminating' state (from ISO DPA), so that leading/trailing edge changes ALWAYS result in a state change (and thus a notification or event, if possible) and a client need not examine state reasons to determine if an operation is legal at the present moment. Harry, could you live with a 'cleanup' state on the switchbar of the three terminal states? It sure makes notifications (or SNMP traps) a lot cleaner and simpler. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------------------------------- Tom's note ---------------------- From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R There has been a good discussion in both the IPP and JMP DL about the semantics of the 'canceled' state: whether the job moves to 'canceled' state immediately upon acceptance of the Cancel-Job operation or whether the job moves to the 'canceled' state when the canceling has completed and the job is quiescent (all the job accounting counters have stopped counting, and all the media sheets are stacked). Usually the time difference is just a few seconds after the Cancel-Job operation has been accepted, but in some implementations the time could be considerably longer than a few seconds, including fixing a paper jam or paper out. The same discussion also applies to when the system aborts a job. Does the job move to the 'aborted' state immediately, or when the system finishes aborting the job? The 'completed' state is specified as being reached when all of the processing, including "media sheets successfully stacked", so that the 'completed' state is reached after the job is quiescent. It is hoped that we could discuss this issue at the IPP telecon today and continue and resolve it at the IPP meeting next week in Atlanta (with JMP participation). We need to keep both specs in synch. The issue is whether to continue the current IPP and JMP semantics: A. Leading Edge Job State Transition: 1. The job changes immediately to the 'canceled' or 'aborted' states from the 'processing' state with the 'processing-to-stop-point' and 'canceled-by-xxx' reasons set. 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' job state reason is removed (but the job state doesn't change since the job is alread in the 'canceled' or 'aborted'). OR change the IPP and JMP semantics to: B. Trailing Edge Job State Transition: 1. The job remains in 'processing' with 'processing-to-stop-point' and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' is removed AND the job transitions to the 'canceled' or 'aborted' state with either 'canceled-by-xxx' or 'aborted-by-system' remaining. (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, but if there every is another reason to abort a job, it may be good to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' is also useful in the pending-held state for systems that chose to allow a user or operator to release a job that has had a problem, perhaps after modifying the job or the environment). PROs and CONs: 1. The 'canceled' and 'aborted' states become quiescent states, like the 'completed' state already is. The advantage of Trailing Edge Job State Transition is that the three terminal states: 'completed', 'canceled', and 'aborted' would be all quiescent state. With the Leading Edge Job State Transition semantics, 'completed' is quiescent, and 'canceled' and 'aborted' are not. 2. Easier rejection of operations: just use the job state, not the reasons The advantage of the Leading Edge Job State Transition is that it is clearer when operations are illegal: only the job states are involved. This is the classis job state transition diagram showing operations and job state transitions. So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error that the job is in an inappropriate state whenever the job state is 'completed', 'canceled', or 'aborted'. With the Trailing Edge Job State Transition, the user and the Printer have to look at both the job state and the job-state-reasons in order to reject multiple Cancel-Job operations and the job state transition diagram is more complicated. 3. Better notification/trapping when job is quiescent The advantage of Trailing Edge Job State Transitions is that an application program, such as an accounting program, that gets a notification or trap on job state transitions, will get the notification or trap on entering the 'completed', 'canceled', or 'aborted' state AFTER all the processing has completed and all the counts have finished counting, so that polling can be avoided for any additional processing to stop point activity. Also the job state reflects the completion of an operation, not just the acceptance of the operation for those operations that are not performed before the response is returned, such as Cancel-Job, when the job is in the 'processing' state. NOTE: IPP has notification, but JMP does not have SNMP trapping, though all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) E-MAIL conclusion: The e-mail discussion seems to favor changing the IPP and JMP semantics to "Trailing Edge Job State Transition" semantics, since many protocols use states to mean that the operation has finished all of its work. Also reducing polling seems to be more important than simplfying the Printer implementation and the job state transition diagram when legal operations are shown. ******************************************************************* We need to see if the rest of the IPP and JMP participants agree to change the spec to Traling Edge Job State Transition semantics. ******************************************************************* Probably neither side would be happy with a compromise that complicates the state model by adding a new Job state: 'terminating' (the name used for the ISO DPA job state). Then the 'processing-to-stop-point' reason would not be needed for this. With such a compromise, there would be a job state transition when the Cancel-job operation is accepted (leading edge transition from 'processing' to 'terminating') and when the operation completes (trailing edge transition from 'terminating' to 'completed', 'canceled', or 'aborted'). The Cancel-Job operation would be rejected when the job was in the 'terminating' job state (as well as when in the 'completed', 'canceled', and 'aborted' job states). Comments? Tom   Received: from cnri by ietf.org id aa23715; 10 Sep 97 20: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 UAA22422 for ; Wed, 10 Sep 1997 20:07:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05433 for ; Wed, 10 Sep 1997 20:04:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 20:00:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04309 for ipp-outgoing; Wed, 10 Sep 1997 19:46:13 -0400 (EDT) Message-Id: <3.0.1.32.19970910163406.00ae5840@garfield> X-Sender: cmanros@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Sep 1997 16:34:06 PDT To: treese@openmarket.com From: Carl-Uno Manros Subject: IPP> Status of TLS spec. Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Win, My name is Carl-Uno Manros, co-chair of the IPP WG. I am writing to you in your role as TLS WG chair. We are approaching the date for sending out our documents for final call and submission to the IESG for approval as Proposed Standards. For your information, we package our IPP semantics in MIME-format, which is transferred using HTTP 1.1 POST, and can obviously make use of Digest Authentication (RFC 2069), but this is not sufficient for all our scenarios. We are still struggling with the absence of formal security specification for secure transmission, in particular the TLS, which we could reference. How close is your group to finish the work on TLS and put it on the IETF standards track? 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 aa23987; 10 Sep 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 UAA22459 for ; Wed, 10 Sep 1997 20:30:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06078 for ; Wed, 10 Sep 1997 20:27:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 20:23:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05557 for ipp-outgoing; Wed, 10 Sep 1997 20:14:23 -0400 (EDT) Message-Id: <3.0.1.32.19970910170222.00ae65d0@garfield> X-Sender: cmanros@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Sep 1997 17:02:22 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from Munich Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, at long last I have now pulled myself together to edit up the minutes from Munich. My thanks to Randy and Scott who took the actual notes during the meetings. I have gone over their notes and edited out the things that were not controversial, to mainly leave in the things that need further action. Hope I did not leave out anything of importance. Here is the text: --- IETF-39 - Minutes from the IPP WG sessions on Monday August 11 and Wednesday August 13, 1997 ================================================================== Chairs: Carl-Uno Manros and Steve Zilles The Monday session meeting was attended by about 35 experts and the Wednesday session by about 25. A total of 48 experts signed up on the attendance sheet. All of the WGs Internet-Drafts were open to review and comments. Session on Monday, August 11 (minutes taken by Randy Turner) ============================ Carl-Uno Manros opened the meeting and reviewed the agenda. The I-D: Requirements for an Internet Printing Protocol was briefly introduced. This document will need some updating to align with more recent documents, otherwise no comments. Steve Zilles then briefly provided a quick overview of IPP, specifically the object concept. The I-D: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol was briefly discussed, limited to the model aspects, without any substantial comments. The I-D: Internet Printing Protocol/1.0: Model and Semantics was introduced by Scott Isaacson. This is the key document for IPP and still contained a number of open issues. Scott had prepared proposed resolutions to all the issues flagged, based on WG input since the draft was published. Most of the proposed resolutions were uncontroversial, but the following raised some discussion: 1. Compression of IPP messages This issue is OPEN. The WG is looking at other standards and existing enumerations for compression algorithms. 2. Alignment with Job Monitoring MIB job-k-octets, job-impressions, and job-media-objects will be aligned semantically with the Job Monitoring MIB. One note about the Job Monitoring MIB. Keith Moore, Area Director for Applications, noted that there is no formal IETF working group chartered for the Job Monitoring MIB effort. Further, there may be problems with IPP documents achieving "proposed" status if IPP documents reference such other documents. He reiterated that the Printer Working Group had submitted an extension to the Printer MIB working group's charter to include the Job MIB, but that the request had not been processed by the IESG, so there may be a problem here. 3. Human Language and Character Set IPP mandates UTF-8 for application/ipp messages. HTTP Accept-Headers will be used for human-language attributes. Questions from the audience asked about whether the WG had considered the use of an updated Unicode spec. UCS-4 which is currently being proposed. Scott Isaacson implied that the WG is open to suggestions as to what standard should be applied here. The basic theme echoed by Keith Moore was to try and follow Harald Alvestrand's document, and if better methods are suggested, the IESG will keep an open mind. 4. Job-URI attribute "A lively discussion ensued". Basically, it was agreed that this issue is still OPEN and will be discussed on the mailing list. 5. Use of "Conditionally Mandatory" in IPP documents. The I-D will be re-edited to focus on what must be implemented in order to realize certain specific functional components. Keith Moore reflected on current IETF documents for keywords such as MUST, SHOULD, MAY, etc. and that the WG should try and follow the IETF guidelines and best current practice with regards to such conformance/compliance vocabulary. 6. Use of MIME types for "document-format" Currently, the model document specifies the use of Printer MIB enumerations for specification of document-format. In addition, at a recent PWG meeting, it was agreed that enumerations for PDF and HTML ought to be added to this list. Upon hearing the proposed alignment with the Printer MIB for these values, "a lively discussion ensued". It was the opinion of Larry Masinter (chair of HTTP WG), Keith Moore, and most of the IETF audience that alignment with the Printer MIB was a mistake, and that we should focus on sticking with MIME-type specifications. Further, Keith Moore went on to say that the current draft of the Printer MIB was "broken", and that he is seriously considering delaying advancement of the Printer MIB draft until this (and possibly other) issues are addressed. Keith did not go into any detailed analysis of why the MIB was broken, but seemed to suggest that there were more than one reason why it's broken. He went on to say that its possible that (ironically) the IESG might suggest to the working group that the Printer MIB should align itself with the MIME-types and change the way that interpreters are enumerated in the MIB. He suggested that the group should consider strings, and not enumerations, to specify these types (i.e., MIME types). Keith was pretty adamant on this issue and would have continued discussion, but Steve Z. and Scott suggested that discussion on the Printer MIB was not appropriate at an IPP WG meeting. 7. Server Timeout The printer will abort a job after some server-configured inactivity timeout. If some documents had already been printed, the rest of the job is canceled. Larry Masinter questioned why IPP operations could not be "re-tried" if a failure occurred. Steve Zilles responded that there might be idempotency problems with operation retries. More discussion on the mailing list should be done. 8. Version Numbers Given the number of HTTP WG members in the room, "a lively discussion" on capability negotiation and version numbers ensued. It is very likely that some combination of versioning, and capability negotiation will be required before gaining IESG acceptance. 9. Color Will remain a boolean, "color-supported'. Leave it to the PDL to handle other color model and capabilities requirements. Some questions by the audience questioned the usefulness of a "boolean" to specify color capabilities. Keith Moore said that he would like to see the specification of color capabilities more fleshed out than just "yes, this device supports color". Larry Masinter also suggested that in order to curb the displeasure with such a "boolean" specification of color, that maybe the WG should remove this and just do a complete color capabilities model in a future version of IPP. He suggested that either IPP should do color (the right way), or not at all. After a brief rationale statement by Scott Isaacson and Steve Zilles for the boolean color-supported, both Larry and Keith seemed to understand why, but still were not crazy about the inclusion of color, without the WG "doing it right". 10. Date and Time "time-since-xxxx" attributes will be in "seconds" (and OPTIONAL). A MANDATORY "printer-up-time" will be added to the spec. and will essentially reflect the MIB-II "sysUpTime" object. Larry Masinter questioned why a printer "end-user" would care about how long the printer had been "up", since IPP 1.0 is basically targeted for end-users. He further questioned why the value was mandatory. The WG implied that since MIB-II sysUpTime was mandatory, that no undue burden should be placed on IPP implementations to support it. 11. Formatting Attributes The WG will work on a proposal for "page-range" and "page-orientation" attributes. 12. Order of Jobs returned by "Get-Jobs" OPEN. 13. Event Notification The WG has an action item to specify event notifications. They should be machine-readable. 14. media-ready vs. media-supported OPEN. Some implementation require this distinction. Especially server-based implementations of IPP. It was suggested that media-supported be dropped and only support for media-ready should be supported, since this would apply to all IPP configurations. The I-D: Internet Printing Protocol/1.0: Directory Schema was introduced by Scott Isaacson. More work needs to be done to bring the current directory schema documents up to date with the current Model document. One of the members of the Service Location Protocol WG mentioned that they already have started working on a schema for Printing Class applications within their WG, and that input from the IPP WG is "very welcome" at this stage. Scott Isaacson stated that such cooperation should definitely take place. Session on Wednesday, August 13 (minutes taken by Scott Isaacson) =============================== Carl-Uno Manros opened the meeting and presented the agenda. The I-D: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol was introduced by Steve Zilles and then briefly discussed, limited to the protocol aspects, without any substantial comments. The I-D: Internet Printing Protocol/1.0: Security was introduced by Carl-Uno Manros. The following comments and discussion followed: 1. Scope of security in IPP What is in and what is out of IPP? How much can we rely on getting from the numerous IETF security projects and what do we have to do ourselves? Should not the HTTP group be responsible for security needed for HTTP? How is the use of TLS with HTTP specified? HTTP seem to ignore further standardization of Basic Authentication and are only progressing Digest Authentication. 2. Status of IETF security standards There is an interest from IPP to use TLS for secure transmission, but the TLS standard is not yet finished. Can SSL be used instead? 3. Secure and insecure communication with the same IPP Printer We should allow for the protocol to have some kind of negotiation mechanism. One suggestion was to always use TLS, allowing the client to be configured to run with TLS NULL, NULL, NULL. It was also stated that the content of the current document will be divided up between the IPP Model & Semantics and Protocol Specification document in the next round of editing. The I-D: Internet Printing Protocol/1.0: Protocol Specification was introduced by Bob Herriot. The following comments and discussion followed: 1. Does IPP need to worry about the fact that some server implementations do not pass HTTP headers to the back end processes (CGI)? No, this is an implementation problem. 2. Accept headers Accept-charset is irrelevant Accept-language is relevant Accept-encoding probably (might be) 3. We need to make sure that the IPP mapping works with generic HTTP clients, HTTP origin servers, and HTTP proxy servers 4. Why POST over new method PRINT? PRO POST It is there It works It really doesn't matter CON POST Harder for proxy server to differentiate Better performance with native method POST was intended to be a "big hole" WEBDAV uses XML and new methods RESOLUTION: Use POST for all of the reasons identified and move on. 5. Why not use some other transport, such as SMTP? IPP has been designed not to prevent this, however no interest in the WG to make such other mappings. Additional mappings could show a mapping of multiple operations in one MIME component, or could use Internet Fax extensions. 6. Content negotiation should be more symmetrical (client telling server, server telling client) The I-D: Mapping between LPD and IPP Protocols was introduced by Bob Herriot. The following points were discussed: 1. How does mapper support "host"? IPP to LPD; set H to mapper host LPD to IPP, ignore H 2. job-k-octets semantic change between IPP and LPD (which includes copy count?). Just do the mapping 3. Move to Job-ID vs. Job-URI Needs to be resolved on the discussion list (see Model & Semantics discussion earlier). 4. Should IPP pick a format for queue status or make it dependent on each LPD implementation? Further discussion on the DL. a. ignore the problem b. pick a format c. make it MUST or SHOULD 5. This mapping document is an INFORMATIONAL RFC, not an IMPLEMENTATION RFC 6. Should DVI, ditroff, or troff should be added as document-format types? If we make them MIME types, then anyone can add them that wants them. 7. Open issue about mapping LPD to IPP error codes. The chairs made clear that the intent of the WG is to move current I-Ds to final call in September 1997. ----- El Segundo, September 11, 1997 - Carl-Uno Manros - IPP Co-chair Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa24206; 10 Sep 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 UAA22485 for ; Wed, 10 Sep 1997 20:48:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06691 for ; Wed, 10 Sep 1997 20:45:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 20:41:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06186 for ipp-outgoing; Wed, 10 Sep 1997 20:33:07 -0400 (EDT) Date: Wed, 10 Sep 1997 17:32:17 -0700 From: Robert Herriot Message-Id: <199709110032.RAA28146@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD copies-supported with regard to collated. X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I suggest that the model document remove the change that has copies-supported consist of two integer ranges, one range for collated copies and one range for uncollated copies. This change makes copies-supported have a different structure from of xxx-supported attributes of integer attributes. It would probably be better for such complexity to handled via some other mechanism, such as a dictionary. As a result, I suggest moving this solution to version 2.0, and reverting to copies-supported being an integer-range with not specification about collated or non-collated. Bob Herriot   Received: from cnri by ietf.org id aa24581; 10 Sep 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 VAA22514 for ; Wed, 10 Sep 1997 21:19:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07048 for ; Wed, 10 Sep 1997 21:16:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 21:13:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06874 for jmp-outgoing; Wed, 10 Sep 1997 21:12:22 -0400 (EDT) Date: Wed, 10 Sep 1997 17:47:16 -0700 (Pacific Daylight Time) From: Ron Bergman To: Harry Lewis cc: ipp@pwg.org, jmp@pwg.org, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com Subject: Re: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema In-Reply-To: <5030300010287025000002L052*@MHS> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jmp-owner@pwg.org Harry, I agree with your position 100%. We spent considerable time developing the three state model and, in spite of the "caboodle" of state reasons, does map very well into a real environment. Keeping the job state at "Processing" for this transient period is merely a small change to the model and shoukd not be difficult for a printer to report or a management application to process. Ron Bergman Dataproducts Corp. On Wed, 10 Sep 1997, Harry Lewis wrote: > Ira, I could live with a new state if we were in the early stages of this MIB. > In the beginning I argued for a succinct list of STATES rather than a caboodle > of catagorized state reasons. But, long ago, we landed on a limited set of > states and many, many reasons. We're in the tweaking stage, now, just trying to > lay down some interoperability regarding use of what we have. I think adding a > state at this point is too big a change. > > I believe we're expending a lot of energy to solve a very transient condition - > the admittedly short time between a CANCEL request and a CANCEL (completed) > state change. I don't think it's necessary, especially in light of the fact > that we have state reasons such as... canceledByOwner, canceledByOperator, > porcessingToStopPoint etc. > > > Harry Lewis - IBM Printing Systems > > > ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- > > > ipp-owner@pwg.org on 09/10/97 02:23:54 PM > Please respond to ipp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com > @ internet > cc: > Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema > > > Hi Tom, > > After reading all that (excellent writeup, by the way), I begin to > like adding the clean and unambiguous 'terminating' state (from > ISO DPA), so that leading/trailing edge changes ALWAYS result > in a state change (and thus a notification or event, if possible) > and a client need not examine state reasons to determine if an > operation is legal at the present moment. > > Harry, could you live with a 'cleanup' state on the switchbar > of the three terminal states? It sure makes notifications (or > SNMP traps) a lot cleaner and simpler. > > Cheers, > - Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > ---------------------------------- Tom's note ---------------------- > From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com > (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from > alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT > Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with > SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost > (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 > for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: > by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from > daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for > jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: > <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, > jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - > 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R > > There has been a good discussion in both the IPP and JMP DL about > the semantics of the 'canceled' state: whether the job moves to > 'canceled' state immediately upon acceptance of the Cancel-Job operation > or whether the job moves to the 'canceled' state when the canceling has > completed and the job is quiescent (all the job accounting counters have > stopped counting, and all the media sheets are stacked). > > Usually the time difference is just a few seconds after the Cancel-Job > operation has been accepted, but in some implementations the time could be > considerably longer than a few seconds, including fixing a paper jam or > paper out. > > The same discussion also applies to when the system aborts a job. > Does the job move to the 'aborted' state immediately, or when the > system finishes aborting the job? > > The 'completed' state is specified as being reached when all of the > processing, including "media sheets successfully stacked", so that the > 'completed' state is reached after the job is quiescent. > > It is hoped that we could discuss this issue at the IPP telecon today > and continue and resolve it at the IPP meeting next week in Atlanta > (with JMP participation). We need to keep both specs in synch. > > > > The issue is whether to continue the current IPP and JMP semantics: > > > A. Leading Edge Job State Transition: > > 1. The job changes immediately to the 'canceled' or 'aborted' states > from the 'processing' state with the 'processing-to-stop-point' > and 'canceled-by-xxx' reasons set. > > 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' > job state reason is removed (but the job state doesn't change since > the job is alread in the 'canceled' or 'aborted'). > > > OR change the IPP and JMP semantics to: > > > B. Trailing Edge Job State Transition: > > 1. The job remains in 'processing' with 'processing-to-stop-point' > and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > > 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' > is removed AND the job transitions to the 'canceled' or 'aborted' state > with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > > (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, > but if there every is another reason to abort a job, it may be good > to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' > is also useful in the pending-held state for systems that chose to > allow a user or operator to release a job that has had a problem, > perhaps after modifying the job or the environment). > > > > > PROs and CONs: > > > 1. The 'canceled' and 'aborted' states become quiescent states, like > the 'completed' state already is. > > The advantage of Trailing Edge Job State Transition is that the three > terminal states: 'completed', 'canceled', and 'aborted' would be > all quiescent state. > > With the Leading Edge Job State Transition semantics, 'completed' is > quiescent, and 'canceled' and 'aborted' are not. > > > 2. Easier rejection of operations: just use the job state, not the reasons > > The advantage of the Leading Edge Job State Transition is that it > is clearer when operations are illegal: only the job states are involved. > This is the classis job state transition diagram showing operations > and job state transitions. > > So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error > that the job is in an inappropriate state whenever the job state > is 'completed', 'canceled', or 'aborted'. > > With the Trailing Edge Job State Transition, the user and the Printer > have to look at both the job state and the job-state-reasons in order > to reject multiple Cancel-Job operations and the job state transition > diagram is more complicated. > > > 3. Better notification/trapping when job is quiescent > > The advantage of Trailing Edge Job State Transitions is that an application > program, such as an accounting program, that gets a notification or trap > on job state transitions, will get the notification or trap on entering > the 'completed', 'canceled', or 'aborted' state AFTER all the processing > has completed and all the counts have finished counting, so that polling > can be avoided for any additional processing to stop point activity. > > Also the job state reflects the completion of an operation, not just the > acceptance of the operation for those operations that are not performed > before the response is returned, such as Cancel-Job, when the job is > in the 'processing' state. > > NOTE: IPP has notification, but JMP does not have SNMP trapping, though > all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > > E-MAIL conclusion: > > The e-mail discussion seems to favor changing the IPP and JMP semantics > to "Trailing Edge Job State Transition" semantics, since many protocols > use states to mean that the operation has finished all of its work. > Also reducing polling seems to be more important than simplfying the Printer > implementation and the job state transition diagram when legal operations > are shown. > > ******************************************************************* > We need to see if the rest of the IPP and JMP participants agree > to change the spec to Traling Edge Job State Transition semantics. > ******************************************************************* > > > Probably neither side would be happy with a compromise that complicates > the state model by adding a new Job state: 'terminating' (the name > used for the ISO DPA job state). Then the 'processing-to-stop-point' reason > would not be needed for this. > > With such a compromise, there would be a job state transition when the > Cancel-job operation is accepted (leading edge transition from 'processing' > to 'terminating') and when the operation completes > (trailing edge transition from 'terminating' to 'completed', > 'canceled', or 'aborted'). The Cancel-Job operation would be rejected > when the job was in the 'terminating' job state (as well as when in the > 'completed', 'canceled', and 'aborted' job states). > > > Comments? > > Tom > > > > >   Received: from cnri by ietf.org id aa24826; 10 Sep 97 21: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 VAA22537 for ; Wed, 10 Sep 1997 21:39:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07805 for ; Wed, 10 Sep 1997 21:36:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 21:28:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06882 for ipp-outgoing; Wed, 10 Sep 1997 21:12:28 -0400 (EDT) Date: Wed, 10 Sep 1997 17:47:16 -0700 (Pacific Daylight Time) From: Ron Bergman To: Harry Lewis cc: ipp@pwg.org, jmp@pwg.org, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com Subject: Re: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema In-Reply-To: <5030300010287025000002L052*@MHS> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Harry, I agree with your position 100%. We spent considerable time developing the three state model and, in spite of the "caboodle" of state reasons, does map very well into a real environment. Keeping the job state at "Processing" for this transient period is merely a small change to the model and shoukd not be difficult for a printer to report or a management application to process. Ron Bergman Dataproducts Corp. On Wed, 10 Sep 1997, Harry Lewis wrote: > Ira, I could live with a new state if we were in the early stages of this MIB. > In the beginning I argued for a succinct list of STATES rather than a caboodle > of catagorized state reasons. But, long ago, we landed on a limited set of > states and many, many reasons. We're in the tweaking stage, now, just trying to > lay down some interoperability regarding use of what we have. I think adding a > state at this point is too big a change. > > I believe we're expending a lot of energy to solve a very transient condition - > the admittedly short time between a CANCEL request and a CANCEL (completed) > state change. I don't think it's necessary, especially in light of the fact > that we have state reasons such as... canceledByOwner, canceledByOperator, > porcessingToStopPoint etc. > > > Harry Lewis - IBM Printing Systems > > > ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ---- > > > ipp-owner@pwg.org on 09/10/97 02:23:54 PM > Please respond to ipp-owner@pwg.org @ internet > To: jmp@pwg.org @ internet, ipp@pwg.org @ internet, hastings@cp10.es.xerox.com > @ internet > cc: > Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema > > > Hi Tom, > > After reading all that (excellent writeup, by the way), I begin to > like adding the clean and unambiguous 'terminating' state (from > ISO DPA), so that leading/trailing edge changes ALWAYS result > in a state change (and thus a notification or event, if possible) > and a client need not examine state reasons to determine if an > operation is legal at the present moment. > > Harry, could you live with a 'cleanup' state on the switchbar > of the three terminal states? It sure makes notifications (or > SNMP traps) a lot cleaner and simpler. > > Cheers, > - Ira McDonald (outside consultant at Xerox) > High North Inc > PO Box 221 > Grand Marais, MI 49839 > 906-494-2434 > ---------------------------------- Tom's note ---------------------- > From jmp-owner@pwg.org Wed Sep 10 12:00:41 1997 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com > (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from > alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT > Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with > SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost > (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321 > for ; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received: > by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from > daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for > jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id: > <9709101550.AA22451@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, 10 Sep 1997 08:47:43 PDT To: ipp@pwg.org, > jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - > 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org Status: R > > There has been a good discussion in both the IPP and JMP DL about > the semantics of the 'canceled' state: whether the job moves to > 'canceled' state immediately upon acceptance of the Cancel-Job operation > or whether the job moves to the 'canceled' state when the canceling has > completed and the job is quiescent (all the job accounting counters have > stopped counting, and all the media sheets are stacked). > > Usually the time difference is just a few seconds after the Cancel-Job > operation has been accepted, but in some implementations the time could be > considerably longer than a few seconds, including fixing a paper jam or > paper out. > > The same discussion also applies to when the system aborts a job. > Does the job move to the 'aborted' state immediately, or when the > system finishes aborting the job? > > The 'completed' state is specified as being reached when all of the > processing, including "media sheets successfully stacked", so that the > 'completed' state is reached after the job is quiescent. > > It is hoped that we could discuss this issue at the IPP telecon today > and continue and resolve it at the IPP meeting next week in Atlanta > (with JMP participation). We need to keep both specs in synch. > > > > The issue is whether to continue the current IPP and JMP semantics: > > > A. Leading Edge Job State Transition: > > 1. The job changes immediately to the 'canceled' or 'aborted' states > from the 'processing' state with the 'processing-to-stop-point' > and 'canceled-by-xxx' reasons set. > > 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' > job state reason is removed (but the job state doesn't change since > the job is alread in the 'canceled' or 'aborted'). > > > OR change the IPP and JMP semantics to: > > > B. Trailing Edge Job State Transition: > > 1. The job remains in 'processing' with 'processing-to-stop-point' > and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > > 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' > is removed AND the job transitions to the 'canceled' or 'aborted' state > with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > > (Actually, the 'aborted-by-system' is redundant with the 'aborted' state, > but if there every is another reason to abort a job, it may be good > to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' > is also useful in the pending-held state for systems that chose to > allow a user or operator to release a job that has had a problem, > perhaps after modifying the job or the environment). > > > > > PROs and CONs: > > > 1. The 'canceled' and 'aborted' states become quiescent states, like > the 'completed' state already is. > > The advantage of Trailing Edge Job State Transition is that the three > terminal states: 'completed', 'canceled', and 'aborted' would be > all quiescent state. > > With the Leading Edge Job State Transition semantics, 'completed' is > quiescent, and 'canceled' and 'aborted' are not. > > > 2. Easier rejection of operations: just use the job state, not the reasons > > The advantage of the Leading Edge Job State Transition is that it > is clearer when operations are illegal: only the job states are involved. > This is the classis job state transition diagram showing operations > and job state transitions. > > So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error > that the job is in an inappropriate state whenever the job state > is 'completed', 'canceled', or 'aborted'. > > With the Trailing Edge Job State Transition, the user and the Printer > have to look at both the job state and the job-state-reasons in order > to reject multiple Cancel-Job operations and the job state transition > diagram is more complicated. > > > 3. Better notification/trapping when job is quiescent > > The advantage of Trailing Edge Job State Transitions is that an application > program, such as an accounting program, that gets a notification or trap > on job state transitions, will get the notification or trap on entering > the 'completed', 'canceled', or 'aborted' state AFTER all the processing > has completed and all the counts have finished counting, so that polling > can be avoided for any additional processing to stop point activity. > > Also the job state reflects the completion of an operation, not just the > acceptance of the operation for those operations that are not performed > before the response is returned, such as Cancel-Job, when the job is > in the 'processing' state. > > NOTE: IPP has notification, but JMP does not have SNMP trapping, though > all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > > E-MAIL conclusion: > > The e-mail discussion seems to favor changing the IPP and JMP semantics > to "Trailing Edge Job State Transition" semantics, since many protocols > use states to mean that the operation has finished all of its work. > Also reducing polling seems to be more important than simplfying the Printer > implementation and the job state transition diagram when legal operations > are shown. > > ******************************************************************* > We need to see if the rest of the IPP and JMP participants agree > to change the spec to Traling Edge Job State Transition semantics. > ******************************************************************* > > > Probably neither side would be happy with a compromise that complicates > the state model by adding a new Job state: 'terminating' (the name > used for the ISO DPA job state). Then the 'processing-to-stop-point' reason > would not be needed for this. > > With such a compromise, there would be a job state transition when the > Cancel-job operation is accepted (leading edge transition from 'processing' > to 'terminating') and when the operation completes > (trailing edge transition from 'terminating' to 'completed', > 'canceled', or 'aborted'). The Cancel-Job operation would be rejected > when the job was in the 'terminating' job state (as well as when in the > 'completed', 'canceled', and 'aborted' job states). > > > Comments? > > Tom > > > > >   Received: from cnri by ietf.org id aa24876; 10 Sep 97 21: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 VAA22544 for ; Wed, 10 Sep 1997 21:42:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08229 for ; Wed, 10 Sep 1997 21:39:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 21:34:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07090 for ipp-outgoing; Wed, 10 Sep 1997 21:18:05 -0400 (EDT) Date: Wed, 10 Sep 1997 18:17:13 -0700 From: Robert Herriot Message-Id: <199709110117.SAA28191@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Interesting observation X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org One of the arguments given repeatedly via email against Job-Ids is that gateways should not drive the architecture of IPP. Yet, the order of jobs returned by Get-Jobs became an open issue in Redmond (and remains so) precisely because of gateways that cannot easily reorder jobs to meet an ordering specified by IPP. It's hard to move ahead with so much behind. Bob Herriot   Received: from cnri by ietf.org id aa25425; 10 Sep 97 22: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 WAA22594 for ; Wed, 10 Sep 1997 22:20:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09136 for ; Wed, 10 Sep 1997 22:17:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 22:13:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08572 for ipp-outgoing; Wed, 10 Sep 1997 22:04:17 -0400 (EDT) Message-Id: <9709110204.AA22721@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, 10 Sep 1997 19:01:45 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Minutes from IPP 9/10/97 telecon Sender: ipp-owner@pwg.org I've posted the minutes from today's telecon: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ -rw-r--r-- 1 pwg pwg 12800 Sep 11 01:58 970910-ipp-conference-call.doc -rw-r--r-- 1 pwg pwg 6706 Sep 11 01:58 970910-ipp-conference-call.pdf -rw-r--r-- 1 pwg pwg 5271 Sep 11 01:56 970910-ipp-conference-call.txt Tom Here is the text version: Subj: Minutes of the IPP telecon, Wed, 9/10/97 From: Tom Hastings and Carl-Uno Manros Date: 9/10/97 File: tc970910.doc Attendees: Scott Isaacson, Roger deBry, Jim Walker, Lee Farrell, Ira McDonald, Bob Herriot, Ron Bergman, Peter Zehler, Steve Zilles, Jay Martin, Don Wright, Carl-Uno Manros, Tom Hastings We wrote these minutes up after the fact, so please comment if any of them are not correct. 1. Functionality freeze We agreed to freeze the functionality of IPP V1.0 in order to get the Model, Protocol, Directory, Requirements, and Rationale specs ready by the end of September to forward to the IESG. We agreed to limit changes to fixing errors and plugging holes in the existing functionality. 2. Making more Job Template attributes document attributes We decided not to make any Job Template attributes document attributes, thereby changing the current draft by making the "document-format", "compression", "document-k-octets", "document-impressions", and "document-media-sheets" Job Template attributes only be job level attributes. Also the semantics that multi-valued Job Template attributes would apply to each document was agreed to be removed from IPP V1.0. It was felt that the Job Template attributes could be made document attributes in IPP V2.0, but that it would take too long to decide now how to do it. We do not want to delay getting IPP V1.0 agreed and forwarded as a standard. As existence proofs, there are at least two proposals for upwards compatible extension to do so, one from Tom and one from Bob. 3. Don't add 'dictionary' attribute syntax at this time We decided that the proposal was good, but that we wouldn't add the functionality at this time, since IPP V1.0 will have no attributes that use it and we want to freeze the functionality. We will reserve an attribute syntax code for it and can then register the attribute syntax using the registration procedures for type 2 enums, after we finish IPP V1.0, so that the 'dictionary' attribute syntax need not wait for IPP V2.0. 4. Job-uri versus a 32-bit job-identifier Since neither Paul Moore nor Randy Turner were participating, we felt it best to postpone the discussion until the IPP meeting next Wednesday and Thursday, 9/17 and 9/18. ACTION ITEM (Carl-Uno): Call Paul and Randy to find out whether they will be attending the IPP meeting on 9/17 and 9/18 in Atlanta or have them attend by teleconference. ACTION ITEM (Don Wright): Set up a conference call for the afternoon of 9/17 for any participants that are not attending for discussion of this issue. We agreed that this issue is the biggest issue remaining in the specification. It is holding up prototyping and implementation. We also agreed that we must agree on a proposal next week and verify it on the mailing list next week. We also wanted to understand the problems of implementing IPP under the existing Windows/NT Print API that returns a 32-bit integer to the application. We didn't know whether the 32-bit integer was the address of a control block which existing for the life of the job (so that a job-uri could be added to the control block), or was a 32-bit integer that was contained in the control block. In the latter case, the control block could go way immediately after the job was created, so that the 32-bit integer was all that the application had to make future references to the job, to query it or cancel it. There is also the issue as to when the 32-bit job-identifier is generated: before contacting the Printer or after. Would a more robust notification mechanism from the IPP Printer when the job completes help with removing stale job-identifier to job-uri map entries from the client, if the IPP Printer returned a job-uri, instead of a 32-bit job-identifier? ACTION ITEM (Paul Moore): Please explain the problems again. 5. Registering MIME-types for document formats We agreed that it would be better for the PWG to register most of the Printer Interpreter Language Family (IANA printer language) enums with IANA as MIME-types. We also agreed that those Printer enums that already have registered MIME-types: 'application/postscript', 'application/pdf', and vnd.hp-PCL should use those MIME-types. ISSUE: Should the PWG register the rest as 'application/xxx' because IPP is on standards track or should the PWG register the rest as 'vnd.vv-xx'? 'application/xxx' requires a document specifying the semantics of each MIME-type. ACTION ITEM (Steve Zilles): Ask our Area Directors which they recommend before the IPP meeting next week. ACTION ITEM (Tom Hastings): Prepare a strawman mapping from Printer enums to MIME-types for discussion at the meeting next week. 6. Security sub-group A phone conference call is scheduled for Thursday, 9/11/97, 1:00 PDT. 7. Prototyping and Testing sub-group The group is looking for a solution for security for Internet testing. One proposal is to have private agreements between clients and Printers on the times to run tests, until security has been resolved. 8. Requirements document ACTION ITEM (Don Wright): Don will try to find time to update the Requirements document by the end of September to agree with the Model document.   Received: from cnri by ietf.org id aa27572; 10 Sep 97 22: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 WAA22648 for ; Wed, 10 Sep 1997 22:57:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09662 for ; Wed, 10 Sep 1997 22:53:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 22:48:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09396 for jmp-outgoing; Wed, 10 Sep 1997 22:45:34 -0400 (EDT) Message-Id: <9709110245.AA22765@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, 10 Sep 1997 19:42:48 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - "job-state-reason" clarifications, additions and movements Sender: jmp-owner@pwg.org I'd like to put this job-state-reasons clarification, additions, and movements on the IPP agenda next week, so that we can keep IPP and JMP in synch. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 09:57:52 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: IPP> Clarifications, additions and movements of some > job-state-reasons >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org > >Subj: Clarifications, additions and movements of some job-state-reasons >From: Tom Hastings and Harry Lewis >Date: 9/10/97 >File: reasons.doc > >On the JMP DL, Harry has made the following proposals for movement >of some job state reasons to jmJobStateReason1 object and clarifications. >Some of these may want to be added to IPP (but IPP can remain a subset >of JMP, since JMP is attempting to cover other job submission protocols >as well as IPP). > >1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that >the server has timed out the job and closed it. >Should be added to IPP as well. > >2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the >service has been disabled, so that all pending jobs are not going to >be processed. > >3. Distinguish between canceling by (authenicate) operator and canceled >at local (unauthenticated) op panel, by adding 'canceled-at-device'. > >4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the >semantics. > >5. Clarify 'canceled-by-operator' to mean authenticated as a privileged >user in some way. > >6. Add 'canceled-by-non-owner' for those systems that have more >comprehensive security mechanisms, such as group privileges in POSIX. > > >If we add these to JMP, Harry has indicated that we could put them >in their logical place in the order of likely occurrence, but only >we need to agree quickly. If we can't agree quickly, then we should >put them at the end of the bit assignments in JMP. (Fortunately, in >IPP, we use keywords, instead of bits, so there is no problem with ordering). > >I've indicated the new bit assignements below for the JMP spec. > > >The proposed specs for each of these job state reasons becomes: > >For JMP: > >submissionInterrupted 0x8 >Indicates that the job was not completely submitted for some unforeseen >reason, such as: (1) the server has crashed before the job was closed by the >client, (2) the server or the document transfer method has crashed in some >non-recoverable way before the document data was entirely transferred to the >server, (3) the client crashed or failed to close the job before the >time-out period. > > >jobCanceledByOwner 0x1000 >The job was canceled by the owner of the job, i.e., by a user >whose name is the same as the value of the job's jmJobOwner object. > > >jobCanceledByOperator 0x2000 >The job was canceled by the operator, i.e., by a user whose has been >authenticated as having operator privileges (whether local or remote). > > >jobCanceledAtDevice 0x4000 >The job was canceled by an unidentified local user, i.e., a user >at a walkup console or operator's panel. > > >jobCanceledByNonOwner 0x8000 >The job was canceled by an authenticated user that is not the owner of the >job. This reason may be used in systems that have the concept of group or >other security mechanisms that allow jobs to be canceled by users other than >the job owner but that are not operators. > > >serviceOffLine 0x40000 >The service or document transform is off-line and accepting no jobs. >All pending jobs are put into the pendingHeld state. This situation >could be true if the service's or document transform's input is impaired >or broken. > > > >NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use >the 3 other 32-bit job state reasons attributes. > > > >IPP: > >For IPP, the names change to all lower case with hyphens to follow keyword >syntax. > >'submission-interrupted': The job was not completely submitted for some >unforeseen reason, such as: (1) the Printer has crashed before the job was >closed by the client, (2) the Printer or the document transfer method has >crashed in some non-recoverable way before the document data was entirely >transferred to the Printer, (3) the client crashed or failed to close the >job before the time-out period. > >'job-canceled-by-owner': The job was canceled by the owner of the job, >i.e., by a user whose name is the same as the value of the job's >"job-originating-user" attribute. > >'job-canceled-by-operator': The job was canceled by the operator >using the CancelJob request, i.e., by a user who has been granted >special privileges. > >'job-canceled-at-device': The job was canceled by an unidentified local >user, i.e., i.e., a user at a walkup console or operator's panel. > >'serviceoff-line': The Printer is off-line and accepting no jobs. All >pending jobs are put into the 'pending-held' state. This situation >could be true if the Printer's input is impaired or broken. > >Comments? > >Tom > > >   Received: from cnri by ietf.org id aa27641; 10 Sep 97 22: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 XAA22654 for ; Wed, 10 Sep 1997 23:00:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09812 for ; Wed, 10 Sep 1997 22:57:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 22:52:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09445 for jmp-outgoing; Wed, 10 Sep 1997 22:48:11 -0400 (EDT) Message-Id: <9709110248.AA22768@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, 10 Sep 1997 19:45:22 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD - ISSUE: 'canceled' and 'aborted' job state semantics Sender: jmp-owner@pwg.org I'd like to put this ISSUE of the 'canceled' and 'aborted' job state semantics on the IPP agenda for next week, 9/17, so that we can keep IPP and JMP in synch for job states. Please send any comments ahead of time as well. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 08:47:43 PDT >To: ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics >Sender: ipp-owner@pwg.org > >There has been a good discussion in both the IPP and JMP DL about >the semantics of the 'canceled' state: whether the job moves to >'canceled' state immediately upon acceptance of the Cancel-Job operation >or whether the job moves to the 'canceled' state when the canceling has >completed and the job is quiescent (all the job accounting counters have >stopped counting, and all the media sheets are stacked). > >Usually the time difference is just a few seconds after the Cancel-Job >operation has been accepted, but in some implementations the time could be >considerably longer than a few seconds, including fixing a paper jam or >paper out. > >The same discussion also applies to when the system aborts a job. >Does the job move to the 'aborted' state immediately, or when the >system finishes aborting the job? > >The 'completed' state is specified as being reached when all of the >processing, including "media sheets successfully stacked", so that the >'completed' state is reached after the job is quiescent. > >It is hoped that we could discuss this issue at the IPP telecon today >and continue and resolve it at the IPP meeting next week in Atlanta >(with JMP participation). We need to keep both specs in synch. > > > >The issue is whether to continue the current IPP and JMP semantics: > > >A. Leading Edge Job State Transition: > >1. The job changes immediately to the 'canceled' or 'aborted' states >from the 'processing' state with the 'processing-to-stop-point' >and 'canceled-by-xxx' reasons set. > >2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' >job state reason is removed (but the job state doesn't change since >the job is alread in the 'canceled' or 'aborted'). > > >OR change the IPP and JMP semantics to: > > >B. Trailing Edge Job State Transition: > >1. The job remains in 'processing' with 'processing-to-stop-point' >and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > >2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' >is removed AND the job transitions to the 'canceled' or 'aborted' state >with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > >(Actually, the 'aborted-by-system' is redundant with the 'aborted' state, >but if there every is another reason to abort a job, it may be good >to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' >is also useful in the pending-held state for systems that chose to >allow a user or operator to release a job that has had a problem, >perhaps after modifying the job or the environment). > > > > >PROs and CONs: > > >1. The 'canceled' and 'aborted' states become quiescent states, like >the 'completed' state already is. > >The advantage of Trailing Edge Job State Transition is that the three >terminal states: 'completed', 'canceled', and 'aborted' would be >all quiescent state. > >With the Leading Edge Job State Transition semantics, 'completed' is >quiescent, and 'canceled' and 'aborted' are not. > > >2. Easier rejection of operations: just use the job state, not the reasons > >The advantage of the Leading Edge Job State Transition is that it >is clearer when operations are illegal: only the job states are involved. >This is the classis job state transition diagram showing operations >and job state transitions. > >So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error >that the job is in an inappropriate state whenever the job state >is 'completed', 'canceled', or 'aborted'. > >With the Trailing Edge Job State Transition, the user and the Printer >have to look at both the job state and the job-state-reasons in order >to reject multiple Cancel-Job operations and the job state transition >diagram is more complicated. > > >3. Better notification/trapping when job is quiescent > >The advantage of Trailing Edge Job State Transitions is that an application >program, such as an accounting program, that gets a notification or trap >on job state transitions, will get the notification or trap on entering >the 'completed', 'canceled', or 'aborted' state AFTER all the processing >has completed and all the counts have finished counting, so that polling >can be avoided for any additional processing to stop point activity. > >Also the job state reflects the completion of an operation, not just the >acceptance of the operation for those operations that are not performed >before the response is returned, such as Cancel-Job, when the job is >in the 'processing' state. > >NOTE: IPP has notification, but JMP does not have SNMP trapping, though >all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* > > >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. > >With such a compromise, there would be a job state transition when the >Cancel-job operation is accepted (leading edge transition from 'processing' >to 'terminating') and when the operation completes >(trailing edge transition from 'terminating' to 'completed', >'canceled', or 'aborted'). The Cancel-Job operation would be rejected >when the job was in the 'terminating' job state (as well as when in the >'completed', 'canceled', and 'aborted' job states). > > >Comments? > >Tom > > >   Received: from cnri by ietf.org id aa02809; 10 Sep 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 XAA22696 for ; Wed, 10 Sep 1997 23:28:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA10812 for ; Wed, 10 Sep 1997 23:24:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 23:10:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09352 for ipp-outgoing; Wed, 10 Sep 1997 22:39:22 -0400 (EDT) Message-Id: <9709110239.AA22759@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, 10 Sep 1997 19:36:52 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: How to determine the document-uri schemes supported? Sender: ipp-owner@pwg.org In the vein of "plugging holes": ISSUE: How can a client determine which uri schemes the Printer supports for use in the "document-uri" attribute in the Print-URI and Send-URI operations? How about adding a printer description attribute: document-uri-schemes-supported (1setOf uriScheme) This attribte specifies the URI schemes that the Printer supports for use in the "document-uri" attribute in the Print-URI and Send-URI operations. If the Printer does not support either of these operations, the "document-uri-schemes-supported" attribute SHALL not be supported.   Received: from cnri by ietf.org id aa03079; 10 Sep 97 23: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 XAA22714 for ; Wed, 10 Sep 1997 23:33:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11648 for ; Wed, 10 Sep 1997 23:30:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 23:18:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09385 for ipp-outgoing; Wed, 10 Sep 1997 22:41:55 -0400 (EDT) Message-Id: <9709110242.AA22762@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, 10 Sep 1997 19:39:21 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute Sender: ipp-owner@pwg.org We missed considering this old proposal at the telecon today. I hope that we could consider it at the IPP meeting next week in the vein of "plugging holes" (and because it was an old action item from 8/20). Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Tue, 9 Sep 1997 10:13:00 PDT >To: ipp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute >Sender: ipp-owner@pwg.org > >I'm resending the proposal that I made on 8/20 >which was my action item from the 8/20 IPP telecon. The action item was >to provide a Printer description attribute that lists the document-formats >that the printer can automatically detect/sense. In other words, to provide >a Printer description attribute that specifies which document-formats >that the Printer can detect when the document-format is either (1) >unspecified or (2) specified as 'application/octet-stream' or whatever we >specify in IPP (or the registry) is the equivalent of the 'langAutomatic' >Printer MIB enum. > >Harald suggested that we could use 'application/octet-stream' MIME-type to >indicate automatic document-format sensing or we might want to register >a MIME-type expoicitly for that purpose. So one of the justfications for this >new attribute: that we couldn't have a MIME-type for automatic sensing goes >away. However, I still believe that we still need the attribute so that >the client and end-users can determine which document-formats are automatically >sensed and which ones require that the end-user or client specify >the document-format as an IPP input attribute. > >Here is the proposal again. As before I've included several different >attribute names and values for us to pick from, depending on what gets the >idea across the most clearly. > >(Also I removed the first justification for the attribute). > >I hope we could discuss it at the Wed 8/10 telecon. > >Thanks, >Tom > >>Return-Path: >>X-Sender: hastings@zazen >>Date: Wed, 20 Aug 1997 15:09:18 PDT >>To: ipp@pwg.org >>From: Tom Hastings >>Subject: IPP> MOD - document-format-supported using MIME types and >> 'automatic' >>Cc: jmp@pwg.org, pmp@pwg.org >>Sender: ipp-owner@pwg.org >> >>We had an IPP telecon today and discussed the issue of changing IPP from >>using Printer MIB enums for document-format to using MIME-types. >> >>Attending: Steve Zilles, Ira McDonald, Lee Farrell, Roger deBry, Tom Hastings >> >>I took the action item to write up the discussion on this point. >> >snip.. > >>From the Printer MIB enum description: >>langAutomatic(37), >> -- Automatic PDL sensing. Automatic >> -- sensing of the interpreter >> -- language family by the printer >> -- examining the document content. >> -- Which actual interpreter language >> -- families are sensed depends on >> -- the printer implementation. >> >> >>The solution that we came up with today [8/20] for IPP is to add a >>Printer description attribute called: "document-formats-detected" (or >>"document-formats-auto-sensed"?). This new IPP attribute solves the problem: >> >>Make it clear to the client which of the document-formats-supported >>can be auto-sensed. Some implementations support more document-formats >>than can be automatically sensed. For example, some implementation support >>PostScript, PJL, and some document format that cannot be reliabilbly sensed. >> >>The "document-formats-detected" Printer attribute would be multi-valued >>that parallels the "document-formats-supporter Printer attribute and >>has a value for each of the values of the "document-formats-supported" >>Printer attribute. Each value would be a keyword that indicates whether the >>corresponding document format is auto-sensed or not. Perhaps, we can even >>have more than two keyword values depending on the degree or reliability >>that the PDL can be sensed. The keyword values might be: >> >> 'auto-detected' >> 'auto-detected-best-effort' >> 'not-auto-detected' >> >>or using the Printer MIB terminology of 'sense', instead of 'detect': >> >> 'auto-sensed' >> 'auto-sensed-best-effort' >> 'not-auto-sensed' >> >>Alternatively, the same values could indicate whether the >>client needs to supply the "document-format" attribute when submitting >>each document or not, so that the following keyword values might be better >>names for the corresponding semantics: >> >> 'document-format-not-required' >> 'document-format-recommended' >> 'document-format-required' >> >For example, the MIME-type for simpleText (whatever that is) would >be indicated with the value: 'document-format-required'. Then it would be >to the clear to the client/end-user that the client must explicitly supply >the IPP attribute: > > "document-format"='application/simpleText' > >to force simple text, such as a PostScript programmer dumping a PostScript >program as simple text, in order to prevent the Printer from autosensing >the file and interpreting it as PostScript. > >snip... > >>Comments? >> >>Tom > > >   Received: from cnri by ietf.org id aa03283; 10 Sep 97 23: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 XAA22724 for ; Wed, 10 Sep 1997 23:37:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA12127 for ; Wed, 10 Sep 1997 23:34:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 23:24:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09404 for ipp-outgoing; Wed, 10 Sep 1997 22:45:52 -0400 (EDT) Message-Id: <9709110245.AA22765@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, 10 Sep 1997 19:42:48 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> MOD - "job-state-reason" clarifications, additions and movements Sender: ipp-owner@pwg.org I'd like to put this job-state-reasons clarification, additions, and movements on the IPP agenda next week, so that we can keep IPP and JMP in synch. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 09:57:52 PDT >To: jmp@pwg.org >From: Tom Hastings >Subject: IPP> Clarifications, additions and movements of some > job-state-reasons >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org > >Subj: Clarifications, additions and movements of some job-state-reasons >From: Tom Hastings and Harry Lewis >Date: 9/10/97 >File: reasons.doc > >On the JMP DL, Harry has made the following proposals for movement >of some job state reasons to jmJobStateReason1 object and clarifications. >Some of these may want to be added to IPP (but IPP can remain a subset >of JMP, since JMP is attempting to cover other job submission protocols >as well as IPP). > >1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that >the server has timed out the job and closed it. >Should be added to IPP as well. > >2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the >service has been disabled, so that all pending jobs are not going to >be processed. > >3. Distinguish between canceling by (authenicate) operator and canceled >at local (unauthenticated) op panel, by adding 'canceled-at-device'. > >4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the >semantics. > >5. Clarify 'canceled-by-operator' to mean authenticated as a privileged >user in some way. > >6. Add 'canceled-by-non-owner' for those systems that have more >comprehensive security mechanisms, such as group privileges in POSIX. > > >If we add these to JMP, Harry has indicated that we could put them >in their logical place in the order of likely occurrence, but only >we need to agree quickly. If we can't agree quickly, then we should >put them at the end of the bit assignments in JMP. (Fortunately, in >IPP, we use keywords, instead of bits, so there is no problem with ordering). > >I've indicated the new bit assignements below for the JMP spec. > > >The proposed specs for each of these job state reasons becomes: > >For JMP: > >submissionInterrupted 0x8 >Indicates that the job was not completely submitted for some unforeseen >reason, such as: (1) the server has crashed before the job was closed by the >client, (2) the server or the document transfer method has crashed in some >non-recoverable way before the document data was entirely transferred to the >server, (3) the client crashed or failed to close the job before the >time-out period. > > >jobCanceledByOwner 0x1000 >The job was canceled by the owner of the job, i.e., by a user >whose name is the same as the value of the job's jmJobOwner object. > > >jobCanceledByOperator 0x2000 >The job was canceled by the operator, i.e., by a user whose has been >authenticated as having operator privileges (whether local or remote). > > >jobCanceledAtDevice 0x4000 >The job was canceled by an unidentified local user, i.e., a user >at a walkup console or operator's panel. > > >jobCanceledByNonOwner 0x8000 >The job was canceled by an authenticated user that is not the owner of the >job. This reason may be used in systems that have the concept of group or >other security mechanisms that allow jobs to be canceled by users other than >the job owner but that are not operators. > > >serviceOffLine 0x40000 >The service or document transform is off-line and accepting no jobs. >All pending jobs are put into the pendingHeld state. This situation >could be true if the service's or document transform's input is impaired >or broken. > > > >NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use >the 3 other 32-bit job state reasons attributes. > > > >IPP: > >For IPP, the names change to all lower case with hyphens to follow keyword >syntax. > >'submission-interrupted': The job was not completely submitted for some >unforeseen reason, such as: (1) the Printer has crashed before the job was >closed by the client, (2) the Printer or the document transfer method has >crashed in some non-recoverable way before the document data was entirely >transferred to the Printer, (3) the client crashed or failed to close the >job before the time-out period. > >'job-canceled-by-owner': The job was canceled by the owner of the job, >i.e., by a user whose name is the same as the value of the job's >"job-originating-user" attribute. > >'job-canceled-by-operator': The job was canceled by the operator >using the CancelJob request, i.e., by a user who has been granted >special privileges. > >'job-canceled-at-device': The job was canceled by an unidentified local >user, i.e., i.e., a user at a walkup console or operator's panel. > >'serviceoff-line': The Printer is off-line and accepting no jobs. All >pending jobs are put into the 'pending-held' state. This situation >could be true if the Printer's input is impaired or broken. > >Comments? > >Tom > > >   Received: from cnri by ietf.org id aa03321; 10 Sep 97 23: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 XAA22730 for ; Wed, 10 Sep 1997 23:38:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA12272 for ; Wed, 10 Sep 1997 23:35:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 23:25:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09457 for ipp-outgoing; Wed, 10 Sep 1997 22:48:34 -0400 (EDT) Message-Id: <9709110248.AA22768@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, 10 Sep 1997 19:45:22 PDT To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: 'canceled' and 'aborted' job state semantics Sender: ipp-owner@pwg.org I'd like to put this ISSUE of the 'canceled' and 'aborted' job state semantics on the IPP agenda for next week, 9/17, so that we can keep IPP and JMP in synch for job states. Please send any comments ahead of time as well. Thanks, Tom >Return-Path: >X-Sender: hastings@zazen >Date: Wed, 10 Sep 1997 08:47:43 PDT >To: ipp@pwg.org, jmp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics >Sender: ipp-owner@pwg.org > >There has been a good discussion in both the IPP and JMP DL about >the semantics of the 'canceled' state: whether the job moves to >'canceled' state immediately upon acceptance of the Cancel-Job operation >or whether the job moves to the 'canceled' state when the canceling has >completed and the job is quiescent (all the job accounting counters have >stopped counting, and all the media sheets are stacked). > >Usually the time difference is just a few seconds after the Cancel-Job >operation has been accepted, but in some implementations the time could be >considerably longer than a few seconds, including fixing a paper jam or >paper out. > >The same discussion also applies to when the system aborts a job. >Does the job move to the 'aborted' state immediately, or when the >system finishes aborting the job? > >The 'completed' state is specified as being reached when all of the >processing, including "media sheets successfully stacked", so that the >'completed' state is reached after the job is quiescent. > >It is hoped that we could discuss this issue at the IPP telecon today >and continue and resolve it at the IPP meeting next week in Atlanta >(with JMP participation). We need to keep both specs in synch. > > > >The issue is whether to continue the current IPP and JMP semantics: > > >A. Leading Edge Job State Transition: > >1. The job changes immediately to the 'canceled' or 'aborted' states >from the 'processing' state with the 'processing-to-stop-point' >and 'canceled-by-xxx' reasons set. > >2. WHEN the canceling or aborting is complete the 'processing-to-stop-point' >job state reason is removed (but the job state doesn't change since >the job is alread in the 'canceled' or 'aborted'). > > >OR change the IPP and JMP semantics to: > > >B. Trailing Edge Job State Transition: > >1. The job remains in 'processing' with 'processing-to-stop-point' >and 'canceled-by-xxx' OR 'aborted-by-system' reasons set. > >2. WHEN the canceling or aborting is completed the 'processing-to-stop-point' >is removed AND the job transitions to the 'canceled' or 'aborted' state >with either 'canceled-by-xxx' or 'aborted-by-system' remaining. > >(Actually, the 'aborted-by-system' is redundant with the 'aborted' state, >but if there every is another reason to abort a job, it may be good >to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system' >is also useful in the pending-held state for systems that chose to >allow a user or operator to release a job that has had a problem, >perhaps after modifying the job or the environment). > > > > >PROs and CONs: > > >1. The 'canceled' and 'aborted' states become quiescent states, like >the 'completed' state already is. > >The advantage of Trailing Edge Job State Transition is that the three >terminal states: 'completed', 'canceled', and 'aborted' would be >all quiescent state. > >With the Leading Edge Job State Transition semantics, 'completed' is >quiescent, and 'canceled' and 'aborted' are not. > > >2. Easier rejection of operations: just use the job state, not the reasons > >The advantage of the Leading Edge Job State Transition is that it >is clearer when operations are illegal: only the job states are involved. >This is the classis job state transition diagram showing operations >and job state transitions. > >So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error >that the job is in an inappropriate state whenever the job state >is 'completed', 'canceled', or 'aborted'. > >With the Trailing Edge Job State Transition, the user and the Printer >have to look at both the job state and the job-state-reasons in order >to reject multiple Cancel-Job operations and the job state transition >diagram is more complicated. > > >3. Better notification/trapping when job is quiescent > >The advantage of Trailing Edge Job State Transitions is that an application >program, such as an accounting program, that gets a notification or trap >on job state transitions, will get the notification or trap on entering >the 'completed', 'canceled', or 'aborted' state AFTER all the processing >has completed and all the counts have finished counting, so that polling >can be avoided for any additional processing to stop point activity. > >Also the job state reflects the completion of an operation, not just the >acceptance of the operation for those operations that are not performed >before the response is returned, such as Cancel-Job, when the job is >in the 'processing' state. > >NOTE: IPP has notification, but JMP does not have SNMP trapping, though >all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?) > > > >E-MAIL conclusion: > >The e-mail discussion seems to favor changing the IPP and JMP semantics >to "Trailing Edge Job State Transition" semantics, since many protocols >use states to mean that the operation has finished all of its work. >Also reducing polling seems to be more important than simplfying the Printer >implementation and the job state transition diagram when legal operations >are shown. > >******************************************************************* >We need to see if the rest of the IPP and JMP participants agree >to change the spec to Traling Edge Job State Transition semantics. >******************************************************************* > > >Probably neither side would be happy with a compromise that complicates >the state model by adding a new Job state: 'terminating' (the name >used for the ISO DPA job state). Then the 'processing-to-stop-point' reason >would not be needed for this. > >With such a compromise, there would be a job state transition when the >Cancel-job operation is accepted (leading edge transition from 'processing' >to 'terminating') and when the operation completes >(trailing edge transition from 'terminating' to 'completed', >'canceled', or 'aborted'). The Cancel-Job operation would be rejected >when the job was in the 'terminating' job state (as well as when in the >'completed', 'canceled', and 'aborted' job states). > > >Comments? > >Tom > > >   Received: from cnri by ietf.org id aa05363; 11 Sep 97 1: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 BAA22837 for ; Thu, 11 Sep 1997 01:26:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA13328 for ; Thu, 11 Sep 1997 01:23:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Sep 1997 01:19:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA12711 for ipp-outgoing; Thu, 11 Sep 1997 01:09:50 -0400 (EDT) Message-ID: <34177CDD.EE9BAB6F@parc.xerox.com> Date: Wed, 10 Sep 1997 22:08:45 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> compression of IPP messages X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > Compression of IPP messages > > This issue is OPEN. The WG is looking at other standards and > existing enumerations for compression algorithms. HTTP supports accept-encoding as a way that clients can tell servers about encodings (including compression) that they will accept. There is currently no 'accept-encoding' for HTTP servers to tell clients about acceptable encodings for PUT or POSTed data. However, the space of HTTP encodings should be the ones useful also for IPP encoded documents. Available encodings include zip, compress, and deflate, with deflate recommended.   Received: from cnri by ietf.org id aa07213; 11 Sep 97 9: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 JAA23668 for ; Thu, 11 Sep 1997 09:40:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA14285 for ; Thu, 11 Sep 1997 09:36:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Sep 1997 09:28:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA13769 for ipp-outgoing; Thu, 11 Sep 1997 09:19:58 -0400 (EDT) Message-Id: <3417F0C3.5EA40F8A@dazel.com> Date: Thu, 11 Sep 1997 08:23:15 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.02 [en] (WinNT; U) Mime-Version: 1.0 To: Robert Herriot Cc: ipp@pwg.org Subject: Re: IPP>MOD new attributes, such as orientation References: <199709102303.QAA28041@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > > ... > > When Roger described the reason for wanting this attribute, it was to > control 2-up so that the orientation would be right. Portrait page > images rotate 90 degrees counterclockwise and landscape page-images > rotate 90 degress clockwise. There is no issue for 1-up or 4-up because > they don't rotate. So, if this is the problem he is solving, he should > instead ask for an additional value called 2-up-landscape or > 2-up-counter-rotate, whatever is his choice. If we are going to be pedantic, then I would suggest that we remove the attribute altogether. I would rather have implementations add their own (incompatible) extensions, and have those extensions implement this properly, than have the kludge suggested above. I mean, we already have existing practive to show that the a content-orientation attribute is very useful as a hint to a number-up algorithm to determine both page rotation and placement. I would hate to see us ignore that experience. And Bob, the orientation is useful for *all* number-up > 1. If you go back and think about number-up 4, one would place the logical pages on the physical page in a different order based upon the orientation hint. think about it... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX   Received: from cnri by ietf.org id aa09447; 11 Sep 97 10: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 KAA23905 for ; Thu, 11 Sep 1997 10:41:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA14931 for ; Thu, 11 Sep 1997 10:37:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Sep 1997 10:33:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14418 for ipp-outgoing; Thu, 11 Sep 1997 10:24: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-05.txt Date: Thu, 11 Sep 1997 10:11:19 -0400 Message-ID: <9709111011.aa08141@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) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-05.txt Pages : 101 Date : 10-Sep-97 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 wih 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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19970910164011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970910164011.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa12107; 11 Sep 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 MAA24430 for ; Thu, 11 Sep 1997 12:46:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15891 for ; Thu, 11 Sep 1997 12:43:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Sep 1997 12:39:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15314 for ipp-outgoing; Thu, 11 Sep 1997 12:29:53 -0400 (EDT) Message-ID: <34181BAD.FBF7D53B@underscore.com> Date: Thu, 11 Sep 1997 12:26:21 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> MOD - ISSUE: How to determine the document-uri schemes supported? References: <9709110239.AA22759@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Considering we have just declared a "Functionality Freeze", is this something we really need to do? Can you cite some examples/scenarios in which *not* having this new attribute would make life very difficult (or impossible) to implement? ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > In the vein of "plugging holes": > > ISSUE: How can a client determine which uri schemes the Printer supports > for use in the "document-uri" attribute in the Print-URI and Send-URI > operations? > > How about adding a printer description attribute: > > document-uri-schemes-supported (1setOf uriScheme) > > This attribte specifies the URI schemes that the Printer supports for use in > the "document-uri" attribute in the Print-URI and Send-URI operations. > If the Printer does not support either of these operations, the > "document-uri-schemes-supported" attribute SHALL not be supported.   Received: from cnri by ietf.org id aa13138; 11 Sep 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 NAA24700 for ; Thu, 11 Sep 1997 13:50:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA16575 for ; Thu, 11 Sep 1997 13:47:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Sep 1997 13:43:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16059 for ipp-outgoing; Thu, 11 Sep 1997 13:34:54 -0400 (EDT) Message-Id: <3.0.1.32.19970911102052.00bce980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 11 Sep 1997 10:20:52 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - PWG Phone Conference September 11 NEW TIME Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org It turned out that one of the main participants Roger deBry could not make the time originally planned. The conference has been moved to start at 2:30 instead! -------- We will hold a short phone conference at 2:30 - 4:00 PST The main subject for discussion is how to meet the IETF requirements for security in IPP without dragging out the process. There are two possible approaches: 1) Dodge the issue, by requiring a very limited set of manadatory security features, basically limited to RFC 2068 and RFC 2069, with the risk of being shot down during the IESG review. 2) Working with the IETF security groups to help find a solution that they would accept. The number to dial is: 1-800-857 5607 passcode: cmanros ----- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa06285; 12 Sep 97 9: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 JAA28048 for ; Fri, 12 Sep 1997 09:40:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA19107 for ; Fri, 12 Sep 1997 09:36:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 09:31:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA18586 for ipp-outgoing; Fri, 12 Sep 1997 09:22:34 -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> 1998 Meeting Plan Message-ID: <5030100008215613000002L032*@MHS> Date: Fri, 12 Sep 1997 09:22:53 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Don, I'll review with my management to see if they will support Hawaii. I also have a personal aversion to cities like Baltimore. I'd prefer smaller, safer places. Would you consider substituting Madison WI for Minneapolis? Roger K deBry Senior Technical 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 09/12/97 07:15 AM --------------------------- IINUS1.SMTP3 @ D03AU017 09/12/97 06:20 AM Please respond to IINUS1.SMTP3 @ VM To: Roger K Debry/Boulder/IBM cc: Subject: PWG> 1998 Meeting Plan Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Fri, 12 Sep 97 08:19:19 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA18234; Fri, 12 Sep 1997 08:19:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 08:17:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA18106 for pwg-outgoing; Fri, 12 Sep 1997 08:16:10 -0400 (EDT) From: don@lexmark.com Message-Id: <199709121215.AA02930@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org Date: Fri, 12 Sep 1997 08:15:54 -0400 Subject: PWG> 1998 Meeting Plan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Well, since a few months ago when I published this proposal for the 1998 meeting schedule, I have heard no significant concerns raised. In that case, we will approve this schedule with votes on Monday (9/15) and Wednesday (9/17) mornings. Going, going, almost gone.... Jan 19-23 Hawaii (W3C Jan 14-15: SFO) Feb Mar 2-6 San Antonio (IETF Mar 30-Apr 1: LA) April 6-10 Portland, OR May 18-22 Baltimore June (W3C Jun 24-25: Geneva) July 6-10 San Francisco Aug 17-21 Minneapolis (IETF Aug 24-28: Chicago) Sep28-Oct2 Charleston, SC Oct Nov 9-13 Phoenix Dec 14-18 San Diego (IETF Dec 7-11: unknown) 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 aa11039; 12 Sep 97 13: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 NAA28978 for ; Fri, 12 Sep 1997 13:26:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19942 for ; Fri, 12 Sep 1997 13:23:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 13:18:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19420 for ipp-outgoing; Fri, 12 Sep 1997 13:09:13 -0400 (EDT) From: Roger K Debry To: masinter@parc.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: Re: IPP>MOD - job-sheet-content attribute Message-ID: <5030100008231969000002L092*@MHS> Date: Fri, 12 Sep 1997 13:09:26 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org so ..... are you suggesting a new IPP attribute called "form"? >One simple encoding of a form is a set of attribute names along >with their value types, but of course, HTML can encode forms >too, as can PDF, etc. Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa11592; 12 Sep 97 13: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 NAA29161 for ; Fri, 12 Sep 1997 13:48:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20524 for ; Fri, 12 Sep 1997 13:45:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 13:42:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20032 for ipp-outgoing; Fri, 12 Sep 1997 13:33:21 -0400 (EDT) Message-Id: <3.0.1.32.19970912102104.00b78e90@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 12 Sep 1997 10:21:04 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Meeting Minutes and Presentations from Munich Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, I have now stored the Munich files on the FTP server at: - IPP WG Minutes - IETF39 in Munich: Link: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/IETF39-IPP-WG-Meeting.txt - Presentation on Model - IETF39 in Munich: Link: ftp://ftp.pwg.org/pub/pwg/ipp/IETF-Presentations/IETF39-Model.pdf - Presentation on Protocol - IETF39 in Munich: Link: ftp://ftp.pwg.org/pub/pwg/ipp/IETF-Presentations/IETF39-Protocol.pdf 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 aa12629; 12 Sep 97 14: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 OAA29288 for ; Fri, 12 Sep 1997 14:09:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21162 for ; Fri, 12 Sep 1997 14:06:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 14:01:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20643 for ipp-outgoing; Fri, 12 Sep 1997 13:52:06 -0400 (EDT) Message-Id: <9709121752.AA23310@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 10:49:09 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Please review Appendix E: Processing IPP Attributes Sender: ipp-owner@pwg.org Scott did a great job of taking the description of processing IPP attributes that some of us started at the Redmond meeting over lunch and expanding it as Appendix E in the Model document. People should review it and it should be on the agenda for the meeting. Here it is in plain text. Tom 15. APPENDIX E: Processing IPP Attributes When submitting a print job to an IPP Printer, the IPP model allows a client to supply operation and Job Template attributes along with the print data. These Job Template attributes in the create request affect the rendering, production and finishing of the documents in the job. Similar types of instructions may also be contained in the document to be printed, that is, embedded within the print data itself. In addition, the Printer has a set of attributes that describe what rendering and finishing options which are supported by that Printer. This model, which allows for flexibility and power, also introduces the potential that at job submission time, these client-supplied attributes may conflict with either: - what the implementation is capable of realizing (i.e., what the Printer supports), as well as - the instructions embedded within the print data itself. The following sections describe how these two types of conflicts are handled in the IPP model. 15.1 Fidelity If there is a conflict between what the client requests and what a Printer supports, the client may request one of two possible conflict handling mechanisms: 1) either reject the job since the job can not be processed exactly as specified, or 2) allow the Printer to make any changes necessary to proceed with processing the Job the best it can. In the first case the client is indicating to the Printer: "Print the job exactly as specified with no exceptions, and if that can't be done, don't even bother printing the job at all." In the second case, the client is indicating to the Printer: "It is more important to make sure the job is printed rather than be processed exactly as specified; just make sure the job is printed even if client supplied attributes need to be changed or ignored." The IPP model accounts for this situation by introducing an "ipp-attribute-fidelity" attribute. In a create request, "ipp-attribute-fidelity" is a boolean attribute that is OPTIONALLY supplied by the client. The value 'true' indicates that total fidelity to client supplied attributes and values is required. The client is requesting that the Job be printed exactly as specified, and if that is not possible then the job must be rejected rather than processed incorrectly. The value 'false' indicates that a reasonable attempt to print the Job is acceptable. If a Printer does not support some of the client supplied Job Template attributes or values, the Printer may ignore them or substitute any supported value for unsupported values. The Printer may choose to substitute the default value associated with that attribute, or use some other supported value that is similar to the unsupported requested value. For example, if a client supplies a "media" value of 'na-letter', the Printer may choose to substitute 'iso-a4' rather than a default value of 'envelope'. Since this is an OPTIONAL attribute, if the client does not supply a value, the Printer assumes a value of 'false'. Each Printer implementation MUST support both types of "fidelty" printing (that is whether the client supplies a value of 'true' or 'false'). This is possible across all types of implementations, since there is a broad range of acceptable actions when substituting or ignoring unsupported attributes and values. Also, even if the client supplies a value of 'false', a Printer might still reject the Job for any reason including an unsupported attributes and/or values. In the other case, where the client requests a value of 'true', it is expected that the Printer support this type of printing since the Printer is already indicating functional support corresponding to all advertised supported attributes and values. Since a client can always query a Printer to find out exactly what is and is not supported, "ipp-attribute-fidelity" set to 'false' is useful when: 1) The End-User uses a command line interface to request attributes that might not be supported. 2) In a GUI context, if the End User expects the job might be moved to another printer and prefers a sub-optimal result to nothing at all. 3) The End User just wants something reasonable in lieu of nothing at all. 15.2 Page Description Language (PDL) Override If there is a conflict between the value of an IPP Job Template attribute and a corresponding instruction in the print data, it is desirable that the value of the IPP attribute take precedence over the document instruction. Consider the case where a previously formatted file of print data is sent to an IPP Printer. In this case, if the client supplies any attributes at job submission time, the client desires that those attributes override the embedded instructions. Consider the case were a previously formatted document has embedded in it commands to load 'iso-a4' media. However, the document is passed to an end user that only has access to a printer with 'na-letter' media loaded. That end user most likely wants to submit that document to an that IPP Printer with the "media" Job Template attribute set to 'na-letter'. The job submission attribute should take precedence over the embedded PDL instruction. However, until companies that supply interpreters for print data allow a way for external IPP attributes to take precedence over embedded job production instructions, a Printer might not be able to support the semantics that IPP attributes override the embedded instructions. The IPP model accounts for this situation by introducing a "pdl-override-supported" attribute. This attribute takes on the following values: - 'attempted': This value indicates that the Printer attempts to make sure that IPP attribute values take precedence over embedded instructions in the Print data, however there is no guarantee. - 'not-attempted': This value indicates that the Printer makes not attempt to ensure that IPP attribute values take precedence over embedded instructions in the print data. This is a MANDATORY Printer attribute. At job processing time, an implementation that supports the value of 'attempted' might try to do one of several different actions: 1) generate an output device specific command sequence to realize the feature represented by the IPP attribute value 2) parse the print data itself and replace the conflicting embedded instruction with a new embedded instruction that matches the intent of the IPP attribute value 3) indicate to the Printer that external supplied attributes take precedence over embedded instructions and then pass the external IPP attribute values to the print data interpreter 4) anything else that allows for the semantics that IPP attributes override embedded print data instructions. Since 'attempted' does not offer any type of guarantee, even though a given implementation might not do a very "good" job of attempting to ensure that IPP attributes take a higher precedence over instructions embedded in the print data, it would still be a conforming implementation. Note: The "ipp-attribute-fidelity" attribute applies to the Printer's ability to either accept or reject other unsupported attributes. In other words, if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if and only if the client supplied attributes and values are supported by the Printer. Whether these attributes actually affect the processing of the Job depends on the ability of the Printer to override the instructions embedded in the print data with the semantics of the IPP attributes. If the print data attributes can be overridden ("pdl-override-supported" set to 'attempted'), the Printer makes an attempt to use the IPP attributes when processing the Job. If the print data attributes can not be overridden ("pdl-override-supported" set to 'not-attempted'), the Printer makes no attempt to use the IPP attributes when processing the Job, and hence, the IPP attributes may fail to affect the Job processing and output in any manner whatsoever. 15.3 Suggested Attribute Processing Algorithm When a Printer receives a create request, the Printer either accepts or rejects the request. The Printer accepts the create request and creates a Job object if it is able to accept all Job Template and Document attributes in the request. The Printer rejects the request and does not create a Job object if the Printer rejects any Job Template or Document attribute in the request. In order to determine whether or not to accept or reject the request, the Printer SHOULD use the following algorithm: 1. The implementation checks to see if the operation is supported. If not, the Printer rejects the request and sets the appropriate status code in the response. 2. The implementation checks to see if the requested version is supported. If not, the Printer rejects the request and sets the appropriate status code in the response. 3. The implementation checks to see if the client supplied an "ipp-attribute-fidelity" attribute. If the attribute is missing (not supplied by the client), the Printer assumes that the value is 'false'. 4. The Printer loops through all other attributes, checking to see if the requested values are supported (e.g., the value of "foo" in the request is one of the values in the Printer's "foo-supported" attribute). If the attribute or its value is unsupported, the Printer flags it as unsupported. 5. Once all attributes have been checked individually, the Printer checks for any inconsistent values among all the supported values. For example a Printer might be able to staple and to print on transparencies, however due to physical stapling limitations, the Printer might not be able to staple transparencies. Any inconsistent values are flagged as unsupported. 6. Once all attributes have been checked and validated, if "ipp-attribute-fidelity" is set to true and there are any attributes flagged as unsupported, the Printer rejects the request and returns all unsupported attributes and values in the response and sets the appropriate status code. 7. If "ipp-attribute-fidelity" is set to 'false' (nor it was not supplied by the client) and there are any attributes that are flagged as unsupported, the Printer, chooses to either ignore the unsupported attributes or change the requested value to some supported value. If, for some reason, it is not possible for the implementation to ignore or substitute values and is unable to "just print the job", the Printer is still able to reject the request and return all unsupported attributes and values in the response. In doing so, the Printer sets the appropriate status code. 8. If the Printer is able to accept the request (either as is or by making changes and the "ipp-attribute-fidelity" attribute is set to 'false'), the Printer creates a new Job object with the remaining valid Job Template attributes. Initially it sets the Job's state to 'pending'. These Job Template attributes are associated with the Job object. All attributes which are associated with the Job object are intended to be override values that take precedence over whatever other embedded instructions might be in the print data itself. That is, IPP allows for submission time attributes to take precedence over static instructions embedded in the print data. These submission time attributes are persistently stored with the Job. However, it is not possible for all implementations to realize the semantics of "override". End users may query the Printer's "pdl-override" attribute to determine if the Printer either attempts or does not attempt to override print data instructions with IPP attributes. 9. There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object. The Printer's default values are used at Job processing time where no other IPP attribute or instruction embedded in the print data is present. Suppose the Printer were to associate the Printer's default value with the Job at creation time for an attribute not supplied by the client. This would change it from a default value to an override value. A later query of the Job object would return a set of attributes. Neither the Printer nor the end user would be able to tell the difference between an attribute that is an "override PDL" attribute supplied by the client or a "default value" attribute supplied by the printer. 10. If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined. 11. Once the Job object has been created, the Printer responds back to the client with a successful response including Job status attributes that indicate the initial state of the Job ('pending', 'processing', etc.). The Printer uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer begins processing the Job, the Printer changes the Job's state to 'processing'. The Printer monitors all Jobs and notifies the intended recipients for each event by processing the all of the "notify-events" and "notify-addresses" Job attributes. If the Printer supports PDL override (the "pdl-override" attribute set to 'attempted'), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the print data. 12. The implementation of the Printer object continues to process the Job until it can move the Job into the 'completed' state. If an Cancel-Job operation is received, the implementation eventually moves the Job into the 'cancelled' state. If the system encounters errors during processing that do not allow it to progress the Job into a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state. 13. Once the Job moves to the 'completed', 'aborted', or 'cancelled' state, it is an implementation decision as to when to destroy the Job object and release all associated resources. Once the Job has been destroyed, the Printer would return either the "not-found" or "gone" status codes for operations directed at that Job. Some Printer implementations may support "ipp-attribute-fidelity" set to 'true' and "pdl-override" set to 'attempted' and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the print data and external job instructions that accompany the print data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, "ipp-attribute-fidelity" and "pdl-override", apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for "number-up". It would only make the IPP model more complex (with relatively little added value) to allow for additional special attributes that apply uniquely to each Job Template attribute or even specific values of each attribute.   Received: from cnri by ietf.org id aa12914; 12 Sep 97 14: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 OAA29357 for ; Fri, 12 Sep 1997 14:21:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21786 for ; Fri, 12 Sep 1997 14:17:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 14:14:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20943 for ipp-outgoing; Fri, 12 Sep 1997 14:03:16 -0400 (EDT) Message-Id: <9709121803.AA23318@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 11:00:32 PDT To: Jay Martin From: Tom Hastings Subject: IPP> Re: MOD - ISSUE: How to determine the document-uri schemes supported? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 09:26 09/11/97 PDT, Jay Martin wrote: >Considering we have just declared a "Functionality Freeze", is this >something we really need to do? I think it is more of a "plugging a hole" than new fuctionality and its only a Printer description attribute. See below to see if you agree. > >Can you cite some examples/scenarios in which *not* having this >new attribute would make life very difficult (or impossible) to >implement? As I understand the spec and agreements, we've agreed that validation of a document-uri cannot be part of a Validate operation, since the Validate operation is identical to a Print-Job operation which cannot have a document-uri attribute. So there is no way for a client to know what scheme to try for a Print-URI or Send-URI scheme, except to try it, in the Print-URI or Send-URI operation. Then we have also been debating whether a Printer has to validate the document-uri or not on the Print-URI or Send-URI operation. We've agreed that the standard will NOT require the Printer to validate the URI. So the user may NOT even get an error back on the Print-URI or the Send-URI operation that the scheme is not supported (though maybe we should add such an error and at least recommend that a Printer at least validate that the URI scheme is supported, if it doesn't validate the entire URI.) Finally, I suspect that it will be an end-user, rather than a program, that will be supplying URIs in Print-URI and Send-URI operations. The end-user knows about document xxx and wants to submit it by reference to Printer yyy, so that the end-user should be able to find out which schemes are supported. We already have a notification-schemes-supported, so that "document-uri-schemes-supported" is very similar. On the other hand, those more familiar with HTTP servers can tell us whether most HTTP servers support most URI schemes that an end-user might need, such as HTTP:, FTP:, and HTTPS: Alternatively, we could recommend a list of URI schemes for a Printer to support. Or would that get out of date? And require a lot discussion and debate? So adding a "document-uri-schemes-supported" Printer attribute seemed an easy solution. The complete proposed spec is given below. Tom > > ...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 -- >---------------------------------------------------------------------- > > >Tom Hastings wrote: >> >> In the vein of "plugging holes": >> >> ISSUE: How can a client determine which uri schemes the Printer supports >> for use in the "document-uri" attribute in the Print-URI and Send-URI >> operations? >> >> How about adding a printer description attribute: >> >> document-uri-schemes-supported (1setOf uriScheme) >> >> This attribte specifies the URI schemes that the Printer supports for use in >> the "document-uri" attribute in the Print-URI and Send-URI operations. >> If the Printer does not support either of these operations, the >> "document-uri-schemes-supported" attribute SHALL not be supported. > >   Received: from cnri by ietf.org id aa13864; 12 Sep 97 14: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 OAA29492 for ; Fri, 12 Sep 1997 14:54:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22485 for ; Fri, 12 Sep 1997 14:51:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 14:44:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21908 for ipp-outgoing; Fri, 12 Sep 1997 14:30:43 -0400 (EDT) Message-Id: <9709121830.AA23355@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 11:27:57 PDT To: Larry Masinter From: Tom Hastings Subject: IPP> Re: MIME types Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Larry, Thanks for the help on MIME-type mapping. I've taken on an action item to make a strawman proposal for next week's IPP meeting. So could the PWG forward a whole bunch of registration proposals of the form: 'application/vnd.xxx-yyy where xxx is the company and yyy is the name of the PDL using the current IANA printer-language registration list (from the Printer MIB) except for the ones that are already registered (Postscript, PDF, and PCL)? A few questions about PDLs, that aren't from a particular vendor: for langSimpleText, you recommended: "text/plain" and Harald has recommended "application/octet-stream" for the automatic sensing, though he also indicated we could make up a more specific one. If we did want to make up a more specific one, since IPP is on standard track, wouldn't it be something like: "application/auto-sense" and we would have to supply a specification for reference in the IANA registration. Could we just reference a separate appendix of the IPP Model document for the meaning of "application/auto-sense"? Thanks for your help. Tom At 22:21 09/10/97 PDT, Larry Masinter wrote: >> We also agreed that those Printer enums that already have registered >> MIME-types: 'application/postscript', 'application/pdf', and vnd.hp-PCL >> should use those MIME-types. >> >> ISSUE: Should the PWG register the rest as 'application/xxx' because IPP is >> on standards track or should the PWG register the rest as 'vnd.vv-xx'? >> 'application/xxx' requires a document specifying the semantics of each >> MIME-type. >> > >Uh, MIME types have two parts: a top level and a subtype. The top level >for most printer documents is "application", unless you can argue that >it fits under "image". (I believe that pdf could arguably be represented >as 'image' rather than 'application', but they chose application/pdf.) > >Under the new rules, you either get an unadorned name ("postscript") or >an adorned one ("vnd") based on whether the type is standards track. >Postscript and PDF are grandfathered in, since they were named before >the >rule was made; if they were being reregistered today they'd be known >as application/vnd.adobe-ps and application/vnd.adobe-pdf, I believe. > >I think that almost all printer formats that are not already registered >would most likely go into the "vnd." hierarchy since they're not >standards >track. > >Larry >-- >http://www.parc.xerox.com/masinter > >   Received: from cnri by ietf.org id aa13971; 12 Sep 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 OAA29515 for ; Fri, 12 Sep 1997 14:59:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA23074 for ; Fri, 12 Sep 1997 14:56:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 14:52:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21933 for ipp-outgoing; Fri, 12 Sep 1997 14:35:59 -0400 (EDT) Date: Fri, 12 Sep 1997 11:35:01 -0700 From: Robert Herriot Message-Id: <199709121835.LAA00266@woden.eng.sun.com> To: don@lexmark.com, rdebry@us.ibm.com Subject: Re: IPP> PWG> 1998 Meeting Plan Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have similiar feelings to Roger about preferring smaller cities or suburbs to the downtown of large congested cities, though I also like to take nonstop flights to the destination. The one exception is cities, like New Orleans, that have really outstanding restaurants -- the one urban feature we have time to take advantage of. The choice of Nashua instead of Boston or Redmond instead of Seattle are examples of a small cities with easy access to airports with nonstop service to many cities. Perhaps, we need to determine what the consensus is for meeting-place criteria. Bob Herriot > From rdebry@us.ibm.com Fri Sep 12 06:33:16 1997 > > Don, I'll review with my management to see if they will support Hawaii. I also > have a personal > aversion to cities like Baltimore. I'd prefer smaller, safer places. Would you > consider substituting > Madison WI for Minneapolis? > > Roger K deBry > Senior Technical 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 09/12/97 07:15 > AM --------------------------- > > IINUS1.SMTP3 @ D03AU017 > 09/12/97 06:20 AM > Please respond to IINUS1.SMTP3 @ VM > > To: Roger K Debry/Boulder/IBM > cc: > Subject: PWG> 1998 Meeting Plan > > Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; > Fri, 12 Sep 97 08:19:19 EDT > Received: from localhost (daemon@localhost) by lists.underscore.com > (8.7.5/8.7.3) with SMTP id IAA18234; Fri, 12 Sep 1997 08:19:14 -0400 (EDT) > Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 08:17:54 -0400 > Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id > IAA18106 for pwg-outgoing; Fri, 12 Sep 1997 08:16:10 -0400 (EDT) From: > don@lexmark.com Message-Id: <199709121215.AA02930@interlock2.lexmark.com> > X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org Date: Fri, 12 Sep 1997 > 08:15:54 -0400 Subject: PWG> 1998 Meeting Plan Mime-Version: 1.0 Content-Type: > text/plain; charset=us-ascii Sender: owner-pwg@pwg.org > > > Well, since a few months ago when I published this proposal > for the 1998 meeting schedule, I have heard no significant > concerns raised. In that case, we will approve this schedule > with votes on Monday (9/15) and Wednesday (9/17) mornings. > > Going, going, almost gone.... > > Jan 19-23 Hawaii (W3C Jan 14-15: SFO) > Feb > Mar 2-6 San Antonio (IETF Mar 30-Apr 1: LA) > April 6-10 Portland, OR > May 18-22 Baltimore > June (W3C Jun 24-25: Geneva) > July 6-10 San Francisco > Aug 17-21 Minneapolis (IETF Aug 24-28: Chicago) > Sep28-Oct2 Charleston, SC > Oct > Nov 9-13 Phoenix > Dec 14-18 San Diego (IETF Dec 7-11: unknown) > > 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 aa14642; 12 Sep 97 15: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 PAA29709 for ; Fri, 12 Sep 1997 15:36:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23923 for ; Fri, 12 Sep 1997 15:32:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 15:29:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23301 for ipp-outgoing; Fri, 12 Sep 1997 15:19:54 -0400 (EDT) Message-ID: <3419952B.8587ABC1@underscore.com> Date: Fri, 12 Sep 1997 15:16:59 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Larry Masinter , ipp@pwg.org Subject: Re: IPP> Re: MIME types References: <9709121830.AA23355@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org As I understand it (and Larry would know best), the standard MIME type of "application/octet-stream" is the universal equivalent of "go fish" in the web/email worlds. I think IPP should follow this de facto standard and NOT devise a new MIME type (such as "application/auto-sense"), as no real value appears to be added by this approach. ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > Larry, > > Thanks for the help on MIME-type mapping. I've taken on an action item > to make a strawman proposal for next week's IPP meeting. > > So could the PWG forward a whole bunch of registration proposals of the > form: > > 'application/vnd.xxx-yyy > > where xxx is the company and yyy is the name of the PDL using the current > IANA printer-language registration list (from the Printer MIB) > > except for the ones that are already registered (Postscript, PDF, and PCL)? > > A few questions about PDLs, that aren't from a particular vendor: > > for langSimpleText, you recommended: "text/plain" > > and Harald has recommended "application/octet-stream" for the > automatic sensing, though he also indicated we could make up a > more specific one. If we did want to make up a more specific one, > since IPP is on standard track, wouldn't it be something like: > > "application/auto-sense" > > and we would have to supply a specification for reference in the > IANA registration. Could we just reference a separate appendix of the > IPP Model document for the meaning of "application/auto-sense"? > > Thanks for your help. > > Tom > > At 22:21 09/10/97 PDT, Larry Masinter wrote: > >> We also agreed that those Printer enums that already have registered > >> MIME-types: 'application/postscript', 'application/pdf', and vnd.hp-PCL > >> should use those MIME-types. > >> > >> ISSUE: Should the PWG register the rest as 'application/xxx' because IPP is > >> on standards track or should the PWG register the rest as 'vnd.vv-xx'? > >> 'application/xxx' requires a document specifying the semantics of each > >> MIME-type. > >> > > > >Uh, MIME types have two parts: a top level and a subtype. The top level > >for most printer documents is "application", unless you can argue that > >it fits under "image". (I believe that pdf could arguably be represented > >as 'image' rather than 'application', but they chose application/pdf.) > > > >Under the new rules, you either get an unadorned name ("postscript") or > >an adorned one ("vnd") based on whether the type is standards track. > >Postscript and PDF are grandfathered in, since they were named before > >the > >rule was made; if they were being reregistered today they'd be known > >as application/vnd.adobe-ps and application/vnd.adobe-pdf, I believe. > > > >I think that almost all printer formats that are not already registered > >would most likely go into the "vnd." hierarchy since they're not > >standards > >track. > > > >Larry > >-- > >http://www.parc.xerox.com/masinter > > > >   Received: from cnri by ietf.org id aa15752; 12 Sep 97 16: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 QAA29895 for ; Fri, 12 Sep 1997 16:19:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24617 for ; Fri, 12 Sep 1997 16:16:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 16:12:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24099 for ipp-outgoing; Fri, 12 Sep 1997 16:03:42 -0400 (EDT) Date: Fri, 12 Sep 1997 13:02:48 -0700 From: Robert Herriot Message-Id: <199709122002.NAA00373@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Please review Appendix E: Processing IPP Attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I agree with Tom. Scott did an excellent job of describing the fidelity and pdl-override-supported attributes. The description should be of great help to implementers. Bob Herriot > From hastings@cp10.es.xerox.com Fri Sep 12 11:02:24 1997 > > Scott did a great job of taking the description of processing IPP attributes > that some of us started at the Redmond meeting over lunch and expanding it as > Appendix E in the Model document. > > People should review it and it should be on the agenda for the > meeting. > > Here it is in plain text. > > Tom >   Received: from cnri by ietf.org id aa16739; 12 Sep 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 RAA00060 for ; Fri, 12 Sep 1997 17:08:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25735 for ; Fri, 12 Sep 1997 17:05:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 17:01:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25225 for ipp-outgoing; Fri, 12 Sep 1997 16:52:34 -0400 (EDT) Message-Id: <9709122052.AA23469@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 13:49:53 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: ambiguity "printer-description" group v.attribute name Sender: ipp-owner@pwg.org We've found a problem implementing the Get-Attributes operation on a Printer. There is an attribute group name called "printer-description" AND a printer attribute called "printer-description". This leads to an obvious ambiguity. Group names can be used in the Get-Attributes and Get-Jobs operations to request particular attributes as the value of the "requested-attributes" input parameter attribute. The group names that we have are: "job-template" "job-description" "printer-description" "all" So a requester can specify: "requested-attributes" = 'job-state', 'job-description' in a Get-Attributes operation. But when the requester specifies: "requested-attributes" = 'printer-description' it is ambiguous whether the group or the attribute is being requested. Possible fixes: 1. Add "-group" to all three for use in Get-Attributes operation: "job-template-group" "job-description-group" "printer-description-group" "all-group" or maybe just keep this "all" To get the group the requester would supply: "requrested-attributes" = 'printer-description-group' 2. Add "-attributes" to all three for use in Get-Attributes operation: "job-template-attributes" "job-description-attributes" "printer-description-attributes" "all-attributes" To get the group the requester would supply: "requrested-attributes" = 'printer-description-attributes' 3. Change the name of the Printer attribute from "printer-description" to "printer-info" (to go with "printer-more-info") and leave the group names alone. Comments? Tom   Received: from cnri by ietf.org id aa18336; 12 Sep 97 18: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 SAA00331 for ; Fri, 12 Sep 1997 18:25:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA26478 for ; Fri, 12 Sep 1997 18:22:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 18:17:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25947 for ipp-outgoing; Fri, 12 Sep 1997 18:08:21 -0400 (EDT) From: don@lexmark.com Message-Id: <199709122208.AA28238@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 12 Sep 1997 18:08:03 -0400 Subject: IPP> Special Conference Call Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org There will be a conference call line available next Wednesday during the IPP meeting starting at 1 PM Eastern Time for the purposes of discussing the JOB URI versus JOB ID issue. The phone number is 1-423-523-7162. The access code is 190148. These are the same as always except for the starting time of 1 PM. There will be 10 ports available. I have reserved 4 hours. Don   Received: from cnri by ietf.org id aa19382; 12 Sep 97 19: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 TAA00496 for ; Fri, 12 Sep 1997 19:39:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA27566 for ; Fri, 12 Sep 1997 19:35:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Sep 1997 19:31:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27073 for ipp-outgoing; Fri, 12 Sep 1997 19:22:47 -0400 (EDT) Message-Id: <9709122323.AA23554@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 16:20:10 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ACTION ITEM: Change color-supported from Boolean to keyword Sender: ipp-owner@pwg.org Here is my belated action item from the Redmond meeting to propose the wording for the "color-supported" printer description attribute. The agreement was that by changing from a Boolean to a type 2 keyword, we would allow a finer granularity of description to evolve, but that we would only bother to specify three fundamental values for IPP V1.0, namely, 'monochrome', 'process', and 'spot' to align with the Printer MIB and current industry practice. We could do more, but at the expense of additional attributes, which we don't want in IPP V1. The values are extensible, so one could register in the future additional values like 'process-3', 'spot-2', etc., to indicate how many colorants are available in the future. Proposed changes to current IPP model-05.txt: Section 4.5, table on page 57 - current text: +----------------------------+----------------------+----------------+ | color-supported | boolean | | +----------------------------+----------------------+----------------+ Change to: +----------------------------+----------------------+----------------+ | color-supported | type2 keyword | | +----------------------------+----------------------+----------------+ Section 4.5.18, page 64 - current text: 4.5.18 color-supported (boolean) This attribute identifies whether the Printer is capable of any type of color printing at all. All document instructions having to do with color are embedded within the document PDL (none are external IPP attributes). Change to: 4.5.18 color-supported (type2 keyword) This attribute identifies whether the Printer is capable of any type of color printing. All document instructions having to do with color are embedded within the document PDL (none are external IPP attributes). This attribute takes on the following values: - 'monochrome': This value indicates that the Printer is capable of printing in just one color (usually black). - 'process': This value indicates that the Printer is capable of process color printing. - 'spot': This value indicates that the Printer is capable of spot color printing; also referred to as highlight color printing.   Received: from cnri by ietf.org id aa03689; 15 Sep 97 10: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 PAA02966 for ; Sun, 14 Sep 1997 15:12:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01258 for ; Sun, 14 Sep 1997 15:09:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 14 Sep 1997 15:02:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00744 for ipp-outgoing; Sun, 14 Sep 1997 14:53:37 -0400 (EDT) Message-ID: <341C3287.A6F7B49D@parc.xerox.com> Date: Sun, 14 Sep 1997 11:52:55 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: IPP> Re: MIME types X-Priority: 3 (Normal) References: <9709121830.AA23355@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom, I am not the authority on the IETF MIME registration proceedure, I've just observed it in practice and have read the relevant RFCs. I don't imply that these answers are authoritative. I believe that the registrant for a "vnd.xxx-" designation should logically be the owner of the "xxx-" trademark, and that trying to register data types in the name of someone else is a bad idea. The type "application/auto-sense" doesn't make sense to me. MIME types designate the type of enclosed content. If you don't know the type, you can supply "application/octet-stream", if you, for example, know absolutely nothing about the data type. However, "application/unknown-print-file" might be a type for designating "this is a file intended for shipping to an autosense printer, but it isn't just some arbitrary bucket of bits." As for whether you can reference a separate appendix of the IPP model document, I think the requirements for having a public specification are fairly generic. Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa18111; 15 Sep 97 17: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 RAA06685 for ; Mon, 15 Sep 1997 17:41:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04468 for ; Mon, 15 Sep 1997 17:37:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 17:29:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03765 for ipp-outgoing; Mon, 15 Sep 1997 17:20:52 -0400 (EDT) Message-Id: <9709152120.AA24013@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, 15 Sep 1997 14:17:58 PDT To: Scott Isaacson From: Tom Hastings Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Cc: Robert.Herriot@eng.sun.com, ipp@pwg.org Sender: ipp-owner@pwg.org I too am trying to understand Bob's third alternative and do not have an opinion. However, there is a variation on Bob's third alternative that might be less of a burden on IPP servers, while providing the same benefit to supporting IPP under current APIs and in gateways. The idea is basically to have only job-uri as the access point for jobs, but require an additional attribute that a client can supply a 32-bit job id in and the server just stored it away. So instead of the client or gateway having to store the job-id to job-uri map, the map is stored in the IPP server. This solves the stale data problem, because the map information is kept as long as the job exists in the server and no longer. This approach is what ISO DPA has in its job-client-id attribute. This is the strategy that we are using in the IETF Job Monitoring MIB with the jmJobSubmissionID table which accepts any client id as an input index and returns the job-id that the server/agent is using. The only issue left is how does a client or gateway find a job with a particular job-id? There are two ways: One way would be to add the job-id as an optional input filter attribute to the Get-Jobs attribute which takes the Printer URI as input, not a JOB URI and the client would get back the job. This would put the burden on the server of being able to access jobs in two ways, but only on Get-Jobs which is a search anyway. The Get-Attributes operation would continue to require the job-uri. So a client could either: (1) cache the job-uri and use it for subsequent Get-Attributes or Cancel-Job (2) always use Get-Jobs operation to perform a Get-Attribtes for a particular job and use Get-Jobs operation first to get the job-uri in order to do the Job-Cancel. The other way, would be to put the burden completely on the client (by only mandating that the IPP server support the "job-client-id" 32-bit attribute and just passively store the attribute supplied by the client). Then the client must use a Get-Jobs with the "requested-attributes"='job-client-id,job-uri' and get all of the mapped pairs back and find the URI it needs to use in the IPP operation on a job: Get-Attribute or Cancel-Job. With either way, the map is kept in the IPP server. Comments? Tom At 08:53 09/09/97 PDT, Scott Isaacson wrote: >Bob did a good job at introducing and summarizing the issues associated with >the "open minded" idea of having both Job IDs and Job URIs. I am really >trying to have an open mind and think new thoughts, but my gut reaction and >continued perception (even after reading Bob's message) is that it is too >cumbersome, and not very elegant. It does not really solve the problems >unless we force ALL Printer implementation to support the passing in and >then passing back out of this helper attribute. That seems ok, but when >implementations must support operations either being addressed to a Printer >(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs >etc with both (J) and (P,s), that sounds very un-ok. > >Let's either fish or cut bait. > >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 >************************************************************ > >>>> Robert Herriot 09/05 5:59 PM >>> >It was suggested at the last teleconference that we should have both >Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. > >I want to make it clear at the outset of this email, that I am not taking >a position on whether we should have both. Rather I want to explore what >the ramifications are if we have both. > >The following are what I think the characteristics of such a solution are. > >If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST >support both; otherwise, we are in worse shape than with just one of >them from all servers. Client MUST be free to use whichever they want. > >For Print-Job, it doesn't matter whether a client specifies whether it >wants a Job-URI or Job-ID, or whether the server returns both. In both >cases, the server has to deal with both and the client has to be aware >of the choice. So for this discussion, let's assume that the server >would return both. > >For Get-Attributes and Cancel-Job, a server must implement these >operations for both Job-URIs and Job-Ids. The target may be a Job-URI >or the target may be a Printer-URI with a Job-Id attribute. > >Both Job-URI and Job-Id attributes are mandatory. Thus a client can >query for either via Get-Jobs or Get-Attributes. > >The following discusses how this solution works with various gateways. >This solution works well in Win32 because it would use the Job-Id only. >It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > >The IPP-to-LPD gateways work well because the Job-Id and Job-URL >are both easy to support. So, acting as an IPP server, the gateway can >easily support both together. > >The LPD-to-IPP gateway is easy to support with Job-Ids, so such a >gateway, as a client of a IPP server, would use only the Job-Id and >would ignore the Job-URL. > >So from a legacy point of view, the solution with both Job-URIs and Job-Ids >is as good as the Job-Id solution only. > >But now we need to examine what this change means for server >implementations. > >With this change servers would have a bit more work to do because they >would have to offer two ways to do the same thing. Moreover, it is >mandatory that if they support a particular operation, they must >support both Job-URIs and Job-Id. That may be a burden that some >implementors won't like -- more code for some abstract future payback. > >I expect that for most IPP servers its Job-URIs will always consists of >its Printer-URI and a Job-Id so the server can easily convert between >Job-URIs and Job-Ids with no architectural additions. > >But for servers that want the Job-URI to reference some remote host, >the solution is more complicated because operations, such as >Get-Attributes and Cancel-Job will go to the remote host when the >client uses the Job-URI and these same operations will go to the >Printer when the client uses the Printer-URI and Job-Id. Such servers >will have to deal with forwarding issues and the fact that a Job-URI >that references a remote host does not guarantee that all traffic goes >there because client that use the Job-Id will still come to the original >printer. > > > >As I said at the beginning of this email, I take no position on this >proposal. Rather I offer it as the beginning of a discussion. > >I would like others to comment on whether this proposal solves the >problem, or adds too much complexity to servers for the payback. > > >Bob Herriot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa19328; 15 Sep 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 SAA06923 for ; Mon, 15 Sep 1997 18:30:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05577 for ; Mon, 15 Sep 1997 18:27:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 18:23:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05081 for ipp-outgoing; Mon, 15 Sep 1997 18:14:00 -0400 (EDT) From: "CN=Roger K Debry/OU=Boulder/O=IBM@IBMUS@IBMLMS01"@us.ibm.com To: ipp@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Message-ID: <5030100008377182000002L022*@MHS> Date: Mon, 15 Sep 1997 18:14:56 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org This may be a real cop-out, but one SIMPLE approach is to declare that for version 1.0 of IPP, Job-ID is what you get . . . period. Then leave the door open for version 2.0 to add a Job-URL IF and WHEN it is determined that customers need the flexibility/scalability that Job-URL adds. In stage II, it wouldn't seem too difficult to add a query to see if a server supported JOB-URL. Roger K deBry Senior Technical 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 09/15/97 04:04 PM --------------------------- ipp-owner @ pwg.org 09/15/97 03:35 PM Please respond to ipp-owner@pwg.org @ internet To: SISAACSON @ novell.com @ internet cc: ipp @ pwg.org @ internet, Robert.Herriot @ Eng.Sun.COM @ internet Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? I too am trying to understand Bob's third alternative and do not have an opinion. However, there is a variation on Bob's third alternative that might be less of a burden on IPP servers, while providing the same benefit to supporting IPP under current APIs and in gateways. The idea is basically to have only job-uri as the access point for jobs, but require an additional attribute that a client can supply a 32-bit job id in and the server just stored it away. So instead of the client or gateway having to store the job-id to job-uri map, the map is stored in the IPP server. This solves the stale data problem, because the map information is kept as long as the job exists in the server and no longer. This approach is what ISO DPA has in its job-client-id attribute. This is the strategy that we are using in the IETF Job Monitoring MIB with the jmJobSubmissionID table which accepts any client id as an input index and returns the job-id that the server/agent is using. The only issue left is how does a client or gateway find a job with a particular job-id? There are two ways: One way would be to add the job-id as an optional input filter attribute to the Get-Jobs attribute which takes the Printer URI as input, not a JOB URI and the client would get back the job. This would put the burden on the server of being able to access jobs in two ways, but only on Get-Jobs which is a search anyway. The Get-Attributes operation would continue to require the job-uri. So a client could either: (1) cache the job-uri and use it for subsequent Get-Attributes or Cancel-Job (2) always use Get-Jobs operation to perform a Get-Attribtes for a particular job and use Get-Jobs operation first to get the job-uri in order to do the Job-Cancel. The other way, would be to put the burden completely on the client (by only mandating that the IPP server support the "job-client-id" 32-bit attribute and just passively store the attribute supplied by the client). Then the client must use a Get-Jobs with the "requested-attributes"='job-client-id,job-uri' and get all of the mapped pairs back and find the URI it needs to use in the IPP operation on a job: Get-Attribute or Cancel-Job. With either way, the map is kept in the IPP server. Comments? Tom At 08:53 09/09/97 PDT, Scott Isaacson wrote: >Bob did a good job at introducing and summarizing the issues associated with >the "open minded" idea of having both Job IDs and Job URIs. I am really >trying to have an open mind and think new thoughts, but my gut reaction and >continued perception (even after reading Bob's message) is that it is too >cumbersome, and not very elegant. It does not really solve the problems >unless we force ALL Printer implementation to support the passing in and >then passing back out of this helper attribute. That seems ok, but when >implementations must support operations either being addressed to a Printer >(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs >etc with both (J) and (P,s), that sounds very un-ok. > >Let's either fish or cut bait. > >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 >************************************************************ > >>>> Robert Herriot 09/05 5:59 PM >>> >It was suggested at the last teleconference that we should have both >Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. > >I want to make it clear at the outset of this email, that I am not taking >a position on whether we should have both. Rather I want to explore what >the ramifications are if we have both. > >The following are what I think the characteristics of such a solution are. > >If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST >support both; otherwise, we are in worse shape than with just one of >them from all servers. Client MUST be free to use whichever they want. > >For Print-Job, it doesn't matter whether a client specifies whether it >wants a Job-URI or Job-ID, or whether the server returns both. In both >cases, the server has to deal with both and the client has to be aware >of the choice. So for this discussion, let's assume that the server >would return both. > >For Get-Attributes and Cancel-Job, a server must implement these >operations for both Job-URIs and Job-Ids. The target may be a Job-URI >or the target may be a Printer-URI with a Job-Id attribute. > >Both Job-URI and Job-Id attributes are mandatory. Thus a client can >query for either via Get-Jobs or Get-Attributes. > >The following discusses how this solution works with various gateways. >This solution works well in Win32 because it would use the Job-Id only. >It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > >The IPP-to-LPD gateways work well because the Job-Id and Job-URL >are both easy to support. So, acting as an IPP server, the gateway can >easily support both together. > >The LPD-to-IPP gateway is easy to support with Job-Ids, so such a >gateway, as a client of a IPP server, would use only the Job-Id and >would ignore the Job-URL. > >So from a legacy point of view, the solution with both Job-URIs and Job-Ids >is as good as the Job-Id solution only. > >But now we need to examine what this change means for server >implementations. > >With this change servers would have a bit more work to do because they >would have to offer two ways to do the same thing. Moreover, it is >mandatory that if they support a particular operation, they must >support both Job-URIs and Job-Id. That may be a burden that some >implementors won't like -- more code for some abstract future payback. > >I expect that for most IPP servers its Job-URIs will always consists of >its Printer-URI and a Job-Id so the server can easily convert between >Job-URIs and Job-Ids with no architectural additions. > >But for servers that want the Job-URI to reference some remote host, >the solution is more complicated because operations, such as >Get-Attributes and Cancel-Job will go to the remote host when the >client uses the Job-URI and these same operations will go to the >Printer when the client uses the Printer-URI and Job-Id. Such servers >will have to deal with forwarding issues and the fact that a Job-URI >that references a remote host does not guarantee that all traffic goes >there because client that use the Job-Id will still come to the original >printer. > > > >As I said at the beginning of this email, I take no position on this >proposal. Rather I offer it as the beginning of a discussion. > >I would like others to comment on whether this proposal solves the >problem, or adds too much complexity to servers for the payback. > > >Bob Herriot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa22086; 15 Sep 97 20: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 UAA07241 for ; Mon, 15 Sep 1997 20:40:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06328 for ; Mon, 15 Sep 1997 20:37:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 20:32:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05834 for ipp-outgoing; Mon, 15 Sep 1997 20:23:38 -0400 (EDT) Date: Mon, 15 Sep 1997 17:24:47 -0700 (PDT) From: papowell@astart.com Message-Id: <199709160024.RAA00608@astart4.astart.com> To: Robert.Herriot@eng.sun.com, walker@dazel.com Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org > From walker@dazel.com Fri Sep 12 16:34:10 1997 > Date: Tue, 09 Sep 1997 15:40:39 -0500 > From: Jim Walker > To: Robert Herriot > Cc: ipp@pwg.org > Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs? > > Some comments on these IPP<->LPD gateway discussions... > > ... I agree with Scott that the gateway between IPP and legacy > systems should *not* be the driving force behind our design. I remember discussions in June where this was addressed at length. The results of the discussion was that there was overwhelming need to have LPD/Microsoft/Whatever be able to gateway to IPP. There was almost no indication that the opposite (IPP to whatever) was desireable, necessary, etc. This was on the basis that the newer protocols/facilities may have options/capabilities that are impossible to support in the older ones. Now you may be able to have users RESUBMIT jobs to the older systems, but note that this is not the same as having an IPP system translate them. > > ... There seems to be a base assumption that mapping a from a > LPD job identifier (integer) to an IPP job URL is a difficult > problem. I would assert that it is not. We have a gateway > that has been in existence for four years now that solves this > exact problem: it maps from the LPD job identifiers to an opaque > printer-independent job identifier. > > And folks, it wasn't that hard to do. > > later... > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX >   Received: from cnri by ietf.org id aa22511; 15 Sep 97 20: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 VAA07274 for ; Mon, 15 Sep 1997 21:00:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06965 for ; Mon, 15 Sep 1997 20:57:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 20:53:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06452 for ipp-outgoing; Mon, 15 Sep 1997 20:44:33 -0400 (EDT) Date: Mon, 15 Sep 1997 17:45:53 -0700 (PDT) From: papowell@astart.com Message-Id: <199709160045.RAA00636@astart4.astart.com> To: ipp@pwg.org Subject: IPP> Printers and Spooling Systems Sender: ipp-owner@pwg.org I apologize for my absence of the three months, but a 2 week vacation unwillingly turned into three months off. I have been reading the various discussions about Job URI/URL and Job IDs, and there are always various objections raised involving 'job movement'. At this point I would like to point out that during initial discussions of the IPP protocol, the following issue was raised (at San Diego, and at several teleconferences prior to this): Patrick Powell: "Is IPP a 'submit job to printer' protocol or a 'submit job to spooler' protocol?" Summary of Answers: It is a 'submit job to printer' protocol. We do not want to deal with spooler management issues in the first draft. In the discussions that are going on, I notice that most of the effort is given to worrying about 'moving jobs' or 'job spoolers'. I would like to then ask the question: Is IPP now a 'submit job to spooler' protocol? If you treat a printer like a 'leaf' at the end of the 'print tree' of client->spooler->spooler....->printer or even client->printer, it simplifies the understanding of the requirements considerably. If you want IPP to be a 'client->spooler' protocol AND a 'client->printer' protocol AND a 'spooler->printer' protocol, I think that you are trying to undertake a major set of problems. One of the difficulties with LPR (RFC1179) was that it was a 'client->spooler' protocol, and did not deal with the 'client->printer' or 'spooler->printer' problems. I would like to solve the 'client->printer' and 'spooler->printer' problems as well as we can. I would like to note that 'moving jobs' from one printer to another can be accomplished at a higher level by having a spooler 'remember' the job and then 'remove' it from the printer and 'send' it to the new printer. There is a cost to this, of course - the spooler has to save the job. However, there is also a cost to 'moving jobs' from the printer - the PRINTER has to save the job. I would like to suggest that we focus on client->printer and spooler->printer issues, and not try to deal with client->spooler or designing spoolers. Let the print spooler vendors/developers do this and do not try to build all the necessary spooler functionality into a printer. Patrick Powell   Received: from cnri by ietf.org id aa23059; 15 Sep 97 21: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 VAA07303 for ; Mon, 15 Sep 1997 21:25:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07623 for ; Mon, 15 Sep 1997 21:21:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 21:18:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07104 for ipp-outgoing; Mon, 15 Sep 1997 21:09:07 -0400 (EDT) Date: Mon, 15 Sep 1997 18:09:12 -0700 (PDT) From: papowell@astart.com Message-Id: <199709160109.SAA00714@astart4.astart.com> To: carl@manros.com, ipp@pwg.org, pzehler@channels.mc.xerox.com Subject: Re: IPP> TES Meeting Minutes Sender: ipp-owner@pwg.org > From carl@manros.com Fri Sep 12 16:34:47 1997 > Date: Tue, 09 Sep 1997 19:39:52 -0700 > To: Peter Zehler , ipp@pwg.org > From: Carl-Uno Manros > Subject: Re: IPP> TES Meeting Minutes > > At 12:36 PM 9/9/97 PDT, you wrote: > >..... > >It was suggested that a TCP port be allocated for IPP(516 was > >suggested). Some of us use 3rd party embedded HTTP servers. We need to > >find out from these companies is supporting IPP on a port other than > >port 80 is a problem. Ira will check with SpyGlass and I will see if I > >can get input from other vendors. This issue will be brought to the > >full IPP group. > > We have discussed this earlier and came to the conclusion that there was > no obvious advantage in having a separate port as part of the standard. > Do we have any new compelling arguments now? It allows the separation of the use of the IPP protocol from that of HTTP default connection port. If you want to implement separate IPP servers, then you have the option of doing this. If in the future, the protocol on PortXXX (HTTP) is ever changed, then the protocol on Port UUU for "IPP" will not change. The separate port allows "firewalls" to separate different types of traffic on a functional basis. I think that expecting a HTTP server to perform all of the actions of a Print Server is overloading the protocol and functionality just a little. (For completeness, I must note that I consider the overloading of HTTP for downloading files to the HTTP server a terrible mistake as well.) > > >We discussed pairwise and blanket IPP interop testing. An IPP Bakeoff > >would have to be arranged to handle the blanket test. We are not ready > >for this at this time. (How much lead time will we need to prepare?) > >Pairwise testing seem to be a sticky point. > > 1) Can an implementer place his IPP Printer on the public side of > >their firewall? > > We are prepared to do this. > > > 2) Are we worried about security issues for initial tests? > > Suggest that we can start without worrying too much about security, > as long as we only gove our Printer URIs to other vselected testers. I note that by having a separate port, you can filter the connections and restrict them from other sites in a trivial manner. This is another advantage of the separate port - a 'defense in depth' type of approach. > > > 3) Would a proxy server using SSL or TLS help security? > > It probably would, but this seems to be more work than putting a printer > outside the firewall initially. > Again, it may be appropropriate to discuss this under the 'security' issues. > > 4) Can we work with a firewall vendor to prototype modifications > >necessary for IPP support? > > Let us see if we can find one. > > > 5) Would a publicly available IPP client make the across the > >Internet pairwise testing unnecessary? > >The way it stands right now is that any two individuals are encouraged > >to arrange a pairwise test. Groupwide IPP pairwise testing is not ruled > >out. We still have obstacles in the way. > > > >There are two main roadblocks to the IPP TES group. One is the IPP > >JobId/JobURI issue. The next is the security issue. These issues will > >be passed on to the IPP chair. > > You are right, that we definately need to settle on the JOB URI decision > quickly. The same goes for security, but I think we can do quite a lot of > testing also without security at this stage. > > Carl-Uno > Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 619-874-6543 FAX 619-279-8424 LPRng - Print Spooler (http:www.astart.com/LPRng)   Received: from cnri by ietf.org id aa24137; 15 Sep 97 22: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 WAA07378 for ; Mon, 15 Sep 1997 22:14:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA08793 for ; Mon, 15 Sep 1997 22:11:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 22:07:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08016 for jmp-outgoing; Mon, 15 Sep 1997 22:03:46 -0400 (EDT) From: don@lexmark.com Message-Id: <199709160203.AA05599@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org, fin@pwg.org Date: Mon, 15 Sep 1997 21:55:05 -0400 Subject: JMP> October PWG Meeting Details Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org Here are the details on the October Meeting... October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Meeting Room charges are estimated at $35-40 per person per day. Participants responsible for making their own reservations. Be sure to reference the PWG or IBM meeting to acquire the preferred rate. Limited numbers of Standard and Deluxe rooms are available. Early callers will get the Standard room/rate until this block is exhausted unless you specifically request Deluxe. The Hotel Boulderado, established in 1909, is a historic landmark with a "historic" section and a more modern wing. You may want to request your preference although I can't guarantee it will be available. Standard rooms tend to be a tad smaller in "historic" but each is unique. Deluxe rooms in the historic section are quite nice. Boulder is located appx. 50 minutes from the Denver International Airport. Free parking is available at the Boulderado for guests. From DIA, take Pena Blvd south 12 miles and merge right onto I-70 West. Take I-70 to I-270 (right) and head northwest to US 36 (right). When you reach Boulder proceed left onto Canyon Blvd (3rd light). Take Canyon to 13th (5th light) and turn right (north). Hotel Boulderado is at the corner of 13th and Spruce. You can also catch a shuttle called the "Airporter" which leaves on the hour from DIA. $14 one way - no reservation necessary. Check in with baggage, on DIA baggage level 5 across from the Hertz counter. It leaves every hr. on the 1/2 hr from the hotel for the return. Reservations recommended but not necessary. The Boulderado is a major stop. Travel time via shuttle is appx 70 minutes. The Boulderado is located in the heart of Boulder one block from "Pearl Street", an outdoor mall with shops, restaurants, etc. Forgoing the automobile is quite feasible. For more information on getting from DIA to Boulder visit http://amath-www.colorado.edu/appm/department/limos.html 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 aa24207; 15 Sep 97 22: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 WAA07394 for ; Mon, 15 Sep 1997 22:17:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09046 for ; Mon, 15 Sep 1997 22:14:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 22:02:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07815 for ipp-outgoing; Mon, 15 Sep 1997 21:53:24 -0400 (EDT) Message-Id: <1.5.4.32.19970916014701.006eb6c8@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Sep 1997 18:47:01 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Meeting in Atlanta September 17-18, 1997 Sender: ipp-owner@pwg.org A last minute Agenda, subject to discussion at the beginning of the meeting. Meeting times as usual 8:30 am - 6:00 pm both days. We will start off with Model & Semantics: - Start by checking which M & S details we want to spend time on in the meeting and which we should rule out as things for version 2. - At 10 am on September 17 we will hold the phone conference on Job URI vs. Printer URI + 32-bit ID. This will last until we have reached an agreement as this is now the most important issue to get resolved. - Other M + S subjects that come to mind are: - How do we register MIME types for document types? - Do we have the complete solution for asynchronous notifications? - Are we happy with the new Appendix E? - Do we have agreement about the security solution for M & S? - Any other issues that are open on Scott's list or that we agreed in the morning discussion to consider within the scope of Version 1? Suspecting that M & S will take all day on Wednesday, I expect to tackle the remaining subjects on Thursday: - Any remaining discussions on the Directory Schema document. - Fix up any remaining issues with the Protocol document (including security). - Review latest version of the Rationale document (if available). - Discuss the kind of changes we think are still needed for the Requirements document. - Discuss the LPR Mappinng document to see if we are agreed about the content. (This subject might be postponed if we run out of time). - Discuss Prototype interworking issues. It looks like we will have no difficulty to keep busy for the two days allocated. I look forward to see many of you in Atlanta and PLEASE make sure that you phone in for the phone conference on Wednesday morning if you want to express any views on JOB URI etc. The numbers as reminder: The phone number is 1-423-523-7162. The access code is 190148. The starting time is 1:00 pm Eastern, 10:00 am Pacific. Regards, Carl-Uno   Received: from cnri by ietf.org id aa24400; 15 Sep 97 22: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 WAA07404 for ; Mon, 15 Sep 1997 22:25:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA09480 for ; Mon, 15 Sep 1997 22:21:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 22:16:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08077 for pwg-outgoing; Mon, 15 Sep 1997 22:04:28 -0400 (EDT) From: don@lexmark.com Message-Id: <199709160203.AA05599@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org, fin@pwg.org Date: Mon, 15 Sep 1997 21:55:05 -0400 Subject: PWG> October PWG Meeting Details Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Here are the details on the October Meeting... October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Meeting Room charges are estimated at $35-40 per person per day. Participants responsible for making their own reservations. Be sure to reference the PWG or IBM meeting to acquire the preferred rate. Limited numbers of Standard and Deluxe rooms are available. Early callers will get the Standard room/rate until this block is exhausted unless you specifically request Deluxe. The Hotel Boulderado, established in 1909, is a historic landmark with a "historic" section and a more modern wing. You may want to request your preference although I can't guarantee it will be available. Standard rooms tend to be a tad smaller in "historic" but each is unique. Deluxe rooms in the historic section are quite nice. Boulder is located appx. 50 minutes from the Denver International Airport. Free parking is available at the Boulderado for guests. From DIA, take Pena Blvd south 12 miles and merge right onto I-70 West. Take I-70 to I-270 (right) and head northwest to US 36 (right). When you reach Boulder proceed left onto Canyon Blvd (3rd light). Take Canyon to 13th (5th light) and turn right (north). Hotel Boulderado is at the corner of 13th and Spruce. You can also catch a shuttle called the "Airporter" which leaves on the hour from DIA. $14 one way - no reservation necessary. Check in with baggage, on DIA baggage level 5 across from the Hertz counter. It leaves every hr. on the 1/2 hr from the hotel for the return. Reservations recommended but not necessary. The Boulderado is a major stop. Travel time via shuttle is appx 70 minutes. The Boulderado is located in the heart of Boulder one block from "Pearl Street", an outdoor mall with shops, restaurants, etc. Forgoing the automobile is quite feasible. For more information on getting from DIA to Boulder visit http://amath-www.colorado.edu/appm/department/limos.html 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 aa26142; 15 Sep 97 22: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 WAA07420 for ; Mon, 15 Sep 1997 22:33:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA10088 for ; Mon, 15 Sep 1997 22:30:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 22:25:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08052 for ipp-outgoing; Mon, 15 Sep 1997 22:04:10 -0400 (EDT) From: don@lexmark.com Message-Id: <199709160203.AA05599@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org, fin@pwg.org Date: Mon, 15 Sep 1997 21:55:05 -0400 Subject: IPP> October PWG Meeting Details Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the details on the October Meeting... October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Meeting Room charges are estimated at $35-40 per person per day. Participants responsible for making their own reservations. Be sure to reference the PWG or IBM meeting to acquire the preferred rate. Limited numbers of Standard and Deluxe rooms are available. Early callers will get the Standard room/rate until this block is exhausted unless you specifically request Deluxe. The Hotel Boulderado, established in 1909, is a historic landmark with a "historic" section and a more modern wing. You may want to request your preference although I can't guarantee it will be available. Standard rooms tend to be a tad smaller in "historic" but each is unique. Deluxe rooms in the historic section are quite nice. Boulder is located appx. 50 minutes from the Denver International Airport. Free parking is available at the Boulderado for guests. From DIA, take Pena Blvd south 12 miles and merge right onto I-70 West. Take I-70 to I-270 (right) and head northwest to US 36 (right). When you reach Boulder proceed left onto Canyon Blvd (3rd light). Take Canyon to 13th (5th light) and turn right (north). Hotel Boulderado is at the corner of 13th and Spruce. You can also catch a shuttle called the "Airporter" which leaves on the hour from DIA. $14 one way - no reservation necessary. Check in with baggage, on DIA baggage level 5 across from the Hertz counter. It leaves every hr. on the 1/2 hr from the hotel for the return. Reservations recommended but not necessary. The Boulderado is a major stop. Travel time via shuttle is appx 70 minutes. The Boulderado is located in the heart of Boulder one block from "Pearl Street", an outdoor mall with shops, restaurants, etc. Forgoing the automobile is quite feasible. For more information on getting from DIA to Boulder visit http://amath-www.colorado.edu/appm/department/limos.html 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 aa26521; 15 Sep 97 22: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 WAA07446 for ; Mon, 15 Sep 1997 22:48:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA10727 for ; Mon, 15 Sep 1997 22:45:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Sep 1997 22:41:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09992 for ipp-outgoing; Mon, 15 Sep 1997 22:29:06 -0400 (EDT) Message-ID: <341DEDD9.CE33D5DF@sharplabs.com> Date: Mon, 15 Sep 1997 19:24:26 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? References: <9709152120.AA24013@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I will try and emphasize my position on LPD gateways by saying that I don't consider the LPD-to-IPP gateway case to be a common case for gateways. As I have stated previously, it gives no value to LPR/LPD clients to gateway to IPP because they are still funneling(filtering) their requests through the same front end interface. The kind of technology we are delivering for IPP version 1.0 is oriented towards the user, so outfitting end users (clients) with IPP as soon as possible should (IMHO) be the goal for deployment of IPP. Also, administrators should not be deinstalling their current base of LPR/LPD services. IPP will supplement, not replace, LPD during a transition phase. I do see a need for IPP-to-LPD gateways because IPP servers (operating as spoolers on WinNT or Unix systems), might want to connect directly to network printers using TCP/IP, and the most commonly deployed embedded TCP/IP printing solution within printers is LPD. We would like to include the existing installed base of network printers in IPP configurations, but we don't want to have to upgrade their firmware to do this. Therefore, allowing IPP servers to transfer print jobs into the LPD environment is something I think needs to happen. Dropping data and control files into LPD spool directories from an IPP server is pretty easy on Unix systems. I'm not positive about Windows/NT based LPD services but I would imagiine that this is also fairly straightforward. Also, concerning Roger's comment about delaying Job-URIs into Version 2.0, I think the URI is one of the only really new features of network printing we are offering and I would really like to see it available in version 1.0; among other things, its the job URI that will allow easy deployment and integration of IPP over other transports other than HTTP, which is something I think we all are thinking about for the future. Also, converning Patrick Powell's comments about the movement of jobs using URIs, this feature is only one of the features that job URI provides so we shouldn't focus on this one aspect of functionality (even though we get it for free with the adoption of the URI concept, and its not hard to envision its use regarding the movement of jobs). Randy Tom Hastings wrote: > I too am trying to understand Bob's third alternative and do not have > an opinion. > > However, there is a variation on Bob's third alternative that might be > less of a burden on IPP servers, while providing the same benefit to > supporting IPP under current APIs and in gateways. > > The idea is basically to have only job-uri as the access point for jobs, but > require an additional attribute that a client can supply a 32-bit job > id in and the server just stored it away. So instead of the client or > gateway having to store the job-id > to job-uri map, the map is stored in the IPP server. This solves the > stale data problem, because the map information is kept as long as the > job exists in the server and no longer. > > This approach is what ISO DPA has in its job-client-id attribute. > > This is the strategy that we are using in the IETF Job Monitoring MIB > with the jmJobSubmissionID table which accepts any client id as an input > index and returns the job-id that the server/agent is using. > > The only issue left is how does a client or gateway find a job > with a particular job-id? > > There are two ways: > > One way would be to add the job-id as an optional input filter attribute to the > Get-Jobs attribute which takes the Printer URI as input, not a JOB URI > and the client would get back the job. This would put the burden on > the server of being able to access jobs in two ways, but only on Get-Jobs > which is a search anyway. > > The Get-Attributes operation would continue to require the job-uri. > > So a client could either: > (1) cache the job-uri and use it for subsequent Get-Attributes or Cancel-Job > (2) always use Get-Jobs operation to perform a Get-Attribtes for a particular > job and use Get-Jobs operation first to get the job-uri in order to do the > Job-Cancel. > > The other way, would be to put the burden completely on the client > (by only mandating that the IPP server support the "job-client-id" 32-bit > attribute and just passively store the attribute supplied by the client). > > Then the client must use a Get-Jobs with the > "requested-attributes"='job-client-id,job-uri' and get all of the > mapped pairs back and find the URI it needs to use in the IPP operation > on a job: Get-Attribute or Cancel-Job. > > With either way, the map is kept in the IPP server. > > Comments? > > Tom > > At 08:53 09/09/97 PDT, Scott Isaacson wrote: > >Bob did a good job at introducing and summarizing the issues associated with > >the "open minded" idea of having both Job IDs and Job URIs. I am really > >trying to have an open mind and think new thoughts, but my gut reaction and > >continued perception (even after reading Bob's message) is that it is too > >cumbersome, and not very elegant. It does not really solve the problems > >unless we force ALL Printer implementation to support the passing in and > >then passing back out of this helper attribute. That seems ok, but when > >implementations must support operations either being addressed to a Printer > >(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs > >etc with both (J) and (P,s), that sounds very un-ok. > > > >Let's either fish or cut bait. > > > >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 > >************************************************************ > > > >>>> Robert Herriot 09/05 5:59 PM >>> > >It was suggested at the last teleconference that we should have both > >Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. > > > >I want to make it clear at the outset of this email, that I am not taking > >a position on whether we should have both. Rather I want to explore what > >the ramifications are if we have both. > > > >The following are what I think the characteristics of such a solution are. > > > >If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST > >support both; otherwise, we are in worse shape than with just one of > >them from all servers. Client MUST be free to use whichever they want. > > > >For Print-Job, it doesn't matter whether a client specifies whether it > >wants a Job-URI or Job-ID, or whether the server returns both. In both > >cases, the server has to deal with both and the client has to be aware > >of the choice. So for this discussion, let's assume that the server > >would return both. > > > >For Get-Attributes and Cancel-Job, a server must implement these > >operations for both Job-URIs and Job-Ids. The target may be a Job-URI > >or the target may be a Printer-URI with a Job-Id attribute. > > > >Both Job-URI and Job-Id attributes are mandatory. Thus a client can > >query for either via Get-Jobs or Get-Attributes. > > > >The following discusses how this solution works with various gateways. > >This solution works well in Win32 because it would use the Job-Id only. > >It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > > > >The IPP-to-LPD gateways work well because the Job-Id and Job-URL > >are both easy to support. So, acting as an IPP server, the gateway can > >easily support both together. > > > >The LPD-to-IPP gateway is easy to support with Job-Ids, so such a > >gateway, as a client of a IPP server, would use only the Job-Id and > >would ignore the Job-URL. > > > >So from a legacy point of view, the solution with both Job-URIs and Job-Ids > >is as good as the Job-Id solution only. > > > >But now we need to examine what this change means for server > >implementations. > > > >With this change servers would have a bit more work to do because they > >would have to offer two ways to do the same thing. Moreover, it is > >mandatory that if they support a particular operation, they must > >support both Job-URIs and Job-Id. That may be a burden that some > >implementors won't like -- more code for some abstract future payback. > > > >I expect that for most IPP servers its Job-URIs will always consists of > >its Printer-URI and a Job-Id so the server can easily convert between > >Job-URIs and Job-Ids with no architectural additions. > > > >But for servers that want the Job-URI to reference some remote host, > >the solution is more complicated because operations, such as > >Get-Attributes and Cancel-Job will go to the remote host when the > >client uses the Job-URI and these same operations will go to the > >Printer when the client uses the Printer-URI and Job-Id. Such servers > >will have to deal with forwarding issues and the fact that a Job-URI > >that references a remote host does not guarantee that all traffic goes > >there because client that use the Job-Id will still come to the original > >printer. > > > > > > > >As I said at the beginning of this email, I take no position on this > >proposal. Rather I offer it as the beginning of a discussion. > > > >I would like others to comment on whether this proposal solves the > >problem, or adds too much complexity to servers for the payback. > > > > > >Bob Herriot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa09753; 16 Sep 97 8: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 IAA08101 for ; Tue, 16 Sep 1997 08:19:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA13691 for ; Tue, 16 Sep 1997 08:15:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 08:07:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA13146 for ipp-outgoing; Tue, 16 Sep 1997 07:58:05 -0400 (EDT) From: don@lexmark.com Message-Id: <199709161157.AA02864@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 16 Sep 1997 07:47:09 -0400 Subject: IPP> ADM - Agenda for PWG IPP Meeting in Atlanta September 17-18, 1997 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Carl-Uno and all --- The telephone conference call is scheduled for 1PM Eastern (10AM Pacific) time. The agenda distributed (which I assume is in local time for the meeting location i.e. Eastern) stated 10 AM. We will have a full morning of agenda items before moving to the afternoon conference call and discussion on Job-URI, Job ID, etc. 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) * ********************************************** ---------------------- Forwarded by Don Wright on 09/16/97 07:44 AM --------------------------- carl%manros.com@interlock.lexmark.com 09/15/97 09:47 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) Subject: IPP> ADM - Agenda for PWG IPP Meeting in Atlanta September 17-18, 1997 A last minute Agenda, subject to discussion at the beginning of the meeting. Meeting times as usual 8:30 am - 6:00 pm both days. We will start off with Model & Semantics: - Start by checking which M & S details we want to spend time on in the meeting and which we should rule out as things for version 2. - At 10 am on September 17 we will hold the phone conference on Job URI vs. Printer URI + 32-bit ID. This will last until we have reached an agreement as this is now the most important issue to get resolved. - Other M + S subjects that come to mind are: - How do we register MIME types for document types? - Do we have the complete solution for asynchronous notifications? - Are we happy with the new Appendix E? - Do we have agreement about the security solution for M & S? - Any other issues that are open on Scott's list or that we agreed in the morning discussion to consider within the scope of Version 1? Suspecting that M & S will take all day on Wednesday, I expect to tackle the remaining subjects on Thursday: - Any remaining discussions on the Directory Schema document. - Fix up any remaining issues with the Protocol document (including security). - Review latest version of the Rationale document (if available). - Discuss the kind of changes we think are still needed for the Requirements document. - Discuss the LPR Mappinng document to see if we are agreed about the content. (This subject might be postponed if we run out of time). - Discuss Prototype interworking issues. It looks like we will have no difficulty to keep busy for the two days allocated. I look forward to see many of you in Atlanta and PLEASE make sure that you phone in for the phone conference on Wednesday morning if you want to express any views on JOB URI etc. The numbers as reminder: The phone number is 1-423-523-7162. The access code is 190148. The starting time is 1:00 pm Eastern, 10:00 am Pacific. Regards, Carl-Uno   Received: from cnri by ietf.org id aa15460; 16 Sep 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 KAA08647 for ; Tue, 16 Sep 1997 10:36:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15204 for ; Tue, 16 Sep 1997 10:33:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 10:28:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14673 for ipp-outgoing; Tue, 16 Sep 1997 10:19:04 -0400 (EDT) Message-Id: <9709161418.AA24283@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Sep 1997 07:16:08 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUES in 09/03 Model document Sender: ipp-owner@pwg.org Subj: Issues in the IPP Model document, version 05, dated 97/09/03. From: Tom Hastings Date: 97/09/15 File: iss-903.doc .txt These issues do not include editorial comments which I'll send to Scott and he can make judgements on as editor. These issues are comments that if not resolved, may result in different implementations not being able to interoperate. I have not included inconsistencies between the great issue of job-uri vs. job-id, since the document is half and half. I have not responded to the ISSUEs listed explicitly in the document either, since they will be covered at the meeting and on the mailine list. I have not included issues that I have aleady raised on the distribution list. Line numbers refer to the version without revisions. NOTE - Sections 3.1, 3.2, and 3.3 (and the new Appendix) go over the same operations. I've only mentioned issues encountered at the first occurrence of the problem. Usually, two or three of the sections will have to be fixed (unless we combine them somehow). 1. Section 3.1.4: Version - Need to make a distinction is made between major and minor version number. For interoperability purposes, minor version number discrepancies should not affect interoperation, while major version numbers are likely to. So a server should not reject a client that is suplying a high numbered minor version number, but might reject a higher major version number. 2. Section 3.1.5: The Printer MUST check that the supplied scheme is supported in Print-URI and Send-URI. Lets add that the Printer MUST at least check that the scheme is supported in the URI supplied by the client in the operation. 3. Section 3.1.5, and 3.3.1: The "document-name" attribute needs to be made MANDATORY, to go along with the "job-name" attribute, even for implementations that only implement Print-Job (not Create-Job/Send-Document). The "document-name" comes from the document or file name and should be generated automatically. The "job-name" is more likely to be generated by the end-user, though it can be generated automatically and may be the same as the "document-name" in such cases, though it need not be. Especially, when using print-by-reference, the document-name does not come from the end-user submitting the job. Such a user may only know the hot link or maybe the URL, but not the document name. 4. Section 3.2.1.1, Print-Job Request, line 695 and Section 4.2, Job Template Attributes, line 1069: The Printer SHALL only use its default attribute values, if the document data does not supply a corresponding instruction. 5. Section 3.2.1.2, Print-Job Response, line 731 and 3.3.1.2 Send-Document Response, line 911: If "ipp-attribute-fidelity" is FALSE, then the Printer returns ignored attributes, but there is no error. 6. Section 3.2.3, Validate-Job Operation, line 750: If "ipp-attribute-fidelity" is FALSE, then the Printer returns success, but with some indication of the ignored attributes. 7. Section 3.2.4 Create-Job operation, line 755: If the Printer supports Create-Job, then it MUST support Send-Document, and MAY OPTIONALLY support Send-URI, not one or the other or both. 8. Sectiion 3.2.5.1 Get-Attributes Request, line 793: Need to agree on the MIME-type that is the equivalent to the Printer enum 'langAutomatic'. Perhaps, either we should specify the existing: 'application/octet-stream' or register a new: 'application/automatic-pdl-sensing' MIME-type. 9. Section 3.3.1 Send-Document Operation, line 867 and line 887: Allow the client to send the last Send-Document with or without data (but always with a Data tag), so that a client application that doesn't know whether it has received the last file or not, need not look ahead. 10. Section 3.3.1 Send-Document Operation, line 879: Must the client always include the "last-document" boolean attribute in each Send-Document, or MAY the client omit it? If the client is allowed to omits it, SHALL the Printer interpret that as TRUE or FALSE? If the client MUST always supply it, what error SHALL the Printer return, if the client omits it? 11. Section 3.3.1.2 Send-Document Response, line 907: If the Printer supports the "job-state-message" attribute then the Printer MUST return it in a Create-Job or Send-Document (and Send-URI) response. Otherwise, the client that wants to get the "job-state-message", if supported by the Printer, has to query the Printer in case the Printer supports it, adding round trips and complication for the client. 12. Section 3.3.3.1 Cancel-Job Request: Why have an optional "message-to-operator" attribute? The specification doesn't have one at the moment. How does the Printer get the message to the operator? Why would the user want to send a message to the operator? Instead, change the attribute from "message" to "job-message-from-operator" which is already defined as a job description attribute. Require the Printer to accept this attribute in the Cancel-Job Request, if the Printer supports the "job-message-from-operator" job attribute. Allow the client to omit the "job-message-from-operator" attribute in the Cancel-Job Request. 13. Section 3.3.3.2 Cancel-Job Response: The "job-state-reasons" attribute should also contain the 'canceled-by-xxx' reason as well to be more clear when the response is returned, rather than delaying setting this reason until the job enters the 'canceled' state. 14. Section 3.3.4.2 Get-Attributes Response, line 970: If the client does not request a document attribute, then no document attributes are returned, correct? The only document attributes for V1.0 are 'document-uri" and "document-name". 15. Section 4.1 Attribute Syntaxes: The enum assignments should be changed to agree with the values that are in the Protocol Document. Then delete the assignments in the Protocol document. Its too hard to keep them aligned. For example, the Protocol document still has octet-string reserved, not assigned. 16. Section 4.1 Attribute Syntaxes: Also add the Delimiter Tag enum values as well to the Model document. We can't have the Protocol document talking about 'out of band' values that are not in the Model. 17. Section 4.1 Attribute Syntaxes: Should the enum values be given in decimal or hex? Usually, enums are given in decimal. The protocol document grouped the values into hex ranges and gave the values in hex. But ok to have ranges in groups of sixteen. 18. Section 4.1, 'resolution' attribute syntax description needs to speak of two 4 octet integers mapped Big Endian, with a 9th octet indicating the units. The "printer-resolution" attribute description (4.2.10) even has the order wrong with cross feed coming second! The "printer-resolution" attribute should not describe the format at all, but just depend on the description of the 'resolution' attribute syntax. 19. Section 4.1, '1setOf X' attribute syntax description should state that whether the values are ordered or not depends on the attribute semantics. 20. Section 4.1, 'rangeOf X' attribute syntax description needs to say whether the lower value is first or last, rather than not specifying so that either order would be conforming. I suggest that the order SHALL be lower value first, higher value last. 21. Section 4.2, Job Template Attributes table: Why can't "notify-addresses" have a default value? Enough authentication is being passed that a Printer could dynamically return a default notification-address, if supported. 22. Section 4.2, Job Template Attributes table: The attribute syntax for "printer-resolution" needs to be changed from 'enum' to 'resolution'. 23. Section 4.2, Job Template Attributes table: Why can't "compression" have a default value ('none' usually, but could have a particular value)? 24. Section 4.2.1 "job-sheets", line 1201: The Printer SHALL return an error only when the client supplies 'none' AND the client also supplies the "ipp-attribute-fidelity" attribute with a TRUE value. 25. Section 4.2.2.1 Event Notification Content: Looks good, but lets add "printer-state-message" as an optional field after printer-state-reason, since they all go together and may contain more detail from the interpreter than can be coded in reasons. 26. Section 4.2.2.1 Event Notification Content: What printable format is the time in? We should specify some printable format, possibly from a standard, though subject to localization. 27. Section 4.2.2.1 Event Notification Content: Needs to be the subject of localization. Simplest would be that it is subject to the localization (language and country) as specified for the submitting user in the create request. The coded character set should be changed from US-ASCII to UTF-8. 28. Section 4.2.6 "multple-document-handling" says that a client may specify that a slip sheet be placed between files a and b (two places). How does the client do that? Do we need to add a value to this attribute or to "job-sheets" attribute to specify slip sheets? 29. Section 4.2.8 "number-up": How about algorithmically specifying the values from 'one' to 'one-hundred', rather than requiring implementors to register this type 3 keyword with IANA? We could call it type 2 keyword. 30. Section 4.2.10 "printer-resolution": Rather than depending on the Printer MIB for the semantics, IPP should explain it. There has been a long standing confusion over the Printer MIB as to whether the single value was the current or the maximum resolution. We need to indicate that the value of the "printer-resolution" is the value requested by the client and the "printer-resolution-supported" is the set of values that the Printer= supports. =20 The first sentence needs to be changed from "This attribute identifies the resolution that Printer uses for a certain Job." to "This attribute identifies the resolution that the Printer SHALL use for the Job." The remainder can be deleted and depend on the semantics of the 'resolution' attribute syntax. 31. Section 4.2.11 "print-quality": Change the first sentence from "This attribute identifies the print quality that Printer uses for a certain Job." to "This attribute identifies the print quality that the Printer SHALL use for the Job." 32. Section 4.2.15 "orientation": Change to actual MIME-type equivalent of langSimpleText, by changing: (such as "text") to (such as 'text/plain') 33. Section 4.2.15 "orientation": Don't we need to specify the direction of rotation of the logical page (or imaged material) for landscape with respect to the media or coordinate system? Since the world is divided on this, don't we need to also provide 'reverse-landscape'? I suggest that we draw from the ISO DPA definition: landscape orientation is a rotation of the logical page image of +90 degrees (i.e., anti-clockwise) compared to portrait, so that binding on the long edge is the same physical edge of the medium for both portrait (on the =93left=94) and landscape (on the =93top=94). =20 However, some applications rotate landscape -90 degrees (i.e., clockwise) with respect to portrait, instead of +90 degrees (i.e., anti-clockwise). Therefore this International Standard provides both landscape and reverse-landscape, so that either semantics for landscape can be specified.= =20 The suggested defiitions would become: '1' 'portrait': The content will be imaged across the short edge of the= medium. '2' 'landscape': The content will be imaged across the long edge of the medium. Landscape is defined to be a rotation of the logical page to be imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from the portrait orientation. NOTE =96 The +90 direction was chosen because simple finishing on the long edge is the same edge whether portrait or landscape '3' 'reverse-landscape': The content will be imaged across the long edge of the medium. Reverse-landscape is defined to be a rotation of the logical page to be imaged by -90 degrees with respect to the medium (i.e. clockwise) from the portrait orientation. NOTE =96 The 'reverse-landscape' value was added because some applications rotate landscape -90 degrees from portrait, rather than +90 degrees.   Received: from cnri by ietf.org id aa21689; 16 Sep 97 13: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 NAA09533 for ; Tue, 16 Sep 1997 13:58:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA16013 for ; Tue, 16 Sep 1997 13:55:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 13:51:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15512 for ipp-outgoing; Tue, 16 Sep 1997 13:42:25 -0400 (EDT) Message-Id: <3.0.1.32.19970916101918.009bc7d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Sep 1997 10:19:18 PDT To: ietf-tls@consensus.com From: Carl-Uno Manros Subject: IPP> Any TLS prototypes or implementations yet? Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, Considering that the TLS spec is now in its final stages, I am asking on behalf of several Internet Printing Protocol (IPP) prototyping teams, whether there are any prototypes or emerging products for TLS that we could use in our IPP prototyping efforts. TLS is planned to be one of the security options for IPP. Carl-Uno Manros Co-chair IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com   Received: from cnri by ietf.org id aa23010; 16 Sep 97 14: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 OAA09732 for ; Tue, 16 Sep 1997 14:31:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16651 for ; Tue, 16 Sep 1997 14:28:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 14:23:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16123 for ipp-outgoing; Tue, 16 Sep 1997 14:14:49 -0400 (EDT) Date: Tue, 16 Sep 1997 11:16:23 -0700 (PDT) From: papowell@astart.com Message-Id: <199709161816.LAA05857@astart4.astart.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Sender: ipp-owner@pwg.org Note: As I have said, I think there is a separate issue of Printers and Spoolers for the IPP protocol. Gateways are EXPLICITLY spoolers. Now you can incorporate or try to incorporate spooler functionality into a printer, but you should note that the 'server' that everybody seems to be referring to is, to me, at least, a PRINTER server and not a SPOOLER server. > From rturner@sharplabs.com Mon Sep 15 19:48:18 1997 > Date: Mon, 15 Sep 1997 19:24:26 -0700 > From: Randy Turner > To: ipp@pwg.org > Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? > > I will try and emphasize my position on LPD gateways by saying that > I don't consider the LPD-to-IPP gateway case to be a common case > for gateways. As I have stated previously, it gives no value to > LPR/LPD clients to gateway to IPP because they are still > funneling(filtering) their requests through the same front end > interface. The kind of technology we are delivering for IPP version > 1.0 is oriented towards the user, so outfitting end users (clients) > with IPP as soon as possible should (IMHO) be the goal for deployment > of IPP. I disagree. I feel that LPD->IPP gateways will be needed for various compatibility reasons, as there are a very large number of folks out there who have LPR/LP type of implementations and want to get the services available with IPP type of control, but do not want to upgrade/change their printing mechanisms on ALL the hosts under their control. I might note that IPP Spoolers are currently not part of the IPP protocol, so we are simply having an academic discussion, right? > > Also, administrators should not be deinstalling their current base > of LPR/LPD services. IPP will supplement, not replace, LPD during > a transition phase. If I was to think about designing a spooler, I would start with a IPP spooler and then design in LPD to IPP translation. But this is a design decision. You could also have separate queues for each job (LPR/IPP) type as well. > > I do see a need for IPP-to-LPD gateways because IPP servers (operating > as spoolers on WinNT or Unix systems), might want to connect directly > to network printers using TCP/IP, and the most commonly deployed > embedded TCP/IP printing solution within printers is > LPD. While this is the most commonly 'deployed' method, I think that most folks would use the 'TCP/IP socket' to the print engine to transer jobs, especially if you wanted to emulate things like status information, etc. > We would like to include the existing installed base of > network printers in IPP configurations, but we don't want to have > to upgrade their firmware to do this. Therefore, allowing IPP > servers to transfer print jobs into the LPD environment is something > I think needs to happen. Dropping data and control files into LPD > spool directories from an IPP server is pretty easy on Unix systems. > I'm not positive about Windows/NT based LPD services but I would > imagiine that this is also fairly straightforward. > Been there, done, that. Trivial. > Also, concerning Roger's comment about delaying Job-URIs into > Version 2.0, I think > > the URI is one of the only really new features of network printing > we are offering and I would really like to see it available in > version 1.0; among other things, its the job URI that will allow > easy deployment and integration of IPP over other transports other > than HTTP, which is something I think we all are thinking about > for the future. > > Also, converning Patrick Powell's comments about the movement of > jobs using URIs, this feature is only one of the features that job > URI provides so we shouldn't focus on this one aspect of functionality > (even though we get it for free with the adoption of the URI concept, > and its not hard to envision its use regarding the movement of > jobs). > > Randy > > > > Tom Hastings wrote: > > > I too am trying to understand Bob's third alternative and do not have > > an opinion. > > > > However, there is a variation on Bob's third alternative that might be > > less of a burden on IPP servers, while providing the same benefit to > > supporting IPP under current APIs and in gateways. > > > > The idea is basically to have only job-uri as the access point for jobs, but > > require an additional attribute that a client can supply a 32-bit job > > id in and the server just stored it away. So instead of the client or > > gateway having to store the job-id > > to job-uri map, the map is stored in the IPP server. This solves the > > stale data problem, because the map information is kept as long as the > > job exists in the server and no longer. > > > > This approach is what ISO DPA has in its job-client-id attribute. > > > > This is the strategy that we are using in the IETF Job Monitoring MIB > > with the jmJobSubmissionID table which accepts any client id as an input > > index and returns the job-id that the server/agent is using. > > > > The only issue left is how does a client or gateway find a job > > with a particular job-id? > > > > There are two ways: > > > > One way would be to add the job-id as an optional input filter attribute to the > > Get-Jobs attribute which takes the Printer URI as input, not a JOB URI > > and the client would get back the job. This would put the burden on > > the server of being able to access jobs in two ways, but only on Get-Jobs > > which is a search anyway. > > > > The Get-Attributes operation would continue to require the job-uri. > > > > So a client could either: > > (1) cache the job-uri and use it for subsequent Get-Attributes or Cancel-Job > > (2) always use Get-Jobs operation to perform a Get-Attribtes for a particular > > job and use Get-Jobs operation first to get the job-uri in order to do the > > Job-Cancel. > > > > The other way, would be to put the burden completely on the client > > (by only mandating that the IPP server support the "job-client-id" 32-bit > > attribute and just passively store the attribute supplied by the client). > > > > Then the client must use a Get-Jobs with the > > "requested-attributes"='job-client-id,job-uri' and get all of the > > mapped pairs back and find the URI it needs to use in the IPP operation > > on a job: Get-Attribute or Cancel-Job. > > > > With either way, the map is kept in the IPP server. > > > > Comments? > > > > Tom > > > > At 08:53 09/09/97 PDT, Scott Isaacson wrote: > > >Bob did a good job at introducing and summarizing the issues associated with > > >the "open minded" idea of having both Job IDs and Job URIs. I am really > > >trying to have an open mind and think new thoughts, but my gut reaction and > > >continued perception (even after reading Bob's message) is that it is too > > >cumbersome, and not very elegant. It does not really solve the problems > > >unless we force ALL Printer implementation to support the passing in and > > >then passing back out of this helper attribute. That seems ok, but when > > >implementations must support operations either being addressed to a Printer > > >(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs > > >etc with both (J) and (P,s), that sounds very un-ok. > > > > > >Let's either fish or cut bait. > > > > > >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 > > >************************************************************ > > > > > >>>> Robert Herriot 09/05 5:59 PM >>> > > >It was suggested at the last teleconference that we should have both > > >Job-URIs and Job-Ids. This email looks at the pros and cons of that idea. > > > > > >I want to make it clear at the outset of this email, that I am not taking > > >a position on whether we should have both. Rather I want to explore what > > >the ramifications are if we have both. > > > > > >The following are what I think the characteristics of such a solution are. > > > > > >If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST > > >support both; otherwise, we are in worse shape than with just one of > > >them from all servers. Client MUST be free to use whichever they want. > > > > > >For Print-Job, it doesn't matter whether a client specifies whether it > > >wants a Job-URI or Job-ID, or whether the server returns both. In both > > >cases, the server has to deal with both and the client has to be aware > > >of the choice. So for this discussion, let's assume that the server > > >would return both. > > > > > >For Get-Attributes and Cancel-Job, a server must implement these > > >operations for both Job-URIs and Job-Ids. The target may be a Job-URI > > >or the target may be a Printer-URI with a Job-Id attribute. > > > > > >Both Job-URI and Job-Id attributes are mandatory. Thus a client can > > >query for either via Get-Jobs or Get-Attributes. > > > > > >The following discusses how this solution works with various gateways. > > >This solution works well in Win32 because it would use the Job-Id only. > > >It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways. > > > > > >The IPP-to-LPD gateways work well because the Job-Id and Job-URL > > >are both easy to support. So, acting as an IPP server, the gateway can > > >easily support both together. > > > > > >The LPD-to-IPP gateway is easy to support with Job-Ids, so such a > > >gateway, as a client of a IPP server, would use only the Job-Id and > > >would ignore the Job-URL. > > > > > >So from a legacy point of view, the solution with both Job-URIs and Job-Ids > > >is as good as the Job-Id solution only. > > > > > >But now we need to examine what this change means for server > > >implementations. > > > > > >With this change servers would have a bit more work to do because they > > >would have to offer two ways to do the same thing. Moreover, it is > > >mandatory that if they support a particular operation, they must > > >support both Job-URIs and Job-Id. That may be a burden that some > > >implementors won't like -- more code for some abstract future payback. > > > > > >I expect that for most IPP servers its Job-URIs will always consists of > > >its Printer-URI and a Job-Id so the server can easily convert between > > >Job-URIs and Job-Ids with no architectural additions. > > > > > >But for servers that want the Job-URI to reference some remote host, > > >the solution is more complicated because operations, such as > > >Get-Attributes and Cancel-Job will go to the remote host when the > > >client uses the Job-URI and these same operations will go to the > > >Printer when the client uses the Printer-URI and Job-Id. Such servers > > >will have to deal with forwarding issues and the fact that a Job-URI > > >that references a remote host does not guarantee that all traffic goes > > >there because client that use the Job-Id will still come to the original > > >printer. > > > > > > > > > > > >As I said at the beginning of this email, I take no position on this > > >proposal. Rather I offer it as the beginning of a discussion. > > > > > >I would like others to comment on whether this proposal solves the > > >problem, or adds too much complexity to servers for the payback. > > > > > > > > >Bob Herriot   Received: from cnri by ietf.org id aa26077; 16 Sep 97 16: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 QAA10331 for ; Tue, 16 Sep 1997 16:08:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA17321 for ; Tue, 16 Sep 1997 16:05:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 16:01:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16812 for ipp-outgoing; Tue, 16 Sep 1997 15:52:45 -0400 (EDT) Message-ID: <341EE2AA.6C8F6E9D@sharplabs.com> Date: Tue, 16 Sep 1997 12:48:59 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? References: <199709161816.LAA05857@astart4.astart.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org PAPowell said: >I disagree. I feel that LPD->IPP gateways will be needed for >various compatibility reasons, as there are a very large number of >folks out there who have LPR/LP type of implementations and want to >get the services available with IPP type of control, but do not want >to upgrade/change their printing mechanisms on ALL the hosts under >their control. You're going to find that mapping IPP semantics (control file, job reject codes, etc.) is going to be very difficult to do, especially given the diverse LPR/LPD environments. I think administrators would much rather transition to IPP than invest a large amount of time shoe-horning these users into the new environment. There current implementations are working fine, and I think we are only talking about Unix clients making up the bulk of these end users. The user interface available with unix-based LPR/LPD clients doesn't even handle the fact that a job can be refused for the vast majority of possible reasons that an IPP server might issue. The LPR interface only handles any errors dropping the file into the spool directory. The LPD daemon writes any errors into an administrative log file that must be looked at to determine if and why a job might not have printed. Its just not realistic to expect massive amounts of gateway code to be written for LPR/LPD clients, only to give them the ability to know whether their job can be printed (i.e., VALIDATE_JOB), which is the only feature of IPP that I could see LPR/LPD clients utilizing. The existing interface just doesn't allow any interactivity with the job submission process. LPR/LPD -to- IPP is not how I think IPP will be deployed; we need a rich user interface (GUI, http-capable, etc.) to really take advantage of what we are offering. Also the Windows print provider interface seems to also provide all of these capabilities to GUI-based windows clients. > I might note that IPP Spoolers are currently not part >of the IPP protocol, so we are simply having an academic discussion, >right? We haven't restricted IPP to either spoolers or print servers, and we shouldn't preclude either implementation. Randy (I hope my email messages are easy to read now, I re-configured my email client to not wrap all of my text)   Received: from cnri by ietf.org id aa28905; 16 Sep 97 17: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 RAA10839 for ; Tue, 16 Sep 1997 17:38:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17986 for ; Tue, 16 Sep 1997 17:35:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 17:31:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17489 for ipp-outgoing; Tue, 16 Sep 1997 17:22:15 -0400 (EDT) Date: Tue, 16 Sep 1997 14:24:03 -0700 (PDT) From: papowell@astart.com Message-Id: <199709162124.OAA09079@astart4.astart.com> To: ipp@pwg.org Subject: IPP> Teleconference Times and Dates Sender: ipp-owner@pwg.org When announcing a teleconference call, could you please put: DATE: (not just 'tomorrow' or the 'usual time', please) TIME: (and put the time zone please :-) Conference Call Number: Key or Passcode: Trouble Call Number: (Or the organization to call if you cannot get through) Organizer of Call: (So the organization can figure out who set up the call) I seem to be having more than the usual set of problems with teleconference calls. Patrick Powell   Received: from cnri by ietf.org id aa00329; 16 Sep 97 18: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 SAA11108 for ; Tue, 16 Sep 1997 18:35:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18632 for ; Tue, 16 Sep 1997 18:31:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 18:25:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18115 for ipp-outgoing; Tue, 16 Sep 1997 18:16:30 -0400 (EDT) Date: Tue, 16 Sep 1997 15:18:16 -0700 (PDT) From: papowell@astart.com Message-Id: <199709162218.PAA09291@astart4.astart.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Sender: ipp-owner@pwg.org > From rturner@sharplabs.com Tue Sep 16 13:09:05 1997 > Date: Tue, 16 Sep 1997 12:48:59 -0700 > From: Randy Turner > To: ipp@pwg.org > Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? > > > PAPowell said: > >I disagree. I feel that LPD->IPP gateways will be needed for > >various compatibility reasons, as there are a very large number of > >folks out there who have LPR/LP type of implementations and want to > >get the services available with IPP type of control, but do not want > >to upgrade/change their printing mechanisms on ALL the hosts under > >their control. > > You're going to find that mapping IPP semantics (control file, job reject codes, etc.) > is going to be very difficult to do, especially given the diverse LPR/LPD > environments. I think administrators would much rather transition to IPP than > invest a large amount of time shoe-horning these users into the new environment. > There current implementations are working fine, and I think we are only talking > about Unix clients making up the bulk of these end users. The user interface > available with unix-based LPR/LPD clients doesn't even handle the fact that > a job can be refused for the vast majority of possible reasons that an IPP server > might issue. The LPR interface only handles any errors dropping the file into the > spool directory. Ummm... that is not true. The LPRng interface quite happily delivers errors. And note that it is free, compiles and runs on just about any UNIX system with TCP/IP networking, and there is even an NT port (Don't ask, it wasn't pretty). > The LPD daemon writes any errors into an administrative log > file that must be looked at to determine if and why a job might not have printed. Not true. See the LPRng implementation. The error messages are stored on a 'per job' basis, and you can use LPQ to see the reasons for print failure. > Its just not realistic to expect massive amounts of gateway code to be written > for LPR/LPD clients, only to give them the ability to know whether their job > can be printed (i.e., VALIDATE_JOB), which is the only feature of IPP that > I could see LPR/LPD clients utilizing. The existing interface just doesn't allow > any interactivity with the job submission process. I don't think 'vast amounts' is the case. While I personally have not done it, collegues have indicated that the IPP protocol could be implemented in about 1500 lines of Perl, and could be backended into LPRng very simply. > > LPR/LPD -to- IPP is not how I think IPP will be deployed; we need a rich user > interface (GUI, http-capable, etc.) to really take advantage of what we are > offering. Also the Windows print provider interface seems to also provide all > of these capabilities to GUI-based windows clients. > > > I might note that IPP Spoolers are currently not part > >of the IPP protocol, so we are simply having an academic discussion, > >right? > > We haven't restricted IPP to either spoolers or print servers, and we shouldn't > preclude either implementation. > I think that if you start trying to deal with spoolers and spooler topics you are widening the scope of discussion far too much. I must say that I think that this is simply a matter of opinion. Somebody WILL implement a LPD to IPP gateway, somebody else (or the same person) WILL implement a IPP to LPD gateway. Now the problem is to see if you can get the gateways to interact correctly with IPP and LPD... Sigh... > Randy > (I hope my email messages are easy to read now, I re-configured my > email client to not wrap all of my text) I think that this type of discussion is need in the context of IPP. Patrick Powell   Received: from cnri by ietf.org id aa00560; 16 Sep 97 18: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 SAA11125 for ; Tue, 16 Sep 1997 18:45:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA19195 for ; Tue, 16 Sep 1997 18:42:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Sep 1997 18:38:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18317 for ipp-outgoing; Tue, 16 Sep 1997 18:26:59 -0400 (EDT) Message-ID: <341F06CF.50A548D6@sharplabs.com> Date: Tue, 16 Sep 1997 15:23:12 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? References: <199709162218.PAA09291@astart4.astart.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org PAPowell wrote: ..snip.. >The LPRng interface quite happily delivers errors. >And note that it is free, compiles and runs on just about any UNIX system >with TCP/IP networking, and there is even an NT port (Don't ask, it wasn't >pretty). The context of our LPR/LPD gateway has been constrained on the widely deployed version that come shipped with Sun, HP, IBM, and other Unix boxes, which is more or less based on RFC 1179 (with vendor extensions) and for which the line mode interface I was referring to is the predominant interface. I don't think any other implementation is worth considering at this point, given the amount of mapping we have to do just to this particular version. If we take on other shareware version of LPR/LPD, we could be here awhile; there are a bunch of 'em, for all platforms. Randy   Received: from cnri by ietf.org id aa23757; 17 Sep 97 2: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 CAA11794 for ; Wed, 17 Sep 1997 02:12:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA20521 for ; Wed, 17 Sep 1997 02:09:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Sep 1997 02:00:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA19973 for ipp-outgoing; Wed, 17 Sep 1997 01:50:56 -0400 (EDT) Message-Id: <9709170551.AA24693@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 1997 22:48:12 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUES: Contents of "document-format" attribute = MIME Content-type Header Field value Sender: ipp-owner@pwg.org 34. Section 4.2.16, "document-format": Need a reference to the spec for what can be included in the value of this attribute. I believe that the RFC is 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies" which has a more recent version. From RFC 1521, the value of the "document-format" is a "The Content-Type Header Field value". For example, in addition to the name of the MIME-type, such as 'application/postscript', or 'text/plain', the coded character set can also be specified as: 'text/plain; charset=us-ascii' or other coded character set names from the IANA coded character set registry. RFC 1521 requires the charset attribute, if the media type is text, else the coded character set shall be assumed to be us-ascii. We either need to re-state that, or require that the value for "document-format" SHALL conform to the requirements of a Content-Type Header Field value in RFC 1521 (or successor). An example would be very helpful. Being able to specify the coded character set for text formats is particularly important (since we don't have an attribute for it. Presumably the values of the "document-format-supported" Printer attribute would contain the various character sets supported for the 'text/plain' type, e.g., 'text/plain; charset=us-ascii', 'text/plain; charset=ISO-8859-1' 34a. Section 4.2.16, "document-format": We need to decide whether to restrict the values to a subset of what is allowed in Content-Type Header Field. For example, the seven standard types are: text, multi-part, messsage, image, audio, video, and application. Presumably, any could be supported, and since we have the "document-format-supported" Printer attribute, a client can determine which values are supported. However, what about the "Content-transfer-encoding" attribute, where different types of Content-transfer-encoding, where the values are: "7bit" ; case-insensitive / "quoted-printable" / "base64" / "8bit" / "binary" / "x-token and presumably utf-8 is a new one? Listing all supported combinations of media-type and coded character set makes sense. However, if they all can be supported with several content-transfer-encodings, then the number of values is the product of the number of each that are supported. Alternatively, we could add a separate Printer description attribute: "content-transfer-encodings" supported. What other capabilities of MIME content headers do we need to consider?   Received: from cnri by ietf.org id aa11795; 17 Sep 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 LAA13341 for ; Wed, 17 Sep 1997 11:40:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21881 for ; Wed, 17 Sep 1997 11:36:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Sep 1997 11:29:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21378 for ipp-outgoing; Wed, 17 Sep 1997 11:20:50 -0400 (EDT) Date: Wed, 17 Sep 1997 08:22:32 -0700 (PDT) From: papowell@astart.com Message-Id: <199709171522.IAA17514@astart4.astart.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? Sender: ipp-owner@pwg.org > From rturner@sharplabs.com Tue Sep 16 15:49:16 1997 > Date: Tue, 16 Sep 1997 15:23:12 -0700 > From: Randy Turner > To: ipp@pwg.org > Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs? > > PAPowell wrote: > ..snip.. > >The LPRng interface quite happily delivers errors. > >And note that it is free, compiles and runs on just about any UNIX system > >with TCP/IP networking, and there is even an NT port (Don't ask, it wasn't > >pretty). > > The context of our LPR/LPD gateway has been constrained on the widely > deployed version that come shipped with Sun, HP, IBM, and other Unix > boxes, which is more or less based on RFC 1179 (with vendor extensions) > and for which the line mode interface I was referring to is the predominant > interface. Are you saying that it will ONLY work with these versions and the vendor specific (and undocumented...) extensions? Or am I missing something here? Not trying to be sarcastic, just trying to find out the basic intent. Patrick   Received: from cnri by ietf.org id aa09164; 18 Sep 97 11: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 LAA16729 for ; Thu, 18 Sep 1997 11:29:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23712 for ; Thu, 18 Sep 1997 11:25:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Sep 1997 11:17:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23194 for ipp-outgoing; Thu, 18 Sep 1997 11:08:40 -0400 (EDT) Date: Thu, 18 Sep 1997 08:12:09 PDT From: Ira Mcdonald x10962 Message-Id: <9709181512.AA10736@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> RFC 2184 language tags for parameter values Sender: ipp-owner@pwg.org Hi Scott Isaacson, Thursday (18 September 1997) Per our IPP telecon yesterday, the new IETF MIME extension for parameter value language tags (RFC 2184, August 1997, N. Freed and K. Moore), is excerpted below. An asterisk ("*") is used at the END of a parameter 'name', to indicate that character set and/or language tags are present, at the BEGINNING of the parameter 'value', each delimited by a right single quote ("'"). Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ----------------------------- From RFC 2184 ---------------------------- Network Working Group N. Freed Request for Comments: 2184 Innosoft Updates: 2045, 2047, 2183 K. Moore Category: Standards Track University of Tennessee August 1997 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations [...] 1. Abstract This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide (1) a means to specify parameter values in character sets other than US-ASCII, (2) to specify the language to be used should the value be displayed, and (3) a continuation mechanism for long parameter values to avoid problems with header line wrapping. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [...] 4. Parameter Value Character Set and Language Information Some parameter values may need to be qualified with character set or language information. It is clear that a distinguished parameter name is needed to identify when this information is present along with a specific syntax for the information in the value itself. In addition, a lightweight encoding mechanism is needed to accomodate 8 bit information in parameter values. Asterisks ("*") are reused to provide the indicator that language and character set information is present and encoding is being used. A single quote ("'") is used to delimit the character set and language information at the beginning of the parameter value. Percent signs ("%") are used as the encoding flag, which agrees with RFC 2047. Specifically, an asterisk at the end of a parameter name acts as an indicator that character set and language information may appear at the beginning of the parameter value. A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal. For example: Content-Type: application/x-stuff; title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A Note that it is perfectly permissible to leave either the character set or language field blank. Note also that the single quote delimiters MUST be present even when one of the field values is omitted. This is done when either character set, language, or both are not relevant to the parameter value at hand. This MUST NOT be done in order to indicate a default character set or language -- parameter field definitions MUST NOT assign a default character set or lanugage. ----------------------------- From RFC 2184 ----------------------------   Received: from cnri by ietf.org id aa21596; 19 Sep 97 20: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 UAA21810 for ; Fri, 19 Sep 1997 20:24:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26404 for ; Fri, 19 Sep 1997 20:21:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Sep 1997 20:14:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25886 for ipp-outgoing; Fri, 19 Sep 1997 20:05:24 -0400 (EDT) Date: Fri, 19 Sep 1997 17:04:18 -0700 From: Robert Herriot Message-Id: <199709200004.RAA11181@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD encoding of language in string X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org At the Atlanta meeting, we decided to use the RFC 2184 mechanism for encoding language in text and names. I understood that the IPP solution would have an asterisk in the initial position of a string. But the RFC defines the asterisk as being the last character in the name. Having the asterisk in the name complicates the name search algorithm and we said that the language designator is mandatory, so the asterisk is unnecessary. What did we decide? Are the initial characters of all text and name strings: [charset] "'" [language] "'" From the syntax above, you can see that the RFC also describes a mechanism for encoding the character set. We should probably adopt that part of the syntax too, so we could use it to specify character set when we go past UTF-8. By the way, this RFC seemed familiar, it is because Tom Hastings sent a pointer to the draft version of this rfc on Nov. 7, 1996. It was draft-freed-pvcsc-01.txt. Bob Herriot   Received: from cnri by ietf.org id aa22869; 19 Sep 97 21: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 VAA21935 for ; Fri, 19 Sep 1997 21:58:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA27036 for ; Fri, 19 Sep 1997 21:55:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Sep 1997 21:50:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA26529 for ipp-outgoing; Fri, 19 Sep 1997 21:41:29 -0400 (EDT) Date: Fri, 19 Sep 1997 18:40:29 -0700 From: Robert Herriot Message-Id: <199709200140.SAA11256@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD document object problem for SendURI X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org We made a decision to eliminate all document attributes because we didn't want to design the mechanism for returning one attribute per document for version 1.0. I agree with that decision. But now I have realized that SendURI has to send a separate document-URI for each Send-URI operation which means there is a separate value of document-URI for each document. The following are possible solutions: 1) bad idea: solve the multiple-document-attribute problem 2) OK maybe: document-URI is an operation attribute that does not stick to the job object. That is, Get-Attributes does not return a document-URI created by a Send-URI operation. Get-Attributes could return a document-URI value set by Print-URI but it might seem strange that document-URI is available for Print-URI jobs but not Create-Job/ Send-URI jobs. 3) OK maybe: eliminate Send-URI in version 1.0, but keep Print-URI which doesn't have this problem. #3 is probably a little bit better than #2. Bob Herriot   Received: from cnri by ietf.org id aa01705; 20 Sep 97 0: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 AAA22121 for ; Sat, 20 Sep 1997 00:50:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA27752 for ; Sat, 20 Sep 1997 00:47:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Sep 1997 00:43:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA27254 for ipp-outgoing; Sat, 20 Sep 1997 00:34:07 -0400 (EDT) Message-Id: <3.0.1.32.19970919140715.009b9dd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Sep 1997 14:07:15 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> NT 5.0 beta Print Server Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Microsoft has just released a beta version of NT 5.0 server and client to subscribers. This version includes code which corresponds to the earlier Simple Web Printing proposal that Microsoft made to the IETF WG on IPP some months back. Do not interpret this as Microsoft trying to follow their own strategy and promoting a different way of doing things as in IPP. It is just a timing problem. You can expect to see some "real" IPP code in their next beta version. 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 aa06808; 20 Sep 97 11: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 LAA22568 for ; Sat, 20 Sep 1997 11:07:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA28705 for ; Sat, 20 Sep 1997 11:04:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Sep 1997 10:55:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA28186 for ipp-outgoing; Sat, 20 Sep 1997 10:46:38 -0400 (EDT) Date: Sat, 20 Sep 1997 07:50:04 PDT From: Ira Mcdonald x10962 Message-Id: <9709201450.AA11215@snorkel.eso.mc.xerox.com> To: Robert.Herriot@eng.sun.com, ipp@pwg.org Subject: Re: IPP>MOD encoding of language in string Sender: ipp-owner@pwg.org Hi Bob, I'm sorry to have misinformed the group during our telecon last week. Since IPP intends the language tag to ALWAYS be present for each 'text' or 'name' string, the asterisk at the END of the name parameter would be redundant. If we want to allow all strings which do NOT specify individual language tags to be in the 'job submission locale' (in the Job Mon MIB, but I think not currently an IPP attribute), then using the asterisk at the end of the parameter name (to tell a parser to look for an explicit language tag in the parameter value) would be a good idea. Second, yes, I think it would be a good idea to use the (empty) 'charset' tag (thus following RFC 2184 syntax exactly), so that systems which (by bilateral cooperation of client and server) can support other character sets than UTF-8-encoded ISO 10646 to use alternate character sets (this is an IMPORTANT point behind RFC 2184). Also, since the base 'charset' of HTTP is ISO 8859-1 (ISO Latin-1) and NOT US-ASCII or UTF-8, it seems like a good idea to preserve the ability to specify 'charset' tags. Cheers, - Ira McDonald High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------ Bob's note ----------------------------- From ipp-owner@pwg.org Fri Sep 19 20:26:03 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA11117; Fri, 19 Sep 97 20:26:02 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA20285; Fri, 19 Sep 97 20:22:05 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <54898(3)>; Fri, 19 Sep 1997 17:22:00 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26221 for ; Fri, 19 Sep 1997 20:18:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Sep 1997 20:14:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25886 for ipp-outgoing; Fri, 19 Sep 1997 20:05:24 -0400 (EDT) Date: Fri, 19 Sep 1997 17:04:18 PDT From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199709200004.RAA11181@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD encoding of language in string X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Status: R At the Atlanta meeting, we decided to use the RFC 2184 mechanism for encoding language in text and names. I understood that the IPP solution would have an asterisk in the initial position of a string. But the RFC defines the asterisk as being the last character in the name. Having the asterisk in the name complicates the name search algorithm and we said that the language designator is mandatory, so the asterisk is unnecessary. What did we decide? Are the initial characters of all text and name strings: [charset] "'" [language] "'" >From the syntax above, you can see that the RFC also describes a mechanism for encoding the character set. We should probably adopt that part of the syntax too, so we could use it to specify character set when we go past UTF-8. By the way, this RFC seemed familiar, it is because Tom Hastings sent a pointer to the draft version of this rfc on Nov. 7, 1996. It was draft-freed-pvcsc-01.txt. Bob Herriot   Received: from cnri by ietf.org id aa07078; 20 Sep 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 LAA22584 for ; Sat, 20 Sep 1997 11:22:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA29277 for ; Sat, 20 Sep 1997 11:18:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Sep 1997 11:13:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28742 for ipp-outgoing; Sat, 20 Sep 1997 11:04:33 -0400 (EDT) Date: Sat, 20 Sep 1997 08:08:10 PDT From: Ira Mcdonald x10962 Message-Id: <9709201508.AA11230@snorkel.eso.mc.xerox.com> To: Robert.Herriot@eng.sun.com, ipp@pwg.org Subject: Re: IPP>MOD document object problem for SendURI Sender: ipp-owner@pwg.org Hi Bob, I vote for your option #3 - dump Send-URI entirely from IPP 1.0. A little bit of document attributes is just as bad as lots. If we don't go with option #3, then we certainly won't get out 'stable' IPP specs by the end-of-September to the IETF. Cheers, - Ira McDonald (outside consultant at Xerox) ------------------------- Bob's note ----------------------- From ipp-owner@pwg.org Fri Sep 19 22:01:09 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA11123; Fri, 19 Sep 97 22:01:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA01012; Fri, 19 Sep 97 21:57:10 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <54288(1)>; Fri, 19 Sep 1997 18:57:12 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA26855 for ; Fri, 19 Sep 1997 21:53:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Sep 1997 21:50:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA26529 for ipp-outgoing; Fri, 19 Sep 1997 21:41:29 -0400 (EDT) Date: Fri, 19 Sep 1997 18:40:29 PDT From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199709200140.SAA11256@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD document object problem for SendURI X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Status: R We made a decision to eliminate all document attributes because we didn't want to design the mechanism for returning one attribute per document for version 1.0. I agree with that decision. But now I have realized that SendURI has to send a separate document-URI for each Send-URI operation which means there is a separate value of document-URI for each document. The following are possible solutions: 1) bad idea: solve the multiple-document-attribute problem 2) OK maybe: document-URI is an operation attribute that does not stick to the job object. That is, Get-Attributes does not return a document-URI created by a Send-URI operation. Get-Attributes could return a document-URI value set by Print-URI but it might seem strange that document-URI is available for Print-URI jobs but not Create-Job/ Send-URI jobs. 3) OK maybe: eliminate Send-URI in version 1.0, but keep Print-URI which doesn't have this problem. #3 is probably a little bit better than #2. Bob Herriot   Received: from cnri by ietf.org id aa08945; 20 Sep 97 13: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 NAA22718 for ; Sat, 20 Sep 1997 13:56:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29979 for ; Sat, 20 Sep 1997 13:53:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Sep 1997 13:49:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29489 for ipp-outgoing; Sat, 20 Sep 1997 13:40:04 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Document attributes Date: Sat, 20 Sep 1997 10:38:56 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I know we agreed not to have any document attributes but isn't "document-format-attribute" a document attribute? Randy   Received: from cnri by ietf.org id aa06453; 21 Sep 97 12: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 MAA23505 for ; Sun, 21 Sep 1997 12:14:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA01391 for ; Sun, 21 Sep 1997 12:11:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 21 Sep 1997 12:04:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00868 for ipp-outgoing; Sun, 21 Sep 1997 11:55:07 -0400 (EDT) Date: Sun, 21 Sep 1997 08:58:37 PDT From: Ira Mcdonald x10962 Message-Id: <9709211558.AA11426@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Document attributes Sender: ipp-owner@pwg.org Hi Randy, I think we agreed that JOBs could have descriptive attributes (either single- or multi-valued??) about the associated document(s), which apply unless (in a future version of IPP) they are overridden at the (future) DOCUMENT object level. I speculate that the following JOB level attributes are necessary or desirable in IPP 1.0: [job]document-name [job]document-URI (to support Send-URI) [job]document-format Cheers, - Ira McDonald (outside consultant at Xerox) High North In 906-494-2434 ------------------------------- Randy's note --------------- From ipp-owner@pwg.org Sat Sep 20 13:58:49 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA11312; Sat, 20 Sep 97 13:58:49 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA01334; Sat, 20 Sep 97 13:54:50 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <52883(5)>; Sat, 20 Sep 1997 10:54:53 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29820 for ; Sat, 20 Sep 1997 13:51:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Sep 1997 13:49:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29489 for ipp-outgoing; Sat, 20 Sep 1997 13:40:04 -0400 (EDT) Message-Id: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Document attributes Date: Sat, 20 Sep 1997 10:38:56 PDT X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Status: R I know we agreed not to have any document attributes but isn't "document-format-attribute" a document attribute? Randy   Received: from cnri by ietf.org id aa06898; 21 Sep 97 12: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 MAA23539 for ; Sun, 21 Sep 1997 12:55:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA01985 for ; Sun, 21 Sep 1997 12:52:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 21 Sep 1997 12:49:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01487 for ipp-outgoing; Sun, 21 Sep 1997 12:40:06 -0400 (EDT) Message-ID: <34254D01.55FD7949@sharplabs.com> Date: Sun, 21 Sep 1997 09:36:17 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Document attributes References: <9709211558.AA11426@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Ok, so we have these actual document attributes that we could admittedly move into "job document attributes" just to save us the work this time of actually doing the work to support document attributes. This might be problematic for future implementations that actually *DO* the document attribute model correctly, having to be backward-compatible with our "hacked" version of document attributes of IPP 1.0. I thought maybe we could allow a placeholder in the model/protocol for V 1.0 for document attributes, so that we could easily integrate this in the future with very little work. Concerning the "job-document-attribute" proposal... I'm assuming that the send-document operation allows these "job-document" attributes to be included (I can't remember the send-document specifics from the model document...). Randy Ira Mcdonald x10962 wrote: > Hi Randy, > > I think we agreed that JOBs could have descriptive attributes > (either single- or multi-valued??) about the associated > document(s), which apply unless (in a future version of IPP) > they are overridden at the (future) DOCUMENT object level. > > I speculate that the following JOB level attributes are > necessary or desirable in IPP 1.0: > > [job]document-name > [job]document-URI (to support Send-URI) > [job]document-format > > Cheers, > - Ira McDonald (outside consultant at Xerox) > High North In > 906-494-2434   Received: from cnri by ietf.org id aa24748; 22 Sep 97 18: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 SAA27046 for ; Mon, 22 Sep 1997 18:50:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03785 for ; Mon, 22 Sep 1997 18:47:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 18:41:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03243 for jmp-outgoing; Mon, 22 Sep 1997 18:37:15 -0400 (EDT) From: Harry Lewis To: fin@pwg.org, p1394@pwg.org, ipp@pwg.org, jmp@pwg.org, pwg@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: JMP> October PING Message-ID: <5030300010927829000002L092*@MHS> Date: Mon, 22 Sep 1997 18:42:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Since Don will not be able to make the October meeting, please PING me (Harry Lewis) at harryl@us.ibm.com regarding your attendance to the October meeting in Boulder. Please let me know the meetings your will attend (p1394 Monday/Tuesday; IPP Wednesday/Thursday; and JMP/FIN Friday), and whether or not you are staying at the Boulderado. Please remember to make your reservations at the Boulderado before 10/3! October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Harry Lewis - IBM Printing Systems   Received: from cnri by ietf.org id aa24914; 22 Sep 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 TAA27078 for ; Mon, 22 Sep 1997 19:00:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04363 for ; Mon, 22 Sep 1997 18:57:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 18:46:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03292 for pwg-outgoing; Mon, 22 Sep 1997 18:38:42 -0400 (EDT) From: Harry Lewis To: fin@pwg.org, p1394@pwg.org, ipp@pwg.org, jmp@pwg.org, pwg@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: PWG> October PING Message-ID: <5030300010927829000002L092*@MHS> Date: Mon, 22 Sep 1997 18:42:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Since Don will not be able to make the October meeting, please PING me (Harry Lewis) at harryl@us.ibm.com regarding your attendance to the October meeting in Boulder. Please let me know the meetings your will attend (p1394 Monday/Tuesday; IPP Wednesday/Thursday; and JMP/FIN Friday), and whether or not you are staying at the Boulderado. Please remember to make your reservations at the Boulderado before 10/3! October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Harry Lewis - IBM Printing Systems   Received: from cnri by ietf.org id aa25087; 22 Sep 97 19: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 TAA27109 for ; Mon, 22 Sep 1997 19:11:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA04843 for ; Mon, 22 Sep 1997 19:08:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 18:55:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03198 for ipp-outgoing; Mon, 22 Sep 1997 18:30:20 -0400 (EDT) Date: Mon, 22 Sep 1997 15:27:05 -0700 From: Robert Herriot Message-Id: <199709222227.PAA14018@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Document attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that we agreed not to decide on the format of attributes that have a separate value for each document by eliminating document-name, and stating that all documents in a job have the same document-format, meaning that document-format is a job-level attribute. Document-URI is still a problem unless either we eliminate Send-URI (my preference) or eliminate document-URI as a job attribute until a later version. Although we previously decided not design a format for per-document attributes until a later version, I pointed out that an attribute 'foo' could take on a "dictionary" value whose values might be "default=XYZ" and "3=ABC" to indicate that the job level 'foo' attribute has a value of "XYZ" and document-3 has a value of "ABC". Such a solution is not precluded by the current design. Bob Herriot > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997 > > Ok, so we have these actual document attributes that we could admittedly move > into "job document attributes" just to save us the work this time of actually doing > the work to support document attributes. This might be > problematic for future implementations that actually *DO* the > document attribute model correctly, having to be backward-compatible > with our "hacked" version of document attributes of IPP 1.0. > > I thought maybe we could allow a placeholder in the model/protocol for > V 1.0 for document attributes, so that we could easily integrate this in > the future with very little work. > > Concerning the "job-document-attribute" proposal... > I'm assuming that the send-document operation allows these "job-document" > attributes to be included (I can't remember the send-document specifics from the > model document...). > > Randy > > Ira Mcdonald x10962 wrote: > > > Hi Randy, > > > > I think we agreed that JOBs could have descriptive attributes > > (either single- or multi-valued??) about the associated > > document(s), which apply unless (in a future version of IPP) > > they are overridden at the (future) DOCUMENT object level. > > > > I speculate that the following JOB level attributes are > > necessary or desirable in IPP 1.0: > > > > [job]document-name > > [job]document-URI (to support Send-URI) > > [job]document-format > > > > Cheers, > > - Ira McDonald (outside consultant at Xerox) > > High North In > > 906-494-2434 > > > >   Received: from cnri by ietf.org id aa25247; 22 Sep 97 19: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 TAA27125 for ; Mon, 22 Sep 1997 19:19:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05899 for ; Mon, 22 Sep 1997 19:16:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 19:09:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03232 for ipp-outgoing; Mon, 22 Sep 1997 18:35:45 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Document attributes Date: Mon, 22 Sep 1997 15:34:30 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Does this seem kind of limiting, to restrict all documents in a particular job to have the same document format? It doesn't seem hard to imagine a 2-document job wherein one file is PCL and another Postscript. If the document attribute says "application/vnd.pcl" then the printer would probably trash the 2nd Postscript job. Just checking to see if we haven't got a hole in this somewhere.... Randy > -----Original Message----- > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > Sent: Monday, September 22, 1997 3:27 PM > To: ipp@pwg.org; rturner@sharplabs.com > Subject: Re: IPP> Document attributes > > I think that we agreed not to decide on the format of attributes that > have a separate value for each document by eliminating document-name, > and stating that all documents in a job have the same document-format, > meaning that document-format is a job-level attribute. > > Document-URI is still a problem unless either we eliminate Send-URI > (my > preference) or eliminate document-URI as a job attribute until a later > version. > > Although we previously decided not design a format for per-document > attributes until a later version, I pointed out that an attribute > 'foo' > could take on a "dictionary" value whose values might be "default=XYZ" > and "3=ABC" to indicate that the job level 'foo' attribute has a value > of "XYZ" and document-3 has a value of "ABC". Such a solution is not > precluded by the current design. > > Bob Herriot > > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997 > > > > Ok, so we have these actual document attributes that we could > admittedly move > > into "job document attributes" just to save us the work this time of > actually doing > > the work to support document attributes. This might be > > problematic for future implementations that actually *DO* the > > document attribute model correctly, having to be backward-compatible > > with our "hacked" version of document attributes of IPP 1.0. > > > > I thought maybe we could allow a placeholder in the model/protocol > for > > V 1.0 for document attributes, so that we could easily integrate > this in > > the future with very little work. > > > > Concerning the "job-document-attribute" proposal... > > I'm assuming that the send-document operation allows these > "job-document" > > attributes to be included (I can't remember the send-document > specifics from the > > model document...). > > > > Randy > > > > Ira Mcdonald x10962 wrote: > > > > > Hi Randy, > > > > > > I think we agreed that JOBs could have descriptive attributes > > > (either single- or multi-valued??) about the associated > > > document(s), which apply unless (in a future version of IPP) > > > they are overridden at the (future) DOCUMENT object level. > > > > > > I speculate that the following JOB level attributes are > > > necessary or desirable in IPP 1.0: > > > > > > [job]document-name > > > [job]document-URI (to support Send-URI) > > > [job]document-format > > > > > > Cheers, > > > - Ira McDonald (outside consultant at Xerox) > > > High North In > > > 906-494-2434 > > > > > > > >   Received: from cnri by ietf.org id aa25256; 22 Sep 97 19: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 TAA27131 for ; Mon, 22 Sep 1997 19:20:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05961 for ; Mon, 22 Sep 1997 19:17:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 19:10:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03251 for ipp-outgoing; Mon, 22 Sep 1997 18:37:33 -0400 (EDT) From: Harry Lewis To: fin@pwg.org, p1394@pwg.org, ipp@pwg.org, jmp@pwg.org, pwg@pwg.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: IPP> October PING Message-ID: <5030300010927829000002L092*@MHS> Date: Mon, 22 Sep 1997 18:42:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Since Don will not be able to make the October meeting, please PING me (Harry Lewis) at harryl@us.ibm.com regarding your attendance to the October meeting in Boulder. Please let me know the meetings your will attend (p1394 Monday/Tuesday; IPP Wednesday/Thursday; and JMP/FIN Friday), and whether or not you are staying at the Boulderado. Please remember to make your reservations at the Boulderado before 10/3! October 27-31 "Hotel Boulderado" 2115 13th St. Boulder, CO 80302 Phone - (303) 442-4344 Fax - (303) 443-7035 Reservations - 1-800-433-4344 Deadline: October 3rd. Rates - $104 (Standard - 1 Queen bed) $114 (Deluxe - 2 Queen or 1 King) Harry Lewis - IBM Printing Systems   Received: from cnri by ietf.org id aa25589; 22 Sep 97 19: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 TAA27193 for ; Mon, 22 Sep 1997 19:49:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06630 for ; Mon, 22 Sep 1997 19:45:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 19:41:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA06110 for ipp-outgoing; Mon, 22 Sep 1997 19:32:39 -0400 (EDT) Date: Mon, 22 Sep 1997 16:31:33 -0700 From: Robert Herriot Message-Id: <199709222331.QAA14105@woden.eng.sun.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: RE: IPP> Document attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org This is a version 1.0 limitation. But I doubt it will cause much hardship because currently: 1) Windows users can only send one document per job. 2) Solaris users can send multiple documents per job, but they must all have the same format, despite the generality of the LPD protocol. I think that most if not all other Unix systems have the same limitation. So that doesn't leave very many people with the capability that we are removing from version 1.0. Bob Herriot > From rturner@sharplabs.com Mon Sep 22 16:12:02 1997 > From: "Turner, Randy" > To: "'ipp@pwg.org'" > Subject: RE: IPP> Document attributes > Date: Mon, 22 Sep 1997 15:34:30 -0700 > X-Priority: 3 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.0.1458.49) > Sender: ipp-owner@pwg.org > X-Lines: 90 > > > Does this seem kind of limiting, to restrict all documents in a > particular job to have the same document format? It doesn't > seem hard to imagine a 2-document job wherein one file > is PCL and another Postscript. If the document attribute > says "application/vnd.pcl" then the printer would probably > trash the 2nd Postscript job. > > Just checking to see if we haven't got a hole in this > somewhere.... > > Randy > > > > -----Original Message----- > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > Sent: Monday, September 22, 1997 3:27 PM > > To: ipp@pwg.org; rturner@sharplabs.com > > Subject: Re: IPP> Document attributes > > > > I think that we agreed not to decide on the format of attributes that > > have a separate value for each document by eliminating document-name, > > and stating that all documents in a job have the same document-format, > > meaning that document-format is a job-level attribute. > > > > Document-URI is still a problem unless either we eliminate Send-URI > > (my > > preference) or eliminate document-URI as a job attribute until a later > > version. > > > > Although we previously decided not design a format for per-document > > attributes until a later version, I pointed out that an attribute > > 'foo' > > could take on a "dictionary" value whose values might be "default=XYZ" > > and "3=ABC" to indicate that the job level 'foo' attribute has a value > > of "XYZ" and document-3 has a value of "ABC". Such a solution is not > > precluded by the current design. > > > > Bob Herriot > > > > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997 > > > > > > Ok, so we have these actual document attributes that we could > > admittedly move > > > into "job document attributes" just to save us the work this time of > > actually doing > > > the work to support document attributes. This might be > > > problematic for future implementations that actually *DO* the > > > document attribute model correctly, having to be backward-compatible > > > with our "hacked" version of document attributes of IPP 1.0. > > > > > > I thought maybe we could allow a placeholder in the model/protocol > > for > > > V 1.0 for document attributes, so that we could easily integrate > > this in > > > the future with very little work. > > > > > > Concerning the "job-document-attribute" proposal... > > > I'm assuming that the send-document operation allows these > > "job-document" > > > attributes to be included (I can't remember the send-document > > specifics from the > > > model document...). > > > > > > Randy > > > > > > Ira Mcdonald x10962 wrote: > > > > > > > Hi Randy, > > > > > > > > I think we agreed that JOBs could have descriptive attributes > > > > (either single- or multi-valued??) about the associated > > > > document(s), which apply unless (in a future version of IPP) > > > > they are overridden at the (future) DOCUMENT object level. > > > > > > > > I speculate that the following JOB level attributes are > > > > necessary or desirable in IPP 1.0: > > > > > > > > [job]document-name > > > > [job]document-URI (to support Send-URI) > > > > [job]document-format > > > > > > > > Cheers, > > > > - Ira McDonald (outside consultant at Xerox) > > > > High North In > > > > 906-494-2434 > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa25996; 22 Sep 97 20: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 UAA27242 for ; Mon, 22 Sep 1997 20:19:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA07246 for ; Mon, 22 Sep 1997 20:16:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 20:12:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06728 for ipp-outgoing; Mon, 22 Sep 1997 20:03:01 -0400 (EDT) Message-ID: <342706F5.EE907004@underscore.com> Date: Mon, 22 Sep 1997 20:01:57 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Document attributes References: <199709222331.QAA14105@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob, Sorry, but there are *lots* of Unix systems that can accept jobs having documents with multiple data formats. Patrick Powell: can you comment on this? Whether having this feature is a "hard core" requirement for the Unix world has yet to be determined. However, prior to the IPP group being formed, several members of the PWG had often described the scenario in which a job consisted of multiple files, where the first file was a pre-built banner page (most often in PostScript), and one or more data files that are *not* PostScript. It sure seems like we should be able to support that kind of scenario, shouldn't we? ...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 -- ---------------------------------------------------------------------- Robert Herriot wrote: > > This is a version 1.0 limitation. But I doubt it will cause much > hardship because currently: > > 1) Windows users can only send one document per job. > 2) Solaris users can send multiple documents per job, but they > must all have the same format, despite the generality of the LPD > protocol. I think that most if not all other Unix systems have > the same limitation. > > So that doesn't leave very many people with the capability that we > are removing from version 1.0. > > Bob Herriot > > > From rturner@sharplabs.com Mon Sep 22 16:12:02 1997 > > From: "Turner, Randy" > > To: "'ipp@pwg.org'" > > Subject: RE: IPP> Document attributes > > Date: Mon, 22 Sep 1997 15:34:30 -0700 > > X-Priority: 3 > > MIME-Version: 1.0 > > X-Mailer: Internet Mail Service (5.0.1458.49) > > Sender: ipp-owner@pwg.org > > X-Lines: 90 > > > > > > Does this seem kind of limiting, to restrict all documents in a > > particular job to have the same document format? It doesn't > > seem hard to imagine a 2-document job wherein one file > > is PCL and another Postscript. If the document attribute > > says "application/vnd.pcl" then the printer would probably > > trash the 2nd Postscript job. > > > > Just checking to see if we haven't got a hole in this > > somewhere.... > > > > Randy > > > > > > > -----Original Message----- > > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > > Sent: Monday, September 22, 1997 3:27 PM > > > To: ipp@pwg.org; rturner@sharplabs.com > > > Subject: Re: IPP> Document attributes > > > > > > I think that we agreed not to decide on the format of attributes that > > > have a separate value for each document by eliminating document-name, > > > and stating that all documents in a job have the same document-format, > > > meaning that document-format is a job-level attribute. > > > > > > Document-URI is still a problem unless either we eliminate Send-URI > > > (my > > > preference) or eliminate document-URI as a job attribute until a later > > > version. > > > > > > Although we previously decided not design a format for per-document > > > attributes until a later version, I pointed out that an attribute > > > 'foo' > > > could take on a "dictionary" value whose values might be "default=XYZ" > > > and "3=ABC" to indicate that the job level 'foo' attribute has a value > > > of "XYZ" and document-3 has a value of "ABC". Such a solution is not > > > precluded by the current design. > > > > > > Bob Herriot > > > > > > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997 > > > > > > > > Ok, so we have these actual document attributes that we could > > > admittedly move > > > > into "job document attributes" just to save us the work this time of > > > actually doing > > > > the work to support document attributes. This might be > > > > problematic for future implementations that actually *DO* the > > > > document attribute model correctly, having to be backward-compatible > > > > with our "hacked" version of document attributes of IPP 1.0. > > > > > > > > I thought maybe we could allow a placeholder in the model/protocol > > > for > > > > V 1.0 for document attributes, so that we could easily integrate > > > this in > > > > the future with very little work. > > > > > > > > Concerning the "job-document-attribute" proposal... > > > > I'm assuming that the send-document operation allows these > > > "job-document" > > > > attributes to be included (I can't remember the send-document > > > specifics from the > > > > model document...). > > > > > > > > Randy > > > > > > > > Ira Mcdonald x10962 wrote: > > > > > > > > > Hi Randy, > > > > > > > > > > I think we agreed that JOBs could have descriptive attributes > > > > > (either single- or multi-valued??) about the associated > > > > > document(s), which apply unless (in a future version of IPP) > > > > > they are overridden at the (future) DOCUMENT object level. > > > > > > > > > > I speculate that the following JOB level attributes are > > > > > necessary or desirable in IPP 1.0: > > > > > > > > > > [job]document-name > > > > > [job]document-URI (to support Send-URI) > > > > > [job]document-format > > > > > > > > > > Cheers, > > > > > - Ira McDonald (outside consultant at Xerox) > > > > > High North In > > > > > 906-494-2434 > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa27067; 22 Sep 97 21: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 VAA27361 for ; Mon, 22 Sep 1997 21:51:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07916 for ; Mon, 22 Sep 1997 21:48:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 21:44:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07421 for ipp-outgoing; Mon, 22 Sep 1997 21:35:08 -0400 (EDT) Message-Id: <3.0.1.32.19970922182210.00c3f3b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 22 Sep 1997 18:22:10 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Conference Call 970924 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, these are subjects that I expect to get discussion on in this week's call: 1) We still seem to have some disagreement what the consequences of dropping all document attributes mean. 2) Do we have any comments on the minutes from Atlanta (not out yet, but will hopefully be out before Wednesday). 3) How is the editing work shaping up? Are we still on track to go for last call at the end of September? 4) Any further news about the joint prototyping efforts? 5) The IETF has sent out a note about reserving WG sessions for the next IETF meeting. Will we be done by then, or will we need a session e.g. to discuss the LPR mapping document? The numbers as reminder: The phone number is 1-423-523-7162. The access code is 190148. 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 aa04950; 22 Sep 97 23: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 XAA27519 for ; Mon, 22 Sep 1997 23:33:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08778 for ; Mon, 22 Sep 1997 23:29:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Sep 1997 23:25:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08256 for ipp-outgoing; Mon, 22 Sep 1997 23:16:31 -0400 (EDT) From: don@lexmark.com Message-Id: <199709230315.AA05569@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: cmanros@cp10.es.xerox.com Cc: Ipp@pwg.org Date: Mon, 22 Sep 1997 23:09:40 -0400 Subject: Re: IPP> ADM - Agenda for PWG IPP Conference Call 970924 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org ... > >2) Do we have any comments on the minutes from Atlanta (not out yet, but >will hopefully be out before Wednesday). Likely. >3) How is the editing work shaping up? Are we still on track to go for >last call at the end of September? I have received no specific areas (other than security) that need to be changed in the Requirements Document. I'd say the chances of publishing a new version are 50-50 for September 30th. 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 aa05746; 23 Sep 97 0: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 AAA27548 for ; Tue, 23 Sep 1997 00:09:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA09446 for ; Tue, 23 Sep 1997 00:06:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 00:01:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08925 for ipp-outgoing; Mon, 22 Sep 1997 23:52:00 -0400 (EDT) From: don@lexmark.com Message-Id: <199709230351.AA06237@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 22 Sep 1997 23:45:18 -0400 Subject: IPP> September Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the meeting minutes from the Spetember Meeting in Atlanta. I have also posted these to the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.pdf 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) * ********************************************** ------ Minutes ------------------------------------------------------------- Internet Printing Project Meeting Minutes September 17-18, 1997 Atlanta, GA The meeting started on September 17, 1997 at 8:40 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: * Randy Turner - Sharp * Ron Bergman - DataProducts * Xavier Riley - Xerox * Peter Zehler - Xerox * Lee Farrell - Canon * Yuji Sasaki - Japan Computer Industry * Philip Thambidurai - Okidata * Bob Pentecost - HP * Rick Landau - Digital * Richard Hart - Digital * Lloyd Young - Lexmark * Dale Wick - TrueSpectra * Bill Wagner - DPI/Osicom * Jeff Van Wie - Kodak * Bob Herriot - Sun * Don Wright - Lexmark * Harry Lewis - IBM * Steve Zilles - Adobe * Mabrey Dozier - QMS * Roger deBry - IBM * Tom Hastings - Xerox * Scott Isaacson - Novell * Carl-Uno Manros - Xerox Carl-Uno Manros reviewed the agenda for the two days. Scott Isaacson reviewed the decision from the last conference call to stop adding functionality and hold additions for a version 2.0. At that call, we decided not to make any of the job template attributes also document attributes. Additionally, IPP V1 will have NO ATTRIBUTES for documents including no longer having a document name. Scott went through his list of issues which were posted to the FTP server (ftp://ftp.pwg.org/ipp/new_MOD/issues- 970916.pdf). 1) Cancel semantics: trailing edge, new job-state reasons from Tom Hastings. 2) Global: MUST, SHOULD, SHALL editor will fix 3) Global: Directory document will become an appendix to the model document 4) Global: URI versus URL: leave as URIs. We will include a requirement that the printer must support an http scheme URL. If notification is supported then you must support at least the mailto scheme. 5) Get-Jobs operation: What order are jobs returned? There were a number of arguments on both sides of this issue. Not all OS's return jobs in the same order. The document will state that pending jobs SHALL be returned in the expected order of execution. Completed jobs SHALL be returned with the most recently completed jobs returned first. A enum attribute will be added to specify whether the request is for pending or completed jobs. Pending Held jobs are be included as active jobs. Where they are included in the list is implementation dependent. 6) References to Printer MIB and Job Monitoring MIB: We will include references to these documents but not indicate whether they are I-Ds or not. 7) Attribute Syntax: Text attributes are specified as 1 to 4095 characters. Anything that might be expected to be exported to a MIB would need to be up to 255. -- Leave as it is. 8) URL versus URI - see #4 above. 9) Attribute Syntax - date/time - reference the correct RFC - Scott will do this. 10) Job Template Attributes: Job Priority - All implementations must accept on the wire values of 1 to 100 and map them evenly to the internal priority levels. An administrator can limit the range a particular user can assign to his job. (100 is the highest priority.) How a UI maps from the user to the wire is outside the scope of this effort. Scott will write it up in the document as described here. 11) Event Notification Content: Job-State Message and Printer-State Message will be UTF-8 encoded ISO10646 characters in the human language negotiated. 12) Document Format: Change "mimeType" to "MediaType" and reference RFC2046. 13) user-human-language: should be renamed to job-user- human-language? - No - This is a job template attribute which we currently plan to use information from the HTTP headers (general or application/IPP?) to set this value. Steve Zilles will write this up for inclusion in the model document. printer-name: need not be translated (set by admin) printer-location: need not be translated (set by admin) printer-description: need not be translated (set by admin) printer-make-and-model: should be translated (set by mfg) printer-state-message: translated (computed) job-name: not translated (set by user) job-state-message: translated (computed) job-message-from-operator: need not be translated (set by oper) The typical internationalization religious discussion ensued. Scott will update the model document to change the definition of attribute syntax type text and name to include a "language tag" (RFC2184) to precede the actual body of the text returned. This is for both server and client created text and names. The client will be able to ask for a certain language from the server using the accept header from HTTP. Implementations may need to remember the language request so that notification or an event is returned in the requested language. 14) time-since-pending/processing/completed -- perform the editing change suggested and time will be in seconds and not ticks. Lunch Break: 11:30 - 1:00 Job-URI versus Job-id At 1:00 we began the conference call to discuss the issues of Job-URI versus Job-ID issue. Some of the issues were listed: 1) Existing, job-id oriented APIs 2) Potential Object-oriented APO 3) Gateways - IPP client <-> legacy system - Legacy client <-> IPP Printer 4) Redirection 5) Scalability 6) "Helper" Attribute could return the numeric job id The issue of the value of being able to see jobs submitted via some legacy means as well as IPP submitted jobs using IPP was discussed. Some participants felt that it is necessary to expose all jobs submitted from any means while others believed that this need was only temporary until clients moved to IPP from the legacy environment. How do we resolve the difference between the way the Job MIB reports jobs versus a Job-URI? Since the Job MIB provides more information such as which page of the current job is printing, a client might want to use the Job MIB to get these details that are not available using IPP. How do you correlate the Job-URI with the JOB ID? We could add an attribute to the JOB MIB that would be the JOB-URI -- Hastings We could mandate a job id to be a part of the Job-URI using some delimiters - P. Moore For the cancel job case, the client must know how to build the URI for the job if the URI is not retained just the numeric job id - P. Moore What if we provided two ways to identify the job: 1) job-URI 2) Printer-URI plus job-id job-URI Discussion Conclusion: All IPP printers shall generate, store (with the job information) and return both the job-URI and a 32-bit job-id on Print-Job, Print-URI or Create-Job. It will accept all job operations (cancel-job, send-document, send-uri, and get-attributes) on either the job-URI or on the Printer-URI plus the job-id. Clients can utilize either method, i.e. they can reference a job using the job-URI or the Printer- URI plus the job-id. IDs are only meaningful in the context of the Printer-URI to which it was originally submitted. Get-Jobs will have to return both job-URI and job-ID as the default. Scott will write this up in the model document. If an "IPP printer" also implements the Job MIB, then the job-id will be the same between the MIB and IPP. - After the conclusion of the job-URI discussion, we reviewed some of the directions set during the morning session with those on the conference call. - While the conference call was still open, we discussed the use of a port besides 80. It was the consensus that we would not mandate an alternative port number but we would not preclude some implementations from using alternative ports. The protocol document should make a statement that by default IPP should be supported by servers and clients over port 80. Model Issues: 15) Change PDL Override back to Boolean -- no 16) Covered by #13 17) Delete appendix C and reference IANA MIME registry: yes, but include a couple of examples in the actual attribute section. 18) Addition of document-formats-detected: No - if the client knows the document format then it should use that attribute and not depend on auto-sensing. 19) If Create-Job is supported then Send-Document must be supported and Send-URI is optional. 20) No document level attributes - yes 21) Delete orientation as a job attribute - no - we will add reverse landscape -- these only apply to the case of simple text. 22) Compression - IPP will support none, compress, gzip and deflate 23) Any character from ISO10646 (level 2) will be encoded in UTF-8. 24) What does the server do when a time-out occurs after a create-job? - delete? (This action could depend on the fidelity setting) - close and hold? - close and schedule? Scott will document these cases and the ramifications. 25) Is any notion of time (absolute, relative) mandatory? - absolute time is not mandatory - relative time is mandatory 26) "media-ready" versus "media-supported" There was a long discussion on the value of a "media- supported" attribute so that a media that could be loaded by an operator would be available to the client to choose from. If a job is submitted with FIDELITY=TRUE and the media requested is not in either list (media-ready or media- supported) then the job would be rejected. If the media is supported and not ready, the job would be held until the media is loaded. If FIDELITY is not TRUE, the job would be printed on the best available media. Scott will write this up for immediate review. 27) Delete syntax for "copies-supported" - We will leave it as it is and add an attribute "collated-copies-supported" that would be available if the printer supported collating copies. 28) Support for ftp and http schemes are required for all IPP printers that implement Send-URI and Print-URI. Document-URI-schemes-supported will not be implemented for V1. User name and password from the ftp URL will be used if provided otherwise anonymous will be used. The printer should check for a supported scheme and reject unsupported ones (a new error code is needed.) 29) Confusion over the group "printer-description" versus the actual "printer-description" attribute. Scott will document a change to remove the ambiguity. 30) Change "color-supported" to provide more information -- no change for V1. 31) Editorial: operations are changed to be like type2 enums and the pseudo-keywords will follow the keyword syntax. 32) Status Codes and Operations will look like a type2 enum but the name space will be managed separately from other type2 enums. Scott will clean up this and #31 in the next document. 33) Job-URI versus Job-id : see discussion and conclusions above. 34) Need some text distinguishing minor version number versus major version number. A change in the major version implies a significant structural change while a minor version can be parsed around and properly ignored. Steve Zilles will submit some proposed wording for inclusion. 35) See #28 above. 36) Document attributes: document attributes are gone. 37) Default Job Template Attributes should not be treated as PDL overrides. 38) If Fidelity is false and attributes are ignored, should the response indicate what attributes were ignored? Yes - document in the model document. 39) Same as #38. 40) See #19. 41) What should be used for media type when PDL is automatic? * When document format is missing then default is used. * When application/octet-stream is sent to the printer the printer does its best to figure it out and print it. * Application/octet-stream is valid as the default and means use the auto-sensing mechanism. 42) The last-sent document can be an empty document. In fact any document can be empty. An empty document does not print a blank sheet; however it will cause a partial sheet to be printed. 43) The last-document attribute (either true or false) must be included in any send-document or send-uri and is an error if omitted. 44) If the printer implements the job-state-message then it must return it in the Create-Job, Send-Job, and Send-URI response. 45) "message-to-operator" operational attribute: keep 46) -- This number was skipped -- 47) Document attribute issue - all document attributes removed 48) Attribute Syntax assignments: Scott will not have assignments in the model document. They will be in the protocol document. 49) Delimiter Tag enums: These will also be in the protocol document. The meeting adjourned at 5:35PM The meeting resumed at 8:30AM, working through the Model issues. 50) Should the enum values be in decimal or hex. -- leave them in hex. 51) Resolution attribute syntax: Will be fixed by Scott. 52) Does '1setOfX' attribute syntax need to indicate whether order is important? : Yes, a statement will be added 53) Does 'rangeOfX' need to specify that lower is first: yes 54) Should notify-addresses have a default value? NO 55) printer-resolution should be of type resolution: Yes 56) Should compression have a default value? Don't need it; client specifies any compression, default doesn't make sense. 57) Job-sheets: When the client provided job-sheets is invalid and FIDELITY is true then the printer will reject the job. 58) Add printer-state-message as an optional field in event notification content: OK 59) Event Notification Content -- What printable format is time in? Scott will reference the RFC which defines an ASCII format for time. Scott will move this to the optional items at the end of the list. 60) Event Notification Content needs to be internationalized: All 'text' and 'name' will be internationalized with the language tag at the front of the string. 61) 'multiple-document-handling' and slip sheets: Job- sheets will be multi-valued. We will not, at this time, add slip-sheets since this is type4 but it could be added later. 62) 'number-up' will be changed to a type 'setof' integers. The lower bound will be 1. Borders on n-up images will be implementation dependent. Scott will clean up the definition of what 'logical' pages are based upon a suggestion from Steve Zilles. Interaction of n-up, orientaton, duplex and finishing need to be discussed in the document -- Steve Zilles will send a draft to the list for review. 63) IPP should explain printer resolution rather depending upon the MIB - Yes 64) print-quality: Change to say that the value of the attribute SHALL be used for the job -- ok 65) In the orientation section, change langSimpleText to the right MediaType -- ok 66) orientation -- added reverse landscape and see Tom Hasting write-up sent on 9/16, subject: MOD - ISSUES in 09/03 Model document. 67) "document-name" mandatory? - no document attributes 68) Should job-URI be a Job Status Attribute? -- It is now returned as an operation attribute. Scott will change this and add job-id to be just a job attribute that is returned. Add 'number of intervening jobs' as an optional attribute returned on the create request. 69) Generic Alerts from the Printer MIB - Peter will list them and Scott will add these as additional printer events. 70) What about Media-Ready: covered as #26 71) Compression: covered as #22 72) Job URI versus job-id: covered in conference call on Wednesday. 73) job-name versus job-user-label: No, we will have no job- user-label 74) "user-human-language" fixed yesterday as #13. 75) New 'processing' description: New proposal from Tom Hastings to be added with some additional clarification. 76) Show partitioning of state reasons with states -- No 77) see #76. 78) printer-up-time mandatory - yes 79) Proposal to fold the security document into the model document - Scott will merge the documents and the result reviewed by the working group. We will state that an IPP printer must support all required authentication security specified in HTTP/1.1 (change in protocol document). (Carl- Uno reported that TLS will probably become a proposed standard in the next few weeks.) After some discussion, the group came around to the fact that in order to read what security means are supported, you must already have made a connection to the printer because the security mechanisms are at the HTTP level or below and not at the IPP level. The group did not want to include a mandate for TLS or TLS framing as a part of IPP. The attribute "security- mechanism-supported" is removed. We will add an attribute "printer-tls-uri" which will have the uri for accessing the printer in a TLS secure mode. If a server does any security, it SHALL support TLS. If additional security means are provided, we must add additional attributes. Randy Turner will investigate and report on the interoperability between SSL and TLS. The security document mentions that the IPP printer must be aware that a virus could be contained in the print job. How that is to be prevented is not addressed by IPP. The document should make this clear. 80) server-error-device-error: This error would only be returned if the device error prevents the create from happening. For example, if a printer doesn't spool and has a limited buffer and the create can't happen because of a device error (e.g. paper jam) then this error would be returned. In the case of an IPP Printer with spooling, this error would not be returned. 81) langAuto -- covered in #41. 82) Relationship to Printer MIB: If an implementation chooses to have both IPP and the Printer MIB, a specified set of attributes/object shall be identical. Harry Lewis will draft this wording. 83) Relationship to Job MIB: If an implementation chooses to have both IPP and the Job MIB, a specified set of attributes/object shall be identical. Harry Lewis will draft this wording. Lunch break: 11:45 until 1PM 84) Proposal on tags (Attribute, Parameter, Data) in the protocol now that Parameters are gone. -- After discussion, we felt it was cleaner to have separate tags to divide up the various sections of attributes: - Operation Attribute Tag - Printer Attribute Tag - Job Attribute Tag - Unsupported Job Attribute Tag - Data Tag By having separate printer-attribute and job-attribute tag we can add a document-attribute tag or something else later. This strategy will make parsing easier. Any Data-Tag would be last; any Operational-Tag would be first. Each operation will explicitly list the order of the tags. Scott will document this approach and include explanation of why various attributes are in each category. More issues from Tom Hastings iss-903a.doc file. Starting with issues 34. TH34) Finishing and orientation: Will be covered by Steve Zilles in his orientation, n-up, etc. document. TH34a1) See RFC2046 TH34a2) Not applicable TH35) user-human-language -- already covered in #13 TH36) job-id: will be positive number TH37) user-human-language -- already covered in #13 TH38) job-state -- leave as type 1 TH39) time-x-x change from milliseconds to seconds - yes, already decided TH40) number-of-intervening-jobs: align with JOB MIB - yes TH41) We will align k-octets, impressions and sheets with the Job MIB. TH42) Change the name of printer-description to printer-info as decided in #29 above. TH43) Copy some language from printer-driver-installer to printer-make-and-model & others: Yes TH44) Add text to indicate there should be an error reason when the printer is "stopped." TH45) Scott will add text to the document. TH46) We have previously agreed not to align with the JOB MIB in the area of defining what an active job is. See #5. TH47) printer-human-language: Already decided in #13 TH48) Color: Already decided as #30 TH49) Internationalization: already decided in #13 TH50) Indicate that supported values might require human (i.e. operator) action. An example of this should be included in the completed description. -- OK TH51) Add a suffix to some attributes (-supported) to make it clear whether an attribute is default or supported -- OK When we add this suffix, the base attribute name will not be changed for grammatical reasons. SECURITY There are reserved port numbers for TLS & SSL on HTTP (port 443) TLS is backwards compatible with SSL3. Actually TLS is SSL3.1 The TLS I-D describes how to support SSL3 interoperability. The group then discussed wording choices for stating the security protocol requirements (SSL3, TLS, etc.) There were four wording alternatives explored: 1) IPP Client/Servers must implement TLS with SSL3 compatibility 2) IPP Client/Servers shall be interoperable with a TLS communicant 3) IPP Client/Servers must be TLS compliant. 4) #2 above plus "with SSL3 backward compatibility" Decision: #1 with some section talking about a transition to TLS. PAGE FORMATING (N-UP, ORIENTATION, Etc.) Steve Zilles presented material on this subject. Steve will detail this more and post to the mailing list. Because all the interactions with finishing will not be defined for V1, the following enums for finishing were removed: 5,6,7,8,9,10. These values could be added back in for V2 when more work has been done to define them. The values for punch, cover and bind will be moved up. While some languages bind on the right and others bind on the left, we will leave this as site specific. Bind-left and bind-right could be added later. MEDIA TYPES Registration of printer datastreams -- Harald A. believes that the only way to make sure it gets done is to do it ourselves. Alternatives for registration: 1) application/print.xxx (application/print.ipds) 2) application/vnd.xxx (application/vnd.ppds) 3) application/vnd.company.xxx (application/vnd.adobe.printgear) 4) application/xxx (application/postscript) Anything that this group registers could include versions and level but it is unclear if level and version could be added to something that is already registered. The group unanimously believed that it must do the registration and would try to do #1 above with #2 as a fall-back. MODEL Add a new type called "range-of-int" that would be 8 bytes, 4 bytes for the low end and 4 bytes for the high end of the range. -- YES, this would clearly differentiate range from setof. We can now remove range-of-x since integer is the only one we use. SZ1) "Instance of a Printer", "Printer Object", "IPP Printer" and "Instance of Printer Object" are all used to mean the same thing. We should use only one -- "Printer Object" - once the model document has introduced the concept of an object. SZ2) 3.2.1 needs more clarification in the area of Validate- Job: Scott will clarify this text. SZ3) When is Job-name generated: The name is generated before the response on the create is returned. SZ4) "snapshot" for all job status attribute is taken at the same time. SZ5) How unsupported attributes are returned needs some clarifications. Scott and Steve Zilles will work out this wording. SZ6) Section 3.3.4.1 change "_names (without values) or attribute groups_" to and/or. SZ7) Section 4.2 - Interaction of defaults with other values -- no simple solution -- ignore for now. Default should be described as the most likely value. For example is the default is 2-sided but the media selected is transparency then 2-sided does not apply. SZ8) Section 4.2.17 - clarification is needed that only the document data is compressed. SCHEDULE Carl-Uno reviewed the schedule -- There are now only two standards tracks documents -- "Model" and "Protocol." Informational documents -- "Requirements," "Rationale" and "LPR Mapping" When all these documents are published, Carl-Uno will issue a last call for the working group. These comments get reflected into the documents. The documents are then sent to the IESG for a last call to the area directors. Once they are turned over to the Area Directors much of the control is removed from the hands of the working group. After the documents have been turned over to the IETF, the PWG group can continue to work on: 1) Interoperability testing 2) V2 requirements 3) Prototyping 4) etc. The meeting adjourned at 5:20 PM.   Received: from cnri by ietf.org id aa10742; 23 Sep 97 12: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 MAA29370 for ; Tue, 23 Sep 1997 12:23:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10527 for ; Tue, 23 Sep 1997 12:20:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 12:12:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09988 for ipp-outgoing; Tue, 23 Sep 1997 12:03:34 -0400 (EDT) Message-Id: <3.0.1.32.19970923085000.00a25100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 23 Sep 1997 08:50:00 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM - Agenda for PWG IPP Conference Call 970924 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >From: papowell@astart.com >To: cmanros@cp10.es.xerox.com >Subject: Re: IPP> ADM - Agenda for PWG IPP Conference Call 970924 > >Could you please put the time/date in the announcement? >i.e.: > >Call: 24 Sept 1997, 1:00 PST (or whatever) > >:-) > >Patrick Patrick is right. We will start at 1:00 pm PST as usual. 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 aa10992; 23 Sep 97 12: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 MAA29445 for ; Tue, 23 Sep 1997 12:39:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA11127 for ; Tue, 23 Sep 1997 12:35:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 12:32:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10581 for ipp-outgoing; Tue, 23 Sep 1997 12:22:49 -0400 (EDT) Date: Tue, 23 Sep 1997 09:25:38 -0700 (PDT) From: papowell@astart.com Message-Id: <199709231625.JAA04004@astart4.astart.com> To: don@lexmark.com, ipp@pwg.org Subject: Re: IPP> September Meeting Minutes Cc: papowell@astart.com Sender: ipp-owner@pwg.org > - While the conference call was still open, we discussed the > use of a port besides 80. It was the consensus that we > would not mandate an alternative port number but we would > not preclude some implementations from using alternative > ports. The protocol document should make a statement that > by default IPP should be supported by servers and clients > over port 80. I think that this is a serious mistake. What is happening here is you are adding required functionality to a HTTP port service without coordinating this with the folks doing the HTTP stuff. In addition, you are requiring non-printer vendors to supply a HTTP server that will not only do regular HTTP functionality but also provide support for IPP as well if they want to do GATEWAY support for the IPP protocol to other print systems. This is the part where I disagree strongly. If you have a separate port for IPP, then the IPP server and the HTTP server can be separate; if you (and ALL HTTP server implementations that I have looked at support this) support an 'alternate' port or range of ports, then this can be easily supported. Note: it is common to use port 8080 for 'test' purposes in many HTTP servers, and to allow 'CGI' type of applications to 'check' on the type of connection allowed. This has to do with firewalls, and internal versus external connections, where only INTERNAL hosts can access via port 8080 and EXTERNAL hosts cannot. If the IPP protocol is only going to be implemented for NON-GATEWAY type applications, i.e. - where you are NOT going to add IPP functionality to a host for system managment purposes, then I think this would be supportable. But since there is constant and concerning discussion about Gateways, and the problems of Gateways, then we MUST make gateways as simple and trivial to implement, independent of the HTTP server. So the argument about needing all HTTP or similar protocols to go to port 80 (i.e. - HTTP server is misleading) if not downright fallacious. I apologize for such strong language, but I feel that this statement must be made. Patrick Powell PHILOSOPHICAL STATEMENT I think that one of the things to keep in mind is separation of functionality in the TCP/IP world was/is done by PORT number, NOT overloading a protocol and server with new/different required functionality. Example: SSH and RSERVICES use different ports - even though it is possible to have the RSERVICES server (rlogin, etc.) distinguish between the type of protocol. In fact, pushing this to an extreme, you could even have FTP/SNMP on the same port, and have the functionality distinguished by the initial connection conversation. The TCP/IP design was based on using port numbers to distinguish the type of service, even if the 'application protocol level' was different. I think that you will encounter a great deal of opposition if you try to push this through.   Received: from cnri by ietf.org id aa12920; 23 Sep 97 13: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 OAA29855 for ; Tue, 23 Sep 1997 14:01:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11806 for ; Tue, 23 Sep 1997 13:58:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 13:54:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11296 for ipp-outgoing; Tue, 23 Sep 1997 13:44:55 -0400 (EDT) Message-Id: <9709231744.AA26310@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Sep 1997 10:42:14 PDT To: Larry Masinter From: Tom Hastings Subject: Re: IPP> MOD - ISSUES: Contents of "document-format" attribute = MIME Content-type Header Field value Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 17:04 09/17/97 PDT, Larry Masinter wrote: >> Alternatively, we could add a separate >> Printer description attribute: "content-transfer-encodings" supported. > >I suggest instead that you supply a single description attribute >which is "accept headers" which describes the document formats >and encodings that the printer will accept. This should take >the same range as the accept headers of HTTP and the document format >accept headers being proposed for Internet Fax. If the MIME-type attributes include content-transfer-encodings as an attribute, then we don't need to add the Printer description attribute. Do they? > >Larry >-- >http://www.parc.xerox.com/masinter > >   Received: from cnri by ietf.org id aa13975; 23 Sep 97 14: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 OAA00100 for ; Tue, 23 Sep 1997 14:39:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12499 for ; Tue, 23 Sep 1997 14:36:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 14:28:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11929 for ipp-outgoing; Tue, 23 Sep 1997 14:16:13 -0400 (EDT) Message-Id: <9709231816.AA26334@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Sep 1997 11:13:24 PDT To: rturner@sharplabs.com From: Tom Hastings Subject: Re: IPP> Document attributes Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Randy, What kind of a place holder did you have in mind for document attributes? Such a place holder might be a way forward, as we have done for the 'dictionary' attribute syntax (by reserving the type code). Tom At 09:36 09/21/97 PDT, Randy Turner wrote: >Ok, so we have these actual document attributes that we could admittedly move >into "job document attributes" just to save us the work this time of actually doing >the work to support document attributes. This might be >problematic for future implementations that actually *DO* the >document attribute model correctly, having to be backward-compatible >with our "hacked" version of document attributes of IPP 1.0. > >I thought maybe we could allow a placeholder in the model/protocol for >V 1.0 for document attributes, so that we could easily integrate this in >the future with very little work. > >Concerning the "job-document-attribute" proposal... > I'm assuming that the send-document operation allows these "job-document" >attributes to be included (I can't remember the send-document specifics from the >model document...). > >Randy > >Ira Mcdonald x10962 wrote: > >> Hi Randy, >> >> I think we agreed that JOBs could have descriptive attributes >> (either single- or multi-valued??) about the associated >> document(s), which apply unless (in a future version of IPP) >> they are overridden at the (future) DOCUMENT object level. >> >> I speculate that the following JOB level attributes are >> necessary or desirable in IPP 1.0: >> >> [job]document-name >> [job]document-URI (to support Send-URI) >> [job]document-format >> >> Cheers, >> - Ira McDonald (outside consultant at Xerox) >> High North In >> 906-494-2434 > > > > >   Received: from cnri by ietf.org id aa14095; 23 Sep 97 14: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 OAA00207 for ; Tue, 23 Sep 1997 14:47:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA13331 for ; Tue, 23 Sep 1997 14:44:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 14:37:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11950 for ipp-outgoing; Tue, 23 Sep 1997 14:22:49 -0400 (EDT) Message-ID: <342808D8.DDB2618B@parc.xerox.com> Date: Tue, 23 Sep 1997 11:22:16 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> MOD - ISSUES: Contents of "document-format" attribute = MIME Content-type Header Field value References: <9709231744.AA26310@zazen.cp10.es.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The content-transfer-encoding (or, for that matter, the transfer-encoding) is orthogonal to the content-type. Logically, any content-transfer-encoding (in email) and any transfer-encoding (in HTTP and, most likely, in IPP) can be used with any content-type. MIME-type attributes (like charset, version, etc.) are, on the other hand, type specific, and the type registration identifies the optional & required parameters and their ranges. Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa15256; 23 Sep 97 15: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 PAA00466 for ; Tue, 23 Sep 1997 15:42:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14158 for ; Tue, 23 Sep 1997 15:39:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 15:34:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13643 for ipp-outgoing; Tue, 23 Sep 1997 15:25:30 -0400 (EDT) Date: Tue, 23 Sep 1997 12:28:34 -0700 (PDT) From: papowell@astart.com Message-Id: <199709231928.MAA04140@astart4.astart.com> To: don@lexmark.com, ipp@pwg.org Subject: Re: IPP> September Meeting Minutes Sender: ipp-owner@pwg.org > SECURITY > There are reserved port numbers for TLS & SSL on HTTP (port > 443) > TLS is backwards compatible with SSL3. Actually TLS is > SSL3.1 The TLS I-D describes how to support SSL3 > interoperability. > The group then discussed wording choices for stating the > security protocol requirements (SSL3, TLS, etc.) There were > four wording alternatives explored: > 1) IPP Client/Servers must implement TLS with SSL3 > compatibility > 2) IPP Client/Servers shall be interoperable with a TLS > communicant > 3) IPP Client/Servers must be TLS compliant. > 4) #2 above plus "with SSL3 backward compatibility" > Decision: #1 with some section talking about a transition to > TLS. I will note carefully that this closely follows the model of having different ports for different protocols. Note that TSL/SSL actually are HTTP over TSL and HTTP over SSL. We are similarly doing IPP over HTTP. Should this be the same port or a different port? Patrick   Received: from cnri by ietf.org id aa16310; 23 Sep 97 16: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 QAA00554 for ; Tue, 23 Sep 1997 16:18:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA14582 for ; Tue, 23 Sep 1997 16:15:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 16:11:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14375 for jmp-outgoing; Tue, 23 Sep 1997 16:08:32 -0400 (EDT) Message-Id: <9709231957.AA26388@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Sep 1997 12:54:46 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: JMP> MOD - Agreed changes to IPP/JMP "job-state" and "job-state-reasons" Sender: jmp-owner@pwg.org I've cross-posted the agreements on the job-state/jmJobState and job-state-reasons /jmJobStateReason1 attributes/object specifications for IPP and JMP. In addition to the JMP changes listed in Ron's list, the JMP agreed to remove the finishing enums that IPP removed (because of a lack of a coordinate system specification for stapling), add private enum range for attributes to agree with IPP, and add 'job-interpreting', and add 'jobInterpreting', 'jobQueued', and 'jobTransforming' to JMP jmJobStateReasons1 to align with the recent additions to IPP "job-state-reasons" attribute. Only the 'jobInterpreting' is to be included in the jmJobStateReasons1 object. The file has the complete specifications for each of the attributes/objects for IPP and JMP: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 71168 Sep 23 19:40 statreas.doc -rw-r--r-- 1 pwg pwg 64184 Sep 23 19:40 statreas.pdf -rw-r--r-- 1 pwg pwg 26237 May 16 05:01 sepstate.txt The .pdf has red revision marks to show the changes. Scott will be replacing the "job-state" and "job-state-reasons" sections in the Job Model spec with the IPP text. Thanks, Tom   Received: from cnri by ietf.org id aa16980; 23 Sep 97 16: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 QAA00663 for ; Tue, 23 Sep 1997 16:51:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA16490 for ; Tue, 23 Sep 1997 16:48:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 16:38:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14358 for ipp-outgoing; Tue, 23 Sep 1997 16:08:11 -0400 (EDT) Message-Id: <3.0.1.32.19970923124644.00a17cb0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 23 Sep 1997 12:46:44 PDT To: papowell@astart.com, don@lexmark.com, ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Use of special port for IPP In-Reply-To: <199709231928.MAA04140@astart4.astart.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:28 PM 9/23/97 PDT, papowell@astart.com wrote: >> SECURITY > > >> There are reserved port numbers for TLS & SSL on HTTP (port >> 443) > >> TLS is backwards compatible with SSL3. Actually TLS is >> SSL3.1 The TLS I-D describes how to support SSL3 >> interoperability. > >> The group then discussed wording choices for stating the >> security protocol requirements (SSL3, TLS, etc.) There were >> four wording alternatives explored: > >> 1) IPP Client/Servers must implement TLS with SSL3 >> compatibility >> 2) IPP Client/Servers shall be interoperable with a TLS >> communicant >> 3) IPP Client/Servers must be TLS compliant. >> 4) #2 above plus "with SSL3 backward compatibility" > >> Decision: #1 with some section talking about a transition to >> TLS. > >I will note carefully that this closely follows the model of having >different ports for different protocols. Note that TSL/SSL actually are >HTTP over TSL and HTTP over SSL. We are similarly doing IPP over HTTP. > >Should this be the same port or a different port? > >Patrick > Patrick, Our decision not to pursue a separate port for IPP in the standard was that there seems to be as many reasons for as against using a separate port. E.g. Netscape has suggested using a separate port, Microsoft has suggested using the standard HTTP port, so even among those heavyweights there is no agreement. If it turns out that a particular domain or vendor wants to use a special port different from the normal HTTP port, it can be included in the Printer URIs for those IPP printers. And as you notice from the notes above, in cases where we want to run IPP over a secure connection such as TLS, the security protocol dictates which port to use, so to define a special port for IPP makes no sense for such scenarios. 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 aa16992; 23 Sep 97 16: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 QAA00668 for ; Tue, 23 Sep 1997 16:51:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA16493 for ; Tue, 23 Sep 1997 16:48:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 16:37:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14367 for ipp-outgoing; Tue, 23 Sep 1997 16:08:20 -0400 (EDT) Message-Id: <9709231957.AA26388@zazen.cp10.es.xerox.com> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Sep 1997 12:54:46 PDT To: jmp@pwg.org, ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Agreed changes to IPP/JMP "job-state" and "job-state-reasons" Sender: ipp-owner@pwg.org I've cross-posted the agreements on the job-state/jmJobState and job-state-reasons /jmJobStateReason1 attributes/object specifications for IPP and JMP. In addition to the JMP changes listed in Ron's list, the JMP agreed to remove the finishing enums that IPP removed (because of a lack of a coordinate system specification for stapling), add private enum range for attributes to agree with IPP, and add 'job-interpreting', and add 'jobInterpreting', 'jobQueued', and 'jobTransforming' to JMP jmJobStateReasons1 to align with the recent additions to IPP "job-state-reasons" attribute. Only the 'jobInterpreting' is to be included in the jmJobStateReasons1 object. The file has the complete specifications for each of the attributes/objects for IPP and JMP: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ -rw-r--r-- 1 pwg pwg 71168 Sep 23 19:40 statreas.doc -rw-r--r-- 1 pwg pwg 64184 Sep 23 19:40 statreas.pdf -rw-r--r-- 1 pwg pwg 26237 May 16 05:01 sepstate.txt The .pdf has red revision marks to show the changes. Scott will be replacing the "job-state" and "job-state-reasons" sections in the Job Model spec with the IPP text. Thanks, Tom   Received: from cnri by ietf.org id aa17015; 23 Sep 97 16: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 QAA00670 for ; Tue, 23 Sep 1997 16:52:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA16499 for ; Tue, 23 Sep 1997 16:48:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 16:37:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14388 for ipp-outgoing; Tue, 23 Sep 1997 16:09:38 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Supported URIs for print-by-reference Date: Tue, 23 Sep 1997 13:08:15 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org At the meeting in Atlanta, it was agreed that we would mandate that both FTP and HTTP would be supported schemes for PrintURI and SendURI. I would like to propose that we also include the FILE: scheme to this list. The FILE: scheme allows the server to print files that are available on locally mounted file system volumes that are available to the server itself. We can talk about this at the teleconference or on the list. Randy   Received: from cnri by ietf.org id aa18233; 23 Sep 97 17: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 RAA00848 for ; Tue, 23 Sep 1997 17:38:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17550 for ; Tue, 23 Sep 1997 17:34:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 17:30:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16949 for ipp-outgoing; Tue, 23 Sep 1997 17:21:25 -0400 (EDT) From: Dale Wick To: papowell@astart.com, ipp@pwg.org Message-ID: <1997Sep23.152820.1896.55617@bricklin.lan.truespectra.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: TrueSpectra Inc. Date: Tue, 23 Sep 1997 17:28:42 -0400 Subject: Re: IPP> Default port (was Re: IPP> September Minutes) Sender: ipp-owner@pwg.org Patrick Powell said: > > - While the conference call was still open, we discussed the > > use of a port besides 80. It was the consensus that we > > would not mandate an alternative port number but we would > > not preclude some implementations from using alternative > > ports. The protocol document should make a statement that > > by default IPP should be supported by servers and clients > > over port 80. > = > I think that this is a serious mistake. What is happening here is you > are adding required functionality to a HTTP port service without > coordinating this with the folks doing the HTTP stuff. > = > In addition, you are requiring non-printer vendors to supply > a HTTP server that will not only do regular HTTP functionality > but also provide support for IPP as well if they want to do GATEWAY > support for the IPP protocol to other print systems. > > This is the part where I disagree strongly. > The falacy in this arguement is that IPP isn't an independent protocol it is a protocol layered inside HTTP 1.1. To have IPP default to anything other than port 80 whould require that our printer URIs be in the form of ipp://site/printer instead of http://site/printer which is not the direction we chose, when we went for a layer under HTTP. If port 80 at a site is occupied by a non-ipp http server, then use allow for = printers to use a different port. Dale -- Dale Wick TrueSpectra Inc., Toronto, Ontario, Canada "Excellence in Graphics"   Received: from cnri by ietf.org id aa20388; 23 Sep 97 20: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 UAA01216 for ; Tue, 23 Sep 1997 20:14:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19512 for ; Tue, 23 Sep 1997 20:11:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 20:03:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18557 for ipp-outgoing; Tue, 23 Sep 1997 19:47:04 -0400 (EDT) Date: Tue, 23 Sep 1997 16:44:53 -0700 From: Robert Herriot Message-Id: <199709232344.QAA15575@woden.eng.sun.com> To: Robert.Herriot@eng.sun.com, jkm@underscore.com Subject: Re: IPP> Document attributes Cc: ipp@pwg.org, rturner@sharplabs.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From jkm@underscore.com Mon Sep 22 17:03:31 1997 > > Bob, > > Sorry, but there are *lots* of Unix systems that can accept jobs > having documents with multiple data formats. What Unix systems offer this feature? In my previous email, I stated that the Solaris spooler does not. It is based on AT&T System V and many other Unix spoolers are based on the same code. It is possible that other vendors have removed the single document-format restriction, though considering the required changes, I doubt it. The BSD LPD spooler and LPD protocols support multiple formats per job, so these systems accept jobs with multiple data formats. But the BSD lpr command does not give access to this feature. It is possible that some vendors have enhanced the lpr command, but I am not aware of such changes. Bob Herriot > > > ...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 -- > ---------------------------------------------------------------------- > > > Robert Herriot wrote: > > > > This is a version 1.0 limitation. But I doubt it will cause much > > hardship because currently: > > > > 1) Windows users can only send one document per job. > > 2) Solaris users can send multiple documents per job, but they > > must all have the same format, despite the generality of the LPD > > protocol. I think that most if not all other Unix systems have > > the same limitation. > > > > So that doesn't leave very many people with the capability that we > > are removing from version 1.0. > > > > Bob Herriot > > > > > From rturner@sharplabs.com Mon Sep 22 16:12:02 1997 > > > From: "Turner, Randy" > > > To: "'ipp@pwg.org'" > > > Subject: RE: IPP> Document attributes > > > Date: Mon, 22 Sep 1997 15:34:30 -0700 > > > X-Priority: 3 > > > MIME-Version: 1.0 > > > X-Mailer: Internet Mail Service (5.0.1458.49) > > > Sender: ipp-owner@pwg.org > > > X-Lines: 90 > > > > > > > > > Does this seem kind of limiting, to restrict all documents in a > > > particular job to have the same document format? It doesn't > > > seem hard to imagine a 2-document job wherein one file > > > is PCL and another Postscript. If the document attribute > > > says "application/vnd.pcl" then the printer would probably > > > trash the 2nd Postscript job. > > > > > > Just checking to see if we haven't got a hole in this > > > somewhere.... > > > > > > Randy > > > > > > > > > > -----Original Message----- > > > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > > > Sent: Monday, September 22, 1997 3:27 PM > > > > To: ipp@pwg.org; rturner@sharplabs.com > > > > Subject: Re: IPP> Document attributes > > > > > > > > I think that we agreed not to decide on the format of attributes that > > > > have a separate value for each document by eliminating document-name, > > > > and stating that all documents in a job have the same document-format, > > > > meaning that document-format is a job-level attribute. > > > > > > > > Document-URI is still a problem unless either we eliminate Send-URI > > > > (my > > > > preference) or eliminate document-URI as a job attribute until a later > > > > version. > > > > > > > > Although we previously decided not design a format for per-document > > > > attributes until a later version, I pointed out that an attribute > > > > 'foo' > > > > could take on a "dictionary" value whose values might be "default=XYZ" > > > > and "3=ABC" to indicate that the job level 'foo' attribute has a value > > > > of "XYZ" and document-3 has a value of "ABC". Such a solution is not > > > > precluded by the current design. > > > > > > > > Bob Herriot > > > > > > > > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997 > > > > > > > > > > Ok, so we have these actual document attributes that we could > > > > admittedly move > > > > > into "job document attributes" just to save us the work this time of > > > > actually doing > > > > > the work to support document attributes. This might be > > > > > problematic for future implementations that actually *DO* the > > > > > document attribute model correctly, having to be backward-compatible > > > > > with our "hacked" version of document attributes of IPP 1.0. > > > > > > > > > > I thought maybe we could allow a placeholder in the model/protocol > > > > for > > > > > V 1.0 for document attributes, so that we could easily integrate > > > > this in > > > > > the future with very little work. > > > > > > > > > > Concerning the "job-document-attribute" proposal... > > > > > I'm assuming that the send-document operation allows these > > > > "job-document" > > > > > attributes to be included (I can't remember the send-document > > > > specifics from the > > > > > model document...). > > > > > > > > > > Randy > > > > > > > > > > Ira Mcdonald x10962 wrote: > > > > > > > > > > > Hi Randy, > > > > > > > > > > > > I think we agreed that JOBs could have descriptive attributes > > > > > > (either single- or multi-valued??) about the associated > > > > > > document(s), which apply unless (in a future version of IPP) > > > > > > they are overridden at the (future) DOCUMENT object level. > > > > > > > > > > > > I speculate that the following JOB level attributes are > > > > > > necessary or desirable in IPP 1.0: > > > > > > > > > > > > [job]document-name > > > > > > [job]document-URI (to support Send-URI) > > > > > > [job]document-format > > > > > > > > > > > > Cheers, > > > > > > - Ira McDonald (outside consultant at Xerox) > > > > > > High North In > > > > > > 906-494-2434 > > > > > > > > > > > > > > > > > > > > > > > >   Received: from cnri by ietf.org id aa20422; 23 Sep 97 20: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 UAA01219 for ; Tue, 23 Sep 1997 20:16:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19760 for ; Tue, 23 Sep 1997 20:13:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Sep 1997 20:07:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18590 for ipp-outgoing; Tue, 23 Sep 1997 19:50:31 -0400 (EDT) Message-Id: <3.0.1.32.19970923163634.009d4ce0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 23 Sep 1997 16:36:34 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: Security in IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Please see this exchange between myself and Keith on the subject of IPP security. I suggest we add this subject to our phone conference on Wednesday September 24. Carl-Uno >Return-Path: >X-Uri: http://www.cs.utk.edu/~moore/ >From: Keith Moore >To: Carl-Uno Manros >Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, szilles@adobe.com, > rdebry@us.ibm.com, manros@cp10.es.xerox.com, don@lexmark.com >Subject: Re: Security in IPP >Date: Tue, 23 Sep 1997 14:27:36 PDT >Sender: moore@cs.utk.edu > >> The IPP WG is now getting close to finishing the IPP specifications, and we >> plan to go out with a last call for the WG in early October. We have been >> trying to come up with a suitable compromise regarding security, which >> takes some real life conditions into account. As recommended to Keith in a >> mail note from Roger deBry, this is the kind of security statements that we >> would like to make: >> >> 1) All IPP clients and IPP servers SHALL support the security features >> specified in RFC 2069 (which provides client authentication to protect >> printers against spamming or other misuse). This would be sufficient for >> some scenarios. > >This is fine. > >> 2) If IPP clients and IPP servers need added security (mutual >> authentication and/or encryption) they SHOULD support TLS. However, we >> would like to add a statement to the effect that use of SSL3 should be >> considered conformant until TLS is commonly available and deployed (as >> specified in Annex E of the TLS specification for interworking between >> SSL3/TLS). > >Hmmm. > >It's okay to mention SSL3, and even suggest that it might be used, >but you should not call it "conformant"... rather, state that use >of IPP+SSL3 is outside the scope of the standard. > >If there are details that need to be specified re: use of IPP >with SSL3 so that such implementations will interoperate, >you might state those in an appendix or in a separate >(informational or experimental) RFC. > >(In general I'm concerned about client configuration issues >w.r.t. this kind of use of TLS -- a TLS 1.0 client has to >know in advance which credentials are required by a particular >server -- the client has no way of finding out which CAs the >server trusts, nor which TLS ciphersuites it uses. It's >not that these issues cannot be dealt with in the context >of IPP -- it's just more information that must be pre-configured >in the client before it can print -- but unless these things are >carefully specified, I fear that IPP clients and servers will >not interoperate in secure mode.) > >The document should state that standardization of IPP+TLS is >expected in the near future, and that clients or servers using SSL3 >which are developed in advance of IPP+TLS standardization might >not be interoperable with IPP+TLS standards-conforming servers or >clients. > >FWIW, to me it looks like the TLS WG may be moving again. > >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 aa02081; 24 Sep 97 2: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 CAA01707 for ; Wed, 24 Sep 1997 02:40:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA22352 for ; Wed, 24 Sep 1997 02:37:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 24 Sep 1997 02:29:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA21695 for ipp-outgoing; Wed, 24 Sep 1997 02:15:17 -0400 (EDT) Message-ID: <3428AFCD.9B46479E@parc.xerox.com> Date: Tue, 23 Sep 1997 23:14:37 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Randy Turner CC: ipp@pwg.org Subject: Re: IPP> Supported URIs for print-by-reference References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > At the meeting in Atlanta, it was agreed that we would mandate that both > FTP and HTTP would be supported schemes for PrintURI and SendURI. > > I would like to propose that we also include the FILE: scheme to this > list. The FILE: scheme allows the server to print files that are > available > on locally mounted file system volumes that are available to the server > itself. > > We can talk about this at the teleconference or on the list. a) without a standard way of loading a print server's disks with any data, mandating support for the "file:" scheme would hardly lead to interoperability. b) While one can imagine "if you support remote printing at all, you should be able to retrieve files from an HTTP server", since it just requires a network connection, it doesn't make as much sense to mandate a "file:" scheme because it presumes that the print server has a file system with a naming system that is URL accessible. c) the "file:" URL scheme is in serious need of attention: the implementations (even on the same platform) are widely divergent, and not conformant with the recommended practice in the RFCs. It's not that this is really a terrible idea, it's just not clear that it's useful to "mandate" something that by most measures has to be optional. Larry -- http://www.parc.xerox.com/masinter   Received: from cnri by ietf.org id aa02153; 24 Sep 97 2: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 CAA01713 for ; Wed, 24 Sep 1997 02:44:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA22903 for ; Wed, 24 Sep 1997 02:41:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 24 Sep 1997 02:36:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA21727 for ipp-outgoing; Wed, 24 Sep 1997 02:20:40 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 24 Sep 1997 00:19:24 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - Action Items Steve, Peter, Harry, Tom Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Just a reminder to the volunteers that are working to supply new text to the model document.... This includes Steve, Peter, Harry, and Tom 1. Appendix C: Relationships Between Job Template Attributes ISSUE: Steve Z. to write up relationships between sides, finishings, number-up, orientation, copies, multipl-document-handling, and any other such attribute. 2. Appendix E: Processing Job Template Attributes ISSUE: Steve Z. to re-write steps 8 and/or 9. 3. APPENDIX F: Relationship to SNMP MIBs Printer MIB ISSUE: Harry L. to write-up. 4. APPENDIX F: Relationship to SNMP MIBs Job Monitoring MIB ISSUE: Tom H. to write-up. 5. Printer Events ISSUE: Peter Z. to write-up Printer MIB generic alerts. 6. number-up ISSUE: Steve Z. to supply better terms for "source page" and "logical page". 7. job-k-octets-process, job-images-completed, job-media-sheets-completed ISSUE: Tom H. to provide the exact wording from JMP. 8. SNMP MIB Considerations ISSUE: Harry L. to write-up. If Job MIB and IPP Printer, then "job-id" SHALL be equal to the "jmJobIndex". You can run but you can't hide.... 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 aa00950; 24 Sep 97 3: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 DAA01772 for ; Wed, 24 Sep 1997 03:22:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA24172 for ; Wed, 24 Sep 1997 03:19:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 24 Sep 1997 03:12:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA23061 for ipp-outgoing; Wed, 24 Sep 1997 02:54:50 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 24 Sep 1997 00:53:58 -0600 From: Scott Isaacson To: Robert.Herriot@eng.sun.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org Subject: Re: IPP>MOD document object problem for SendURI Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I noticed the same problem in the editing. I vote for number 2. Scott >>> Ira Mcdonald x10962 09/20 9:08 AM >>> Hi Bob, I vote for your option #3 - dump Send-URI entirely from IPP 1.0. A little bit of document attributes is just as bad as lots. If we don't go with option #3, then we certainly won't get out 'stable' IPP specs by the end-of-September to the IETF. Cheers, - Ira McDonald (outside consultant at Xerox) ------------------------- Bob's note ----------------------- From ipp-owner@pwg.org Fri Sep 19 22:01:09 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA11123; Fri, 19 Sep 97 22:01:08 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA01012; Fri, 19 Sep 97 21:57:10 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <54288(1)>; Fri, 19 Sep 1997 18:57:12 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA26855 for ; Fri, 19 Sep 1997 21:53:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Sep 1997 21:50:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA26529 for ipp-outgoing; Fri, 19 Sep 1997 21:41:29 -0400 (EDT) Date: Fri, 19 Sep 1997 18:40:29 PDT From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199709200140.SAA11256@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD document object problem for SendURI X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Status: R We made a decision to eliminate all document attributes because we didn't want to design the mechanism for returning one attribute per document for version 1.0. I agree with that decision. But now I have realized that SendURI has to send a separate document-URI for each Send-URI operation which means there is a separate value of document-URI for each document. The following are possible solutions: 1) bad idea: solve the multiple-document-attribute problem 2) OK maybe: document-URI is an operation attribute that does not stick to the job object. That is, Get-Attributes does not return a document-URI created by a Send-URI operation. Get-Attributes could return a document-URI value set by Print-URI but it might seem strange that document-URI is available for Print-URI jobs but not Create-Job/ Send-URI jobs. 3) OK maybe: eliminate Send-URI in version 1.0, but keep Print-URI which doesn't have this problem. #3 is probably a little bit better than #2. Bob Herriot   Received: from cnri by ietf.org id aa00956; 24 Sep 97 3: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 DAA01775 for ; Wed, 24 Sep 1997 03:22:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA24178 for ; Wed, 24 Sep 1997 03:19:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 24 Sep 1997 03:12:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA23050 for ipp-outgoing; Wed, 24 Sep 1997 02:53:33 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 24 Sep 1997 00:51:36 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document posted 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. It is dated 9/26 (so I got it done early ....) ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970926-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970926-rev.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970926.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970926.txt It is not really ALL done. There are outstanding action item issues from people who promised to send me text for the document. Some things like security, directory are just mostly done. I am looking for some help on these from the experts. References still need some fixing up. I didn't get through all the Printer object vs instance of vs IPP Printer stuff yet either. I have to miss the 9/25 teleconfernce call, so I will look for minutes. Remember, NO NEW FEATURES. I tried to go through ALL the issues from Atlanta, so I would appreciate pointers of places where I forget stuff or inconsistencies. Best thing for comments is line numbers on the NO REV marks PDF file. 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 aa05400; 24 Sep 97 8: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 IAA02132 for ; Wed, 24 Sep 1997 08:44:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA26166 for ; Wed, 24 Sep 1997 08:40:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 24 Sep 1997 08:33:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA25585 for ipp-outgoing; Wed, 24 Sep 1997 08:23:45 -0400 (EDT) From: don@lexmark.com Message-Id: <199709241223.AA04512@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 24 Sep 1997 08:15:43 -0400 Subject: IPP>MOD document object problem for SendURI Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I will miss today's conference call as I will be on a flight to the Post Office meeting I mentioned in Redmond. However, I did want to send in my vote for #2 below. 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) * ********************************************** Bob Herriot said: > >The following are possible solutions: > > 1) bad idea: solve the multiple-document-attribute problem > > 2) OK maybe: document-URI is an operation attribute that does > not stick to the job object. That is, Get-Attributes does not > return a document-URI created by a Send-URI operation. > Get-Attributes could return a document-URI value set by > Print-URI but it might seem strange that document-URI is > available for Print-URI jobs but not Create-Job/ Send-URI jobs. > > 3) OK maybe: eliminate Send-URI in version 1.0, but keep Print-URI which > doesn't have this problem.  From daemon Wed Oct 29 10:00:27 1997 Delivery-Date: Wed, 29 Oct 1997 10:07:53 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA17396 for ietf-123-outbound.10@ietf.org; Wed, 29 Oct 1997 09:59:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA17355; Wed, 29 Oct 1997 09:58:01 -0500 (EST) Message-Id: <199710291458.JAA17355@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-01.txt Date: Wed, 29 Oct 1997 09:57:57 -0500 Sender: cclark@cnri.reston.va.us --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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-01.txt Pages : 26 Date : 28-Oct-97 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. The full set of IPP documents includes: Internet Printing Protocol: 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 The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Oct 29 10:17:35 1997 Delivery-Date: Wed, 29 Oct 1997 10:17:35 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA18034 for ; Wed, 29 Oct 1997 10:17:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09685 for ; Wed, 29 Oct 1997 10:20:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA27445 for ; Wed, 29 Oct 1997 10:17:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Oct 1997 10:09:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26891 for ipp-outgoing; Wed, 29 Oct 1997 09:59:03 -0500 (EST) Message-Id: <199710291458.JAA17355@ietf.org> 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-protocol-01.txt Date: Wed, 29 Oct 1997 09:57:57 -0500 Sender: ipp-owner@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-01.txt Pages : 26 Date : 28-Oct-97 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. The full set of IPP documents includes: Internet Printing Protocol: 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 The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Oct 29 10:55:23 1997 Delivery-Date: Wed, 29 Oct 1997 10:55:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA18961 for ; Wed, 29 Oct 1997 10:55:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09813 for ; Wed, 29 Oct 1997 10:58:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA28097 for ; Wed, 29 Oct 1997 10:55:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Oct 1997 10:51:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27564 for ipp-outgoing; Wed, 29 Oct 1997 10:40:30 -0500 (EST) Mime-Version: 1.0 Date: Wed, 29 Oct 1997 10:40:05 -0500 Message-ID: <0002A713.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) To: ipp@pwg.org Subject: IPP> New protocol document? Content-Type: multipart/mixed; boundary="IMA.Boundary.004041878" Sender: ipp-owner@pwg.org --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part The new protocol document referred to by the recent posting (shown below) has the same date as the earlier protocol I-D (July 30). ______________________________ Forward Header __________________________________ Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-01.txt Author: Internet-Drafts@ietf.org at INTERNET Date: 10/29/97 9:57 AM 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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-01.txt Pages : 26 Date : 28-Oct-97 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. The full set of IPP documents includes: Internet Printing Protocol: 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 The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipp-protocol-01.txt" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: inline; filename="draft-ietf-ipp-protocol-01.txt" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> --IMA.Boundary.004041878-- From ipp-owner@pwg.org Thu Oct 30 00:24:47 1997 Delivery-Date: Thu, 30 Oct 1997 00:24:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA05197 for ; Thu, 30 Oct 1997 00:24:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12577 for ; Thu, 30 Oct 1997 00:27:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA29804 for ; Thu, 30 Oct 1997 00:24:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 00:16:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29231 for ipp-outgoing; Thu, 30 Oct 1997 00:05:43 -0500 (EST) Message-Id: <3.0.1.32.19971029210918.00fecaa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Oct 1997 21:09:18 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org NOTE: The file name is 01, not 02. This maybe because we didn't forward the 01 protocol document to the secretariate? The 02 file name appears on the Protocol document that Bob posted. So it looks like the secretariate updates the number by 1 each time, no matter what we say. To reduce confusion we should rename the 02 version to have a 1 plus additional words on our FTP server, like draft-ietf-ipp-protocol-01-published-i-d.txt. Then the next version can have 02 on it (again). Tom >Return-Path: >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-protocol-01.txt >Date: Wed, 29 Oct 1997 06:57:57 PST >Sender: ipp-owner@pwg.org > >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. Turner, R. Herriot, S. Butler, P. Moore > Filename : draft-ietf-ipp-protocol-01.txt > Pages : 26 > Date : 28-Oct-97 > >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. > >The full set of IPP documents includes: > > Internet Printing Protocol: 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 > >The requirements document takes a broad look at distributed printing >functionality, and it enumerates real-life scenarios that help to >clarify the features that need to be included in a printing protocol for >the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls >out a subset of end user requirements that MUST be satisfied in the >first version of IPP. Operator and administrator requirements are out >of scope for v1.0. The model and semantics document describes a >simplified model with abstract objects, their attributes, and their >operations. The model introduces a Printer object and a Job object. The >Job object supports multiple documents per job. The security document >covers potential threats and proposed counters to those threats. The >protocol specification is formal document which incorporates the ideas >in all the other documents into a concrete mapping using clearly defined >data representations and transport protocol mappings that real >implementers can use to develop interoperable client and server side >components. Finally, the directory schema document shows a generic >schema for directory service entries that represent instances of IPP >Printers. > >This document is the ''Internet Printing Protocol/1.0: Protocol >Specification'' document. > > >Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-01.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > From ipp-owner@pwg.org Thu Oct 30 00:35:50 1997 Delivery-Date: Thu, 30 Oct 1997 00:35:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA05375 for ; Thu, 30 Oct 1997 00:35:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12602 for ; Thu, 30 Oct 1997 00:38:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00421 for ; Thu, 30 Oct 1997 00:35:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 00:31:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29517 for ipp-outgoing; Thu, 30 Oct 1997 00:18:45 -0500 (EST) Message-Id: <3.0.1.32.19971029212232.00fecaa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Oct 1997 21:22:32 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I should have pulled the document from the IETF FTP server before sending the following message. The 01 file is from last July 30. I guess we haven't forwarded a new Protocol document since then. So 02 is the correct file name. But for some reason the 02 file is NOT on the IETF FTP servers. So disregard my suggestion about the file name. We need to query the IETF secretariat about this. Tom >Date: Wed, 29 Oct 1997 21:09:18 -0800 >To: ipp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt > >NOTE: The file name is 01, not 02. This maybe because we didn't forward >the 01 protocol document to the secretariate? The 02 file name appears >on the Protocol document that Bob posted. So it looks like the secretariate >updates the number by 1 each time, no matter what we say. > >To reduce confusion we should rename the 02 version to have a 1 plus additional >words on our FTP server, like draft-ietf-ipp-protocol-01-published-i-d.txt. Then the next version can have 02 on it (again). > >Tom > >>Return-Path: >>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-protocol-01.txt >>Date: Wed, 29 Oct 1997 06:57:57 PST >>Sender: ipp-owner@pwg.org >> >>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. Turner, R. Herriot, S. Butler, P. Moore >> Filename : draft-ietf-ipp-protocol-01.txt >> Pages : 26 >> Date : 28-Oct-97 >> >>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. >> >>The full set of IPP documents includes: >> >> Internet Printing Protocol: 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 >> >>The requirements document takes a broad look at distributed printing >>functionality, and it enumerates real-life scenarios that help to >>clarify the features that need to be included in a printing protocol for >>the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls >>out a subset of end user requirements that MUST be satisfied in the >>first version of IPP. Operator and administrator requirements are out >>of scope for v1.0. The model and semantics document describes a >>simplified model with abstract objects, their attributes, and their >>operations. The model introduces a Printer object and a Job object. The >>Job object supports multiple documents per job. The security document >>covers potential threats and proposed counters to those threats. The >>protocol specification is formal document which incorporates the ideas >>in all the other documents into a concrete mapping using clearly defined >>data representations and transport protocol mappings that real >>implementers can use to develop interoperable client and server side >>components. Finally, the directory schema document shows a generic >>schema for directory service entries that represent instances of IPP >>Printers. >> >>This document is the ''Internet Printing Protocol/1.0: Protocol >>Specification'' document. >> >> >>Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". >>A URL for the Internet-Draft is: >>ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt >> >>Internet-Drafts directories are located at: >> >> Africa: ftp.is.co.za >> >> Europe: ftp.nordu.net >> ftp.nis.garr.it >> >> Pacific Rim: munnari.oz.au >> >> US East Coast: ds.internic.net >> >> 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-01.txt". >> >>NOTE: The mail server at ds.internic.net can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >> From ipp-owner@pwg.org Thu Oct 30 00:52:11 1997 Delivery-Date: Thu, 30 Oct 1997 00:52:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA05422 for ; Thu, 30 Oct 1997 00:52:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12631 for ; Thu, 30 Oct 1997 00:55:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA01044 for ; Thu, 30 Oct 1997 00:52:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 00:47:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00486 for ipp-outgoing; Thu, 30 Oct 1997 00:36:54 -0500 (EST) Message-ID: <34581BE0.EF94D173@sharplabs.com> Date: Wed, 29 Oct 1997 21:32:16 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> FYI...on SSL Content-Type: multipart/mixed; boundary="------------7215BB89CEC7B735D3F379A5" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------7215BB89CEC7B735D3F379A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought some of you might want to know how SSL will be tunneled through firewalls for IPP.... Randy --------------7215BB89CEC7B735D3F379A5 Content-Type: text/html; charset=us-ascii; name="tunneling_ssl.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tunneling_ssl.html" Content-Base: "file:///C|/WINDOWS/DESKTOP/tunneling_s sl.html" Tunneling SSL Through a WWW Proxy
INTERNET-DRAFT
Expires: June 14, 1996
<draft-luotonen-ssl-tunneling-02.txt> 		        Ari Luotonen
Netscape Communications Corporation
December 14, 1995

Tunneling SSL Through a WWW Proxy

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Table of Contents

  • Overview
  • General Considerations
  • The CONNECT Method
  • Proxy Response
  • Security Considerations
  • Extensibility
Overview

The wide success of SSL (Secure Sockets Layer from Netscape Communications Corporation) has made it vital that the current WWW proxy protocol be extended to allow an SSL client to open a secure tunnel through the proxy.

The HTTPS protocol, which is just HTTP on top of SSL, can be proxied in the same way that currently other protocols are handled by the proxies: to have the proxy initiate a secure session with the remote HTTPS server, and then perform the HTTPS transaction. This is the way

Luotonen [Page 1]

SSL TUNNELING INTERNET-DRAFT December 1995

FTP and Gopher get handled by proxies, too. However, this approach has two disadvantages:

  • The connection between the client and the proxy is normal HTTP, and hence, not secure. This is, however, often acceptable if the clients are in a trusted subnet (behind a firewall).
  • The proxy will need to have full SSL implementation incorporated into it.
This document describes a way to do SSL tunneling without an implementation of SSL, in a way that is compatible with the current WWW proxy protocol (as defined by the HTTP/1.0 specification). The existing implementation of SSL tunneling in the Netscape Navigator and the Netscape Proxy Server conform to this specification. A patch implementing this feature also exists for the CERN proxy server (CERN httpd).

General Considerations

When tunneling SSL, the proxy must not have access to the data being transferred in either direction, for sake of security. The proxy merely knows the source and destination addresses, and possibly, if the proxy supports user authentication, the name of the requesting user.

In other words, there is a handshake between the client and the proxy to establish the connection between the client and the remote server through the proxy. In order to make this extension be backwords compatible, the handshake must be in the same format as HTTP/1.0 requests, so that proxies without support for this feature can still cleanly determine the request as impossible for them to service, and give proper error responses (rather than e.g. get hung on the connection).

SSL tunneling isn't really SSL specific -- it's a general way to have a third party establish a connection between two points, after which bytes are simply copied back and forth by this intermediary.

When SSL tunneling support is put into the SSL source code, it will work for any SSL enhanced application.

The CONNECT Method

The client connects to the proxy, and uses the CONNECT method to specify the hostname and the port number to connect to. The hostname

Luotonen [Page 2]

SSL TUNNELING INTERNET-DRAFT December 1995

and port number are separated by a colon, and both of them must be specified.

The host:port part is followed by a space and a string specifying the HTTP version number, e.g. HTTP/1.0, and the line terminator (CR LF pair, or a single LF).

After that there is a series of zero or more of HTTP request header lines, followed by an empty line. Each of those header lines is also terminated by the CR LF pair, or a single LF. The empty line is simply another CR LF pair, or another LF.

After the empty line, if the handshake to establish the connection was successful, SSL data transfer can begin.

Example:

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
The advantage of this approach is that this protocol is freely extensible; for example, the proxy authentication can be used.

Example:

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
Proxy-authorization: basic aGVsbG86d29ybGQ=
Proxy Response

After the empty line in the request, the client will wait for a response from the proxy. The proxy will evaluate the request, make sure that it is valid, and that the user is authorized to request such a connection. If everything is in order, the proxy will make a connection to the destination server, and, if successful, send a "200 Connection established" response to the client. Again, the response follows the HTTP/1.0 protocol, so the response line starts with the protocol version specifier, and the response line is followed by zero or more response headers, followed by an empty line. The line separator is CR LF pair, or a single LF.

Example:

HTTP/1.0 200 Connection established
Proxy-agent: Netscape-Proxy/1.1

Luotonen [Page 3]

SSL TUNNELING INTERNET-DRAFT December 1995

After the empty line, the proxy will start passing data from the client connection to the remote server connection, and vice versa. At any time, there may be data coming from either connection, and that data should be forwarded to the other connection immediately.

If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that peer undelivered, that data will be discarded.

Security Considerations

CONNECT is really a lower-level function than the rest of the HTTP methods, kind of an escape mechanism for saying that the proxy should not interfere with the transaction, but merely forward the data. This is because the proxy should not need to know the entire URI that is being accessed (privacy, security), only the information that it explicitly needs (hostname and port number). Due to this fact, the proxy cannot verify that the protocol being spoken is really SSL, and so the proxy configuration should explicitly limit allowed connections to well-known SSL ports (such as 443 for HTTPS, 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority).

Extensibility

The SSL tunneling handshake is freely extensible using the HTTP/1.0 headers; as an example, to enforce authentication for the proxy the proxy will simply use the 407 status code and the Proxy-authenticate response header (as defined by the HTTP/1.0 specification) to ask the client to send authentication information:

HTTP/1.0 407 Proxy authentication required
Proxy-authenticate: ...
The client would then send the authentication information in the Proxy-authorization header:
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: ...
Proxy-authorization: ...
Multiple Proxy Servers

Luotonen [Page 4]

SSL TUNNELING INTERNET-DRAFT December 1995

This specification applies also to proxy servers talking to other proxy servers. As an example, double firewalls make this necessary. In this case, the inner proxy is simply considered a client with respect to the outer proxy.

References
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0",
draft-ietf-http-v10-spec-04.html, October 14, 1995.
[SSL] K. Hickman, T. Elgamal, "The SSL Protocol",
draft-hickman-netscape-ssl-01.txt,
Netscape Communications Corporation, June 1995

Author's Address:

Ari Luotonen <ari@netscape.com>
Netscape Communications Corporation
501 E. Middlefield Road
Mountain View, CA 94043
USA

Luotonen [Page 5] --------------7215BB89CEC7B735D3F379A5-- From ipp-owner@pwg.org Thu Oct 30 13:53:33 1997 Delivery-Date: Thu, 30 Oct 1997 13:53:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA16391 for ; Thu, 30 Oct 1997 13:53:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14829 for ; Thu, 30 Oct 1997 13:56:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA02381 for ; Thu, 30 Oct 1997 13:53:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 13:42:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01791 for ipp-outgoing; Thu, 30 Oct 1997 13:31:37 -0500 (EST) Message-Id: <3.0.32.19971030102851.006bfae4@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Oct 1997 10:29:04 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP> MOD/PRO Should mediaType be mimeType in the Protocol spec? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, I just noticed that the protocol spec (23Oct97) lists a new mediaType value tag but does not contain a mime type value tag. Should the mediaType value tage be changed to mimeType? Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Thu Oct 30 16:59:49 1997 Delivery-Date: Thu, 30 Oct 1997 16:59:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA18923 for ; Thu, 30 Oct 1997 16:59:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15702 for ; Thu, 30 Oct 1997 17:02:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03990 for ; Thu, 30 Oct 1997 16:59:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 16:54:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03422 for ipp-outgoing; Thu, 30 Oct 1997 16:43:11 -0500 (EST) Message-Id: <3.0.32.19971030134042.00730a98@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Oct 1997 13:40:43 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP>MOD - Must charset and natural-language always be sent? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The latest model spec states that the attributes "attributes-charset" and "attributes-natural-language" are MANDATORY. Does this mean that they must be sent by the client even when the client does not send any text and/or name type attributes? Up until now, none of the IPP request operations had required attributes. I don't have an opinion one way or the other but I was assuming that some companies were pushing for no mandatory attributes on requests. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Thu Oct 30 17:48:13 1997 Delivery-Date: Thu, 30 Oct 1997 17:48:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19871 for ; Thu, 30 Oct 1997 17:47:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15897 for ; Thu, 30 Oct 1997 17:50:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA05046 for ; Thu, 30 Oct 1997 17:47:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 17:36:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04097 for ipp-outgoing; Thu, 30 Oct 1997 17:13:24 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 30 Oct 1997 15:12:13 -0700 From: Scott Isaacson To: rick@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP>MOD - Must charset and natural-language always be sent? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Yes they will always be sent. See the notes from the 10/29/97 IPP meetings and see the new document that will come out in the next few days. Scott >>> Rick Yardumian 10/30 2:40 PM >>> The latest model spec states that the attributes "attributes-charset" and "attributes-natural-language" are MANDATORY. Does this mean that they must be sent by the client even when the client does not send any text and/or name type attributes? Up until now, none of the IPP request operations had required attributes. I don't have an opinion one way or the other but I was assuming that some companies were pushing for no mandatory attributes on requests. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Thu Oct 30 17:49:47 1997 Delivery-Date: Thu, 30 Oct 1997 17:49:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19969 for ; Thu, 30 Oct 1997 17:49:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15905 for ; Thu, 30 Oct 1997 17:52:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA05339 for ; Thu, 30 Oct 1997 17:49:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Oct 1997 17:40:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04108 for ipp-outgoing; Thu, 30 Oct 1997 17:15:57 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 30 Oct 1997 15:15:09 -0700 From: Scott Isaacson To: rick@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD/PRO Should mediaType be mimeType in the Protocol spec? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org It should be mediaType, but since we already have "media" we will use "mimeMediaType" in both the Model and Protocol documents. See the meeting minutes from the 10/29/97 meeting and the new documents in the next few days. Scott >>> Rick Yardumian 10/30 11:29 AM >>> Hi, I just noticed that the protocol spec (23Oct97) lists a new mediaType value tag but does not contain a mime type value tag. Should the mediaType value tage be changed to mimeType? Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From jmp-owner@pwg.org Fri Oct 31 18:37:03 1997 Delivery-Date: Fri, 31 Oct 1997 18:37:03 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13902 for ; Fri, 31 Oct 1997 18:37:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20009 for ; Fri, 31 Oct 1997 18:40:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA07856 for ; Fri, 31 Oct 1997 18:36:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 18:31:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07336 for jmp-outgoing; Fri, 31 Oct 1997 18:28:39 -0500 (EST) Message-Id: <3.0.1.32.19971031151202.00b8cc60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 15:12:02 PST To: ipp@pwg.org, pwg@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org From: Carl-Uno Manros Subject: JMP> PING for Los Angeles Meeting December 1-5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From pmp-owner@pwg.org Fri Oct 31 18:39:53 1997 Delivery-Date: Fri, 31 Oct 1997 18:39:53 -0500 Return-Path: pmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13912 for ; Fri, 31 Oct 1997 18:39:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20021 for ; Fri, 31 Oct 1997 18:42:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA08146 for ; Fri, 31 Oct 1997 18:39:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 18:34:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07325 for pmp-outgoing; Fri, 31 Oct 1997 18:28:33 -0500 (EST) Message-Id: <3.0.1.32.19971031151202.00b8cc60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 15:12:02 PST To: ipp@pwg.org, pwg@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org From: Carl-Uno Manros Subject: PMP> PING for Los Angeles Meeting December 1-5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: pmp-owner@pwg.org Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From pwg-owner@pwg.org Fri Oct 31 18:45:33 1997 Delivery-Date: Fri, 31 Oct 1997 18:45:33 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13930 for ; Fri, 31 Oct 1997 18:45:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20030 for ; Fri, 31 Oct 1997 18:48:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA08721 for ; Fri, 31 Oct 1997 18:45:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 18:38:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07353 for pwg-outgoing; Fri, 31 Oct 1997 18:28:54 -0500 (EST) Message-Id: <3.0.1.32.19971031151202.00b8cc60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 15:12:02 PST To: ipp@pwg.org, pwg@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org From: Carl-Uno Manros Subject: PWG> PING for Los Angeles Meeting December 1-5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Oct 31 19:00:12 1997 Delivery-Date: Fri, 31 Oct 1997 19:00:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA13955 for ; Fri, 31 Oct 1997 19:00:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20067 for ; Fri, 31 Oct 1997 19:03:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09338 for ; Fri, 31 Oct 1997 19:00:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 18:51:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07370 for ipp-outgoing; Fri, 31 Oct 1997 18:29:11 -0500 (EST) Message-Id: <3.0.1.32.19971031151202.00b8cc60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 15:12:02 PST To: ipp@pwg.org, pwg@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org From: Carl-Uno Manros Subject: IPP> PING for Los Angeles Meeting December 1-5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Oct 31 19:37:20 1997 Delivery-Date: Fri, 31 Oct 1997 19:37:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14076 for ; Fri, 31 Oct 1997 19:37:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20148 for ; Fri, 31 Oct 1997 19:40:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09964 for ; Fri, 31 Oct 1997 19:37:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 19:32:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA09437 for ipp-outgoing; Fri, 31 Oct 1997 19:22:05 -0500 (EST) Message-Id: <3.0.1.32.19971031141209.00c38a80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 14:12:09 PST To: Robert.Herriot@Eng.Sun.COM, Scott_isaacson@novell.com From: Carl-Uno Manros Subject: IPP> Use of SSL3 Framing Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Bob, The decision to require SSL3 framing has a number of consequences which needs to be reflected in the Protocol document. Where you speak about Encoding of Transport Layer (lines 350 - 357), you now need to say that we are using the combination of SSL3/HTTP. The default port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: https (rather than http). All Printer-URI and Job-URIs will now start with "https://" Hope this reaches you in time to get these changes in. Scott may need to check for similar changes in the Model document. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Oct 31 20:15:05 1997 Delivery-Date: Fri, 31 Oct 1997 20:15:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14234 for ; Fri, 31 Oct 1997 20:15:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA20226 for ; Fri, 31 Oct 1997 20:18:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA10637 for ; Fri, 31 Oct 1997 20:15:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Oct 1997 20:10:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA10082 for ipp-outgoing; Fri, 31 Oct 1997 19:59:49 -0500 (EST) Message-Id: <3.0.1.32.19971031161951.009c0100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 16:19:51 PST To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, agenda@ietf.org From: Carl-Uno Manros Subject: IPP> Re: Washington Scheduling: My traditional message Cc: szilles@adobe.com, ipp@pwg.org In-Reply-To: <2444.877961250@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 06:07 AM 10/27/97 PST, you wrote: >OK, here it is: > >Please send in your requests to meet at the Washington IETF. > >I've been late - the stream of requests BEFORE I sent this out was >large enough to make me think it wasn't needed, but it seems that >it was. >There is not yet a preliminary agenda from the agenda keepers, so >I feel hesitant about announcing the track made so far - but you are >not forgotten! > >DO read the instructions from the IETF agenda keepers before sending >in a request - we DO use that information! > >The core is reproduced below. > >See you all in Washington! > > Harald A > ----- a. Working Group (or BOF) Name. Internet Printing Protocol (ipp) b. Area under which Working Group appears: Application c. Conflicts you wish to avoid: HTTP, IFAX, TLS d. Expected Attendance: 20 - 30 e. Any special requests: None f. Timeslot in preliminary schedule: December 10, 1997, 0900-1130 Agenda: Discuss any remaining issues associated with the IPP WG I-Ds: - Requirements for an Internet Printing Protocol or later - Internet Printing Protocol/1.0: Model and Semantics or later - Internet Printing Protocol/1.0: Protocol Specification or later - Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol or later - Mapping between LPD and IPP Protocols or later ----- Carl-Uno Manros Co-chair IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sat Nov 1 03:48:18 1997 Delivery-Date: Sat, 01 Nov 1997 03:48:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id DAA22892 for ; Sat, 1 Nov 1997 03:48:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA20810 for ; Sat, 1 Nov 1997 03:51:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA11623 for ; Sat, 1 Nov 1997 03:48:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 1 Nov 1997 03:43:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA11061 for ipp-outgoing; Sat, 1 Nov 1997 03:33:07 -0500 (EST) Message-ID: <345AE81E.4011A1D4@sharplabs.com> Date: Sat, 01 Nov 1997 00:28:14 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing References: <3.0.1.32.19971031141209.00c38a80@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org As an action item from the Boulder meeting, I am preparing a proposal document that addresses the order of operations for negotiating security. This document also discusses, in part, the use of URLs to designate security. A number of outside parties involved with security (TLS working group and others) will be reviewing this short document prior to distribution to the IPP working gruop at large. This is in order to save the IPP WG time reviewing and trying to understand something that is technically inaccurate. Carl Kugler at IBM has also volunteered to help review and verify a security negotitation proposal for IPP. One of the ideas expressed in this document is that the working group does not have to explicitly mandate the use of HTTPS for a security scheme. I will try to have this document out late next week. Randy Carl-Uno Manros wrote: > > Bob, > > The decision to require SSL3 framing has a number of consequences which > needs to be reflected in the Protocol document. > > Where you speak about Encoding of Transport Layer (lines 350 - 357), you > now need to say that we are using the combination of SSL3/HTTP. The default > port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: > https (rather than http). All Printer-URI and Job-URIs will now start with > "https://" > > Hope this reaches you in time to get these changes in. > > Scott may need to check for similar changes in the Model document. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sat Nov 1 14:29:16 1997 Delivery-Date: Sat, 01 Nov 1997 14:29:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA24047 for ; Sat, 1 Nov 1997 14:29:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21697 for ; Sat, 1 Nov 1997 14:32:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12777 for ; Sat, 1 Nov 1997 14:29:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 1 Nov 1997 14:11:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12137 for ipp-outgoing; Sat, 1 Nov 1997 14:00:12 -0500 (EST) Message-Id: <1.5.4.32.19971101175747.006752cc@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, 01 Nov 1997 09:57:47 -0800 To: Randy Turner From: Carl-Uno Manros Subject: Re: IPP> Use of SSL3 Framing Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Randy, This is probably a good idea. It would have been an even better idea if you had come up with it a month or so ago... Could you try to explain to us what the impact would be of this new document you plan to write. 1) Would it impact anything in our current Model and Protocol documents? 2) Would the new negotiation mechanism be mandatory for all IPP clients and servers? 3) Will this hold up our current plans for progressing the Model and Protocol documents? I think we all need quick answers to these questions. Thanks, Carl-Uno At 12:28 AM 11/1/97 -0800, you wrote: >As an action item from the Boulder meeting, I am preparing a >proposal document that addresses the order of operations for >negotiating security. This document also discusses, in part, >the use of URLs to designate security. A number of outside >parties involved with security (TLS working group and others) >will be reviewing this short document prior to distribution to >the IPP working gruop at large. This is in order to save the >IPP WG time reviewing and trying to understand something that >is technically inaccurate. Carl Kugler at IBM has also >volunteered to help review and verify a security >negotitation proposal for IPP. > >One of the ideas expressed in this document is that the >working group does not have to explicitly mandate the use >of HTTPS for a security scheme. > >I will try to have this document out late next week. > >Randy > > >Carl-Uno Manros wrote: >> >> Bob, >> >> The decision to require SSL3 framing has a number of consequences which >> needs to be reflected in the Protocol document. >> >> Where you speak about Encoding of Transport Layer (lines 350 - 357), you >> now need to say that we are using the combination of SSL3/HTTP. The default >> port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: >> https (rather than http). All Printer-URI and Job-URIs will now start with >> "https://" >> >> Hope this reaches you in time to get these changes in. >> >> Scott may need to check for similar changes in the Model document. >> >> Carl-Uno >> Carl-Uno Manros >> Principal Engineer - Advanced Printing Standards - Xerox Corporation >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Sat Nov 1 17:40:47 1997 Delivery-Date: Sat, 01 Nov 1997 17:40:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA24343 for ; Sat, 1 Nov 1997 17:40:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21880 for ; Sat, 1 Nov 1997 17:43:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13754 for ; Sat, 1 Nov 1997 17:40:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 1 Nov 1997 17:29:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13163 for ipp-outgoing; Sat, 1 Nov 1997 17:18:22 -0500 (EST) Message-ID: <345BA993.7344AC18@sharplabs.com> Date: Sat, 01 Nov 1997 14:13:40 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing References: <1.5.4.32.19971101175747.006752cc@pop3.holonet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The TLS/SSL encapsulation details should be included in the model document, so our security negotiation requirements are transport-independent. HTTP-specific security mechanisms should be discussed in the protocol document, with appropriate references to the model document. These additions will probably not make it into the working group last call, but definitely into the IETF last call well in advance of the December plenary. There should be no delays in going to proposed, unless valid negative comments are received during last call. Randy Carl-Uno Manros wrote: > > Randy, > > This is probably a good idea. It would have been an even better > idea if you had come up with it a month or so ago... > > Could you try to explain to us what the impact would be of this > new document you plan to write. > > 1) Would it impact anything in our current Model and Protocol > documents? > > 2) Would the new negotiation mechanism be mandatory for all > IPP clients and servers? > > 3) Will this hold up our current plans for progressing the Model > and Protocol documents? > > I think we all need quick answers to these questions. > > Thanks, > > Carl-Uno > > At 12:28 AM 11/1/97 -0800, you wrote: > >As an action item from the Boulder meeting, I am preparing a > >proposal document that addresses the order of operations for > >negotiating security. This document also discusses, in part, > >the use of URLs to designate security. A number of outside > >parties involved with security (TLS working group and others) > >will be reviewing this short document prior to distribution to > >the IPP working gruop at large. This is in order to save the > >IPP WG time reviewing and trying to understand something that > >is technically inaccurate. Carl Kugler at IBM has also > >volunteered to help review and verify a security > >negotitation proposal for IPP. > > > >One of the ideas expressed in this document is that the > >working group does not have to explicitly mandate the use > >of HTTPS for a security scheme. > > > >I will try to have this document out late next week. > > > >Randy > > > > > >Carl-Uno Manros wrote: > >> > >> Bob, > >> > >> The decision to require SSL3 framing has a number of consequences which > >> needs to be reflected in the Protocol document. > >> > >> Where you speak about Encoding of Transport Layer (lines 350 - 357), you > >> now need to say that we are using the combination of SSL3/HTTP. The default > >> port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: > >> https (rather than http). All Printer-URI and Job-URIs will now start with > >> "https://" > >> > >> Hope this reaches you in time to get these changes in. > >> > >> Scott may need to check for similar changes in the Model document. > >> > >> Carl-Uno > >> Carl-Uno Manros > >> Principal Engineer - Advanced Printing Standards - Xerox Corporation > >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > >> Phone +1-310-333 8273, Fax +1-310-333 5514 > >> Email: manros@cp10.es.xerox.com > > > > From daemon Mon Nov 3 10:19:28 1997 Delivery-Date: Mon, 03 Nov 1997 10:28:36 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA14199 for ietf-123-outbound.10@ietf.org; Mon, 3 Nov 1997 10:19:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14180; Mon, 3 Nov 1997 10:19:06 -0500 (EST) Message-Id: <199711031519.KAA14180@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-02.txt Date: Mon, 03 Nov 1997 10:19:05 -0500 Sender: cclark@cnri.reston.va.us --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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-02.txt Pages : 33 Date : 31-Oct-97 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Internet Printing Protocol: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971031182025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971031182025.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Nov 3 10:37:53 1997 Delivery-Date: Mon, 03 Nov 1997 10:37:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14550 for ; Mon, 3 Nov 1997 10:37:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02764 for ; Mon, 3 Nov 1997 10:40:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA18435 for ; Mon, 3 Nov 1997 10:37:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 10:30:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA17899 for ipp-outgoing; Mon, 3 Nov 1997 10:19:16 -0500 (EST) Message-Id: <199711031519.KAA14180@ietf.org> 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-protocol-02.txt Date: Mon, 03 Nov 1997 10:19:05 -0500 Sender: ipp-owner@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-02.txt Pages : 33 Date : 31-Oct-97 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Internet Printing Protocol: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971031182025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971031182025.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Nov 3 11:43:43 1997 Delivery-Date: Mon, 03 Nov 1997 11:43:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15880 for ; Mon, 3 Nov 1997 11:43:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03172 for ; Mon, 3 Nov 1997 11:46:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19102 for ; Mon, 3 Nov 1997 11:43:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 11:39:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA18577 for ipp-outgoing; Mon, 3 Nov 1997 11:28:26 -0500 (EST) From: don@lexmark.com Message-Id: <199711031628.AA13151@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 3 Nov 1997 11:28:12 -0500 Subject: IPP> Conference Calls Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I have set up three more conference calls as follows. I did not set up a call for November 26th as it is the day before Thanksgiving. Call dates: 11/5, 11/12, 11/19 Dial-in: 608-250-1828 Time: 4PM EST (1PM PST) Duration: 2 hours Access Code: 190148 Considering where we are with IPP and that the first two weeks of December are IPP and IETF meetings, we need to consider the need for these calls for the remainder of 1997. 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) * ********************************************** From jmp-owner@pwg.org Mon Nov 3 16:12:09 1997 Delivery-Date: Mon, 03 Nov 1997 16:12:09 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21124 for ; Mon, 3 Nov 1997 16:12:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04473 for ; Mon, 3 Nov 1997 16:15:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20095 for ; Mon, 3 Nov 1997 16:11:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 16:06:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19587 for jmp-outgoing; Mon, 3 Nov 1997 16:03:23 -0500 (EST) From: don@lexmark.com Message-Id: <199711032102.AA28468@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, P1394@pwg.org, sense@pwg.org Date: Mon, 3 Nov 1997 16:02:50 -0500 Subject: JMP> December Meeting in LA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, here's my first pass at a meeting schedule for the December meeting. Dec 1, 2 - 1394 Printing Dec 3 - IPP Dec 4 - SENSE Dec 5 - FIN I will issue a final agenda on or about November 24th. 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) * ********************************************** From pwg-owner@pwg.org Mon Nov 3 16:24:15 1997 Delivery-Date: Mon, 03 Nov 1997 16:24:15 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21288 for ; Mon, 3 Nov 1997 16:24:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04521 for ; Mon, 3 Nov 1997 16:27:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20963 for ; Mon, 3 Nov 1997 16:24:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 16:15:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19637 for pwg-outgoing; Mon, 3 Nov 1997 16:03:59 -0500 (EST) From: don@lexmark.com Message-Id: <199711032102.AA28468@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, P1394@pwg.org, sense@pwg.org Date: Mon, 3 Nov 1997 16:02:50 -0500 Subject: PWG> December Meeting in LA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, here's my first pass at a meeting schedule for the December meeting. Dec 1, 2 - 1394 Printing Dec 3 - IPP Dec 4 - SENSE Dec 5 - FIN I will issue a final agenda on or about November 24th. 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) * ********************************************** From ipp-owner@pwg.org Mon Nov 3 16:28:46 1997 Delivery-Date: Mon, 03 Nov 1997 16:28:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21332 for ; Mon, 3 Nov 1997 16:28:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04559 for ; Mon, 3 Nov 1997 16:31:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21288 for ; Mon, 3 Nov 1997 16:28:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 16:18:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19557 for ipp-outgoing; Mon, 3 Nov 1997 15:56:21 -0500 (EST) Message-Id: <199711032050.FAA11804@jci.co.jp> X-My-Real-Login-Name: sasaki; post.jci.co.jp MIME-Version: 1.0 X-Mailer: Denshin 8 Go V321.1b7 Date: Mon, 03 Nov 1997 12:59:09 -0700 From: Yuji Sasaki To: ipp@pwg.org Subject: IPP> ASIAN languages in IPP. Sender: ipp-owner@pwg.org Dear IPP members, I'm still concerning what language should be used when the text attributes becomes mixed language, such as :"%%[PrinterError:Offending command while printing file ******.ps%%]" (please assume ***** as a Japanese kanji anything you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be English, Japanese, or we don't have to care?? I have another concern to use Unicode in multilanguage environment. I know it is a IPP client/browser issue more than a protocol issue, But it is improtant for Asian like me. We have at least three Kanji codes: Chinese, Japanese, and Korean. But in the specification of ISO10646-1(UCS-4), most of them were combined into a sigle page, called "CJK charcter set". The problem is, some of Kanji charcters in CJK are "Looks similer" but have defferent "faces" depending on the language which the charcter "belongs to". In extreme cases, one string can include several languages like: The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo". ~~~~~~~~~~~~~ ~~~~~~~~~~~~ (Chinese Kanji) (Japanese Kanji) In that case, even RFC2069 (Adding a language information to each strings) is not enough. Much less, current version of IPP could have only one language information for all text attributes within a session. In HTML4.0, "LANG" tag is defined so we can describe like: The document named Woo Hoi Chang was printed from Aoyama Tokyo. But I don't feel like to use HTML as IPP 1.0 presentation layer, it's too heavy to implement for clients. Practically, we Asian can know what does the word mean evenif the details are slightly different (like you guys can know "colour" is the same word as "color"). And I think we will implement CJK difference as "assuming native language". In the case above, all kanjis will be displaied as "Japanese Kanjis" in Japan, and will be "Chinese Kanjis" in China. But the problem still remains, especially for describing human names or name of places. We have to know EXCACTLY CORRECT kanjis to identify the particular persons/places, mostly because historical reasons. Like in English, "Colour" and "Color" is the same but "Kristen" and "Cristen" are definitely different. Unfortunatelly, we don't have the standard method to use CJK in multi- language environment(except HTML4). Even in a single language(e.g Japanese), we are still strugging to use too many charcters in the limited capacity of Unicode CJK. Do you think it is okay to use "native language" as default language to handle CJK charcters (in other words, "depends on implementation")? I think we have no alternetive other than it. This will spoil the excact international interoperability from IPP, but the problem is rooted on Unicode CJK itself, not the matter of IPP. I hope future version of IPP (and Unicode) will solve this problem. Sorry for persistance of this issue and (I gueess) make you guys confused. But I'm afraid if IETF people point out that it is unclear how to handle CJK charcters in IPP specification. Well, it is clear. Just say, "Depends on implementation" ;-). Sincerely, -------- Yuji Sasaki E-Mail:sasaki@jci.co.jp From ipp-owner@pwg.org Mon Nov 3 16:35:16 1997 Delivery-Date: Mon, 03 Nov 1997 16:35:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21473 for ; Mon, 3 Nov 1997 16:35:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04609 for ; Mon, 3 Nov 1997 16:38:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21905 for ; Mon, 3 Nov 1997 16:35:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 16:31:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19606 for ipp-outgoing; Mon, 3 Nov 1997 16:03:39 -0500 (EST) From: don@lexmark.com Message-Id: <199711032102.AA28468@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, P1394@pwg.org, sense@pwg.org Date: Mon, 3 Nov 1997 16:02:50 -0500 Subject: IPP> December Meeting in LA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting, here's my first pass at a meeting schedule for the December meeting. Dec 1, 2 - 1394 Printing Dec 3 - IPP Dec 4 - SENSE Dec 5 - FIN I will issue a final agenda on or about November 24th. 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) * ********************************************** From ipp-owner@pwg.org Mon Nov 3 19:20:56 1997 Delivery-Date: Mon, 03 Nov 1997 19:20:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24016 for ; Mon, 3 Nov 1997 19:20:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05216 for ; Mon, 3 Nov 1997 19:23:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA22811 for ; Mon, 3 Nov 1997 19:20:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Nov 1997 19:14:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22262 for ipp-outgoing; Mon, 3 Nov 1997 19:03:57 -0500 (EST) Message-Id: <3.0.1.32.19971103154805.00a6ab40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 3 Nov 1997 15:48:05 PST To: Yuji Sasaki From: Carl-Uno Manros Subject: Re: IPP> ASIAN languages in IPP. Cc: ipp@pwg.org In-Reply-To: <199711032050.FAA11804@jci.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Yuki, Formally, we can allow any character set allowed by the whole ISO 10646 standard over the IPP protocol, not only the UNICODE subset. Does that solve your problem? My expectation though, is that nobody will actually support the full ISO 10646 in a workstation. If the USA and Europe supports Unicode, is there another subset that you would implement in Japanese or Chinese language workstations? Carl-Uno At 11:59 AM 11/3/97 PST, you wrote: >Dear IPP members, > > I'm still concerning what language should be used when the text attributes >becomes mixed language, such as :"%%[PrinterError:Offending command while >printing file ******.ps%%]" (please assume ***** as a Japanese kanji anything >you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be English, >Japanese, or we don't have to care?? > > I have another concern to use Unicode in multilanguage environment. >I know it is a IPP client/browser issue more than a protocol issue, >But it is improtant for Asian like me. > > We have at least three Kanji codes: Chinese, Japanese, and Korean. But >in the specification of ISO10646-1(UCS-4), most of them were combined into >a sigle page, called "CJK charcter set". > The problem is, some of Kanji charcters in CJK are "Looks similer" but >have defferent "faces" depending on the language which the charcter >"belongs to". > > In extreme cases, one string can include several languages like: > >The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo". > ~~~~~~~~~~~~~ ~~~~~~~~~~~~ > (Chinese Kanji) (Japanese Kanji) > > In that case, even RFC2069 (Adding a language information to each strings) >is not enough. Much less, current version of IPP could have only one >language information for all text attributes within a session. > >In HTML4.0, "LANG" tag is defined so we can describe like: > >The document named Woo Hoi Chang was printed from >Aoyama Tokyo. > > But I don't feel like to use HTML as IPP 1.0 presentation layer, it's too >heavy to implement for clients. > > Practically, we Asian can know what does the word mean evenif the details >are slightly different (like you guys can know "colour" is the same word >as "color"). > And I think we will implement CJK difference as "assuming native language". >In the case above, all kanjis will be displaied as "Japanese Kanjis" in Japan, >and will be "Chinese Kanjis" in China. > > But the problem still remains, especially for describing human names or >name of places. We have to know EXCACTLY CORRECT kanjis to identify the >particular persons/places, mostly because historical reasons. Like in >English, "Colour" and "Color" is the same but "Kristen" and "Cristen" are >definitely different. > Unfortunatelly, we don't have the standard method to use CJK in multi- >language environment(except HTML4). Even in a single language(e.g Japanese), >we are still strugging to use too many charcters in the limited capacity >of Unicode CJK. > > Do you think it is okay to use "native language" as default language to >handle CJK charcters (in other words, "depends on implementation")? > I think we have no alternetive other than it. This will spoil the excact >international interoperability from IPP, but the problem is rooted on >Unicode CJK itself, not the matter of IPP. I hope future version of IPP >(and Unicode) will solve this problem. > > Sorry for persistance of this issue and (I gueess) make you guys confused. >But I'm afraid if IETF people point out that it is unclear how to handle >CJK charcters in IPP specification. > >Well, it is clear. Just say, "Depends on implementation" ;-). > >Sincerely, >-------- >Yuji Sasaki >E-Mail:sasaki@jci.co.jp > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Nov 4 11:42:11 1997 Delivery-Date: Tue, 04 Nov 1997 11:42:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA08609 for ; Tue, 4 Nov 1997 11:42:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07291 for ; Tue, 4 Nov 1997 11:45:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24180 for ; Tue, 4 Nov 1997 11:42:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 11:32:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23645 for ipp-outgoing; Tue, 4 Nov 1997 11:21:07 -0500 (EST) Message-Id: <3.0.1.32.19971104082415.01069560@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 08:24:15 PST To: Scott Isaacson , rick@cp10.es.xerox.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD - Must charset and natural-language always besent? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Rick, To further amplify Scott's reply: The reason why the client MUST always send the attributes-natural-language and attributes-charset, even though the client is NOT submittig any 'text' and 'name' attributes, is that the Printer object may be returning a 'text' and/or a 'name' attribute in the response, such as job-state-message or may be returning a Error Message, in case the request is rejected. So the Printer object needs to know what language and charset to use in the response. Also (in the future) when we get notification, it will be important for the notification to know what language and charset to use for the notification, so that the values passed in by the client MUST be stored with the job. Storing the values also helps when other clients (who may be in different locales) query the job. Tom At 14:12 10/30/1997 PST, Scott Isaacson wrote: >Yes they will always be sent. See the notes from the 10/29/97 IPP meetings >and see the new >document that will come out in the next few days. > >Scott > > >>>> Rick Yardumian 10/30 2:40 PM >>> >The latest model spec states that the attributes "attributes-charset" and >"attributes-natural-language" are MANDATORY. Does this mean that they must >be sent by the client even when the client does not send any text and/or >name type attributes? Up until now, none of the IPP request operations had >required attributes. I don't have an opinion one way or the other but I was >assuming that some companies were pushing for no mandatory attributes on >requests. > >Rick >______________________________________________________________________ >Rick Yardumian >Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 >Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 >701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com >El Segundo, CA 90245 >______________________________________________________________________ > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Tue Nov 4 12:40:47 1997 Delivery-Date: Tue, 04 Nov 1997 12:40:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09197 for ; Tue, 4 Nov 1997 12:40:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07513 for ; Tue, 4 Nov 1997 12:43:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25435 for ; Tue, 4 Nov 1997 12:40:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 12:36:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24882 for ipp-outgoing; Tue, 4 Nov 1997 12:25:28 -0500 (EST) Message-Id: <3.0.1.32.19971104092849.0106c100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 09:28:49 PST To: Yuji Sasaki , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> ASIAN languages in IPP. In-Reply-To: <199711032050.FAA11804@jci.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:59 11/03/1997 PST, Yuji Sasaki wrote: >Dear IPP members, > > I'm still concerning what language should be used when the text attributes >becomes mixed language, such as :"%%[PrinterError:Offending command while >printing file ******.ps%%]" (please assume ***** as a Japanese kanji anything >you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be English, >Japanese, or we don't have to care?? Interesting question, since an error message attribute could have such an example. Lets assume that the user submitted the request and specified that Japanese was the natural language, because the client submitted the "attributes-natural-language" with the value 'jp' (is that the correct language code for Japanese?) and the "attributes-charset" with, say, 'utf-8'. Then there is no ambiguity in your example. The Japanese glyphs, not the Chinese glyphs, will be chosen for the file name. The Printer object should have responded with the entire string in Japanese, not just the file name. However, I realize that PostScript only returns English error message text. However, I suspect that we don't really have a problem with IPP, if the message is in a charset that supports ASCII characers and Kanji, such as UTF-8, Shift JIS, or EUC JIS, since the first part of your example message would be "ASCII" characters, which even in Japanese are displayed as: %%[PrinterError:Offending command while printing file If the Printer object also supports one of the Japanese charsets, such as: 'JIS_C6226-1983' or 'JIS_X0212-1990' or 'Shift_JIS' or 'EUC-JP' or 'Windows-31J' there also is no problem, because they all contain ASCII characters for the english part of your example. Thus the client could have supplied one of these charset values, provided that the Printer object also supported it. PROPOSAL FOR AFTER IPP V1.0: After version 1.0 of IPP is forwarded, I'd like to see us register two new Job Description attributes that contain error messages encountered during processing, such as the one in your example. One attribute would have a 'keyword' value for programs, and the other would have a 'text' value for human users. Maybe they should be multi-valued, so that an implementation could indicate a number of problems if the implementation wanted, but would not be required to. Perhaps, call these attributes: job-processing-error-id (1setOf type3 keyword) This attribute indicates one (or more) errors encountered during the processing of the job. The intent of this attribute is for program consumption while the intent of the corresponding "job-processing-error-message" is for human consumption. job-processing-error-message (1setOf 'text) This attribute indicates one (or more) errors encountered during the processing of the job. The intent of this attribute is for human consumption while the intent of the corresponding "job-processing-error-id" is for program consumption. ISSUES for discusion would include: 1. Do we want to include warnings or not. If so, how are they indicated? Do all keywords have the suffix "-error" or "-warning" in them? 2. In order to improve interoperability, we should list a whole bunch of keywords with the registration of this attribute. This is why we can't take the time now for IPP V1.0 for this attribute. 3. Should the type of the keyword be type2 so that review could eliminate duplicates, or type 3 so that there is no review after our initial set). > > I have another concern to use Unicode in multilanguage environment. >I know it is a IPP client/browser issue more than a protocol issue, >But it is improtant for Asian like me. > > We have at least three Kanji codes: Chinese, Japanese, and Korean. But >in the specification of ISO10646-1(UCS-4), most of them were combined into >a sigle page, called "CJK charcter set". > The problem is, some of Kanji charcters in CJK are "Looks similer" but >have defferent "faces" depending on the language which the charcter >"belongs to". > > In extreme cases, one string can include several languages like: > >The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo". > ~~~~~~~~~~~~~ ~~~~~~~~~~~~ > (Chinese Kanji) (Japanese Kanji) Such an example could even occur in IPP attributes, if the error message was in, say, Japanese, but the file name was in, say, Chinese. However, the chances are small and so the file name would get presented in Japanese, instead of Chinese. The most likely occurrence of mixed Chinese and Japanese would be in the document data itself, which is a problem for the document format specifications, such as HTML and PostScript, not for IPP. The 'text/plain' document format would not be able to distinguish the Chinese from the Japanese. > > In that case, even RFC2069 (Adding a language information to each strings) >is not enough. Much less, current version of IPP could have only one >language information for all text attributes within a session. > >In HTML4.0, "LANG" tag is defined so we can describe like: > >The document named Woo Hoi Chang was printed from >Aoyama Tokyo. > > But I don't feel like to use HTML as IPP 1.0 presentation layer, it's too >heavy to implement for clients. Agreed. > > Practically, we Asian can know what does the word mean evenif the details >are slightly different (like you guys can know "colour" is the same word >as "color"). > And I think we will implement CJK difference as "assuming native language". >In the case above, all kanjis will be displaied as "Japanese Kanjis" in Japan, >and will be "Chinese Kanjis" in China. > > But the problem still remains, especially for describing human names or >name of places. We have to know EXCACTLY CORRECT kanjis to identify the >particular persons/places, mostly because historical reasons. Like in >English, "Colour" and "Color" is the same but "Kristen" and "Cristen" are >definitely different. > Unfortunatelly, we don't have the standard method to use CJK in multi- >language environment(except HTML4). Even in a single language(e.g Japanese), >we are still strugging to use too many charcters in the limited capacity >of Unicode CJK. Fortunately, for IPP, each 'name' attribute is separate, and so can have its own "override natural-language", so that a job can contain 'name' attributes in different languages. > > Do you think it is okay to use "native language" as default language to >handle CJK charcters (in other words, "depends on implementation")? So the client requests attributes to be returned in the user's natural language, say, Japanese. If the message contains ASCII characters, they should be displayed correctly. They could even contain accented Latin characters, or Cyrillic charactes. Its only for the CJK characters that the ambiguity becomes a problem. But the Japanese user requesting IPP attributes from a job with one or more Chinese name attributes, could still present each Chinese name in the correct Chinese glyphs to the Japanese user, becuase the IPP Printer returns the natural-language override on the name attributes indicating that the name is in Chinese, not Japanese as requested. Ok? > I think we have no alternetive other than it. This will spoil the excact >international interoperability from IPP, but the problem is rooted on >Unicode CJK itself, not the matter of IPP. I hope future version of IPP >(and Unicode) will solve this problem. See if my explanation solves your problem. We hope it does, since that is why we included the override mechanism in IPP/1.0. > > Sorry for persistance of this issue and (I gueess) make you guys confused. >But I'm afraid if IETF people point out that it is unclear how to handle >CJK charcters in IPP specification. > >Well, it is clear. Just say, "Depends on implementation" ;-). > >Sincerely, >-------- >Yuji Sasaki >E-Mail:sasaki@jci.co.jp > > > From ipp-owner@pwg.org Tue Nov 4 14:38:36 1997 Delivery-Date: Tue, 04 Nov 1997 14:38:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA11178 for ; Tue, 4 Nov 1997 14:38:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA07976 for ; Tue, 4 Nov 1997 14:41:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27060 for ; Tue, 4 Nov 1997 14:38:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 14:30:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA25902 for ipp-outgoing; Tue, 4 Nov 1997 14:09:51 -0500 (EST) Message-Id: <199711041859.DAA28393@jci.co.jp> X-My-Real-Login-Name: sasaki; post.jci.co.jp MIME-Version: 1.0 X-Mailer: Denshin 8 Go V321.1b7 Date: Tue, 04 Nov 1997 11:08:31 -0700 From: Yuji Sasaki To: Tom Hastings , Yuji Sasaki , ipp@pwg.org In-Reply-To: Your message of "Tue, 4 Nov 1997 09:28:49 PST" <3.0.1.32.19971104092849.0106c100@garfield> References: <3.0.1.32.19971104092849.0106c100@garfield> Subject: Re: IPP> ASIAN languages in IPP. Sender: ipp-owner@pwg.org Hello, Tom. >The Printer object should have responded with the entire string in >Japanese, not just the file name. However, I realize that PostScript >only returns English error message text. However, I suspect that >we don't really have a problem with IPP, if the message is in a >charset that supports ASCII characers and Kanji, such as UTF-8, Shift JIS, or >EUC JIS, since the first part of your example message would be >"ASCII" characters, which even in Japanese are displayed as: > > %%[PrinterError:Offending command while printing file > >If the Printer object also supports one of the Japanese charsets, such as: >'JIS_C6226-1983' or 'JIS_X0212-1990' or 'Shift_JIS' or 'EUC-JP' >or 'Windows-31J' there also is no problem, because they all contain >ASCII characters for the english part of your example. Thus the client >could have supplied one of these charset values, provided that the >Printer object also supported it. Do you mean I can use language as "Japanese" even if the whole text was alphabetical because it could be displayed? >> In extreme cases, one string can include several languages like: >> >>The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo". >> ~~~~~~~~~~~~~ ~~~~~~~~~~~~ >> (Chinese Kanji) (Japanese Kanji) > >Such an example could even occur in IPP attributes, if the error >message was in, say, Japanese, but the file name was in, say, Chinese. >However, the chances are small and so the file name would get presented >in Japanese, instead of Chinese. > >The most likely occurrence of mixed Chinese and Japanese would be >in the document data itself, which is a problem for the document format >specifications, such as HTML and PostScript, not for IPP. I think so. The example above is an extreme case, not usual. >> Practically, we Asian can know what does the word mean evenif the details >>are slightly different (like you guys can know "colour" is the same word >>as "color"). >> And I think we will implement CJK difference as "assuming native language". >>In the case above, all kanjis will be displaied as "Japanese Kanjis" in >Japan, >>and will be "Chinese Kanjis" in China. >> >> But the problem still remains, especially for describing human names or >>name of places. We have to know EXCACTLY CORRECT kanjis to identify the >>particular persons/places, mostly because historical reasons. Like in >>English, "Colour" and "Color" is the same but "Kristen" and "Cristen" are >>definitely different. >> Unfortunatelly, we don't have the standard method to use CJK in multi- >>language environment(except HTML4). Even in a single language(e.g Japanese), >>we are still strugging to use too many charcters in the limited capacity >>of Unicode CJK. > >Fortunately, for IPP, each 'name' attribute is separate, and so can have >its own "override natural-language", so that a job can contain 'name' >attributes in different languages. I checked out the model document(model-06.txt) but I couldn't found "override language" description. >> Do you think it is okay to use "native language" as default language to >>handle CJK charcters (in other words, "depends on implementation")? > >So the client requests attributes to be returned in the user's natural >language, say, Japanese. If the message contains ASCII characters, >they should be displayed correctly. They could even contain accented >Latin characters, or Cyrillic charactes. Its only for the CJK characters >that the ambiguity becomes a problem. But the Japanese user requesting >IPP attributes from a job with one or more Chinese name attributes, could >still present each Chinese name in the correct Chinese glyphs to the >Japanese user, becuase the IPP Printer returns the natural-language >override on the name attributes indicating that the name is in Chinese, >not Japanese as requested. Ok? I'm sorry I don't understand what do you mean with "natural-language override". Does it mean IPP server could have several "text" values according to the language for single atrribute? -------- Yuji Sasaki E-Mail:sasaki@jci.co.jp From ipp-owner@pwg.org Tue Nov 4 14:38:38 1997 Delivery-Date: Tue, 04 Nov 1997 14:38:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA11183 for ; Tue, 4 Nov 1997 14:38:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA07977 for ; Tue, 4 Nov 1997 14:41:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27065 for ; Tue, 4 Nov 1997 14:38:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 14:31:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA25822 for ipp-outgoing; Tue, 4 Nov 1997 14:08:36 -0500 (EST) Message-Id: <199711041859.DAA28390@jci.co.jp> X-My-Real-Login-Name: sasaki; post.jci.co.jp MIME-Version: 1.0 X-Mailer: Denshin 8 Go V321.1b7 Date: Tue, 04 Nov 1997 11:08:21 -0700 From: Yuji Sasaki To: Carl-Uno Manros , Yuji Sasaki Cc: ipp@pwg.org In-Reply-To: Your message of "Mon, 3 Nov 1997 15:48:05 PST" <3.0.1.32.19971103154805.00a6ab40@garfield> References: <3.0.1.32.19971103154805.00a6ab40@garfield> Subject: Re: IPP> ASIAN languages in IPP. Sender: ipp-owner@pwg.org Thanks, >Formally, we can allow any character set allowed by the whole ISO 10646 >standard over the IPP protocol, not only the UNICODE subset. Does that >solve your problem? My expectation though, is that nobody will actually >support the full ISO 10646 in a workstation. If the USA and Europe supports >Unicode, is there another subset that you would implement in Japanese or >Chinese language workstations? I checked out the IPP model document, then realized that "attributes- charset" is not limited only to use UTF-8, but "SHALL" support it. I also found a syntax error at Line 1154 in draft-ietf-ipp-model-06.txt (raw text version), "attributescharset" should be "attributes-charset" . -------- Yuji Sasaki E-Mail:sasaki@jci.co.jp From ipp-owner@pwg.org Tue Nov 4 15:49:01 1997 Delivery-Date: Tue, 04 Nov 1997 15:49:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA12100 for ; Tue, 4 Nov 1997 15:48:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08333 for ; Tue, 4 Nov 1997 15:51:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA27976 for ; Tue, 4 Nov 1997 15:48:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 15:44:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27419 for ipp-outgoing; Tue, 4 Nov 1997 15:32:56 -0500 (EST) Message-Id: <3.0.1.32.19971104121658.00c7c490@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 12:16:58 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> TES - Info about IPP prototype from IBM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The prototype software from IBM, mentioned in the PWG meeting in Boulder last week is now available at: http://www.printers.ibm.com/ipp/ipp.html The prototype is limited to just the Print-Job operation, but it is a start. Carl-uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Nov 4 16:32:25 1997 Delivery-Date: Tue, 04 Nov 1997 16:32:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA12568 for ; Tue, 4 Nov 1997 16:32:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA08504 for ; Tue, 4 Nov 1997 16:35:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28720 for ; Tue, 4 Nov 1997 16:32:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 16:28:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28178 for ipp-outgoing; Tue, 4 Nov 1997 16:17:20 -0500 (EST) Message-Id: <3.0.1.32.19971104130117.009cf5d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 13:01:17 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 971105 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference 971105, 1:00 - 3:00 pm PST I do not have a lot of an agenda at this stage, but expect to give a short report from the Boulder for those of you who were not there and check up on the latest status of the editing work. This might be a short conference, unless something new shows up before tomorrow. The details are as follows: Call date: 11/5 Dial-in: 608-250-1828 Time: 4PM EST (1PM PST) Duration: 2 hours Access Code: 190148 Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Nov 4 21:40:18 1997 Delivery-Date: Tue, 04 Nov 1997 21:40:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15850 for ; Tue, 4 Nov 1997 21:40:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA09253 for ; Tue, 4 Nov 1997 21:43:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29965 for ; Tue, 4 Nov 1997 21:40:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Nov 1997 21:35:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29437 for ipp-outgoing; Tue, 4 Nov 1997 21:24:20 -0500 (EST) Message-ID: <345F8187.CF8ECEEF@parc.xerox.com> Date: Tue, 4 Nov 1997 12:11:51 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Yuji Sasaki CC: ipp@pwg.org Subject: Re: IPP> ASIAN languages in IPP. References: <199711032050.FAA11804@jci.co.jp> Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA15850 > I'm still concerning what language should be used when the text attributes > becomes mixed language, such as :"%%[PrinterError:Offending command while > printing file ******.ps%%]" (please assume ***** as a Japanese kanji anything > you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be English, > Japanese, or we don't have to care?? I just want to point out that this is not just an 'ASIAN language' issue. The content-language attribute of a string is used for a variety of purposes, such as determining hyphenation (German and French and English hyphenate differently), as an aid in text-to-speech translation, as well as a way of controlling presentation (such as might occur with Chinese and Japanese language strings.) As you point out, simple text strings have no way to indicate in-line language shifts. The same problem would occur, for example, if a message were both in French and English, and was sent to a text-to-speech processor without further annotation. As you say, a technical solution (use HTML instead of text) might well be to allow additional markup, the cost of supporting that markup for simple strings returned from printer errors might be higher than we want to impose on simple clients. > But the problem still remains, especially for describing human names or > name of places. We have to know EXCACTLY CORRECT kanjis to identify the > particular persons/places, mostly because historical reasons. Most of the discussions I've seen on this issue (on many mailing lists) have actually petered out because there has never been a realistic example submitted; the issue seems to be theoretical and political rather than practical. For example, do you actually have a client that supports both renderings of characters that would otherwise be ambiguous, and scenerio in which the difference matters, or is it just a theoretical matter? Martin Duerst, Martin Dürst, which one do you mean? But of course, he puts up with being mis-identified. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Nov 5 06:00:16 1997 Delivery-Date: Wed, 05 Nov 1997 06:00:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id GAA25313 for ; Wed, 5 Nov 1997 06:00:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA10139 for ; Wed, 5 Nov 1997 06:03:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA01156 for ; Wed, 5 Nov 1997 06:00:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 05:55:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA00614 for ipp-outgoing; Wed, 5 Nov 1997 05:44:00 -0500 (EST) Message-Id: <3.0.1.32.19971105024734.00d05ce0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 5 Nov 1997 02:47:34 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Minutes of 10/29 - 10/30 IPP Meeting, Boulder Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA25313 I've posted the Minutes in: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-minutes-971029.doc .pdf .txt If there are any problems with the minutes, we can discuss at the Wednesday telecon, 11/5/97, 1:00 pm PST. Here is the text version (without page headers and footers): IPP Working Group Meeting Minutes October 29-30, 1997 Boulder, Colorado The meeting started on October 29 at 8:30 AM. The attendees were: Ron Bergman - Dataproducts Corp. Dennis Carney - IBM Lee Farrell - Canon Information Systems Steve Gebert - IBM Jeff Haemer - QMS Tom Hastings - Xerox Corp. Bob Herriot - Sun Microsystems Scott Isaacson - Novell David Kellerman - Northlake Software Carl Kugler - IBM Harry Lewis - IBM Carl-Uno Manros, Xerox, Corp. Jay Martin - Underscore Pat Nogay - IBM Jerry Podojil - Genicom Stuart Rowley, Kyocera Yuji Sasaki, JCI Ron Sherer - Peerless Randy Turner - Sharp Atsushi Uchino - Epson Dale Wick, True Spectra Atsushi Yuki - Kyocera Lloyd Young - Lexmark Peter Zehler, Xerox, Corp. 1. Agenda 1) What is needed to make the Model and Protocol documents eady to initiate the WG last call from and that priority ONE is to make sure we get any remaining comments reviewed, so that we can get the "final" draft version of the documents out and start the last call some time next week. Other subjects, which we decided to leave out from Version 1.0 or other left overs are: 2) The Mapping document to LPD/LPR 3) Asynchronous Notifications 4) Document level attributes 5) Dictionary Syntax 6) IPP use of TLS (when that spec gets frozen) 7) IPP prototyping/interoperability testing 2. Model and Semantics Document Issues The following issues were identified and the indicated resolutions were agreed to. Scott will include them in the next version of the Model and Semantics document for review by the DL. 2.1 Adding new Operation attributes in the future? It was agreed that adding new Operation attributes would require that the major version number be incremented. So a Printer object SHALL reject requests that contain Operation attributes that are not supported, independent of the setting of the "ipp-fidelity" attribute. Thses requirements will help with interoperability. NOTE: Job Template attributes that a Printer object does not support SHALL be ignored when the "ipp-fidelity" attribute is 'false', so most of the registered and private extensions will be in the Job Template attributes group, not the Operation Attribute group. 1.2 Remove "document-charset" Operation attribute? We don't need this attribute for PostScript™. PCL drivers embed an escape sequence to indicate the charset of the document, so we don't need this attribute for PCL. We agreed that any media type that needed a charset specification should indicate it in the media registration specification. Even 'application/octet-stream' for PDL sniffing does not need a charset; the Printer object will assume the printer's default charset, if the document doesn't have an embedded indication of charset. 1.3 Get-Attributes requesting an unsupported attribute - error or ignore? We decided that the Printer object SHALL ignore any requests for unsupported attributes and return no indication of such an occurrence. The client looks at the attributes that are returned which are only the supported attributes. 1.4 How to return supported attributes whose values are not yet known? We decided that to use an out-of-band coding for all attribute syntaxes, including enums and integers. So, unlike the Printer and Job Monitoring MIBs, the -2 value will NOT be used for integers and the +2 will not be used for enums to indicate a value that is not yet known to the Printer object. Mapping from the MIB representation to the IPP representation of unknown is straightforward for implemenations that support both IPP and the Printer or Job Monitoring MIBs. 1.5 The term "imposed page" vs. "impression" We agreed that we didn't need the new term "imposed page" because "impression" is the same. 1.6 Should the Model require conformance to the Protocol? We agreed to remove the statement in the Model document that an implementation MUST also conform to the Protocol document. Retaining the statement would preclude ever having a different protocol document. The protocol document already requires conformance to it. 1.7 When "ipp-attribute-fidelity" = 'false' MAY an IPP object reject a request? We agreed that when "ipp-attribute-fidelity" is 'false', that the IPP object MUST try its best to perform the create operation and SHALL not reject the create job operation. 1.8 Should IPP attributes include ISO 10646 level 3? Since the IPP protocol does not require any attribute matching, the difficulty that level 3 introduces of multiple ways to encode the same (accented) letters is not a problem. So we agreed to remove the restriction that utf-8 'text' and 'name' attributes had to be ISO 10646 level 2 or less. [Editor's note: but the Cancel-Job operation does require the IPP object to make sure that user requesting the operation is the same as the one that submitted the job, so that there is a comparison of user names that could include accented letters that use level 3 encoding with non-spacing accents. Also if the security policy is that users can only get attributes for their own jobs, then the IPP object will also be doing compares for Get-Attributes and Get-Jobs operations on user names submitted with the request to those stored with the job.] 1.9 Natural-language override: differs between Model and Protocol We agreed to use the mechanism in the Protocol document with the CompoundValue tag that indicates the number of following attribute values that are taken together, rather than just have two values, 'naturalLanguage' followed by 'text' or 'name'. The CompoundValue is more general and less ad hoc. It could be used for other purposes in the future. In the case of the natural-language override, the value of the CompoundValues value SHALL be as '2', immediately followed by the natural-language value followed by the 'text' or 'name' value. A CompoundValue is then treated as if it were a single value. The Model document will say nothing about the representation of the natural-language override or the concept of CompoundValue. The protocol document will introduce the concept of CompoundValue. 1.10 Are Operation attributes MANDATORY? We re-affirmed that all operation attributes are MANDATORY for the Printer object to accept and support in requests and for the client to accept in responses. 1.11 Do we need both "printer-uri' and "print-tls-uri"? We agreed that there should be only one uri for a Printer object. So delete the "printer-tls-uri attribute from both the Printer object and the directory schema. If the one URI has a scheme that requires security, then that is sufficient. The "printer-uri" attribute will remain single-valued in both the Printer object and the directory entry. 1.12 What security is MANDATORY in IPP/1.0? We agreed that clients MUST issue and Printer objects MUST accept TLS with at least SSL3 framing. The client and the Printer object MAY then negotiate down to null (no-auth). But a client SHALL NOT start out without TLS and a Printer SHALL NOT accept non-TLS. It is expected that when TLS is finished, that it will have SSL3 compatibility, since so much SSL3 is deployed today. 1.13 Do we need "security-schemes-supported"? We agreed to delete security schemes supported, since now the Protocol document will MANDATE that the HTTPS: scheme be used for IPP. ACTION ITEM (Randy, Carl-Uno): work on an Appendix or implementation notes that could be a separate information RFC on how the security negotiation works. 1.14 Should the Protocol recommend a port to use when not using the default port for the scheme in use? The default port for HTTP: is 80. The default port for HTTPS: is some other value which becomes the default port for IPP. The Protocol document will mention this default port. If an alternate is wanted for IPP, the Protocol document will recommend a particular (different) port that will have to be explicit in the URI. There is a problem in UNIX in that an explicit port number (below) 1024 can be used only if the client is logged in as root. No fix for this problem was forth coming. ACTION ITEM (Carl-Uno): Apply for this alternate port for IPP. 1.15 Remove reference to Send-URI in Validate-Job Section 3.2.3: Remove the reference to Send-URI in Validate-Job. 1.16 MUST return all unsupported attributes, not just the first one Section 3.2.1.2: We agreed that the Printer object MUST return all unsupported attributes and attribute values in the create operation response, not just the first unsupported attribute or value. Implementations have found that it isn't more difficult to return all and returning all will mean that the client can fix up all problems and try again. 1.17 Remove vendor extension for per-document attributes Section 3.2.1.1: Remove the mention of vendor extension for per-document attributes. We need to work together on this extension in order to keep interoperability. 1.18 Auto-sensing is best-efforts Section 4.1.9: Add a note that application/octet-stream auto-sensing is not absolutely guaranteed, but customers love it none-the-less. 3. Comments on the Protocol document The following agreements were reached on the Protocol document. Bob will include them in the next version of the Protocol document for review by the DL. 3.1 Remove the redundant attribute syntax descriptions The Protocol document will only explain the representation of each attribute syntax, not the semantics. The model will describe only the semantics. 4. Other Documents The following additional documents will be produced and the indicated actions taken: 4.1 LPD Mapping to IPP document Bob Herriot says that the LPD Mapping document is finished. The last July Internet-Draft is the final version. It will become an informational RFC. ACTION ITEM (Carl-Uno): Announce it for a two week WG last call immediately. 4.2 The Rationale document The Rationale document is being updated by Steve Zilles. It will become an informational RFC. It is desirable for it to be available when the Model and Protocol documents are. ACTION ITEM (Steve Zilles): Send the final Internet-Draft to the IETF Secretariat and announce a two week WG last call when the Secretariat announces the I-D. 4.3 The Requirements document Don Wright has finished the requirements document. It will be an informational RFC. ACTION ITEM (Carl-Uno): Announce it for a two week WG last call. 5. Asynchronous Event Notification After much discussion back and forth we agreed that the WG needs to work on a program parsable representation for asynchronous events after forwarding IPP/1.0 Model and Protocol documents to the IESG. The IPP WG charter includes such. We removed the asynchronous event notification from IPP/1.0 document because we only had a simple text representation that programs might try to parse. The experience with PostScript error messages being only text made us realize that leaving in only text messages would cause the same problems all over again. One approach would be to define a multi-part/alternative media type that contains a program parsable alternative and an text/plain alternative. The recipient chooses which alternative to use. Such a media type could be sent using a mailto: scheme. The second problem with asynchronous event notification is the transport of the event messages. The Simple Event Notification System Environment (SENSE) is a candidate. Jay Martin presented its concepts to the group. It has been implemented and deployed in printing applications over the last two years. It seems general enough for IPP needs. It is also very portable. The specifications are on the PWG FTP server under: ftp://ftp.pwg.org/pub/pwg/SENSE/ In order to be used with IPP, a specification of the SENSE properties to be used in a publication and an edition needs to be written and agreed to for use with IPP. Otherwise, interoperability between one vendors subscribers and another vendors publishers is not possible. See separate minutes produced by Jay to the SENSE DL. The IPP WG can produce another RFC which augments the current IPP Model and Protocol documents, just as MIME has done. We need to specify this as soon as possible, least implementers invent their own representations and transports and the opportunity for interoperability is lost. This topic will be on both the next IPP WG agenda and the IETF IPP agenda. 6. Interoperability Testing Randy Turner and Peter Zehler indicated that they were close to trying pair-wise interoperability testing over the Internet. Peter is installing a prototype outside the Xerox firewall. Randy indicated that he has the same capability. Others are encouraged to participate. >From the experience with the Printer MIB interoperability/bake-off, we agreed that we need to develop a specification of a set of operation requests, including the attribute values supplied and the expected attribute and status code responses. Error conditions need to be included. This specification was called a set of scenarios and needs to be executable. 7. Next IPP WG meeting, 12/3/97, Los Angeles The next IPP WG meeting will be Wednesday, in Los Angeles. Reservations need to be make by 11/7/97 to get the low rate. Else the rate doubles. We will probably only need one day, which will be Wednesday. 8. Next IETF meeting, week of 12/8/97, Washington DC Carl-Uno has requested a two hour slot. We may only need one hour. We agreed that it was important to have the slot. We can reduce the time near the end of November. The meeting adjourned at 5:30 PM. From ipp-owner@pwg.org Wed Nov 5 10:10:04 1997 Delivery-Date: Wed, 05 Nov 1997 10:10:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27444 for ; Wed, 5 Nov 1997 10:10:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10860 for ; Wed, 5 Nov 1997 10:13:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA02321 for ; Wed, 5 Nov 1997 10:10:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 10:02:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA01762 for ipp-outgoing; Wed, 5 Nov 1997 09:50:57 -0500 (EST) From: "Zehler,Peter" To: "Redirector IPP (E-mail)" Subject: IPP> IPP developers mailing list established Date: Wed, 5 Nov 1997 06:54:10 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Nov5.065037pst."56735(7)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, Jeff Schnitzer created an mailing list for us. (thanks Jeff) This discussion list is for the exchange of information related to the development and implementation of IPP clients or servers/printers. Any issues identified will be tracked to insure resolution. The issues will be reported back to the main IPP list and any individuals necessary to resolve the issue. As usual for majordomo, people who want to subscribe should send mail to with subscribe ippdev end as the body of their message. 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 __________________________________ From ipp-owner@pwg.org Wed Nov 5 14:33:48 1997 Delivery-Date: Wed, 05 Nov 1997 14:33:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA00943 for ; Wed, 5 Nov 1997 14:33:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA12037 for ; Wed, 5 Nov 1997 14:36:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA03900 for ; Wed, 5 Nov 1997 14:33:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 14:25:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03311 for ipp-outgoing; Wed, 5 Nov 1997 14:14:37 -0500 (EST) Message-Id: <3.0.1.32.19971105105414.009e61c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 5 Nov 1997 10:54:14 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> IPP WG Last Call for Requirements and LPD Mapping drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Folks, This is a formal request for final comments within the IETF IPP working group, prior to submitting two specifications on to the IESG for consideration as Informational RFCs. The documents have undergone considerable and repeated review and revision and we believe that we now have working group consensus on their adequacy. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Last Call is for 2 weeks. Hence, the period for working group comments will close on Wednesday, 19 November (US pacific time reference). The relevant documents are: Title : Requirements for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-01.txt Pages : 55 Date : 16-Oct-97 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. The full set of IPP documents include: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure and Model and Protocol for the Internet Printing Protocol ------ 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. ---- For retrieval: Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-req-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt and: "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 --- Expect to see our remaining documents for Last Call shortly. Carl-Uno Manros Co-Chair, IETF IPP Working Group Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Nov 5 16:06:02 1997 Delivery-Date: Wed, 05 Nov 1997 16:06:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA02452 for ; Wed, 5 Nov 1997 16:06:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12344 for ; Wed, 5 Nov 1997 16:09:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA05507 for ; Wed, 5 Nov 1997 16:06:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 16:00:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04915 for ipp-outgoing; Wed, 5 Nov 1997 15:48:48 -0500 (EST) Message-Id: <199711052048.PAA04910@lists.underscore.com> Date: Wed, 5 Nov 97 13:49:00 MST From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" To: ipp@pwg.org Subject: IPP> IPP Client Prototype Sender: ipp-owner@pwg.org Just wanted to let people know that the simple client IBM put out on the web is delivered as a tar file. It needs to be 'untarred' to extract the instructions and the Java classes. Apparently on operating systems other than Unix, the file is downloaded and renamed IPP.exe rather than IPP.tar. Sorry for the confusion. Steve From ipp-owner@pwg.org Wed Nov 5 20:41:41 1997 Delivery-Date: Wed, 05 Nov 1997 20:41:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA05397 for ; Wed, 5 Nov 1997 20:41:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13146 for ; Wed, 5 Nov 1997 20:44:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA07051 for ; Wed, 5 Nov 1997 20:41:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 20:36:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06418 for ipp-outgoing; Wed, 5 Nov 1997 20:25:16 -0500 (EST) Message-Id: <3.0.1.32.19971105170908.00ab4b00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 5 Nov 1997 17:09:08 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971105 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference 971105 Attending: Harry Lewis Ron Bergman Randy Turner Carl-Uno Manros Tom Hastings Peter Zehler Xavier Riley John Wenn Ira Mcdonald Stan McConnell Scott Isaacson The following topics were discussed: Comments on minutes from Boulder How to perform checking that the sender of a Cancel-Job operation is the same as the job initiator. It was concluded that the responsibility for this is in the IPP server, which might use a simple user name or a more elaborate user certificate to establish the identity (depending on security level used). The attribute "originating-user-id" has been intended for this. this can contain non-printable information. It was concluded that this is really a hidden atribute which the server uses internally and hence can be deleted from the IPP specification. Some text explaining this should be added instead. Another discussion was held on the use of SSL3 negotiation. Some conclusions oiut of that discussion was: All IPP communication over HTTP will be using the URI scheme "hhtps". Alias names can be given to printers using some other schema e.g. "http', but in such cases the server would refer the user to the real "https" URI before the actual IPP protocol exchange starts. The latter is really an implementation matter and does not need to go into the standards text. It was suggested that we do not specify use of "https", or any other URI scheme in the Model document (but in the Protocol document) apart from in examples. Randy also wanted to mandate use of SSL3 (later TLS) in the Model document. There was not full agreement about this. Some concerns were raised that not all current Web server implementation supporting SSL3 also support null framing only, and that hence only some serevers could be used for IPP if we mandate the SSL3 framing. Some further discussion with vendors is needed. Randy promised to have his proposed security changes out to the DL before the end of the week. At this stage is unclear whether it is meaningful to make that text into a I-D or just consider as a proposal against the planned "last call" texts. Carl-Uno stated that he will hold off the request to AINA for a port number until we know for sure what the security details will be. It had been discovered that the atribute on "page-ranges" needs some further text to explain how it behaves for multi document jobs. Tom will try to improve the text. Scott joined in towards the end of the conference and confirmed that he and Tom were still doing some editing on the Model document, but that it should be ready to send to the IETF this week. It is assumed that Bob is working to the same schedule. No news where Steve Zilles stands with the update of the Rationale document. Carl-Uno pointed oput that he has started the final call for the Requirements and the LPD Mapping documents today (both have been available as drafts for some time). Ira commented that he had found some atribute name differences compared to the latest Model draft. He will submit these differences in response to the "last call". We expect to have the next call same time next week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Nov 5 22:17:05 1997 Delivery-Date: Wed, 05 Nov 1997 22:17:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA05820 for ; Wed, 5 Nov 1997 22:17:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA13323 for ; Wed, 5 Nov 1997 22:20:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07913 for ; Wed, 5 Nov 1997 22:17:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 22:12:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA07336 for ipp-outgoing; Wed, 5 Nov 1997 22:01:21 -0500 (EST) Message-Id: <3.0.32.19971105190017.006caef0@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 5 Nov 1997 19:00:20 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP>MOD - minor corrections Cc: xriley@cp10.es.xerox.com, cmanros@cp10.es.xerox.com, thastings@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Assuming that document-charset is the newer version of content-charset, the following changes should be made to section 3.2.4 "Creat-Job Operation": Change "content-charset" to "document-charset" on lines 1012 & 1014 Change "content-natural-language" to "document-natural-language" on lines 1012 and 1015. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Wed Nov 5 23:58:31 1997 Delivery-Date: Wed, 05 Nov 1997 23:58:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id XAA13067 for ; Wed, 5 Nov 1997 23:58:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA13497 for ; Thu, 6 Nov 1997 00:01:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08653 for ; Wed, 5 Nov 1997 23:58:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 5 Nov 1997 23:53:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08054 for ipp-outgoing; Wed, 5 Nov 1997 23:42:24 -0500 (EST) X-Sender: bva@ultranet.com Message-Id: In-Reply-To: <3.0.1.32.19971031141209.00c38a80@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 23:44:44 -0500 To: Carl-Uno Manros From: Bob Van Andel Subject: IPP> Use of SSL3 Framing???? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Carl-Uno, >The decision to require SSL3 framing has a number of consequences which >needs to be reflected in the Protocol document. The minutes from the Boulder meeting do not reflect why this decision was made. Can you enlighten me? I could envision the following scenarios where this requirement would not be necessary. - IP level security is in place - the entire conversation is on a private intranets behind firewalls - the printer is designated as equivalent to a public fax machine. This requirement increases implementation and execution costs for both clients and servers. Regards, Bob ---------------------------------------- Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Information on the RomPager embedded web server toolkit is at From ipp-owner@pwg.org Thu Nov 6 01:14:39 1997 Delivery-Date: Thu, 06 Nov 1997 01:14:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id BAA13807 for ; Thu, 6 Nov 1997 01:14:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA13615 for ; Thu, 6 Nov 1997 01:17:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA09312 for ; Thu, 6 Nov 1997 01:14:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 01:10:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA08769 for ipp-outgoing; Thu, 6 Nov 1997 00:59:31 -0500 (EST) Message-ID: <34615B9E.14D0EA36@sharplabs.com> Date: Wed, 05 Nov 1997 21:54:38 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Bob Van Andel CC: ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The fact that scenarios exist where security is not necessary, do not obviate the need for the standard to specify security as a requirement. Its possible that one of the machines in one of these scenarios might be moved or requested to communicate outside of the scenario-specific domain and we don't want to have to modify the configuration or install new software in order to interoperate. TCP supports re-ordering of packets and checksumming but neither of these is really needed for hosts on a single ethernet segment; nevertheless, the standard specifies the capability in order to interoperate outside of the segment, if need be. The requirement for a specific security mechanism to be used for IPP is closer to guaranteeing that some level of security can be negotiated, end to end, across any number of topologies. Randy Bob Van Andel wrote: > > Carl-Uno, > > >The decision to require SSL3 framing has a number of consequences which > >needs to be reflected in the Protocol document. > > The minutes from the Boulder meeting do not reflect why this decision was > made. Can you enlighten me? > > I could envision the following scenarios where this requirement would not > be necessary. > > - IP level security is in place > - the entire conversation is on a private intranets behind firewalls > - the printer is designated as equivalent to a public fax machine. > > This requirement increases implementation and execution costs for both > clients and servers. > > Regards, > > Bob > > ---------------------------------------- > Bob Van Andel > Allegro Software Development Corporation > 43 Waite Road > Boxborough, MA 01719 > (978) 266-1375 > (978) 266-2839 fax > > Information on the RomPager embedded web server toolkit is at > From ipp-owner@pwg.org Thu Nov 6 09:38:36 1997 Delivery-Date: Thu, 06 Nov 1997 09:38:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16077 for ; Thu, 6 Nov 1997 09:38:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14503 for ; Thu, 6 Nov 1997 09:41:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA10370 for ; Thu, 6 Nov 1997 09:38:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 09:27:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA09791 for ipp-outgoing; Thu, 6 Nov 1997 09:15:56 -0500 (EST) X-Sender: bva@ultranet.com Message-Id: In-Reply-To: <34615B9E.14D0EA36@sharplabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Nov 1997 09:18:57 -0500 To: Randy Turner From: Bob Van Andel Subject: Re: IPP> Use of SSL3 Framing???? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Randy, >The fact that scenarios exist where security is not >necessary, do not obviate the need for the standard >to specify security as a requirement. Its possible >that one of the machines in one of these scenarios >might be moved or requested to communicate outside >of the scenario-specific domain and we don't want >to have to modify the configuration or install new >software in order to interoperate. > Existing Web browsers and servers make the transition from insecure (non-SSL3) to secure (SSL3) modes and back all the time. Why can't IPP clients dynamically negotiate those transitions for those environments where the site configuration warrants it. I would expect that a number of site configuration issues will be necessary that don't require software changes to interoperate, but do require administrative attention. Why is this different than the administrator configuring which bin has letterhead? I'm assuming that the IPP spec allows a printer with a single paper source to ignore multi-tray attributes. Bob ---------------------------------------- Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Information on the RomPager embedded web server toolkit is at From ipp-owner@pwg.org Thu Nov 6 09:52:10 1997 Delivery-Date: Thu, 06 Nov 1997 09:52:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16300 for ; Thu, 6 Nov 1997 09:52:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14563 for ; Thu, 6 Nov 1997 09:55:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA11008 for ; Thu, 6 Nov 1997 09:52:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 09:48:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA10185 for ipp-outgoing; Thu, 6 Nov 1997 09:35:24 -0500 (EST) Message-ID: From: "Gordon, Charles" To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: IPP> RE: SSL3 Date: Thu, 6 Nov 1997 09:33:42 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org As someone representing a print server vendor, I would like to go on record as being against requiring support for SSL3. Requiring support for it will add additional cost to both the client and the printer, and most applications will not need it. I have no objection to making support for a secure protocol optional. Some vendors will have applications which require security, and having a standardized way of supporting secure IPP will allow products from those vendors to interoperate. However, the rest of us who don't need security, should not be forced to incur the additional cost of implementing something like SSL3 in order to be IPP compliant. In other words, basic IPP should not require SSL3 or any other secure protocol. However, if some vendor wants to implement a secure version of IPP, then the IPP spec should require that they implement it in a specific fashion so that their products are compatible with products from other vendors who implement secure IPP. Also, I think SSL3 is a proprietary protocol owned by Netscape. If this is the case, we definitely should not MANDATE support for a proprietary protocol. I suggest that we support a secure protocol which is in the public domain. I suggest TLS. From what I understand about it, TLS is based on SSL3, but is in the public domain (or at least will be when the spec is finalized). My objection to SSL3 is because I think it's proprietary. If I'm wrong and SSL3 is in the public domain, then I have no objection to it as long as IPP does not require support for it in applications which don't require security. Charles Gordon Osicom/DPI > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Wednesday, November 05, 1997 8:09 PM > To: ipp@pwg.org > Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971105 > > Minutes from PWG IPP Phone Conference 971105 > > Attending: Harry Lewis > Ron Bergman > Randy Turner > Carl-Uno Manros > Tom Hastings > Peter Zehler > Xavier Riley > John Wenn > Ira Mcdonald > Stan McConnell > Scott Isaacson > > The following topics were discussed: > > Comments on minutes from Boulder > > How to perform checking that the sender of a Cancel-Job operation is > the > same as the job initiator. It was concluded that the responsibility > for > this is in the IPP server, which might use a simple user name or a > more > elaborate user certificate to establish the identity (depending on > security > level used). The attribute "originating-user-id" has been intended for > this. this can contain non-printable information. It was concluded > that > this is really a hidden atribute which the server uses internally and > hence > can be deleted from the IPP specification. Some text explaining this > should > be added instead. > > Another discussion was held on the use of SSL3 negotiation. Some > conclusions oiut of that discussion was: All IPP communication over > HTTP > will be using the URI scheme "hhtps". Alias names can be given to > printers > using some other schema e.g. "http', but in such cases the server > would > refer the user to the real "https" URI before the actual IPP protocol > exchange starts. The latter is really an implementation matter and > does not > need to go into the standards text. It was suggested that we do not > specify > use of "https", or any other URI scheme in the Model document (but in > the > Protocol document) apart from in examples. Randy also wanted to > mandate use > of SSL3 (later TLS) in the Model document. There was not full > agreement > about this. > > Some concerns were raised that not all current Web server > implementation > supporting SSL3 also support null framing only, and that hence only > some > serevers could be used for IPP if we mandate the SSL3 framing. Some > further > discussion with vendors is needed. > > Randy promised to have his proposed security changes out to the DL > before > the end of the week. At this stage is unclear whether it is meaningful > to > make that text into a I-D or just consider as a proposal against the > planned "last call" texts. > > Carl-Uno stated that he will hold off the request to AINA for a port > number > until we know for sure what the security details will be. > > It had been discovered that the atribute on "page-ranges" needs some > further text to explain how it behaves for multi document jobs. Tom > will > try to improve the text. > > Scott joined in towards the end of the conference and confirmed that > he and > Tom were still doing some editing on the Model document, but that it > should > be ready to send to the IETF this week. It is assumed that Bob is > working > to the same schedule. No news where Steve Zilles stands with the > update of > the Rationale document. > > Carl-Uno pointed oput that he has started the final call for the > Requirements and the LPD Mapping documents today (both have been > available > as drafts for some time). > > Ira commented that he had found some atribute name differences > compared to > the latest Model draft. He will submit these differences in response > to the > "last call". > > We expect to have the next call same time next week. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Nov 6 10:16:02 1997 Delivery-Date: Thu, 06 Nov 1997 10:16:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17235 for ; Thu, 6 Nov 1997 10:16:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA14710 for ; Thu, 6 Nov 1997 10:19:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA11651 for ; Thu, 6 Nov 1997 10:16:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 10:12:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11102 for ipp-outgoing; Thu, 6 Nov 1997 10:00:53 -0500 (EST) Message-ID: <3461DA88.D9124707@sharplabs.com> Date: Thu, 06 Nov 1997 06:56:08 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Bob Van Andel CC: ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob Van Andel wrote: > > Randy, > > >The fact that scenarios exist where security is not > >necessary, do not obviate the need for the standard > >to specify security as a requirement. Its possible > >that one of the machines in one of these scenarios > >might be moved or requested to communicate outside > >of the scenario-specific domain and we don't want > >to have to modify the configuration or install new > >software in order to interoperate. > > > > > Existing Web browsers and servers make the transition from insecure > (non-SSL3) to secure (SSL3) modes and back all the time. Why can't IPP > clients dynamically negotiate those transitions for those environments > where the site configuration warrants it. SSL3 allows security parameters to be negotiated dynamically. All thats required is the support for SSL3 framing and session initialization. We're not absolutely requiring all of the cipher suites and authentication mechanisms the SSL3 spec includes. > > I would expect that a number of site configuration issues will be necessary > that don't require software changes to interoperate, but do require > administrative attention. Why is this different than the administrator > configuring which bin has letterhead? I'm assuming that the IPP spec > allows a printer with a single paper source to ignore multi-tray attributes.s Thats true, but security requirements for a particular printer will not change as often as media in a tray, or other printing-specific attributes. An administrator will decide if a device should be secured and it will probably stay that way. Security requirements for a printing server will be somewhat static. Also, I might point out, for a lot of cases, it will be client that decides security is necessary for a particular session because the client knows the sensitivity of the content that will be transmitted to the server. In any of these scenarios, publishing a single URL for the printer and using SSL3/TLS to negotiate security will come closer to making sure client and server can interoperate, at least as far as security is concerned. Randy > > Bob > > ---------------------------------------- > Bob Van Andel > Allegro Software Development Corporation > 43 Waite Road > Boxborough, MA 01719 > (978) 266-1375 > (978) 266-2839 fax > > Information on the RomPager embedded web server toolkit is at > From ipp-owner@pwg.org Thu Nov 6 10:38:16 1997 Delivery-Date: Thu, 06 Nov 1997 10:38:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17595 for ; Thu, 6 Nov 1997 10:38:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA14829 for ; Thu, 6 Nov 1997 10:41:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA12349 for ; Thu, 6 Nov 1997 10:38:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 10:34:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11759 for ipp-outgoing; Thu, 6 Nov 1997 10:23:01 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> Use of SSL3 Framing???? Message-ID: <5030100012626234000002L042*@MHS> Date: Thu, 6 Nov 1997 10:23:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17595 Randy wrote: >SSL3 allows security parameters to be negotiated >dynamically. All thats required is the support >for SSL3 framing and session initialization. >We're not absolutely requiring all of the >cipher suites and authentication >mechanisms the SSL3 spec includes. I'm always concerned when I see the phrase "all "that's required is ..." From ipp-owner@pwg.org Thu Nov 6 11:41:45 1997 Delivery-Date: Thu, 06 Nov 1997 11:41:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18352 for ; Thu, 6 Nov 1997 11:41:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15166 for ; Thu, 6 Nov 1997 11:44:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA13400 for ; Thu, 6 Nov 1997 11:41:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 11:33:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12768 for ipp-outgoing; Thu, 6 Nov 1997 11:17:14 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Use of SSL3 Framing???? Message-ID: <5030100012632207000002L072*@MHS> Date: Thu, 6 Nov 1997 11:17:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18352 Is this "SSL3 Framing" provided by what's referred to as the "Record layer" in appendix A.1.1 of "The SSL Protocol Version 3.0" at http://home.netscape.com/eng/ssl3/draft302.txt? Is http://home.netscape.com/eng/ssl3/draft302.txt the right reference for this? -Carl Kugler From ipp-owner@pwg.org Thu Nov 6 11:47:53 1997 Delivery-Date: Thu, 06 Nov 1997 11:47:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18409 for ; Thu, 6 Nov 1997 11:47:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15205 for ; Thu, 6 Nov 1997 11:50:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA14051 for ; Thu, 6 Nov 1997 11:47:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 11:43:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12805 for ipp-outgoing; Thu, 6 Nov 1997 11:24:32 -0500 (EST) Priority: Urgent From: Harry Lewis To: Subject: Re: IPP> Use of SSL3 Framing???? Message-ID: <5030300013763669000002L092*@MHS> Date: Thu, 6 Nov 1997 11:29:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18409 Randy wrote: >The fact that scenarios exist where security is not >necessary, do not obviate the need for the standard >to specify security as a requirement I would restate this, slightly... "The fact that scenarios exist where security is not necessary does not obviate the need for the standard to SPECIFY THE REQUIREMENTS FOR SECURITY". I think the IETF is trying to tell us "not to build a protocol without addressing security". We are interpreting this to mean "do not allow an implementation which is not secure". Is every web server, on the Internet today, required to support HTTPS? Why? Many servers would have no need to be secure. MAKING every IPP printer behave in a secure fashion could be misleading From ipp-owner@pwg.org Thu Nov 6 12:35:40 1997 Delivery-Date: Thu, 06 Nov 1997 12:35:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA18794 for ; Thu, 6 Nov 1997 12:35:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15577 for ; Thu, 6 Nov 1997 12:38:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15521 for ; Thu, 6 Nov 1997 12:35:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 12:24:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14204 for ipp-outgoing; Thu, 6 Nov 1997 11:55:52 -0500 (EST) Message-ID: <3461F575.9F24A76C@sharplabs.com> Date: Thu, 06 Nov 1997 08:51:01 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? References: <5030100012632207000002L072*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl Kugler wrote: > > Is this "SSL3 Framing" provided by what's referred to as the "Record layer" in > appendix A.1.1 of "The SSL Protocol Version 3.0" at > http://home.netscape.com/eng/ssl3/draft302.txt? SSL3 (and TLS) have an outer layer encapsulation that has a variant field called "type" that identifies the type of SSL3 message contained within a message. I believe this is called the "record" layer. The "type" of message is either "handshake", "alert", "application-data", or "change-cipher-spec". For a minimal IPP implementation, the "handshake" and "application-data" records would be used. Randy > > Is http://home.netscape.com/eng/ssl3/draft302.txt the right reference for this? If this spec. is dated November 1996, then this is the spec. I am referencing which I think is current. > -Carl Kugler From ipp-owner@pwg.org Thu Nov 6 12:36:12 1997 Delivery-Date: Thu, 06 Nov 1997 12:36:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA18800 for ; Thu, 6 Nov 1997 12:36:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15583 for ; Thu, 6 Nov 1997 12:39:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15594 for ; Thu, 6 Nov 1997 12:36:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 12:25:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14176 for ipp-outgoing; Thu, 6 Nov 1997 11:55:20 -0500 (EST) Message-Id: <3.0.1.32.19971106085352.00928100@xmicro.cp10.es.xerox.com> X-Sender: xriley@xmicro.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 6 Nov 1997 08:53:52 PST To: ipp@pwg.org From: "Xavier D. Riley" Subject: Re: IPP> Use of SSL3 Framing???? In-Reply-To: References: <3.0.1.32.19971031141209.00c38a80@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, > > This requirement increases implementation and execution costs for both > clients and servers. > I second this opinion. Although I support your intentions of wanting to have one entry for both a non-secure and secure IPP print system, I think the FUTURE TLS is the only practical solution to this problem. I would speculate that most SSL3 web server implementations don't support configuring the Cipher Suite to be SSL_NULL_NULL_WITH_NULL_NULL. My vote (today) is to keep secure and non-secure entries separate for IPP 1.0 and when TLS is approved and deployed in existing off the shelf web servers, we specify the use of it in a later version of IPP. I will hold my final vote until I read the document you plan to release this week. The advertisement of non-secure and secure IPP print systems can occur outside the IPP specification by the simple use of a Web page or LDAP server advertising both print system URLs. I would venture to say that most implementations would either be configured to be non-secure or secure, not both. Non-Secure IPP Print Systems = No Authentication Basic Authentication Digest Access Authentication. Secure IPP Print Systems = Channel level security (i.e. SSL3) ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Thu Nov 6 12:40:51 1997 Delivery-Date: Thu, 06 Nov 1997 12:40:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA18831 for ; Thu, 6 Nov 1997 12:40:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15620 for ; Thu, 6 Nov 1997 12:43:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16233 for ; Thu, 6 Nov 1997 12:40:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 12:35:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14292 for ipp-outgoing; Thu, 6 Nov 1997 12:06:25 -0500 (EST) Message-ID: <3461F7EA.9C64AEF9@sharplabs.com> Date: Thu, 06 Nov 1997 09:01:30 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? References: <5030300013763669000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry Lewis wrote: > > Randy wrote: > > >The fact that scenarios exist where security is not > >necessary, do not obviate the need for the standard > >to specify security as a requirement > > I would restate this, slightly... "The fact that scenarios exist where > security is not necessary does not obviate the need for the standard > to SPECIFY THE REQUIREMENTS FOR SECURITY". Yes, I like this wording better. > > I think the IETF is trying to tell us "not to build a protocol without > addressing security". We are interpreting this to mean "do not allow an > implementation which is not secure". > > Is every web server, on the Internet today, required to support HTTPS? > Why? Many servers would have no need to be secure. They are required by de facto, not by a pure standard, to support HTTPS because no commercial vendor of HTTP servers would introduce a server incapable of providing the capability for internet commerce. Its like I was saying a previous message about TCP, you don't design a protocol for the easy case, you design it to scale from the easy to the more advanced, which is why, yes, for an intranet application, you might need HTTPS, but that scenario doesn't deter vendors from including it in their product, because they're not interested in rolling different products to support different scenarios. Just ship one product that scales nicely. HTTP 1.1 will probably require digest authentication, so if IPP is implemented over HTTP 1.1, then this would be a requirement. This is one of the reasons why I'm not so sure it would be overly burdensome to require IPP servers to support MD5 digest authentication, whether its used by HTTP or SSL3/TLS. > > MAKING every IPP printer behave in a secure fashion could be misleading I'm curious why this would be misleading... Randy From ipp-owner@pwg.org Thu Nov 6 12:58:14 1997 Delivery-Date: Thu, 06 Nov 1997 12:58:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19060 for ; Thu, 6 Nov 1997 12:58:13 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15703 for ; Thu, 6 Nov 1997 13:01:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16977 for ; Thu, 6 Nov 1997 12:58:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 12:53:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16320 for ipp-outgoing; Thu, 6 Nov 1997 12:42:02 -0500 (EST) Message-Id: <3.0.1.32.19971106092545.0142cc00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 6 Nov 1997 09:25:45 PST To: "Gordon, Charles" From: Carl-Uno Manros Subject: IPP> RE: SSL3 Cc: ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Charles, There is still some misunderstandings about what the proposed security solution for IPP is. Randy Turner from Sharp is currently writing up some text to explain the propsed solution in more detail which should be available shortly, but see some initial comments from me inserted in your text below: At 06:33 AM 11/6/97 PST, you wrote: >As someone representing a print server vendor, I would like to go on >record as being against requiring support for SSL3. Requiring support >for it will add additional cost to both the client and the printer, and >most applications will not need it. I have no objection to making >support for a secure protocol optional. Some vendors will have >applications which require security, and having a standardized way of >supporting secure IPP will allow products from those vendors to >interoperate. However, the rest of us who don't need security, should >not be forced to incur the additional cost of implementing something >like SSL3 in order to be IPP compliant. There is a difference in supporting the whole SSL3 set of functionality vs. using the negotitiation mechanism, which actually allows you to state that your IPP client or IPP server does not want to use any security features. The current discussion is about mandating the capability for IPP clients and servers to support the negotiation mechanism, but allowing implementations to negotiate NULL securiry. Earlier IPP solutions discussed the option of having both a secure and an insecure URI for the same IPP printer object, but this turned out to be rather messy, like would you cross-reference between the two URIs, which one (or both?) would you list in a Directory etc. The latest proposal solves a number of such issues. >In other words, basic IPP should not require SSL3 or any other secure >protocol. However, if some vendor wants to implement a secure version >of IPP, then the IPP spec should require that they implement it in a >specific fashion so that their products are compatible with products >from other vendors who implement secure IPP. > >Also, I think SSL3 is a proprietary protocol owned by Netscape. If this >is the case, we definitely should not MANDATE support for a proprietary >protocol. I suggest that we support a secure protocol which is in the >public domain. I suggest TLS. From what I understand about it, TLS is >based on SSL3, but is in the public domain (or at least will be when the >spec is finalized). My objection to SSL3 is because I think it's >proprietary. If I'm wrong and SSL3 is in the public domain, then I have >no objection to it as long as IPP does not require support for it in >applications which don't require security. We DO intend to use TLS for IPP as documented in our latest drafts. Unfortunately the TLS specifications are not yet frozen so we cannot reference them. SSL3 is an open specification from Netscape, which has also been implemented by Microsoft and many others, and is the closest we can get until the TLS specification gets official. Furthermore, the TLS specifications will include rules for how to interwork with SSL3. A number of vendors are already preparing IPP products and we cannot delay the IPP specifications further in wait for TLS if we want to avoid seeing a number of "almost IPP, but not quite" implementations in the market place. > > Charles Gordon > Osicom/DPI > > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Wednesday, November 05, 1997 8:09 PM >> To: ipp@pwg.org >> Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971105 >> >> Minutes from PWG IPP Phone Conference 971105 >> >> Attending: Harry Lewis >> Ron Bergman >> Randy Turner >> Carl-Uno Manros >> Tom Hastings >> Peter Zehler >> Xavier Riley >> John Wenn >> Ira Mcdonald >> Stan McConnell >> Scott Isaacson >> >> The following topics were discussed: >> >> Comments on minutes from Boulder >> >> How to perform checking that the sender of a Cancel-Job operation is >> the >> same as the job initiator. It was concluded that the responsibility >> for >> this is in the IPP server, which might use a simple user name or a >> more >> elaborate user certificate to establish the identity (depending on >> security >> level used). The attribute "originating-user-id" has been intended for >> this. this can contain non-printable information. It was concluded >> that >> this is really a hidden atribute which the server uses internally and >> hence >> can be deleted from the IPP specification. Some text explaining this >> should >> be added instead. >> >> Another discussion was held on the use of SSL3 negotiation. Some >> conclusions oiut of that discussion was: All IPP communication over >> HTTP >> will be using the URI scheme "hhtps". Alias names can be given to >> printers >> using some other schema e.g. "http', but in such cases the server >> would >> refer the user to the real "https" URI before the actual IPP protocol >> exchange starts. The latter is really an implementation matter and >> does not >> need to go into the standards text. It was suggested that we do not >> specify >> use of "https", or any other URI scheme in the Model document (but in >> the >> Protocol document) apart from in examples. Randy also wanted to >> mandate use >> of SSL3 (later TLS) in the Model document. There was not full >> agreement >> about this. >> >> Some concerns were raised that not all current Web server >> implementation >> supporting SSL3 also support null framing only, and that hence only >> some >> serevers could be used for IPP if we mandate the SSL3 framing. Some >> further >> discussion with vendors is needed. >> >> Randy promised to have his proposed security changes out to the DL >> before >> the end of the week. At this stage is unclear whether it is meaningful >> to >> make that text into a I-D or just consider as a proposal against the >> planned "last call" texts. >> >> Carl-Uno stated that he will hold off the request to AINA for a port >> number >> until we know for sure what the security details will be. >> >> It had been discovered that the atribute on "page-ranges" needs some >> further text to explain how it behaves for multi document jobs. Tom >> will >> try to improve the text. >> >> Scott joined in towards the end of the conference and confirmed that >> he and >> Tom were still doing some editing on the Model document, but that it >> should >> be ready to send to the IETF this week. It is assumed that Bob is >> working >> to the same schedule. No news where Steve Zilles stands with the >> update of >> the Rationale document. >> >> Carl-Uno pointed oput that he has started the final call for the >> Requirements and the LPD Mapping documents today (both have been >> available >> as drafts for some time). >> >> Ira commented that he had found some atribute name differences >> compared to >> the latest Model draft. He will submit these differences in response >> to the >> "last call". >> >> We expect to have the next call same time next week. >> >> Carl-Uno >> Carl-Uno Manros >> Principal Engineer - Advanced Printing Standards - Xerox Corporation >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> Email: manros@cp10.es.xerox.com > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Nov 6 13:25:19 1997 Delivery-Date: Thu, 06 Nov 1997 13:25:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19305 for ; Thu, 6 Nov 1997 13:25:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15786 for ; Thu, 6 Nov 1997 13:28:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17842 for ; Thu, 6 Nov 1997 13:25:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 13:21:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17237 for ipp-outgoing; Thu, 6 Nov 1997 13:09:55 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> Use of SSL3 Framing???? Message-ID: <5030300013774060000002L002*@MHS> Date: Thu, 6 Nov 1997 13:15:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19305 Sorry... my message got truncated somehow... >> MAKING every IPP printer behave in a secure fashion could be misleading > >I'm curious why this would be misleading... What I tried to say is that if the data is sensitive enough to require a secure socket, it's likely the printer should also be, physically, in a secure area. If every IPP printer must support HTTPS (for example) then one could easily be duped into thinking they were engaged in "secure printing" when, indeed, they are not. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Thu Nov 6 13:48:24 1997 Delivery-Date: Thu, 06 Nov 1997 13:48:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19579 for ; Thu, 6 Nov 1997 13:48:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15925 for ; Thu, 6 Nov 1997 13:51:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18628 for ; Thu, 6 Nov 1997 13:48:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 13:40:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17956 for ipp-outgoing; Thu, 6 Nov 1997 13:28:52 -0500 (EST) Message-Id: <3.0.1.32.19971106101155.0142ed60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 6 Nov 1997 10:11:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Use of SSL3 Framing???? In-Reply-To: <3461F575.9F24A76C@sharplabs.com> References: <5030100012632207000002L072*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >Carl Kugler wrote: >> Is http://home.netscape.com/eng/ssl3/draft302.txt the right reference for this? Well, yes and no. The reference above points to an expired IETF I-D which is absolutely useless as an official reference in our IPP documents. However, there is another document version somewhere on Netscape's site with the same text as a public Netscape document, which we are currently using as our official reference in the Protocol document. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Nov 6 14:01:30 1997 Delivery-Date: Thu, 06 Nov 1997 14:01:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA19744 for ; Thu, 6 Nov 1997 14:01:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA15987 for ; Thu, 6 Nov 1997 14:04:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA19426 for ; Thu, 6 Nov 1997 14:01:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 13:55:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18091 for ipp-outgoing; Thu, 6 Nov 1997 13:40:53 -0500 (EST) Message-ID: From: "Wagner, William" Cc: ipp@pwg.org Subject: RE: IPP> Use of SSL3 Framing???? Date: Thu, 6 Nov 1997 13:39:09 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I appreciate Carl-Uno's clarification of the security issue, and for expressing the rational for the IPP doing something of an about face at this late date. I also am disturbed by what appears to be a new requirement and am awaiting a more detailed analysis of the impact to implementation and schedules. I would much prefer keeping Secure IPP as an option, as was established in Atlanta. I know that some feel that IPP is intended only for Internet (as distinguished from intranet) printing; but I would suggest that IPP only makes sense as a common IP printing service, indeed supplanting LPD and the myriad of proprietary TCP/IP print services. It we structure IPP as intended primarily for cross firewall communications, we are severely limiting its applicability. Considering that (to pick out a number), something in excess of 95% of IP Printing will be within a local environment, coming up with a printing protocol aimed at less then 5% of the traffic seems inefficient. Also, there are those who intend the IPP server to be implemented in a stand-alone HTTP server; mandating some degree of security may have little impact upon them since the servers are intended for non-local communication. However, a large potential class of IPP user would be constituted of the smaller network printer which for cost effectiveness has an embedded IPP capability. For this potentially predominant product class, security of this sort is superfluous. To identify a mechanism for secure IPP is necessary; to make it mandatory so as to burden the majority of the units with something needed by relatively few does not seem reasonable (although it perhaps smacks of the IETF rational that does not recognize the intranet environment). Also, as is pointed out, requiring SSL3 makes little sense since it is an interim solution. Requiring TLS is unfeasible since it is not final. Mandating a capability which is still in such flux does not seem appropriate to getting IPP up and running. We should again consider whether our objective is just to create a specification, or to enable the inclusion of a new, necessary and viable printing service in printer products. Bill Wagner DPI/Osicom From ipp-owner@pwg.org Thu Nov 6 14:17:09 1997 Delivery-Date: Thu, 06 Nov 1997 14:17:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20039 for ; Thu, 6 Nov 1997 14:17:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA16074 for ; Thu, 6 Nov 1997 14:20:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20162 for ; Thu, 6 Nov 1997 14:17:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 14:12:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19327 for ipp-outgoing; Thu, 6 Nov 1997 14:00:12 -0500 (EST) Message-Id: <3.0.1.32.19971106104329.01435d50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 6 Nov 1997 10:43:29 PST To: "Gordon, Charles" From: Carl-Uno Manros Subject: RE: IPP> RE: SSL3 Cc: ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 10:06 AM 11/6/97 PST, you wrote: >Thanks for the explaination. If I understand you correctly, you are >proposing that IPP devices which do not support secure connections >support only enough of the SSL3 protocol to indicate so to clients, and >that devices which do support security do so through SSL3. As long as >the additional code required for devices which don't support security is >minimal, I don't have a problem with it. > > --- Charles Yes this is correct. One of the debating points though is still whether you will be able to go out and buy a "NULL package" SSL3 implementation, or if you have to craft that on your own. It also seems that a number of current web servers which use HTTP 1.1 and SSL3 do not accept negotiation to "NULL", so if you want to use an existing web server implementation as basis for your IPP server, your choices might be limited. Carl-Uno >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Thursday, November 06, 1997 12:26 PM >> To: Gordon, Charles >> Cc: ipp@pwg.org >> Subject: IPP> RE: SSL3 >> >> Charles, >> >> There is still some misunderstandings about what the proposed security >> solution for IPP is. Randy Turner from Sharp is currently writing up >> some >> text to explain the propsed solution in more detail which should be >> available shortly, but see some initial comments from me inserted in >> your >> text below: >> >> At 06:33 AM 11/6/97 PST, you wrote: >> >As someone representing a print server vendor, I would like to go on >> >record as being against requiring support for SSL3. Requiring >> support >> >for it will add additional cost to both the client and the printer, >> and >> >most applications will not need it. I have no objection to making >> >support for a secure protocol optional. Some vendors will have >> >applications which require security, and having a standardized way of >> >supporting secure IPP will allow products from those vendors to >> >interoperate. However, the rest of us who don't need security, >> should >> >not be forced to incur the additional cost of implementing something >> >like SSL3 in order to be IPP compliant. >> >> There is a difference in supporting the whole SSL3 set of >> functionality vs. >> using the negotitiation mechanism, which actually allows you to state >> that >> your IPP client or IPP server does not want to use any security >> features. >> The current discussion is about mandating the capability for IPP >> clients >> and servers to support the negotiation mechanism, but allowing >> implementations to negotiate NULL securiry. >> >> Earlier IPP solutions discussed the option of having both a secure and >> an >> insecure URI for the same IPP printer object, but this turned out to >> be >> rather messy, like would you cross-reference between the two URIs, >> which >> one (or both?) would you list in a Directory etc. The latest proposal >> solves a number of such issues. >> >> >In other words, basic IPP should not require SSL3 or any other secure >> >protocol. However, if some vendor wants to implement a secure >> version >> >of IPP, then the IPP spec should require that they implement it in a >> >specific fashion so that their products are compatible with products >> >from other vendors who implement secure IPP. >> > >> >Also, I think SSL3 is a proprietary protocol owned by Netscape. If >> this >> >is the case, we definitely should not MANDATE support for a >> proprietary >> >protocol. I suggest that we support a secure protocol which is in >> the >> >public domain. I suggest TLS. From what I understand about it, TLS >> is >> >based on SSL3, but is in the public domain (or at least will be when >> the >> >spec is finalized). My objection to SSL3 is because I think it's >> >proprietary. If I'm wrong and SSL3 is in the public domain, then I >> have >> >no objection to it as long as IPP does not require support for it in >> >applications which don't require security. >> >> We DO intend to use TLS for IPP as documented in our latest drafts. >> Unfortunately the TLS specifications are not yet frozen so we cannot >> reference them. SSL3 is an open specification from Netscape, which has >> also >> been implemented by Microsoft and many others, and is the closest we >> can >> get until the TLS specification gets official. Furthermore, the TLS >> specifications will include rules for how to interwork with SSL3. A >> number >> of vendors are already preparing IPP products and we cannot delay the >> IPP >> specifications further in wait for TLS if we want to avoid seeing a >> number >> of "almost IPP, but not quite" implementations in the market place. >> >> > >> > Charles Gordon >> > Osicom/DPI >> > >> > >> >> -----Original Message----- >> >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> >> Sent: Wednesday, November 05, 1997 8:09 PM >> >> To: ipp@pwg.org >> >> Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971105 >> >> >> >> Minutes from PWG IPP Phone Conference 971105 >> >> >> >> Attending: Harry Lewis >> >> Ron Bergman >> >> Randy Turner >> >> Carl-Uno Manros >> >> Tom Hastings >> >> Peter Zehler >> >> Xavier Riley >> >> John Wenn >> >> Ira Mcdonald >> >> Stan McConnell >> >> Scott Isaacson >> >> >> >> The following topics were discussed: >> >> >> >> Comments on minutes from Boulder >> >> >> >> How to perform checking that the sender of a Cancel-Job operation >> is >> >> the >> >> same as the job initiator. It was concluded that the responsibility >> >> for >> >> this is in the IPP server, which might use a simple user name or a >> >> more >> >> elaborate user certificate to establish the identity (depending on >> >> security >> >> level used). The attribute "originating-user-id" has been intended >> for >> >> this. this can contain non-printable information. It was concluded >> >> that >> >> this is really a hidden atribute which the server uses internally >> and >> >> hence >> >> can be deleted from the IPP specification. Some text explaining >> this >> >> should >> >> be added instead. >> >> >> >> Another discussion was held on the use of SSL3 negotiation. Some >> >> conclusions oiut of that discussion was: All IPP communication over >> >> HTTP >> >> will be using the URI scheme "hhtps". Alias names can be given to >> >> printers >> >> using some other schema e.g. "http', but in such cases the server >> >> would >> >> refer the user to the real "https" URI before the actual IPP >> protocol >> >> exchange starts. The latter is really an implementation matter and >> >> does not >> >> need to go into the standards text. It was suggested that we do not >> >> specify >> >> use of "https", or any other URI scheme in the Model document (but >> in >> >> the >> >> Protocol document) apart from in examples. Randy also wanted to >> >> mandate use >> >> of SSL3 (later TLS) in the Model document. There was not full >> >> agreement >> >> about this. >> >> >> >> Some concerns were raised that not all current Web server >> >> implementation >> >> supporting SSL3 also support null framing only, and that hence only >> >> some >> >> serevers could be used for IPP if we mandate the SSL3 framing. Some >> >> further >> >> discussion with vendors is needed. >> >> >> >> Randy promised to have his proposed security changes out to the DL >> >> before >> >> the end of the week. At this stage is unclear whether it is >> meaningful >> >> to >> >> make that text into a I-D or just consider as a proposal against >> the >> >> planned "last call" texts. >> >> >> >> Carl-Uno stated that he will hold off the request to AINA for a >> port >> >> number >> >> until we know for sure what the security details will be. >> >> >> >> It had been discovered that the atribute on "page-ranges" needs >> some >> >> further text to explain how it behaves for multi document jobs. Tom >> >> will >> >> try to improve the text. >> >> >> >> Scott joined in towards the end of the conference and confirmed >> that >> >> he and >> >> Tom were still doing some editing on the Model document, but that >> it >> >> should >> >> be ready to send to the IETF this week. It is assumed that Bob is >> >> working >> >> to the same schedule. No news where Steve Zilles stands with the >> >> update of >> >> the Rationale document. >> >> >> >> Carl-Uno pointed oput that he has started the final call for the >> >> Requirements and the LPD Mapping documents today (both have been >> >> available >> >> as drafts for some time). >> >> >> >> Ira commented that he had found some atribute name differences >> >> compared to >> >> the latest Model draft. He will submit these differences in >> response >> >> to the >> >> "last call". >> >> >> >> We expect to have the next call same time next week. >> >> >> >> Carl-Uno >> >> Carl-Uno Manros >> >> Principal Engineer - Advanced Printing Standards - Xerox >> Corporation >> >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> >> Email: manros@cp10.es.xerox.com >> > >> > >> Carl-Uno Manros >> Principal Engineer - Advanced Printing Standards - Xerox Corporation >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> Email: manros@cp10.es.xerox.com > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Nov 6 16:33:58 1997 Delivery-Date: Thu, 06 Nov 1997 16:33:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22345 for ; Thu, 6 Nov 1997 16:33:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA16702 for ; Thu, 6 Nov 1997 16:36:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22232 for ; Thu, 6 Nov 1997 16:33:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 16:26:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21530 for ipp-outgoing; Thu, 6 Nov 1997 16:14:53 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Nov 1997 14:14:23 -0700 From: Scott Isaacson To: WWagner@digprod.com Cc: ipp@pwg.org Subject: Re: RE: IPP> Use of SSL3 Framing???? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org >>> "Wagner, William" 11/06 11:39 AM >>> > Also, as is pointed out, requiring SSL3 makes little sense since it is > an interim solution. It is not an interim solution in that TSL accepts the fact that SSL3 is in place today and it is deployed almost everywhere and TSL shows a way to accept SSL3 as a compatibility mode. The way to get to TSL is through SSL3. SSL3 is really the only thing that any product would use if deployed in the next few months anyway. Scott From ipp-owner@pwg.org Thu Nov 6 17:00:40 1997 Delivery-Date: Thu, 06 Nov 1997 17:01:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA22682 for ; Thu, 6 Nov 1997 17:00:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA16857 for ; Thu, 6 Nov 1997 17:03:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23443 for ; Thu, 6 Nov 1997 17:00:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 16:52:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21827 for ipp-outgoing; Thu, 6 Nov 1997 16:28:20 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Nov 1997 14:27:20 -0700 From: Scott Isaacson To: xriley@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org >>> "Xavier D. Riley" 11/06 9:53 AM >>> > I would speculate that most SSL3 web server implementations don't support > configuring the Cipher Suite to be SSL_NULL_NULL_WITH_NULL_NULL. Good point, however I am very interested in why you "speculate" that? Tried it and it didn't work? Gut feel? The product documentation says so? Which web servers? Scott My vote (today) is to keep secure and non-secure entries separate for IPP 1.0 and when TLS is approved and deployed in existing off the shelf web servers, we specify the use of it in a later version of IPP. I will hold my final vote until I read the document you plan to release this week. The advertisement of non-secure and secure IPP print systems can occur outside the IPP specification by the simple use of a Web page or LDAP server advertising both print system URLs. I would venture to say that most implementations would either be configured to be non-secure or secure, not both. Non-Secure IPP Print Systems = No Authentication Basic Authentication Digest Access Authentication. Secure IPP Print Systems = Channel level security (i.e. SSL3) ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Thu Nov 6 17:03:11 1997 Delivery-Date: Thu, 06 Nov 1997 17:03:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA22717 for ; Thu, 6 Nov 1997 17:03:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA16884 for ; Thu, 6 Nov 1997 17:05:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23765 for ; Thu, 6 Nov 1997 17:02:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 16:55:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22204 for ipp-outgoing; Thu, 6 Nov 1997 16:33:30 -0500 (EST) Message-Id: <199711062131.QAA11921@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: pzehler@channels.mc.xerox.com Subject: IPP> Re: IPP developers mailing list established cc: moore@cs.utk.edu, IPP@pwg.org From: Keith Moore Date: Thu, 06 Nov 1997 16:31:27 -0500 Sender: ipp-owner@pwg.org > Jeff Schnitzer created an mailing list for us. > (thanks Jeff) This discussion list is for the exchange of > information related to the development and implementation > of IPP clients or servers/printers. Traditionally, discussion of development and implementation happens on the main IETF working group list, to keep a tight feedback loop. Also, customary IETF practice is to keep a WG's mailing list open even after the WG is finished, to facilitate discussion by implementors. Especially given that IPP's work is almost finished, is there some reason this needs to be a separate list? Keith From ipp-owner@pwg.org Thu Nov 6 17:34:37 1997 Delivery-Date: Thu, 06 Nov 1997 17:34:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23093 for ; Thu, 6 Nov 1997 17:34:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17023 for ; Thu, 6 Nov 1997 17:37:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA24703 for ; Thu, 6 Nov 1997 17:34:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 17:26:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23857 for ipp-outgoing; Thu, 6 Nov 1997 17:07:39 -0500 (EST) Message-ID: <34623F66.555D378D@parc.xerox.com> Date: Thu, 6 Nov 1997 14:06:30 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Randy Turner CC: Harry Lewis , ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing???? References: <5030300013763669000002L092*@MHS> <3461F7EA.9C64AEF9@sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > They are required by de facto, not by a pure standard, to support HTTPS > because no commercial vendor of HTTP servers would introduce a server > incapable of providing the capability for internet commerce. This is utterly false. Not all HTTP servers are required to support Internet commerce. -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Thu Nov 6 17:38:32 1997 Delivery-Date: Thu, 06 Nov 1997 17:38:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23113 for ; Thu, 6 Nov 1997 17:38:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17064 for ; Thu, 6 Nov 1997 17:41:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25234 for ; Thu, 6 Nov 1997 17:38:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 17:33:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23928 for ipp-outgoing; Thu, 6 Nov 1997 17:13:05 -0500 (EST) Message-ID: From: "Turner, Randy" To: Larry Masinter , Randy Turner Cc: Harry Lewis , ipp@pwg.org Subject: RE: IPP> Use of SSL3 Framing???? Date: Thu, 6 Nov 1997 14:11:05 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Let me emphasize the word "de facto", because I can't think of any HTTP server shipping today that doesn't support HTTPS (Netscape Enterprise Server, Microsoft IIS, Apache). The question was whether or not there is some requirement, and there is no STANDARD requirement that HTTP servers support SSL3, but there is a very strong MARKET requirement for this type of support. Randy > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Thursday, November 06, 1997 2:07 PM > To: Randy Turner > Cc: Harry Lewis; ipp@pwg.org > Subject: Re: IPP> Use of SSL3 Framing???? > > > They are required by de facto, not by a pure standard, to support > HTTPS > > because no commercial vendor of HTTP servers would introduce a > server > > incapable of providing the capability for internet commerce. > > This is utterly false. Not all HTTP servers are required to support > Internet > commerce. > -- > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Thu Nov 6 18:25:54 1997 Delivery-Date: Thu, 06 Nov 1997 18:25:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23670 for ; Thu, 6 Nov 1997 18:25:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA17287 for ; Thu, 6 Nov 1997 18:28:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA26199 for ; Thu, 6 Nov 1997 18:25:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 6 Nov 1997 18:21:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25566 for ipp-outgoing; Thu, 6 Nov 1997 18:10:06 -0500 (EST) Message-Id: <3.0.1.32.19971106144929.00c692b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 6 Nov 1997 14:49:29 PST To: "Turner, Randy" , Larry Masinter , Randy Turner From: Carl-Uno Manros Subject: RE: IPP> Use of SSL3 Framing???? Cc: Harry Lewis , ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, You seem to think only about web server vendors. There are a number of other HTTP implementations, in particular for embedding in devices (such as printers) that are counting every bit they put in. Carl-Uno At 02:11 PM 11/6/97 PST, Turner, Randy wrote: > > >Let me emphasize the word "de facto", because I can't think of any HTTP >server shipping today that doesn't support HTTPS (Netscape Enterprise >Server, Microsoft IIS, Apache). The question was whether or not there is >some requirement, and there is no STANDARD requirement that HTTP servers >support >SSL3, but there is a very strong MARKET requirement for this type of >support. > >Randy > > >> -----Original Message----- >> From: Larry Masinter [SMTP:masinter@parc.xerox.com] >> Sent: Thursday, November 06, 1997 2:07 PM >> To: Randy Turner >> Cc: Harry Lewis; ipp@pwg.org >> Subject: Re: IPP> Use of SSL3 Framing???? >> >> > They are required by de facto, not by a pure standard, to support >> HTTPS >> > because no commercial vendor of HTTP servers would introduce a >> server >> > incapable of providing the capability for internet commerce. >> >> This is utterly false. Not all HTTP servers are required to support >> Internet >> commerce. >> -- >> http://www.parc.xerox.com/masinter > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Nov 7 11:54:12 1997 Delivery-Date: Fri, 07 Nov 1997 11:54:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA08646 for ; Fri, 7 Nov 1997 11:54:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA19658 for ; Fri, 7 Nov 1997 11:57:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA13355 for ; Fri, 7 Nov 1997 11:54:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 11:43:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09473 for ipp-outgoing; Fri, 7 Nov 1997 11:26:58 -0500 (EST) Message-Id: <3.0.32.19971107082558.006cd49c@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 7 Nov 1997 08:26:00 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP>MOD - minor corrections Cc: xriley@cp10.es.xerox.com, cmanros@cp10.es.xerox.com, thastings@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Assuming that document-charset is the newer version of content-charset, the following changes should be made to section 3.2.4 "Creat-Job Operation": Change "content-charset" to "document-charset" on lines 1012 & 1014 Change "content-natural-language" to "document-natural-language" on lines 1012 and 1015. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Fri Nov 7 13:24:25 1997 Delivery-Date: Fri, 07 Nov 1997 13:24:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09590 for ; Fri, 7 Nov 1997 13:24:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19986 for ; Fri, 7 Nov 1997 13:27:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA26957 for ; Fri, 7 Nov 1997 13:24:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 13:18:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23910 for ipp-outgoing; Fri, 7 Nov 1997 13:02:37 -0500 (EST) Message-Id: <3.0.1.32.19971107094603.00c76100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 7 Nov 1997 09:46:03 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Article about IPP in Infoworld Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Philip Thambidurai just pointed me to a new article on IPP on today's Infoworld web site. You may be interested to take a look at it. They got some things right and some things wrong as usual... http://www.infoworld.com/cgi-bin/displayStory.pl?97116.wipp.htm Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Nov 7 16:36:27 1997 Delivery-Date: Fri, 07 Nov 1997 16:36:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA12654 for ; Fri, 7 Nov 1997 16:36:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20840 for ; Fri, 7 Nov 1997 16:39:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25626 for ; Fri, 7 Nov 1997 16:36:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 16:32:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23570 for ipp-outgoing; Fri, 7 Nov 1997 16:16:58 -0500 (EST) Message-ID: <3463845A.FA158554@underscore.com> Date: Fri, 07 Nov 1997 16:12:58 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> ADM - Article about IPP in Infoworld References: <3.0.1.32.19971107094603.00c76100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl, > Philip Thambidurai just pointed me to a new article on IPP on today's > Infoworld web site. You may be interested to take a look at it. They got > some things right and some things wrong as usual... > > http://www.infoworld.com/cgi-bin/displayStory.pl?97116.wipp.htm I read the article. What, in your opinion, did they get wrong? Just curious. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Nov 7 17:41:15 1997 Delivery-Date: Fri, 07 Nov 1997 17:41:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA13332 for ; Fri, 7 Nov 1997 17:41:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21037 for ; Fri, 7 Nov 1997 17:44:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26509 for ; Fri, 7 Nov 1997 17:41:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 17:34:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25765 for ipp-outgoing; Fri, 7 Nov 1997 17:23:15 -0500 (EST) Message-Id: <199711072222.RAA06683@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> on the use of SSL3 framing and SASL cc: moore@cs.utk.edu From: Keith Moore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Nov 1997 17:22:55 -0500 Sender: ipp-owner@pwg.org Chances are that IESG won't allow a standards track RFC to incorporate the SSL3 protocol. It will have to reference the TLS protocol. Fortuantely, the TLS spec is essentally finished - the TLS WG has finished its internal Last Call and would appear to be ready to send the spec back to IESG. So I don't expect that referencing the TLS spec would delay adoption of IPP as a standard. Also, while it's technically feasible to always use TLS framing with IPP, it seems like it would be far better to define a SASL negotiation framework for HTTP, which could then negotiate TLS. SASL is already a Proposed Standard RFC, and is being retro-fitted into a number of existing apps protocols. Keith From ipp-owner@pwg.org Fri Nov 7 18:12:53 1997 Delivery-Date: Fri, 07 Nov 1997 18:12:54 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13745 for ; Fri, 7 Nov 1997 18:12:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21153 for ; Fri, 7 Nov 1997 18:15:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27188 for ; Fri, 7 Nov 1997 18:12:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 18:08:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26623 for ipp-outgoing; Fri, 7 Nov 1997 17:56:51 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: IPP> Security proposal Date: Fri, 7 Nov 1997 14:55:00 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I have placed a draft of my IPP security proposal on the PWG FTP server. There is a Microsoft Word 2.0 document version ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.doc and an HTML version ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.html Randy From ipp-owner@pwg.org Fri Nov 7 18:46:16 1997 Delivery-Date: Fri, 07 Nov 1997 18:46:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA14210 for ; Fri, 7 Nov 1997 18:46:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21246 for ; Fri, 7 Nov 1997 18:49:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA28805 for ; Fri, 7 Nov 1997 18:45:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 18:31:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27256 for ipp-outgoing; Fri, 7 Nov 1997 18:13:28 -0500 (EST) Message-ID: <3463A089.F81EE8BA@underscore.com> Date: Fri, 07 Nov 1997 18:13:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org Subject: Re: IPP> Security proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Turner, Randy wrote: > > I have placed a draft of my IPP security proposal on the > PWG FTP server. > > There is a Microsoft Word 2.0 document version > > ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.doc > > and an HTML version > > ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.html When I try to access the HTML form, I get a blank document. Perhaps an upload error? ...jay From ipp-owner@pwg.org Fri Nov 7 19:37:27 1997 Delivery-Date: Fri, 07 Nov 1997 19:37:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14575 for ; Fri, 7 Nov 1997 19:37:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21370 for ; Fri, 7 Nov 1997 19:40:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01651 for ; Fri, 7 Nov 1997 19:37:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 19:22:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27484 for ipp-outgoing; Fri, 7 Nov 1997 18:25:32 -0500 (EST) Date: Fri, 7 Nov 1997 15:23:44 -0800 (Pacific Standard Time) From: Ron Bergman To: Keith Moore cc: ipp@pwg.org Subject: Re: IPP> on the use of SSL3 framing and SASL In-Reply-To: <199711072222.RAA06683@spot.cs.utk.edu> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Keith, Could you give me a hint as what RFC describes SASL? A search on SASL or security or secure does not result in a match. Thanks, Ron Bergman On Fri, 7 Nov 1997, Keith Moore wrote: > Chances are that IESG won't allow a standards track RFC to incorporate > the SSL3 protocol. It will have to reference the TLS protocol. > Fortuantely, the TLS spec is essentally finished - the TLS WG has > finished its internal Last Call and would appear to be ready to send > the spec back to IESG. So I don't expect that referencing the TLS > spec would delay adoption of IPP as a standard. > > Also, while it's technically feasible to always use TLS framing with > IPP, it seems like it would be far better to define a SASL negotiation > framework for HTTP, which could then negotiate TLS. SASL is already a > Proposed Standard RFC, and is being retro-fitted into a number of > existing apps protocols. > > Keith > > > > > > > > > > > From ipp-owner@pwg.org Fri Nov 7 19:47:26 1997 Delivery-Date: Fri, 07 Nov 1997 19:47:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14634 for ; Fri, 7 Nov 1997 19:47:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21387 for ; Fri, 7 Nov 1997 19:50:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02535 for ; Fri, 7 Nov 1997 19:46:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 19:33:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28382 for ipp-outgoing; Fri, 7 Nov 1997 18:38:44 -0500 (EST) Message-Id: <3.0.1.32.19971107152209.00bc7a90@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 7 Nov 1997 15:22:09 PST To: Keith Moore , Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: Re: IPP> on the use of SSL3 framing and SASL Cc: ipp@pwg.org, jis@mit.edu, treese@openmarket.com In-Reply-To: <199711072222.RAA06683@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 02:22 PM 11/7/97 PST, Keith Moore wrote: >Chances are that IESG won't allow a standards track RFC to incorporate >the SSL3 protocol. It will have to reference the TLS protocol. >Fortuantely, the TLS spec is essentally finished - the TLS WG has >finished its internal Last Call and would appear to be ready to send >the spec back to IESG. So I don't expect that referencing the TLS >spec would delay adoption of IPP as a standard. > >Also, while it's technically feasible to always use TLS framing with >IPP, it seems like it would be far better to define a SASL negotiation >framework for HTTP, which could then negotiate TLS. SASL is already a >Proposed Standard RFC, and is being retro-fitted into a number of >existing apps protocols. > >Keith > Keith, We will never get this project finished if we keep getting new or changed security requirements from the Area Directors every week. This has already held us up for an extra couple of months. Can you confirm whether SASL now allows a user to negotiate that they do NOT want to use security features as an option, otherwise I expect that we do not want to touch it. An assumption in earlier discussions was that TLS allowed for this, but apparently not any more after the latest IESG intervention. Can you PLEASE consider our project as a user of the IETF security standards and when security comes up next in the IESG, in your role as our project advisor, make it clear that we want to have one option which is simply NO SECURITY (beyond RFC 2069, which we mandate support for in our protocol specification). Thanks, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Nov 7 19:48:11 1997 Delivery-Date: Fri, 07 Nov 1997 19:48:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14646 for ; Fri, 7 Nov 1997 19:48:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21393 for ; Fri, 7 Nov 1997 19:51:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02633 for ; Fri, 7 Nov 1997 19:48:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 19:34:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28334 for ipp-outgoing; Fri, 7 Nov 1997 18:38:14 -0500 (EST) Date: Fri, 7 Nov 1997 15:34:47 PST From: xriley@cp10.es.xerox.com (Xavier Riley.) Message-Id: <199711072334.PAA02160@xmicro.cp10.es.xerox.com> To: moore@cs.utk.edu Subject: Re: IPP> on the use of SSL3 framing and SASL Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Keith, > > Also, while it's technically feasible to always use TLS framing with > IPP, it seems like it would be far better to define a SASL negotiation > framework for HTTP, which could then negotiate TLS. SASL is already a > Proposed Standard RFC, and is being retro-fitted into a number of > existing apps protocols. > > Keith > Any estimate on how soon you expect the major Web server vendors to implement SASL and TLS in their Web servers? Thanks, Xavier ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Fri Nov 7 20:33:18 1997 Delivery-Date: Fri, 07 Nov 1997 20:33:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14899 for ; Fri, 7 Nov 1997 20:33:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA21484 for ; Fri, 7 Nov 1997 20:36:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA03426 for ; Fri, 7 Nov 1997 20:33:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 20:12:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01173 for ipp-outgoing; Fri, 7 Nov 1997 19:30:36 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 07 Nov 1997 17:29:46 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document 971107 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have posted a new Model document. This is going to the IETF I-D secretariat as draft-ietf-ipp-model-07.txt which replaces not just draft-ietf-ipp-model-06.txt but draft-ietf-ipp-dir-schema-01.txt and draft-ietf-ipp-security-01.txt. The files are: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971107-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971107-rev.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971107.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971107.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971107.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-07.txt Tom and Bob have spent many hours in the last week going over this. Thanks to Tom for his online, editing help. This is the document that we want to use for the WG last call for comments before sending it off to the IESG for their last call for comments. Look for the IETF I-D announcement on draft-ietf-ipp-model-07.txt and then Carl-Uno will send out the mail message on this mailing list about starting the last call. Significant changes since 971021 1. Added MANDATORY "containing-printer-uri" Job Description attribute, so a client can get to the Printer given just the Job URI. 2. Changed the status code name from 'client-error-unsupported-document-format' to 'client-error-document-format-not-supported' to agree with all the other 'xxx-not-supported' status codes. 3. Printer object MUST accept and store all natural languages, whether supported or not. Never return an error, so behavior is the same whether "ipp-attribute-fidelity" is 'true' or 'false'. 4. Printer object always rejects a "document-format" that is not supported, even if "ipp-attribute-fidelity" is 'false'. Therefore, moved 'document-format' from Job Template to operation attribute on Create operations and Send-Document/Send-URI operations and added "document-format" and "document-formats-supported" to the Printer object. 5. Added "requesting-user-name" operation attribute to all operations and as a Job Description attribute and removed "job-originating-user-id" Job Description attribute. Its an internal matter of how to store a principle certificate in a Job object for authorizing. 7. 'uriScheme', 'charset', and 'naturalLanguage' are all lower case to simplify compare, even though the registrations are case-insensitive; 'mimeMediaType' remains case-insensitive. 8. Added a 0 value to "number-up" to turn off all embellishments. 9. Added "my-jobs" operation attribute to Get-Jobs, so that a user could request his/her jobs or all jobs (default). 10. Added "copies-collated-default" instead overloading "copies-default" depending on the Printer object's "multiple-document-handling-default" value. 11. Indicated the effects of "multiple-document-handling" on "page-range" attribute. 12. IPP objects return submitted attributes and values that have problems, not the substituted values. Client can query the Job object to see what is ignored and what is substituted. Needed this simplification to handle cross attribute conflicts. This simplifies returning the Unsupported Attributes because what is returned is the same whether "ipp-attribute-fidelity" is 'true' or 'false'. Added 'successful-ok-conflicting-attributes' and 'client-error-conflicting-attributes' status code for those implementations that want to support validation of conflicting attributes. 13. Read Section 15, because the algorithms have been significantly added to and clarified. 14. Security statements softened from "MUST use SSL3/TLS to "if a secure communcation channel is needed, then use SSL3/TLS" Randy's document did not make it in - needs to be reviewed separately. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., MS PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: scott_isaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Fri Nov 7 20:56:11 1997 Delivery-Date: Fri, 07 Nov 1997 20:56:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14964 for ; Fri, 7 Nov 1997 20:56:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA21544 for ; Fri, 7 Nov 1997 20:59:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04307 for ; Fri, 7 Nov 1997 20:56:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 20:36:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA02288 for ipp-outgoing; Fri, 7 Nov 1997 19:43:24 -0500 (EST) Message-Id: <199711080042.TAA07142@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ron Bergman cc: Keith Moore , ipp@pwg.org Subject: Re: IPP> on the use of SSL3 framing and SASL In-reply-to: Your message of "Fri, 07 Nov 1997 15:23:44 PST." Date: Fri, 07 Nov 1997 19:42:51 -0500 Sender: ipp-owner@pwg.org > Could you give me a hint as what RFC describes SASL? RFC 2222 From ipp-owner@pwg.org Fri Nov 7 21:06:12 1997 Delivery-Date: Fri, 07 Nov 1997 21:06:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15009 for ; Fri, 7 Nov 1997 21:06:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21561 for ; Fri, 7 Nov 1997 21:09:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA04712 for ; Fri, 7 Nov 1997 21:06:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 20:47:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA02729 for ipp-outgoing; Fri, 7 Nov 1997 19:50:54 -0500 (EST) Message-Id: <199711080049.TAA07157@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: xriley@cp10.es.xerox.com (Xavier Riley.) cc: moore@cs.utk.edu, ipp@pwg.org Subject: Re: IPP> on the use of SSL3 framing and SASL In-reply-to: Your message of "Fri, 07 Nov 1997 15:34:47 PST." <199711072334.PAA02160@xmicro.cp10.es.xerox.com> Date: Fri, 07 Nov 1997 19:49:20 -0500 Sender: ipp-owner@pwg.org > Any estimate on how soon you expect the major Web server > vendors to implement SASL and TLS in their Web servers? No. I'll have to poll them to see what they think. (but then again, how many of them implement TLS framing w/o security?) One advantage in IPP using SASL+TLS over just TLS would be that an IPP client or server that didn't need security could use ordinary HTTP client or server code. Personally, I'm hoping that all of the protocols layered on HTTP can use the same security negotiation mechanism. Keith From ipp-owner@pwg.org Fri Nov 7 21:26:34 1997 Delivery-Date: Fri, 07 Nov 1997 21:26:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15065 for ; Fri, 7 Nov 1997 21:26:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21581 for ; Fri, 7 Nov 1997 21:29:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06307 for ; Fri, 7 Nov 1997 21:26:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 21:11:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA02769 for ipp-outgoing; Fri, 7 Nov 1997 20:02:42 -0500 (EST) Message-Id: <3.0.1.32.19971107164605.00bd02d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 7 Nov 1997 16:46:05 PST To: "Turner, Randy" , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Security proposal In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 02:55 PM 11/7/97 PST, Turner, Randy wrote: > >I have placed a draft of my IPP security proposal on the >PWG FTP server. > >There is a Microsoft Word 2.0 document version > >ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.doc > >and an HTML version > >ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.html > >Randy > Randy, Randy, Thanks for taking the time to put your ideas on paper. I looked over your proposal and would like you to comment on the following things. I expect to get back with more detailed comments after having spoken to my security guys on Monday. 1) I was disappointed that you did not spell out what is now the minimum "extra stuff" that every implementation would have to include if we mandated TLS negotiation for all IPP clients and servers. My latest impression is that it is a lot more than we anticipated when the subject was discussed in the Boulder PWG meeting. 2) Earlier today Keith Moore came up with a proposal to take a new look at SASL, which might eliviate some of the extra burden that 1) above might incur. Do you or anybody else knows if "the world" is really going to implement SASL in the foreseeable future (or are we up against yet another road block here)? Judging from the comments on the DL recently, a number of people have asked for a very light weight mechanism to do the initial security negotiation, with the option to say "NO I do not want any security", and I am still not convinced that TLS will deliver that. --- If I have interpreted the feelings of the WG on this subject correctly, I would like to draw a comparison with safe sex: If you tend to mix with new or potentially unreliable partners, you are quite likely to want to have some form of protection and would welcome the subject to be brought up before you get too intimate. However, if you only practise it with a steady and wellknown partner, you would probably be upset to have to go through a forced negotitation about different types of preventive tools and methods every time. If you trust your partner, you should be allowed to practise unsafe sex at your own risk, without any lengthy negotiation beforehand! Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Nov 7 21:26:40 1997 Delivery-Date: Fri, 07 Nov 1997 21:26:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15067 for ; Fri, 7 Nov 1997 21:26:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21586 for ; Fri, 7 Nov 1997 21:29:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06322 for ; Fri, 7 Nov 1997 21:26:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 21:11:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA02782 for ipp-outgoing; Fri, 7 Nov 1997 20:03:53 -0500 (EST) Message-Id: <199711080102.UAA07204@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , Harald.T.Alvestrand@uninett.no, ipp@pwg.org, jis@mit.edu, treese@openmarket.com Subject: Re: IPP> on the use of SSL3 framing and SASL In-reply-to: Your message of "Fri, 07 Nov 1997 15:22:09 PST." <3.0.1.32.19971107152209.00bc7a90@garfield> Date: Fri, 07 Nov 1997 20:02:05 -0500 Sender: ipp-owner@pwg.org > We will never get this project finished if we keep getting new or changed > security requirements from the Area Directors every week. This has already > held us up for an extra couple of months. The alternative, in this case, might be to get the project "finished" but have it going in a different direction from other HTTP-based protocols. If the IPP working group wants to explicitly decide to do that, that might be just fine, but I believe it's worth considering how to keep things coordinated. > Can you confirm whether SASL now allows a user to negotiate that they do > NOT want to use security features as an option. Of course it does. Both parties have to agree on the level of security used. Otherwise nobody would use it. With SASL, if a client doesn't want to use security, it simply doesn't issue the AUTH command. (Of course, the server could then deny access to any other commands with an insufficient authentication error.) > Can you PLEASE consider our project as a user of the IETF security > standards and when security comes up next in the IESG, in your role as our > project advisor, make it clear that we want to have one option which is > simply NO SECURITY (beyond RFC 2069, which we mandate support for in our > protocol specification). This is fine with me, and as far as I know, it will be fine with the rest of IESG. As far as I'm concerned, SASL and/or TLS can be optional for an implementation. Keith From ipp-owner@pwg.org Fri Nov 7 21:29:16 1997 Delivery-Date: Fri, 07 Nov 1997 21:29:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15081 for ; Fri, 7 Nov 1997 21:29:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21593 for ; Fri, 7 Nov 1997 21:32:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06687 for ; Fri, 7 Nov 1997 21:29:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 21:14:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA02812 for ipp-outgoing; Fri, 7 Nov 1997 20:10:31 -0500 (EST) Date: Fri, 7 Nov 1997 17:09:44 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711080109.RAA07134@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO new protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded a new protocol document to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The documents are: ipp-pro-971107-rev.doc MS Word 6.0 with revisions ipp-pro-971107.doc MS Word 6.0 with no revisions ipp-pro-971107.txt text version with no revisions The text version has been sent to the IETF as -03- version. Bob Herriot From ipp-owner@pwg.org Fri Nov 7 21:33:08 1997 Delivery-Date: Fri, 07 Nov 1997 21:33:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA15089 for ; Fri, 7 Nov 1997 21:33:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21606 for ; Fri, 7 Nov 1997 21:36:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07227 for ; Fri, 7 Nov 1997 21:33:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 21:27:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03416 for ipp-outgoing; Fri, 7 Nov 1997 20:32:52 -0500 (EST) Message-ID: From: "Turner, Randy" To: Carl-Uno Manros , "Turner, Randy" , ipp@pwg.org Subject: RE: IPP> Security proposal Date: Fri, 7 Nov 1997 17:30:34 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org [Carl Uno Manros wrote...] > > Randy, > > Thanks for taking the time to put your ideas on paper. > > I looked over your proposal and would like you to comment on the > following > things. > I expect to get back with more detailed comments after having spoken > to my > security guys on Monday. > > 1) I was disappointed that you did not spell out what is now the > minimum > "extra stuff" that every implementation would have to include if we > mandated TLS negotiation for all IPP clients and servers. My latest > impression is that it is a lot more than we anticipated when the > subject > was discussed in the Boulder PWG meeting. [Turner, Randy] I modified my stand in Boulder to require the minimum negotiated security to be MD5 message digest, this is in order to be compliant with some web servers that use SSL3 but might not be able to negotiate down to NO security. Also, after thinking about it, it didn't make much sense to have an encapsulation without utilizing it to some degree. MD5 message digest is a very simple security mechanism that, even in intranet environments, would not be a burden to implement. And in the cases where a minimally compliant printer would be accessed across a possibly insecure topology (i.e., the internet), then at least the minimally compliant printer could offer some level of security. I don't think this minimal level of security is too much to ask from an "Internet" printing protocol... [Turner, Randy] [end] > > 2) Earlier today Keith Moore came up with a proposal to take a new > look at > SASL, which might eliviate some of the extra burden that 1) above > might > incur. Do you or anybody else knows if "the world" is really going to > implement SASL in the foreseeable future (or are we up against yet > another > road block here)? Judging from the comments on the DL recently, a > number of > people have asked for a very light weight mechanism to do the initial > security negotiation, with the option to say "NO I do not want any > security", and I am still not convinced that TLS will deliver that. [Turner, Randy] All I can say is to read the TLS specification. Its quite clear on what it is and is not capable of doing. Randy [..snip..] From ipp-owner@pwg.org Fri Nov 7 22:01:39 1997 Delivery-Date: Fri, 07 Nov 1997 22:01:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA15139 for ; Fri, 7 Nov 1997 22:01:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA21651 for ; Fri, 7 Nov 1997 22:04:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07864 for ; Fri, 7 Nov 1997 22:01:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 21:57:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07327 for ipp-outgoing; Fri, 7 Nov 1997 21:45:43 -0500 (EST) Message-Id: <3.0.1.32.19971107184931.01620a00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 7 Nov 1997 18:49:31 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO new protocol document - .pdf files downloaded too Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've added the .pdf files as well: ipp-pro-971107-rev-red.doc PDF with red revision marks ipp-pro-971107-rev-black.doc PDF with black revision marks ipp-pro-971107.doc PDF witn no revision marks Tom >Date: Fri, 7 Nov 1997 17:09:44 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO new protocol document >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I have just downloaded a new protocol document to: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > >The documents are: > > ipp-pro-971107-rev.doc MS Word 6.0 with revisions > ipp-pro-971107.doc MS Word 6.0 with no revisions > ipp-pro-971107.txt text version with no revisions > > >The text version has been sent to the IETF as -03- version. > > >Bob Herriot > > From ipp-owner@pwg.org Fri Nov 7 22:28:33 1997 Delivery-Date: Fri, 07 Nov 1997 22:28:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA16681 for ; Fri, 7 Nov 1997 22:28:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA21682 for ; Fri, 7 Nov 1997 22:31:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA08516 for ; Fri, 7 Nov 1997 22:28:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 7 Nov 1997 22:24:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA07966 for ipp-outgoing; Fri, 7 Nov 1997 22:13:14 -0500 (EST) Message-Id: <3.0.1.32.19971107185655.00b58b30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 7 Nov 1997 18:56:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - THANKS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Thanks to Scott, Bob and Tom for bringing us the documents that can now shortly go out for Last Call. This is an important milestone for us all. I hope that the WG members will be happy with the latest edits and final touches to our documents, and that we do not get too many comments back! Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sat Nov 8 02:01:38 1997 Delivery-Date: Sat, 08 Nov 1997 02:02:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id CAA22781 for ; Sat, 8 Nov 1997 02:01:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA21928 for ; Sat, 8 Nov 1997 02:04:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA09488 for ; Sat, 8 Nov 1997 02:01:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 01:56:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA08952 for ipp-outgoing; Sat, 8 Nov 1997 01:45:28 -0500 (EST) Message-ID: <34640968.B3FC1655@sharplabs.com> Date: Fri, 07 Nov 1997 22:40:40 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Keith Moore CC: Carl-Uno Manros , Harald.T.Alvestrand@uninett.no, ipp@pwg.org, jis@mit.edu, treese@openmarket.com Subject: Re: IPP> on the use of SSL3 framing and SASL References: <199711080102.UAA07204@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org By the way, I could be easily convinced to modify my proposal instead to use SASL/TLS, as long as we specify only one way to do IPP security, one that meets our charter requirements. I would also like to see us do our best to avoid secure and non-secure URIs for IPP services. Randy Keith Moore wrote: > > > We will never get this project finished if we keep getting new or changed > > security requirements from the Area Directors every week. This has already > > held us up for an extra couple of months. > > The alternative, in this case, might be to get the project "finished" > but have it going in a different direction from other HTTP-based > protocols. If the IPP working group wants to explicitly decide to > do that, that might be just fine, but I believe it's worth considering > how to keep things coordinated. > > > Can you confirm whether SASL now allows a user to negotiate that they do > > NOT want to use security features as an option. > > Of course it does. Both parties have to agree on the level of > security used. Otherwise nobody would use it. > > With SASL, if a client doesn't want to use security, it simply > doesn't issue the AUTH command. (Of course, the server could then > deny access to any other commands with an insufficient authentication > error.) > > > Can you PLEASE consider our project as a user of the IETF security > > standards and when security comes up next in the IESG, in your role as our > > project advisor, make it clear that we want to have one option which is > > simply NO SECURITY (beyond RFC 2069, which we mandate support for in our > > protocol specification). > > This is fine with me, and as far as I know, it will be fine with > the rest of IESG. As far as I'm concerned, SASL and/or TLS can > be optional for an implementation. > > Keith From ipp-owner@pwg.org Sat Nov 8 09:57:36 1997 Delivery-Date: Sat, 08 Nov 1997 09:57:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA23719 for ; Sat, 8 Nov 1997 09:57:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA22363 for ; Sat, 8 Nov 1997 10:00:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA10405 for ; Sat, 8 Nov 1997 09:57:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 09:49:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA09873 for ipp-outgoing; Sat, 8 Nov 1997 09:37:53 -0500 (EST) Message-ID: <346478E3.A1B388B5@ibm.net> Date: Sat, 08 Nov 1997 09:36:19 -0500 From: Philip Thambidurai Reply-To: pthambi@ibm.net X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Security proposal X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I think that the MD5 (or other message digest or secure hash algorithm) is used only when the client and the server ALREADY SHARE A SECRET (such as a password). (it is assumed that some other secure channel has been used to transmit that secret from one party to the other). In the Internet Printing context, I can see an end-user who would like to print to an IPP-Printer that may not have any knowledge about the end-user. In such a case, requiring MD5 will prevent the end-user from printing, even if no security of any kind is necessary (internet or intranet). Turner, Randy wrote: > [Carl Uno Manros wrote...] > > > > Randy, > > > > Thanks for taking the time to put your ideas on paper. > > > > I looked over your proposal and would like you to comment on the > > following > > things. > > I expect to get back with more detailed comments after having spoken > > > to my > > security guys on Monday. > > > > 1) I was disappointed that you did not spell out what is now the > > minimum > > "extra stuff" that every implementation would have to include if we > > mandated TLS negotiation for all IPP clients and servers. My latest > > impression is that it is a lot more than we anticipated when the > > subject > > was discussed in the Boulder PWG meeting. > [Turner, Randy] > I modified my stand in Boulder to require the minimum > negotiated > security to be MD5 message digest, this is in order to be > compliant > with some web servers that use SSL3 but might not be able to > negotiate down to NO security. Also, after thinking about it, > it > didn't > make much sense to have an encapsulation without utilizing it > to > some > degree. MD5 message digest is a very simple security mechanism > > that, even in intranet environments, would not be a burden to > implement. > And in the cases where a minimally compliant printer would be > accessed > across a possibly insecure topology (i.e., the internet), then > > at least the > minimally compliant printer could offer some level of > security. > I don't think > this minimal level of security is too much to ask from an > "Internet" > printing protocol... > [Turner, Randy] [end] > > > > > 2) Earlier today Keith Moore came up with a proposal to take a new > > look at > > SASL, which might eliviate some of the extra burden that 1) above > > might > > incur. Do you or anybody else knows if "the world" is really going > to > > implement SASL in the foreseeable future (or are we up against yet > > another > > road block here)? Judging from the comments on the DL recently, a > > number of > > people have asked for a very light weight mechanism to do the > initial > > security negotiation, with the option to say "NO I do not want any > > security", and I am still not convinced that TLS will deliver that. > [Turner, Randy] > All I can say is to read the TLS specification. Its quite > clear > on > what it is and is not capable of doing. > > Randy > > [..snip..] From ipp-owner@pwg.org Sat Nov 8 11:22:04 1997 Delivery-Date: Sat, 08 Nov 1997 11:22:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24055 for ; Sat, 8 Nov 1997 11:22:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22472 for ; Sat, 8 Nov 1997 11:25:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA11105 for ; Sat, 8 Nov 1997 11:22:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 11:16:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10568 for ipp-outgoing; Sat, 8 Nov 1997 11:05:27 -0500 (EST) Message-Id: <199711081606.LAA06490@devnix.agranat.com> To: pthambi@ibm.net cc: ipp@pwg.org Subject: Re: IPP> Security proposal In-reply-to: <346478E3.A1B388B5@ibm.net> Date: Sat, 08 Nov 1997 11:06:37 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org >>>>> "PT" == Philip Thambidurai writes: PT> I think that the MD5 (or other message digest or secure hash algorithm) PT> is used only when PT> the client and the server ALREADY SHARE A SECRET (such as a password). PT> (it is assumed that some other secure channel has been used to transmit PT> that secret from one party to the other). The HTTP Digest Access Authentication scheme does require a shared secret. PT> In the Internet Printing context, I can see an end-user who would like PT> to print to PT> an IPP-Printer that may not have any knowledge about the end-user. PT> In such a case, requiring MD5 will prevent the end-user from PT> printing, even if no security of any kind is necessary (internet or PT> intranet). If the printer is configured to accept print jobs without authentication, then it does not need to issue an authentication challenge and none will be needed. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Sat Nov 8 11:46:05 1997 Delivery-Date: Sat, 08 Nov 1997 11:46:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24149 for ; Sat, 8 Nov 1997 11:46:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22518 for ; Sat, 8 Nov 1997 11:49:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA11762 for ; Sat, 8 Nov 1997 11:46:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 11:42:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11211 for ipp-outgoing; Sat, 8 Nov 1997 11:30:43 -0500 (EST) Message-ID: <3464928E.39386EFA@sharplabs.com> Date: Sat, 08 Nov 1997 08:25:50 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Security proposal References: <346478E3.A1B388B5@ibm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The shared secret was not indicated by the TLS document, but the connection startup algorithms from SASL may give us a way out of this problem. I agree that we do not want to impose heavy weight requirements on clients that want to initiate, what i will call, "anonymous" printing. Randy Philip Thambidurai wrote: > > I think that the MD5 (or other message digest or secure hash algorithm) > is used only when > the client and the server ALREADY SHARE A SECRET (such as a password). > (it is assumed that some other secure channel has been used to transmit > that > secret from one party to the other). > > In the Internet Printing context, I can see an end-user who would like > to print to > an IPP-Printer that may not have any knowledge about the end-user. > In such a case, requiring MD5 will prevent the end-user from > printing, even if no security of any kind is necessary (internet or > intranet). > > Turner, Randy wrote: > > > [Carl Uno Manros wrote...] > > > > > > Randy, > > > > > > Thanks for taking the time to put your ideas on paper. > > > > > > I looked over your proposal and would like you to comment on the > > > following > > > things. > > > I expect to get back with more detailed comments after having spoken > > > > > to my > > > security guys on Monday. > > > > > > 1) I was disappointed that you did not spell out what is now the > > > minimum > > > "extra stuff" that every implementation would have to include if we > > > mandated TLS negotiation for all IPP clients and servers. My latest > > > impression is that it is a lot more than we anticipated when the > > > subject > > > was discussed in the Boulder PWG meeting. > > [Turner, Randy] > > I modified my stand in Boulder to require the minimum > > negotiated > > security to be MD5 message digest, this is in order to be > > compliant > > with some web servers that use SSL3 but might not be able to > > negotiate down to NO security. Also, after thinking about it, > > it > > didn't > > make much sense to have an encapsulation without utilizing it > > to > > some > > degree. MD5 message digest is a very simple security mechanism > > > > that, even in intranet environments, would not be a burden to > > implement. > > And in the cases where a minimally compliant printer would be > > accessed > > across a possibly insecure topology (i.e., the internet), then > > > > at least the > > minimally compliant printer could offer some level of > > security. > > I don't think > > this minimal level of security is too much to ask from an > > "Internet" > > printing protocol... > > [Turner, Randy] [end] > > > > > > > > 2) Earlier today Keith Moore came up with a proposal to take a new > > > look at > > > SASL, which might eliviate some of the extra burden that 1) above > > > might > > > incur. Do you or anybody else knows if "the world" is really going > > to > > > implement SASL in the foreseeable future (or are we up against yet > > > another > > > road block here)? Judging from the comments on the DL recently, a > > > number of > > > people have asked for a very light weight mechanism to do the > > initial > > > security negotiation, with the option to say "NO I do not want any > > > security", and I am still not convinced that TLS will deliver that. > > [Turner, Randy] > > All I can say is to read the TLS specification. Its quite > > clear > > on > > what it is and is not capable of doing. > > > > Randy > > > > [..snip..] From ipp-owner@pwg.org Sat Nov 8 12:34:18 1997 Delivery-Date: Sat, 08 Nov 1997 12:34:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA24245 for ; Sat, 8 Nov 1997 12:34:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA22582 for ; Sat, 8 Nov 1997 12:37:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA12485 for ; Sat, 8 Nov 1997 12:34:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 12:30:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11915 for ipp-outgoing; Sat, 8 Nov 1997 12:18:38 -0500 (EST) Message-ID: <34649DCD.C529EE8A@sharplabs.com> Date: Sat, 08 Nov 1997 09:13:49 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: pthambi@ibm.net CC: ipp@pwg.org Subject: Re: IPP> Security proposal References: <346478E3.A1B388B5@ibm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Another comment on my previous comment... I would like to suggest that we might want to consider *anonymous* printing, a separate case (and class) of IPP printing. I think TLS can handle most of the other requirements for *authenticated* printing (including the exchange of shared secrets...). I'm wondering if we could define an *anonymous* authentication that clients could use and that IPP servers would recognize as a kind of *guest* authentication...this may have already been defined within some other security working group.... Randy Philip Thambidurai wrote: > > I think that the MD5 (or other message digest or secure hash algorithm) > is used only when > the client and the server ALREADY SHARE A SECRET (such as a password). > (it is assumed that some other secure channel has been used to transmit > that > secret from one party to the other). > > In the Internet Printing context, I can see an end-user who would like > to print to > an IPP-Printer that may not have any knowledge about the end-user. > In such a case, requiring MD5 will prevent the end-user from > printing, even if no security of any kind is necessary (internet or > intranet). > > Turner, Randy wrote: > > > [Carl Uno Manros wrote...] > > > > > > Randy, > > > > > > Thanks for taking the time to put your ideas on paper. > > > > > > I looked over your proposal and would like you to comment on the > > > following > > > things. > > > I expect to get back with more detailed comments after having spoken > > > > > to my > > > security guys on Monday. > > > > > > 1) I was disappointed that you did not spell out what is now the > > > minimum > > > "extra stuff" that every implementation would have to include if we > > > mandated TLS negotiation for all IPP clients and servers. My latest > > > impression is that it is a lot more than we anticipated when the > > > subject > > > was discussed in the Boulder PWG meeting. > > [Turner, Randy] > > I modified my stand in Boulder to require the minimum > > negotiated > > security to be MD5 message digest, this is in order to be > > compliant > > with some web servers that use SSL3 but might not be able to > > negotiate down to NO security. Also, after thinking about it, > > it > > didn't > > make much sense to have an encapsulation without utilizing it > > to > > some > > degree. MD5 message digest is a very simple security mechanism > > > > that, even in intranet environments, would not be a burden to > > implement. > > And in the cases where a minimally compliant printer would be > > accessed > > across a possibly insecure topology (i.e., the internet), then > > > > at least the > > minimally compliant printer could offer some level of > > security. > > I don't think > > this minimal level of security is too much to ask from an > > "Internet" > > printing protocol... > > [Turner, Randy] [end] > > > > > > > > 2) Earlier today Keith Moore came up with a proposal to take a new > > > look at > > > SASL, which might eliviate some of the extra burden that 1) above > > > might > > > incur. Do you or anybody else knows if "the world" is really going > > to > > > implement SASL in the foreseeable future (or are we up against yet > > > another > > > road block here)? Judging from the comments on the DL recently, a > > > number of > > > people have asked for a very light weight mechanism to do the > > initial > > > security negotiation, with the option to say "NO I do not want any > > > security", and I am still not convinced that TLS will deliver that. > > [Turner, Randy] > > All I can say is to read the TLS specification. Its quite > > clear > > on > > what it is and is not capable of doing. > > > > Randy > > > > [..snip..] From ipp-owner@pwg.org Sat Nov 8 16:57:55 1997 Delivery-Date: Sat, 08 Nov 1997 16:57:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA24812 for ; Sat, 8 Nov 1997 16:57:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA22851 for ; Sat, 8 Nov 1997 17:00:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13538 for ; Sat, 8 Nov 1997 16:57:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 16:52:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12968 for ipp-outgoing; Sat, 8 Nov 1997 16:41:29 -0500 (EST) Date: Sat, 8 Nov 1997 16:41:14 -0500 (EST) X-Sender: bva@ultranet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Randy Turner From: bva@allegrosoft.com (Bob Van Andel) Subject: Re: IPP> Security proposal Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Randy, > > I'm wondering if we could define an *anonymous* > authentication that clients could use and that IPP > servers would recognize as a kind of *guest* > authentication...this may have already been > defined within some other security working group.... > Why is *anonymous* printing (which is certainly a desirable case) any different than *anonymous* Web site access? In other words, why isn't unsecured access acceptable for this case? Bob Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Read about the RomPager embedded web server toolkit at: www.allegrosoft.com From ipp-owner@pwg.org Sat Nov 8 19:17:09 1997 Delivery-Date: Sat, 08 Nov 1997 19:17:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25139 for ; Sat, 8 Nov 1997 19:17:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22966 for ; Sat, 8 Nov 1997 19:20:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14639 for ; Sat, 8 Nov 1997 19:16:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 8 Nov 1997 19:12:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA14094 for ipp-outgoing; Sat, 8 Nov 1997 19:01:12 -0500 (EST) Message-ID: <3464FD30.C816FB86@underscore.com> Date: Sat, 08 Nov 1997 19:00:48 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Randy Turner CC: pthambi@ibm.net, ipp@pwg.org Subject: Re: IPP> Security proposal References: <346478E3.A1B388B5@ibm.net> <34649DCD.C529EE8A@sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I agree, this is a good idea. It might get us out of admin hell later on, at the point when a customer says "don't force security down my throat if I don't want it." ...jay Randy Turner wrote: > > Another comment on my previous comment... > > I would like to suggest that we might want to > consider *anonymous* printing, a separate case > (and class) of IPP printing. I think TLS > can handle most of the other requirements > for *authenticated* printing (including the > exchange of shared secrets...). > > I'm wondering if we could define an *anonymous* > authentication that clients could use and that IPP > servers would recognize as a kind of *guest* > authentication...this may have already been > defined within some other security working group.... > > Randy > > Philip Thambidurai wrote: > > > > I think that the MD5 (or other message digest or secure hash algorithm) > > is used only when > > the client and the server ALREADY SHARE A SECRET (such as a password). > > (it is assumed that some other secure channel has been used to transmit > > that > > secret from one party to the other). > > > > In the Internet Printing context, I can see an end-user who would like > > to print to > > an IPP-Printer that may not have any knowledge about the end-user. > > In such a case, requiring MD5 will prevent the end-user from > > printing, even if no security of any kind is necessary (internet or > > intranet). > > > > Turner, Randy wrote: > > > > > [Carl Uno Manros wrote...] > > > > > > > > Randy, > > > > > > > > Thanks for taking the time to put your ideas on paper. > > > > > > > > I looked over your proposal and would like you to comment on the > > > > following > > > > things. > > > > I expect to get back with more detailed comments after having spoken > > > > > > > to my > > > > security guys on Monday. > > > > > > > > 1) I was disappointed that you did not spell out what is now the > > > > minimum > > > > "extra stuff" that every implementation would have to include if we > > > > mandated TLS negotiation for all IPP clients and servers. My latest > > > > impression is that it is a lot more than we anticipated when the > > > > subject > > > > was discussed in the Boulder PWG meeting. > > > [Turner, Randy] > > > I modified my stand in Boulder to require the minimum > > > negotiated > > > security to be MD5 message digest, this is in order to be > > > compliant > > > with some web servers that use SSL3 but might not be able to > > > negotiate down to NO security. Also, after thinking about it, > > > it > > > didn't > > > make much sense to have an encapsulation without utilizing it > > > to > > > some > > > degree. MD5 message digest is a very simple security mechanism > > > > > > that, even in intranet environments, would not be a burden to > > > implement. > > > And in the cases where a minimally compliant printer would be > > > accessed > > > across a possibly insecure topology (i.e., the internet), then > > > > > > at least the > > > minimally compliant printer could offer some level of > > > security. > > > I don't think > > > this minimal level of security is too much to ask from an > > > "Internet" > > > printing protocol... > > > [Turner, Randy] [end] > > > > > > > > > > > 2) Earlier today Keith Moore came up with a proposal to take a new > > > > look at > > > > SASL, which might eliviate some of the extra burden that 1) above > > > > might > > > > incur. Do you or anybody else knows if "the world" is really going > > > to > > > > implement SASL in the foreseeable future (or are we up against yet > > > > another > > > > road block here)? Judging from the comments on the DL recently, a > > > > number of > > > > people have asked for a very light weight mechanism to do the > > > initial > > > > security negotiation, with the option to say "NO I do not want any > > > > security", and I am still not convinced that TLS will deliver that. > > > [Turner, Randy] > > > All I can say is to read the TLS specification. Its quite > > > clear > > > on > > > what it is and is not capable of doing. > > > > > > Randy > > > > > > [..snip..] From ipp-owner@pwg.org Sun Nov 9 22:47:38 1997 Delivery-Date: Sun, 09 Nov 1997 22:47:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA04563 for ; Sun, 9 Nov 1997 22:47:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA01289 for ; Sun, 9 Nov 1997 22:50:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA16733 for ; Sun, 9 Nov 1997 22:47:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 9 Nov 1997 22:40:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA16184 for ipp-outgoing; Sun, 9 Nov 1997 22:28:32 -0500 (EST) Message-ID: <34667E3A.C462520C@sharplabs.com> Date: Sun, 09 Nov 1997 19:23:38 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Bob Van Andel CC: ipp@pwg.org Subject: Re: IPP> Security proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob Van Andel wrote: > > Randy, > > > > > I'm wondering if we could define an *anonymous* > > authentication that clients could use and that IPP > > servers would recognize as a kind of *guest* > > authentication...this may have already been > > defined within some other security working group.... > > > > Why is *anonymous* printing (which is certainly a desirable case) > any different than *anonymous* Web site access? > In other words, why isn't unsecured access acceptable for this case? Logically, I think the two scenarios are the same. The problem with this scenario is that HTTP and IPP have two different goals with respect to the end user. Currently, I don't know of any way an HTTP client has to direct an HTTP server to make a particular connection secure, and IPP needs either end to indicate this requirement. We're just using HTTP to transport IPP messages, IPP has different end user scenarios... Randy > > Bob > > Bob Van Andel > Allegro Software Development Corporation > 43 Waite Road > Boxborough, MA 01719 > (978) 266-1375 > (978) 266-2839 fax > > Read about the RomPager embedded web server toolkit at: > www.allegrosoft.com From ipp-owner@pwg.org Mon Nov 10 09:08:51 1997 Delivery-Date: Mon, 10 Nov 1997 09:08:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11919 for ; Mon, 10 Nov 1997 09:08:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02131 for ; Mon, 10 Nov 1997 09:11:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA18316 for ; Mon, 10 Nov 1997 09:08:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 10 Nov 1997 09:00:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA17769 for ipp-outgoing; Mon, 10 Nov 1997 08:48:53 -0500 (EST) Message-Id: <199711101448.JAA00594@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Security proposal In-reply-to: <34667E3A.C462520C@sharplabs.com> Date: Mon, 10 Nov 1997 09:48:56 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org >>>>> "RT" == Randy Turner writes: RT> Currently, I don't know of any way an HTTP client has to direct an RT> HTTP server to make a particular connection secure, and IPP needs RT> either end to indicate this requirement. If you're using 'secure' as 'confidential', then the client requests that protection by making the connection on the SSL port (https:), and indicates that it does not require confidentiality by making the request on a non-SSL port. The service (the printer or print server) probably cares more about authentication than confidentiality for IPP, and it can get that on a connection that is either confidentiality protected or not using Digest Access Authentication. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Mon Nov 10 14:42:25 1997 Delivery-Date: Mon, 10 Nov 1997 14:42:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA16753 for ; Mon, 10 Nov 1997 14:42:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03890 for ; Mon, 10 Nov 1997 14:45:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA23488 for ; Mon, 10 Nov 1997 14:42:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 10 Nov 1997 14:36:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22907 for ipp-outgoing; Mon, 10 Nov 1997 14:25:13 -0500 (EST) Message-Id: <3.0.1.32.19971110091630.00bcc2a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 10 Nov 1997 09:16:30 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - FYI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >From: Harald.T.Alvestrand@uninett.no >Note that there is a new "Instructions to RFC authors" out there, >RFC 2223, which contains explicit instructions about the copyright >notice. > >Following the rest of the instructions will also greatly speed the >progress of documents after they've been handed to the RFC Editor! > >Ciao, > > Harald A > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 10 19:24:17 1997 Delivery-Date: Mon, 10 Nov 1997 19:24:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA19547 for ; Mon, 10 Nov 1997 19:24:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05037 for ; Mon, 10 Nov 1997 19:27:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA25316 for ; Mon, 10 Nov 1997 19:24:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 10 Nov 1997 19:17:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA24762 for ipp-outgoing; Mon, 10 Nov 1997 19:06:21 -0500 (EST) Message-Id: <3.0.1.32.19971110153626.00978ca0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 10 Nov 1997 15:36:26 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 971112 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference 971112, 1:00 - 3:00 pm PST Again, I do not have a lot of an agenda at this stage, but it seems that we should at least discuss Randy's proposal for security and any comments against the latest Model and Protocol drafts. The details are as follows: Call date: 11/12 Dial-in: 608-250-1828 Time: 4PM EST (1PM PST) Duration: 2 hours Access Code: 190148 Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 10 20:10:28 1997 Delivery-Date: Mon, 10 Nov 1997 20:10:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA19855 for ; Mon, 10 Nov 1997 20:10:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05148 for ; Mon, 10 Nov 1997 20:13:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26025 for ; Mon, 10 Nov 1997 20:10:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 10 Nov 1997 20:04:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25467 for ipp-outgoing; Mon, 10 Nov 1997 19:53:20 -0500 (EST) Date: Mon, 10 Nov 1997 16:52:40 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711110052.QAA09893@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD problem with MANDATORY support of operation attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have two concerns a) about an operation being rejected if it contains an unsupported operation-attribute, and b) the incrementing of the major version when an operation attribute is added. I think that the major version should be incremented only when a Printer is likely to make a major mistake, e.g. the syntax has changed. A new operation attribute might fall into this category, but wouldn't normally if a Printer is allowed to ignore unrecognized ones, as I suggest below. The current model document says that a Printer MUST support all operation-attributes and by implication that a Printer rejects an operation if the operation contains an unsupported operation attribute (though I cannot find such language and the algorithm in section 15.3 does not loop through operation attributes (a bug?)). But Scott and Tom believe this to be the case. This issue is much like the fidelity notion for Job-Template attributes and probably calls for two changes in the future: a) an operation attribute "ipp-operation-fidelity" which if false allows the Printer to ignore operation-attributes, and b) an unsupported-operation-attributes group in a response to hold those operation attributes that the Printer ignored. The current behavior of rejecting an operation with unsupported operation attributes is simple, but will lead to problems in the future when different versions are trying to interoperate and users prefer something to nothing. But if an operation ignores attributes without telling the client, that can create problems too. I think that we have painted ourselves into a corner here. a) If we keep the current behavior of rejecting operations that have unsupported operation attributes, we have to rev the major version with each new operation attribute which will create a lot of needless versions to deal with. b) If we allow operations with unsupported operation attributes, then all operations responses need to be able to contain a list of ignored operation attributes (yet another change); otherwise clients won't know how to interpret a response. c) If we believe that a client should be able to choose between a strict and forgiving operation, then we also need to add the operation attribute "ipp-operation-fidelity". Bob Herriot From daemon Tue Nov 11 09:08:08 1997 Delivery-Date: Tue, 11 Nov 1997 09:16:53 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA00944 for ietf-123-outbound.10@ietf.org; Tue, 11 Nov 1997 09:07:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00916; Tue, 11 Nov 1997 09:07:45 -0500 (EST) Message-Id: <199711111407.JAA00916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-07.txt Date: Tue, 11 Nov 1997 09:07:44 -0500 Sender: cclark@cnri.reston.va.us --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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-07.txt Pages : 144 Date : 10-Nov-97 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [IPP-REQ] Internet Printing Protocol/1.0: Model and Semantics (this document) Internet Printing Protocol/1.0: Protocol Specification [IPP-PRO] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [IPP-RAT] The requirements document, ''Requirements for an Internet Printing Protocol'', takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. This document, ''Internet Printing Protocol/1.0: Model and Semantics'', describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed. The protocol specification, '' Internet Printing Protocol/1.0: Protocol Specification'', is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. The protocol specification defines the encoding rules for a new Internet media type called ''application/ipp''. 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-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-07.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: <19971110160419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971110160419.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Tue Nov 11 09:09:57 1997 Delivery-Date: Tue, 11 Nov 1997 09:18:07 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA01016 for ietf-123-outbound.10@ietf.org; Tue, 11 Nov 1997 09:09:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00997; Tue, 11 Nov 1997 09:09:42 -0500 (EST) Message-Id: <199711111409.JAA00997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-03.txt Date: Tue, 11 Nov 1997 09:09:41 -0500 Sender: cclark@cnri.reston.va.us --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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-03.txt Pages : 32 Date : 10-Nov-97 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971110161828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971110161828.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 11 09:40:42 1997 Delivery-Date: Tue, 11 Nov 1997 09:40:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02015 for ; Tue, 11 Nov 1997 09:40:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA06433 for ; Tue, 11 Nov 1997 09:43:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA28932 for ; Tue, 11 Nov 1997 09:40:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 11 Nov 1997 09:30:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA27813 for ipp-outgoing; Tue, 11 Nov 1997 09:09:54 -0500 (EST) Message-Id: <199711111409.JAA00997@ietf.org> 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-protocol-03.txt Date: Tue, 11 Nov 1997 09:09:41 -0500 Sender: ipp-owner@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-03.txt Pages : 32 Date : 10-Nov-97 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971110161828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971110161828.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 11 09:40:43 1997 Delivery-Date: Tue, 11 Nov 1997 09:40:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02018 for ; Tue, 11 Nov 1997 09:40:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA06436 for ; Tue, 11 Nov 1997 09:43:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA28938 for ; Tue, 11 Nov 1997 09:40:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 11 Nov 1997 09:30:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA27797 for ipp-outgoing; Tue, 11 Nov 1997 09:07:54 -0500 (EST) Message-Id: <199711111407.JAA00916@ietf.org> 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-07.txt Date: Tue, 11 Nov 1997 09:07:44 -0500 Sender: ipp-owner@pwg.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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-07.txt Pages : 144 Date : 10-Nov-97 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [IPP-REQ] Internet Printing Protocol/1.0: Model and Semantics (this document) Internet Printing Protocol/1.0: Protocol Specification [IPP-PRO] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [IPP-RAT] The requirements document, ''Requirements for an Internet Printing Protocol'', takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. This document, ''Internet Printing Protocol/1.0: Model and Semantics'', describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed. The protocol specification, '' Internet Printing Protocol/1.0: Protocol Specification'', is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. The protocol specification defines the encoding rules for a new Internet media type called ''application/ipp''. 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-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-07.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: <19971110160419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971110160419.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 11 11:20:26 1997 Delivery-Date: Tue, 11 Nov 1997 11:20:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03159 for ; Tue, 11 Nov 1997 11:20:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA06839 for ; Tue, 11 Nov 1997 11:23:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA29737 for ; Tue, 11 Nov 1997 11:20:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 11 Nov 1997 11:15:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA29188 for ipp-outgoing; Tue, 11 Nov 1997 11:03:55 -0500 (EST) Message-Id: <1.5.4.32.19971111145550.006de800@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, 11 Nov 1997 06:55:50 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> IETF IPP WG - LAST CALL for Model & Semantics and Protocol Specification Sender: ipp-owner@pwg.org Folks, This is a formal request for final comments within the IETF IPP working group, prior to submitting two specifications on to the IESG for consideration as Proposed Standard (first level standards track) RFCs. The documents have undergone considerable and repeated review and revision and we believe that we now have working group consensus on their adequacy. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Last Call is for 2 weeks. Hence, the period for working group comments will close on Tuesday, 25 November (US pacific time reference). The relevant documents are: Title : Internet Printing Protocol/1.0: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-07.txt Pages : 144 Date : 10-Nov-97 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses only on end user functionality. ------ Title : Internet Printing Protocol/1.0: Protocol Specification Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-03.txt Pages : 32 Date : 10-Nov-97 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. ---- For retrieval: Internet-Drafts are available by anonymous FTP. Login wih 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-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-07.txt and: "get draft-ietf-ipp-protocol-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-03.txt --- Carl-Uno Manros Co-Chair, IETF IPP Working Group From ipp-owner@pwg.org Tue Nov 11 16:56:28 1997 Delivery-Date: Tue, 11 Nov 1997 16:56:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA06888 for ; Tue, 11 Nov 1997 16:56:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA08407 for ; Tue, 11 Nov 1997 16:59:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00618 for ; Tue, 11 Nov 1997 16:56:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 11 Nov 1997 16:51:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00021 for ipp-outgoing; Tue, 11 Nov 1997 16:39:43 -0500 (EST) Message-ID: From: "Turner, Randy" To: Scott Lawrence , ipp@pwg.org Subject: RE: IPP> Security proposal Date: Tue, 11 Nov 1997 13:37:37 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org > -----Original Message----- > From: Scott Lawrence [SMTP:lawrence@agranat.com] > Sent: Monday, November 10, 1997 6:49 AM > To: ipp@pwg.org > Subject: Re: IPP> Security proposal > > > >>>>> "RT" == Randy Turner writes: > > RT> Currently, I don't know of any way an HTTP client has to direct an > RT> HTTP server to make a particular connection secure, and IPP needs > RT> either end to indicate this requirement. > > >>>>> "SL" == Scott Lawrence > > SL> If you're using 'secure' as 'confidential', then the client > requests > SL> that protection by making the connection on the SSL port (https:), > SL> and indicates that it does not require confidentiality by making > the > SL> request on a non-SSL port. > > The problem is that HTTPS is a different URL. What I was considering > was the > case where there is only one URL specified for the IPP printer. What > I'm trying to > avoid is running two different IPP services (one secure and one > non-secure) if > I want to support both secure and non-secure environments. With one > URL, > we just connect and negotiate whether or not security is required. > > SL> The service (the printer or print server) probably cares more > about > SL> authentication than confidentiality for IPP, and it can get that > on > SL> a connection that is either confidentiality protected or not > using > SL> Digest Access Authentication. > > The server caring more about authentication than confidentiality is > emphaisized in my previous proposal, as is the option for > confidentiality or not. > > Ultimately, my proposal prioritizes the selection of TLS for our only > security framework for IPP. If we end up going down the path of > supporting multiple URLs for different types of security, I think > it would be unfortunate and add greater administrative and > resource impact for those environments that would like to > support both secure and non-secure IPP services. > Randy > -- > Scott Lawrence EmWeb Embedded Server > > Agranat Systems, Inc. Engineering > http://www.agranat.com/ From ipp-owner@pwg.org Wed Nov 12 08:09:06 1997 Delivery-Date: Wed, 12 Nov 1997 08:09:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA17721 for ; Wed, 12 Nov 1997 08:09:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA09822 for ; Wed, 12 Nov 1997 08:12:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA01847 for ; Wed, 12 Nov 1997 08:09:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 08:01:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA01289 for ipp-outgoing; Wed, 12 Nov 1997 07:50:14 -0500 (EST) Mime-Version: 1.0 Date: Wed, 12 Nov 1997 07:54:19 -0500 Message-ID: <0002D0EB.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re[2]: IPP> Security proposal To: ipp@pwg.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org I don't really see a problem in having two URLs, one for non-secure and the other for secure (https). The directory schema could list both. If security is desired then TLS could be used to negogitate (automatically) to the desired ciphersuite. The non-secure server could allow unauthenticated, basic-auth and digest-auth. The unauthenticated case would correspond to the "anonymous printing" that Randy mentioned earlier. Using https and then negotiating down to no security at all still requires use of port 453 --- this is somewhat deceptive (to a sys admin person). It might?? be difficult to monitor who is using non-secure vs. secure if we use port 453 for both. If security is mandated when using 453, then the sys admin does not have to worry as much about any potential attack. It then makes sense to keep the non-secure server separate (port 80). Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: RE: IPP> Security proposal Author: "Turner; Randy" at INTERNET Date: 11/11/97 1:37 PM > -----Original Message----- > From: Scott Lawrence [SMTP:lawrence@agranat.com] > Sent: Monday, November 10, 1997 6:49 AM > To: ipp@pwg.org > Subject: Re: IPP> Security proposal > > > >>>>> "RT" == Randy Turner writes: > > RT> Currently, I don't know of any way an HTTP client has to direct an > RT> HTTP server to make a particular connection secure, and IPP needs > RT> either end to indicate this requirement. > > >>>>> "SL" == Scott Lawrence > > SL> If you're using 'secure' as 'confidential', then the client > requests > SL> that protection by making the connection on the SSL port (https:), > SL> and indicates that it does not require confidentiality by making > the > SL> request on a non-SSL port. > > The problem is that HTTPS is a different URL. What I was considering > was the > case where there is only one URL specified for the IPP printer. What > I'm trying to > avoid is running two different IPP services (one secure and one > non-secure) if > I want to support both secure and non-secure environments. With one > URL, > we just connect and negotiate whether or not security is required. > > SL> The service (the printer or print server) probably cares more > about > SL> authentication than confidentiality for IPP, and it can get that > on > SL> a connection that is either confidentiality protected or not > using > SL> Digest Access Authentication. > > The server caring more about authentication than confidentiality is > emphaisized in my previous proposal, as is the option for > confidentiality or not. > > Ultimately, my proposal prioritizes the selection of TLS for our only > security framework for IPP. If we end up going down the path of > supporting multiple URLs for different types of security, I think > it would be unfortunate and add greater administrative and > resource impact for those environments that would like to > support both secure and non-secure IPP services. > Randy > -- > Scott Lawrence EmWeb Embedded Server > > Agranat Systems, Inc. Engineering > http://www.agranat.com/ From tcplw-relay@services.BSDI.COM Wed Nov 12 09:45:33 1997 Delivery-Date: Wed, 12 Nov 1997 09:45:52 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18960 for ; Wed, 12 Nov 1997 09:44:58 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA10129 for ; Wed, 12 Nov 1997 09:47:57 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.7) id HAA04485 for tcplw-list@bsdi.com; Wed, 12 Nov 1997 07:39:52 -0700 (MST) Received: from janus.unik.no (janus.unik.no [193.156.96.46]) by services.BSDI.COM (8.8.7/8.8.7) with ESMTP id HAA04477 for ; Wed, 12 Nov 1997 07:39:46 -0700 (MST) Received: from unik.no (ask.unik.no [193.156.96.167]) by janus.unik.no (8.8.5/8.7.3) with ESMTP id PAA15555; Wed, 12 Nov 1997 15:26:11 +0100 (MET) Sender: plageman@unik.no Message-ID: <3469BBFA.E95F587B@unik.no> Date: Wed, 12 Nov 1997 15:23:54 +0100 From: Thomas Plagemann Organization: University of Oslo X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, cost237-teleservices@comp.lancs.ac.uk, tcplw@bsdi.com CC: idms98@unik.no Subject: CfP IDMS'98 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by services.BSDI.COM id HAA04483 Dear Collegues, please find below the Call for papers for IDMS'98: 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway Online information for IDMS'98 (including the CfP) can be found at: http://www.unik.no/~idms98 You will be doing us a great favor if you disseminate the this Call for papers among your interested colleagues. Please accept our apologies if you receive multiple copies of this announcement. Best regards, Vera Goebel Thomas Plagemann __________________________________________________________________________ | | Organization Committee IDMS'98 | | 5th International Workshop on Interactive Distributed Multimedia | Systems and Telecommunication Services | Oslo, Norway, 1998 | | UniK - Center for Technology at Kjeller | University of Oslo | P.O. Box 70, N-2007 Kjeller, Norway | | e-mail: idms98@unik.no | WWW: http://www.unik.no/~idms98 |__________________________________________________________________________ Call for Papers IDMS'98 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway The Fifth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshops held 1997 in Darmstadt and 1996 in Berlin. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services -- ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to · High-speed/ATM networks · Mobile multimedia systems · Multimedia over sattelite · Multimedia middelware · Quality of service issues · Media scaling · Resource management · Protocol design and implementation · Distributed multimedia database systems · Development tools for distributed multimedia applications · Multimedia-specific intelligent agents · Computer supported collaborative work · Distributed virtual reality systems · Distance education · Conferencing · Digital libraries · Interactive television · Video-on-demand systems · Compression algorithms IDMS'98 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavour of a workshop, the number of participants will be restricted. Furthermore, we encurage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings. The proceedings will be published in the Springer LNCS series and will be available during the workshop. It is intended to forward selected papers to a special issue of the "Computer Communications" Journal. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'98 web page: http://www.unik.no/~idms98. Authors without web access may send mail to idms98@unik.no requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to one of the workshops chairs ATTN: IDMS'98. Important dates: Submission due: February 1, 1998 Notification of acceptance: April 15, 1998 Camera ready version: May 15, 1998 Workshop: September 9 - 11, 1998 Program co-chairs: Vera Goebel and Thomas Plagemann UniK - Center for Technology at Kjeller, University of Oslo, P.O. Box 70, N-2007 Kjeller, Norway Email: {goebel; plageman}@unik.no, Phone: +47/63.81.45.70, Fax: +47/63.81.81.46 Program Committee: F. A. Aagesen, NTNU Trondheim, Norway H. Affifi, ENST Bretagne, France E. Biersack, Institut Eurécom, France G. Bochmann, University of Montreal, Canada B. Butscher, DeTeBerkom, Germany A. T. Campbell, Columbia University, USA S. Chanson, Hong Kong University of Science & Technology, HK L. Delgrossi, University Cattolica Piacenza, Italy M. Diaz, LAAS-CNRS, France F. Eliassen, University of Tromsø, Norway W. Effelsberg, University Mannheim, Germany D. Ferrari, University Cattolica Piacenza, Italy J.-P. Hubaux, EPFL Lausanne, Switzerland D. Hutchison, Lancaster University, UK W. Kalfa, TU Chemnitz, Germany T. D. C. Little, Boston University, USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, University of Illinois, USA G. Parulkar, Washington University St. louis, USA B. Pehrson, KTH Stockholm, Sweden S. Pink, SICS, Sweden B. Plattner, ETH Zurich, Switzerland H. Scholten, University of Twente, Netherlands R. Steinmetz, GMD, Germany H. Tokuda, Keio University, Japan L. Wolf, TH Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany From ipp-owner@pwg.org Wed Nov 12 15:36:32 1997 Delivery-Date: Wed, 12 Nov 1997 15:36:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24291 for ; Wed, 12 Nov 1997 15:36:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11878 for ; Wed, 12 Nov 1997 15:39:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA03006 for ; Wed, 12 Nov 1997 15:36:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 15:31:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02440 for ipp-outgoing; Wed, 12 Nov 1997 15:19:34 -0500 (EST) Message-Id: <3.0.1.32.19971112122045.009329d0@xmicro.cp10.es.xerox.com> X-Sender: xriley@xmicro.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 12 Nov 1997 12:20:45 PST To: ipp@pwg.org From: "Xavier D. Riley" Subject: IPP> Security - Issues with the existing proposals Cc: CManros@cp10.es.xerox.com, JWenn@cp10.es.xerox.com, Manchala@cp10.es.xerox.com, XRiley@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, The purpose of this note is to discuss the implications of using the security schemes discussed thus far related to IPP. The following is a summary of details and issues of the security schemes. It is assumed that there will be embedded servers in some low-end IPP printers. Proposal #1 (2 URI scheme) ++++++++++++++++++++++++++ - Characteristics 1. 2 URIs - one for secure and one for non-secure connections 2. Non-secure connections would use the following schemes: -Digest Access Authentication -No Authentication 3. Secure connections would use the following schemes: -TLS with configurable Cipher Suites at both the client and server (negotiated at connection time). - Advantages: 1. Non-secure (as defined above) can be the minimum security implemented 2. TLS implementation can be optionally implemented in print systems. 3. No need to wait for TLS deployment (can use existing off-the-shelf web servers) - Disadvantages: 1. 2 URI configurations needed Xavier's Editorial: It is debatable whether this is a major disadvantage. It could be seen to some, at most, an annoyance. The 2 URI scheme is the existing model of the WWW (http & https). Keep in mind that two URIs are only needed if a print system is enabled to be both non-secure and secure. In my opinion, most printers will either be secure or non-secure, not both. (I would like to hear other opinions on this.) 2. Complicated directory entries needed to reference printers that are configured to support both non-secure and secure schemes simultaneously. There may need to be two entries with cross references to each other. Proposal #2 (1 URI scheme) ++++++++++++++++++++++++++ - Characteristics 1. Have a single URI for both secure and non-secure using TLS framing. 2. As an minimum, one of the following cipher suites would need to be implemented by all IPP compliant printers since TLS_NULL_NULL_NULL is not an option based on the latest TLS draft: A. TLS_RSA_WITH_NULL_MD5 - Server authentication enabled (using RSA certificate) - No encryption of data - Data Integrity (using the MD5 algorithm) - Client Authentication is optional (using either Client certificates or Digest Access Authentication) B. TLS_DH_anon_Export_with_RC4_40_MD5 - No server authentication - Encryption (using RC4/DES40 algorithms) - Data Integrity (using the MD5 algorithm) - No client authentication (Digest Access can be used) C. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA - No server authentication - Encryption (using 3DES algorithms) - Data Integrity (using the SHA algorithm) - No client authentication (Digest Access can be used) Notes - TLS uses (DH_anon*) as a minimum - TLS_NULL_NULL_NULL is not an option for no security. (See section A.5 of the latest TLS draft) - Advantages 1. Single URI 2. Simpler directory schema - Disadvantages 1. Dependency on the deployment of TLS capable web servers. 2. Increased footprint for embedded print systems due to the mandatory implementation of the minimum TLS cipher suites (MD5, RC4, 3DES, SHA, or RSA CERTIFICATE INFRASTRUCTURE) 3. Runtime overhead for using encryption (RSA , RC4 or 3DES) Carl-Uno Manros John Wenn Daniel Manchala Xavier Riley ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Wed Nov 12 16:37:40 1997 Delivery-Date: Wed, 12 Nov 1997 16:37:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA25273 for ; Wed, 12 Nov 1997 16:37:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12195 for ; Wed, 12 Nov 1997 16:40:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03718 for ; Wed, 12 Nov 1997 16:37:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 16:32:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03181 for ipp-outgoing; Wed, 12 Nov 1997 16:21:02 -0500 (EST) Mime-Version: 1.0 Date: Wed, 12 Nov 1997 16:21:29 -0500 Message-ID: <0002D356.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re: IPP> Security - Issues with the existing proposals To: ipp@pwg.org, "Xavier D. Riley" Cc: CManros@cp10.es.xerox.com, JWenn@cp10.es.xerox.com, Manchala@cp10.es.xerox.com, XRiley@cp10.es.xerox.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org A couple of comments on your good summary: 1) The TLS spec also states that the TLS_DH_anon ... ciphersuites are "deprecated". These are part of SSL3. 2) In Proposal #2, when you say that "Digest Authentication" can be used, I assume you are refering to the HTTP level. My take on this is to go with your proposal #1. It would certainly be more difficult for us to agree on ciphersuites!! (a "minimum" level). Definitely not our domain or task to decide how much of TLS should be required. Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: IPP> Security - Issues with the existing proposals Author: "Xavier D. Riley" at INTERNET Date: 11/12/97 12:20 PM All, The purpose of this note is to discuss the implications of using the security schemes discussed thus far related to IPP. The following is a summary of details and issues of the security schemes. It is assumed that there will be embedded servers in some low-end IPP printers. Proposal #1 (2 URI scheme) ++++++++++++++++++++++++++ - Characteristics 1. 2 URIs - one for secure and one for non-secure connections 2. Non-secure connections would use the following schemes: -Digest Access Authentication -No Authentication 3. Secure connections would use the following schemes: -TLS with configurable Cipher Suites at both the client and server (negotiated at connection time). - Advantages: 1. Non-secure (as defined above) can be the minimum security implemented 2. TLS implementation can be optionally implemented in print systems. 3. No need to wait for TLS deployment (can use existing off-the-shelf web servers) - Disadvantages: 1. 2 URI configurations needed Xavier's Editorial: It is debatable whether this is a major disadvantage. It could be seen to some, at most, an annoyance. The 2 URI scheme is the existing model of the WWW (http & https). Keep in mind that two URIs are only needed if a print system is enabled to be both non-secure and secure. In my opinion, most printers will either be secure or non-secure, not both. (I would like to hear other opinions on this.) 2. Complicated directory entries needed to reference printers that are configured to support both non-secure and secure schemes simultaneously. There may need to be two entries with cross references to each other. Proposal #2 (1 URI scheme) ++++++++++++++++++++++++++ - Characteristics 1. Have a single URI for both secure and non-secure using TLS framing. 2. As an minimum, one of the following cipher suites would need to be implemented by all IPP compliant printers since TLS_NULL_NULL_NULL is not an option based on the latest TLS draft: A. TLS_RSA_WITH_NULL_MD5 - Server authentication enabled (using RSA certificate) - No encryption of data - Data Integrity (using the MD5 algorithm) - Client Authentication is optional (using either Client certificates or Digest Access Authentication) B. TLS_DH_anon_Export_with_RC4_40_MD5 - No server authentication - Encryption (using RC4/DES40 algorithms) - Data Integrity (using the MD5 algorithm) - No client authentication (Digest Access can be used) C. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA - No server authentication - Encryption (using 3DES algorithms) - Data Integrity (using the SHA algorithm) - No client authentication (Digest Access can be used) Notes - TLS uses (DH_anon*) as a minimum - TLS_NULL_NULL_NULL is not an option for no security. (See section A.5 of the latest TLS draft) - Advantages 1. Single URI 2. Simpler directory schema - Disadvantages 1. Dependency on the deployment of TLS capable web servers. 2. Increased footprint for embedded print systems due to the mandatory implementation of the minimum TLS cipher suites (MD5, RC4, 3DES, SHA, or RSA CERTIFICATE INFRASTRUCTURE) 3. Runtime overhead for using encryption (RSA , RC4 or 3DES) Carl-Uno Manros John Wenn Daniel Manchala Xavier Riley ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Wed Nov 12 16:58:04 1997 Delivery-Date: Wed, 12 Nov 1997 16:58:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA25704 for ; Wed, 12 Nov 1997 16:58:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12282 for ; Wed, 12 Nov 1997 17:01:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04350 for ; Wed, 12 Nov 1997 16:58:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 16:54:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03815 for ipp-outgoing; Wed, 12 Nov 1997 16:42:25 -0500 (EST) Message-ID: From: "Gordon, Charles" To: "'Xavier D. Riley'" , ipp@pwg.org Cc: CManros@cp10.es.xerox.com, JWenn@cp10.es.xerox.com, Manchala@cp10.es.xerox.com Subject: RE: IPP> Security - Issues with the existing proposals Date: Wed, 12 Nov 1997 16:40:33 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org If I understand what you are saying here, adopting option two would require that all IPP servers implement some form of encryption, or authentication and data signing. This will add additional requirements to all IPP implementations, even low end ones which have no need for security. Please bear in mind that many IPP printers (possibly most) will not be used on the Internet at all. They will be used for printing on internal corporate networks. There is no need for security for this application, and requiring it simply adds to the cost of the product with no real benefit to the user. While option two may be appropiate to higher end IPP implementations, it would just be an unneeded burden for the majority of the market. Option one is much more reasonable, and I don't see any real disadvantages to it. In the original message you stated that the disadvantages to it are: (1) It requires two URIs instead of one. (2) It complicates the directory structure for IPP URIs. As you point out in your comments, it is hard to come up with a reason why printers need to support both modes of printing. In most cases, printers will either be secure and will require a secure connection, or will be unsecure and need not support security at all. As long as it is one or the other, you will only have one URI base, and one directory structure. There will be no disadvantages at all for these IPP implementations. The only IPP implementations which will have to support both URI's and a more complicated directory structure are those which support both modes of printing. These will be high end printers and it is reasonable to expect them to take on the extra burden for this feature since they will probably have greater CPU resources and a larger price tag. Charles Gordon Osicom/DPI > -----Original Message----- > From: Xavier D. Riley [SMTP:xriley@cp10.es.xerox.com] > Sent: Wednesday, November 12, 1997 3:21 PM > To: ipp@pwg.org > Cc: CManros@cp10.es.xerox.com; JWenn@cp10.es.xerox.com; > Manchala@cp10.es.xerox.com; XRiley@cp10.es.xerox.com > Subject: IPP> Security - Issues with the existing proposals > > All, > The purpose of this note is to discuss the > implications of using the security schemes > discussed thus far related to IPP. The following is > a summary of details and issues of the security > schemes. It is assumed that there will be embedded > servers in some low-end IPP printers. > > Proposal #1 (2 URI scheme) > ++++++++++++++++++++++++++ > - Characteristics > 1. 2 URIs - one for secure and one for non-secure > connections > 2. Non-secure connections would use the following > schemes: > -Digest Access Authentication > -No Authentication > 3. Secure connections would use the following > schemes: > -TLS with configurable Cipher Suites at both > the client and server (negotiated at > connection time). > - Advantages: > 1. Non-secure (as defined above) can be the > minimum security implemented > 2. TLS implementation can be optionally implemented > in print systems. > 3. No need to wait for TLS deployment (can use > existing off-the-shelf web servers) > > - Disadvantages: > 1. 2 URI configurations needed > Xavier's Editorial: It is debatable whether this > is a major disadvantage. It could be seen to some, > at most, an annoyance. The 2 URI scheme is the > existing model of the WWW (http & https). Keep in > mind that two URIs are only needed if a print > system is enabled to be both non-secure and secure. > In my opinion, most printers will either be secure > or non-secure, not both. (I would like to hear other > opinions on this.) > > 2. Complicated directory entries needed to reference > printers that are configured to support both > non-secure and secure schemes simultaneously. There > may need to be two entries with cross references to > each other. > > > Proposal #2 (1 URI scheme) > ++++++++++++++++++++++++++ > - Characteristics > 1. Have a single URI for both secure and non-secure > using TLS framing. > 2. As an minimum, one of the following cipher suites > would need to be implemented by all IPP compliant > printers since TLS_NULL_NULL_NULL is not an option > based on the latest TLS draft: > A. TLS_RSA_WITH_NULL_MD5 > - Server authentication enabled (using RSA > certificate) > - No encryption of data > - Data Integrity (using the MD5 algorithm) > - Client Authentication is optional (using > either Client certificates or Digest Access > Authentication) > B. TLS_DH_anon_Export_with_RC4_40_MD5 > - No server authentication > - Encryption (using RC4/DES40 algorithms) > - Data Integrity (using the MD5 algorithm) > - No client authentication (Digest Access > can be used) > C. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA > - No server authentication > - Encryption (using 3DES algorithms) > - Data Integrity (using the SHA algorithm) > - No client authentication (Digest Access can > be used) > Notes > - TLS uses (DH_anon*) as a minimum > - TLS_NULL_NULL_NULL is not an option for no > security. (See section A.5 of the latest > TLS draft) > > - Advantages > 1. Single URI > 2. Simpler directory schema > > - Disadvantages > 1. Dependency on the deployment of TLS capable > web servers. > 2. Increased footprint for embedded print systems > due to the mandatory implementation of the > minimum TLS cipher suites (MD5, RC4, 3DES, > SHA, or RSA CERTIFICATE INFRASTRUCTURE) > 3. Runtime overhead for using encryption (RSA , > RC4 or 3DES) > > > Carl-Uno Manros > John Wenn > Daniel Manchala > Xavier Riley > > > > > ______________________________________________________________________ > Xavier Riley > Xerox Corp. > Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 > 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 > El Segundo, California 90245 Email: xriley@cp10.es.xerox.com > ______________________________________________________________________ From ipp-owner@pwg.org Wed Nov 12 18:29:10 1997 Delivery-Date: Wed, 12 Nov 1997 18:29:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA27393 for ; Wed, 12 Nov 1997 18:29:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12727 for ; Wed, 12 Nov 1997 18:32:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05064 for ; Wed, 12 Nov 1997 18:29:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 18:22:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04487 for ipp-outgoing; Wed, 12 Nov 1997 18:10:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: IPP> New srvloc printer schema draft Date: Wed, 12 Nov 1997 15:08:34 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCEF7C.D8946BC0" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BCEF7C.D8946BC0 Content-Type: text/plain ------ =_NextPart_000_01BCEF7C.D8946BC0 Content-Type: text/plain; name="draft-ietf-srvloc-printer-scheme-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-srvloc-printer-scheme-00.txt" Service Location Working Group Pete St. = Pierre INTERNET DRAFT Sun = Microsystems 4 November = 1997 Definition of printer: URLs for use with Service Location draft-ietf-srvloc-printer-scheme-00.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@corp.home.net mailing list. Distribution of this memo is unlimited. 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 (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific = Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines the printer service type and the attributes associated with it. This template is designed to be used in conjuction with the Service Location Protocol [1], but may be used with any directory service supporting attribute/value pair registration. The printer service type is designed as an abstract service type. = It is expected that printers advertised with the printer type may be accessible by one or more protocols. IPP and lpr are a two examples of printing protocols that may be used to perform the actual = printing function. St.Pierre Expires 4 May 1998 [Page = i] =0C Internet Draft Service Templates and URLs 4 November = 1997 Contents Status of This Memo = i Abstract = i 1. Printer service: URL Scheme = 1 2. urlpath Definition = 1 2.1. IPP . . . . . . . . . . . . . . . . . . . . . . . . . . . = 1 2.2. lpr . . . . . . . . . . . . . . . . . . . . . . . . . . . = 2 3. Printer Scheme Background = 2 4. Printer Service Template = 3 A. Attribute Origins = 9 B. References = 10 1. Printer service: URL Scheme Service Type templates are used to describe in a standard way those services which use the service: URL. The template described in this document is an abstract type that includes concrete types such as the printing protocol defined in RFC 1179 [2], "Line Printer Daemon Protocol". The service type for this service: URL is printer. 2. urlpath Definition The printer type is an abstract service type. Because an abstract service type may contain one of many concrete types, the urlpath associated with a printer URL may vary. Two types of printers that are expected to be common in printer URLs are ipp and lpr. 2.1. IPP An IPP printer uses the http protocol and the queue name for a printer is inherent in the http URL. The definition of an IPP = printer object is defined in section 2.1 of the IPP Model and Semantics draft.[3] Using this definition, a Service URL for an IPP printer would look like: St.Pierre Expires 4 May 1998 [Page = 1] =0C Internet Draft Service Templates and URLs 4 November = 1997 service:printer:http://server.sun.com/cgi-bin/public-printer service:printer:http://www.sun.com/cgi-bin/printers?public-printer 2.2. lpr An lpr accessible printer includes a queue name as the last part of the URL. If a queue name is absent, the print server is assumed to use a default print queue. service:printer:lpr://server.sun.com service:printer:lpr://server.sun.com/public-printer 3. Printer Scheme Background The printer scheme provides for consistent registration of printer services. The attributes described within this draft are a combination of previous works conducted by the IETF Printer MIB WG, the IETF IPP WG and the Salutation Consortium. The attributes specified are intended to facilitate both automatic as well as manual selection of services not to provide service statistics or notification. In short, the target audience of = service attributes are users, either programatic or end users, whereas the audience of MIB statistics are network managers. St.Pierre Expires 4 May 1998 [Page = 2] =0C Internet Draft Service Templates and URLs 4 November = 1997 4. Printer Service Template The printer template, as defined below, conforms to the grammar described in "Service Templates and service: Schemes". Please = refer to [4] for detailed explaination of the syntax. type =3D printer version =3D 0.0 language =3D en description =3D The printer service template describes the attributes supported by network printing devices. Devices may be = either directly connected to a network, or connected to a printer spooler that understands the a network queuing protocol = such as IPP, lpr or the Salutation Architecture. url-syntax =3D url-path =3D ippurl / lprurl ippurl =3D url as defined in [3] lprurl =3D "lpr://" hostport [ "/" qname ] hostport =3D host [ ":" port ] host =3D hostname / hostnumber hostname =3D *( domainlavel "." ) toplabel domainlabel =3D alphanum / alphanum * [alphanum / "-"] alphanum toplabel =3D alpha / alpha * [alphanum / "-"] alphanum hostnumber =3D ipv4-number / ipv6-number ipv4-number =3D 1*3digit 3*3("." 1*3digit) ipv6-number =3D 32*hex 3digit =3D digit digit digit port =3D 1*digit alphanum =3D alpha / digit alpha =3D "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" digit =3D "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" name =3D STRING # This attribute contains the name of the printer. It is a # name that is more user friendly than the printer-URI. St.Pierre Expires 4 May 1998 [Page = 3] =0C Internet Draft Service Templates and URLs 4 November = 1997 # An administrator determines a printer's name and sets = this # attribute to that name. This name may be the last part = of # the printer's URI or it may be unrelated. In non-US-Engli= sh # locales, a name may contain characters that are not = allowed # in a URI. description =3D STRING # A free form string that can contain any site-specific # descriptive information about this printer. printer-info =3D STRING L O # A URI used to obtain more information about # this specific printer. For example, this could # be an HTTP type URI referencing an HTML page accessible # to a Web Browser. The information obtained from this # URI is intended for end user consumption. Features # outside the scope of IPP can be accessed from this URI. security-mechanisms-supported =3D STRING L M none # The security mechanisms supported. tls, ssl, http-basic, http-digest, none protocols =3D STRING L M # The names of the concrete protocol types supported # by the printer abstract service type. Example values # include http and lpr make-model =3D STRING L # A simple text string defined by the manufacturer # The syntax shall be: # vendor-name "/" model-name # where the vendor-name is the same as that registered with # IANA for use in domain names. # For example: "vendor-x/super-duper-printer". location-description =3D STRING # A free form description of this printer's physical # location For example: "2nd floor, near the fire escape" location-address =3D STRING O # Physical/Postal address for this device. Useful for # nailing down a group of printers in a very large = corporate # network. For example: 960 Main Street, San Jose, CA = 95130 operator =3D STRING L M # A person, or persons responsible for maintaining a # printer on a day-to-day basis. St.Pierre Expires 4 May 1998 [Page = 4] =0C Internet Draft Service Templates and URLs 4 November = 1997 duplex-mode =3D STRING M simplex # The duplex capabilities a printer can handle. simplex, duplex, tumble priority-queue =3D BOOLEAN O FALSE # The printer or print queue is a priority queuing device. fonts-supported =3D STRING L M O # A list of fonts that are supported by the printer. number-up =3D INTEGER O 1 # Specifies the number of source page-images to impose # upon a single side of an instance of a selected # medium. For example, if the value is: # '1': The Printer SHALL place one logical page on a # single side of an instance of the selected medium # (MAY add some sort of translation, scaling, or # rotation). # '2': The Printer SHALL place two logical pages on a # single side of an instance of the selected medium # (MAY add some sort of translation, scaling, or # rotation). # '4': The Printer SHALL place four logical pages on a # single side of an instance of the selected medium # (MAY add some sort of translation, scaling, or # rotation). 1, 2, 4 media-size =3D STRING L M na-letter # Size values follow the ISO standards. iso-a0, iso-a1, iso-a2, iso-a3, iso-a4, iso-a5, iso-a6, iso-a7, iso-a8, iso-a9, iso-a10, iso-b0, iso-b1, iso-b2, iso-b3, iso-b4, iso-b5, iso-b6, iso-b7, iso-b8, iso-b9, iso-b10, na-letter, na-legal, executive, folio, invoice, ledger, quarto, iso-c3, iso-c4, iso-c5, iso-c6, iso-designated-long, na-10x13-envelope, na-9x12-envelope, na-number-10-envelope, na-7x9-envelope, na-7x9-envelope, na-9x11-envelope, na-10x14-envelope, na-number-9-envelope, na-6x9-envelope, na-10x15-envelope, monarch-envelope, a, b, c, d, jis-b0, jis-b1, jis-b2, jis-b3, jis-b4, jis-b5, jis-b6, jis-b7, jis-b8, jis-b9, jis-b10, unknown media-color =3D STRING M O white # The color of the print media St.Pierre Expires 4 May 1998 [Page = 5] =0C Internet Draft Service Templates and URLs 4 November = 1997 other, unknown, white, pink, yellow, buff, goldenrod, blue, green, transparent color-supported =3D BOOLEAN O false # Indicates whether color is supported color-type =3D STRING L M O none # Whether the printer supports color none, highlight, three color, four color, monochromatic marker-color =3D STRING L M O black # The name of the color of this colorant(ink). other, unknown, white, red, green, blue, cyan, magenta, yellow, black max-speed =3D INTEGER O # The maximum speed of the printer expressed in Speed # units. speed-units =3D STRING O sheetsPerHour # Unit of speed for the Max speed value. tenThousandthsOfInchesPerHour, micrometersPerHour, charactersPerHour, linesPerHour, impressionsPerHour, sheetsPerHour, dotRowPerHour, feetPerHour, metersPerHour document-format =3D STRING O M # The format of the data to be printed. The standard # values for this attribute are Internet Media types # which are sometimes called MIME types. paper-output =3D STRING M L O standard # The mode in which pages output are arranged. standard, noncollated sort, collated sort, stack, unknown media-direction =3D STRING O portrait # The orientation of the media as it is fed to the # printer. portrait, landscape, unknown print-quality =3D STRING O normal # Subjective evaluation of the overall printing quality. draft, normal, high St.Pierre Expires 4 May 1998 [Page = 6] =0C Internet Draft Service Templates and URLs 4 November = 1997 resolution =3D STRING L M O unknown # The pixel density of the printer in dots per inch. other, res-100, res-200, res-240, res-300, res-600, = res-800, res-1200, res-1800, res-100x200, res-300x600, res-600x300, res-400x800, res-800x400, res-600x1200, res-1200x600, res-1800x600, unknown copy-count =3D INTEGER O -1 # The maximum number of copies of a document # that will be printed as a single job. A value of -1 # indicates there is no limit. max-job-size =3D INTEGER O -1 # The maximum size, in Kilobytes, of a print job that # the print queue will accept." A value of -1 indicates # there is no limit. finishing =3D STRING M O none # Identifies the finishing operationssupported by the = printer. none, staple, staple-top-left, staple-bottom-left, staple-top-right, staple-bottom-right, saddle-stitch, edge-stitch, punch, bind, cover stacking-order =3D STRING O unknown # The current state of the stacking order for the = associated # output sub-unit. 'firstToLast' means that as pages are # output, the front of the next page is placed against the # back of the previous page. 'lastToFirst' means that as # pages are output, the back of the next page is placed # against the front of the previous page. unknown, First to Last, Last to First delivery-orientation =3D STRING O unknown # Orientation of pages as the are printed and ejected from # the printer. unknown, face up, face down service-person =3D STRING O M # A list of service contact names for this printer. media-type =3D STRING O M stationery St.Pierre Expires 4 May 1998 [Page = 7] =0C Internet Draft Service Templates and URLs 4 November = 1997 # Media types available to be printed upon. stationery, transparency, envelope, envelope-plain, envelope-window, continuous-long, continuous-short, tab-stock, multi-part-form, labels, multi-layer, unknown media-length =3D INTEGER O -1 # Indicates the length (in the direction of the printer # feed) of the media. The value -2 indicates that the # length is unknown -1 means there is no limit. media-capacity =3D INTEGER O # The total amount of media that may be contained in a # media tray. Used with the media size, the maximum size = of # a print job may be calculated. This assumes the media # tray is full. media-capacity-units =3D STRING O -1 # The unit of media capacity. # -1 indicates that the units are unknown. -1, .0001 inches, micrometers, sheets, feet, meters St.Pierre Expires 4 May 1998 [Page = 8] =0C Internet Draft Service Templates and URLs 4 November = 1997 A. Attribute Origins The following table summarizes the attributes included in the = printer scheme and their origins. This table does not include attributes required in the "Service Templates and URLs" Draft. It also = includes attributes that may not have a specific origin, but were deemed useful in locating a printer service. Attribute Printer MIB[5] IPP[3] Salutation[6] Printer Name X Printer Description X Printer Info X Security Mechanisms X Protocols Make/Model X Location Description X Location Address Operator X Duplex Mode X Priority Queue X Fonts Supported X Number Up X Media Size X X Media Color X Color Supported X Color Type Colors Max Speed X X Speed Units X X Document Format X X Paper Output X Media Direction X Print Quality X Resolution X X Max Copy Count X Max Job Size X Finishings Supported X Stacking Order X Stacking Orientation X X Service Person X Media Type X Media Length X Media Capacity X Media Capacity Units X St.Pierre Expires 4 May 1998 [Page = 9] =0C Internet Draft Service Templates and URLs 4 November = 1997 B. References [1]J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. "Service Location Protocol", RFC 2165. June 1997. [2]L. McLaughlin III, "Line Printer Daemon Protocol", RFC 1179. August 1990. [3]R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "IPP/1.0: Model and Semantics", Work in progress, October 1997. [4]E. Guttman, C. Perkins, J. Kempf, "Service Templates and = service: Schemes", Work in Progress, September, 1997 draft-ietf-svrloc-service-scheme-03.txt [5]R. Turner, F. Wright, R. Smith, "Printer MIB", Work in progress, April 1997. [6]Salutation Consortium, Inc., "Salutation Architecture Specification V2.0", December 1996. Authors' Addresses Questions about this memo can be directed to: Pete St. Pierre Sun Microsystems 901 San Antonio Avenue Palo Alto, CA 94043 USA Phone: +1 415 786-5790 email: Pete.StPierre@Eng.Sun.COM St.Pierre Expires 4 May 1998 [Page = 10] ------ =_NextPart_000_01BCEF7C.D8946BC0-- From ipp-owner@pwg.org Wed Nov 12 18:44:59 1997 Delivery-Date: Wed, 12 Nov 1997 18:45:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA27616 for ; Wed, 12 Nov 1997 18:44:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12780 for ; Wed, 12 Nov 1997 18:47:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05715 for ; Wed, 12 Nov 1997 18:44:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 18:41:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04984 for ipp-outgoing; Wed, 12 Nov 1997 18:28:16 -0500 (EST) Date: Wed, 12 Nov 1997 15:32:24 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711122332.AA00621@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> Comment on LPD Mapping document Sender: ipp-owner@pwg.org Hi folks, I was reminded at today's IPP Telecon, that I should send the comment to the DL that the July version of the LPD Mapping document (draft-ietf-ipp-lpd-ipp-map-01.txt on PWG server) still has references to 'job-number' and NOT to 'job-id' and doesn't explain any relationship between 'job-uri' and 'job-id'. Bob Herriot was on today's IPP Telecon at the time, so I am recording that the mapping document has a *little* work left to align with the most recent decisions in IPP/1.0 Model and Protocol documents. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc 716-442-0609 PS - Jay, above is my home number until April 1998 - Ira From ipp-owner@pwg.org Wed Nov 12 22:57:36 1997 Delivery-Date: Wed, 12 Nov 1997 22:57:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA00671 for ; Wed, 12 Nov 1997 22:57:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA13157 for ; Wed, 12 Nov 1997 23:00:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA06477 for ; Wed, 12 Nov 1997 22:57:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 12 Nov 1997 22:52:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA05930 for ipp-outgoing; Wed, 12 Nov 1997 22:40:36 -0500 (EST) Date: Wed, 12 Nov 1997 19:39:58 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711130339.TAA13069@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Ambiguity in what groups should be in an operation X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org As I try to figure out what groups should be in an operation, I have found the following ambiguities not covered by the model. 1) What should a printer do if an operation contains an unexpected group, e.g. a printer-attributes-tag. a) reject the operation always. b) reject a create job operation if ipp-attribute-fidelity is true and ignore the group for other operations and for ipp-attribute-fidelity is false. Return a new attribute 'unsupported-groups' with the tag values that were ignored. I favor b because it is similar to unrecognized operation attributes. 2) What should a Printer do if the correct groups are present but in the wrong order, e.g. Job Template attributes precede the operation attributes. a) reject the job b) allow an implementation to accept or reject an operation I favor b. Client should be required to follow the order, but servers/printers need not enforce the order. 3) If Get-Attributes is returning no job/printer attributes, does it return a) a Job/Printer group which is empty or b) no Job/Printer group I favor a so that there is always an expected group. From ipp-owner@pwg.org Thu Nov 13 09:15:08 1997 Delivery-Date: Thu, 13 Nov 1997 09:15:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08249 for ; Thu, 13 Nov 1997 09:15:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA13816 for ; Thu, 13 Nov 1997 09:18:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA08185 for ; Thu, 13 Nov 1997 09:15:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 09:06:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA07617 for ipp-outgoing; Thu, 13 Nov 1997 08:55:00 -0500 (EST) From: Roger K Debry To: Cc: Steve Gebert , Keith Carter Subject: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 Message-ID: <5030100013266059000002L092*@MHS> Date: Thu, 13 Nov 1997 08:54:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA08249 Participating in the call were: Ron Bergman, Harry Lewis, Xavier Riley, Tom Hastings, Steve Zilles, Randy Turner, Bob Herriot, Ira McDonald, and Roger deBry. Steve Zilles moderated the call and Roger deBry took minutes. Everyone is urged to read through the latest versions of the IPP internet dratfs and comment on issues for the last call. Issues will be collected and be part of the agenda for the December PWG meeting in L.A. Xavier Riley discussed his email outlining two approaches to handling security for IPP. There was a lot of good discussion on this topic with the following agreement: 1) We will have two URI's, distinguished by the scheme (http and https) 2) We will have two attributes in the model document, and in the directory to store these: Printer-URI and Secure-Printer-URI. 3) The implementation of http 1.1is mandatory. 4) The implementation of TLS/ SSL (associated with Secure-Printer-URI) is optional. 5) The implementation of Printer-URI and Secure-Printer-URI attributes is mandatory. 6) An administrator must be able to configure the security options. 7) If Printer-URI has been "turned-off" by the administrator, a query will return "no-value". 8) If Secure printing is not implemented or has been turned off by the adminsitrator, a query of Secure-Printer-URI will return "no-value". 9) If a client somehow derives a URI and tries to connect and the service (e.g. Printer-URI) has been turned-off, an appropriate http error code will be returned. 10) If a printer supports both secure and non-secure printing, it will be recommended that administrators make the address portion of the URIs for secure and non-secure printing the same to make things easier for the end user. Randy agreed to take the action item on suggested writeup of this agreement for the model and protocol documents. He will work with Scott and Bob on this. Randy asked whether or not we should plan on an IPP bake-off during the PWG meeting set for Portland in April. He wanted to make the necessary room arrangements if there was interest in this. Most felt that an electronic bake-off over the internet would work better, and this was generally agreed to. Bob Herriot raised the issue discussed in his email having to do with handling operation attributes. He wanted to be sure that there was a graceful way of handling (future) unsupported operation attributes, thus avoiding a lot of major version changes. It was agreed that this was a good idea. Section 15.3 of the model documents needs to be modified to provide a generic description covering all operations and the agreement on operation attributes. Bob Herriot took the action item to make the suggested changes. Tom Hastings agreed to assist. Carl-Uno asked Steve to get the Rationale document sent to the IETF. Carl-Uno asked that the text for the application/ipp mime type be posted to the discussion list for reading and approval by the group. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu Nov 13 10:11:12 1997 Delivery-Date: Thu, 13 Nov 1997 10:11:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA08905 for ; Thu, 13 Nov 1997 10:11:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA14091 for ; Thu, 13 Nov 1997 10:14:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA08862 for ; Thu, 13 Nov 1997 10:11:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 10:05:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08304 for ipp-outgoing; Thu, 13 Nov 1997 09:54:02 -0500 (EST) Message-Id: <199711131441.JAA07949@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 In-reply-to: <5030100013266059000002L092*@MHS> Date: Thu, 13 Nov 1997 09:41:24 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org The agreement Roger describes sounds good; one minor nit... RKD> 9) If a client somehow derives a URI and tries to connect and the RKD> service (e.g. Printer-URI) has been turned-off, an appropriate RKD> http error code will be returned. Why impose that requirement? That would mean that a printer without security (for whatever reason) would need to listen on the TLS port and implement enough of the handshake to negotiate no security so that it can send an HTTP error. Similarly, a secure-only server would need to listen on the unsecured port just to send an HTTP error. Just let TCP do the right thing - if they've constructed an invalid URI (one with the wrong scheme or port number in it), then it won't work, which is what should happen. It really isn't the business of the IPP spec to say what will happen on a TCP port on which IPP is not available. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Thu Nov 13 11:48:54 1997 Delivery-Date: Thu, 13 Nov 1997 11:48:54 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10057 for ; Thu, 13 Nov 1997 11:48:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA14648 for ; Thu, 13 Nov 1997 11:51:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09999 for ; Thu, 13 Nov 1997 11:48:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 11:35:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09001 for ipp-outgoing; Thu, 13 Nov 1997 11:19:21 -0500 (EST) Message-ID: <346B2880.68C1EB0E@underscore.com> Date: Thu, 13 Nov 1997 11:19:12 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 References: <5030100013266059000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger K Debry wrote: > Xavier Riley discussed his email outlining two approaches to handling > security for IPP. There was a lot of good discussion on this topic with > the following agreement: > > [...snip...] > > 6) An administrator must be able to configure the security options. What exactly is the significance of this statement? That is, what kinds of thoughts were offered during the telecom regarding expected methods for "configuring" the "security options"? This is not a challenge, but rather a request for clarification. It would seem obvious (to some, anyway) that of course the administrator must be able to configure a target element. But why mention this fact in a list in which the other items are far more detailed? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Nov 13 11:56:24 1997 Delivery-Date: Thu, 13 Nov 1997 11:56:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10161 for ; Thu, 13 Nov 1997 11:56:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA14707 for ; Thu, 13 Nov 1997 11:59:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA10785 for ; Thu, 13 Nov 1997 11:56:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 11:52:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09023 for ipp-outgoing; Thu, 13 Nov 1997 11:26:54 -0500 (EST) Message-ID: <346B2959.286C007D@underscore.com> Date: Thu, 13 Nov 1997 11:22:49 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Scott Lawrence CC: ipp@pwg.org Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 References: <199711131441.JAA07949@devnix.agranat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I entirely agree with Scott. Supporting a service for which no real support is provided doesn't jive with traditional approaches (ie, just don't answer the call if you're not supposed to talk). Was there some underlying goal/idea not stated in the minutes for which this approach is necessary? ...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 -- ---------------------------------------------------------------------- Scott Lawrence wrote: > > The agreement Roger describes sounds good; one minor nit... > > RKD> 9) If a client somehow derives a URI and tries to connect and the > RKD> service (e.g. Printer-URI) has been turned-off, an appropriate > RKD> http error code will be returned. > > Why impose that requirement? That would mean that a printer without > security (for whatever reason) would need to listen on the TLS port > and implement enough of the handshake to negotiate no security so > that it can send an HTTP error. Similarly, a secure-only server > would need to listen on the unsecured port just to send an HTTP > error. Just let TCP do the right thing - if they've constructed an > invalid URI (one with the wrong scheme or port number in it), then > it won't work, which is what should happen. It really isn't the > business of the IPP spec to say what will happen on a TCP port on > which IPP is not available. > > -- > Scott Lawrence EmWeb Embedded Server > Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Thu Nov 13 15:54:25 1997 Delivery-Date: Thu, 13 Nov 1997 15:54:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA12324 for ; Thu, 13 Nov 1997 15:54:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15752 for ; Thu, 13 Nov 1997 15:57:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11576 for ; Thu, 13 Nov 1997 15:54:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 15:49:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA11006 for ipp-outgoing; Thu, 13 Nov 1997 15:37:33 -0500 (EST) Date: Thu, 13 Nov 1997 12:36:00 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711132036.MAA14002@woden.eng.sun.com> To: ipp@pwg.org, lawrence@agranat.com Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org My recollection of the discussion was that we agreed that the client should get standard TCP/IP and HTTP behavior for situations best handled by those layers. > From lawrence@agranat.com Thu Nov 13 07:06:50 1997 > To: ipp@pwg.org > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 > In-reply-to: <5030100013266059000002L092*@MHS> > Date: Thu, 13 Nov 1997 09:41:24 -0500 > From: "Scott Lawrence" > Sender: ipp-owner@pwg.org > Content-Length: 1051 > X-Lines: 21 > > > The agreement Roger describes sounds good; one minor nit... > > RKD> 9) If a client somehow derives a URI and tries to connect and the > RKD> service (e.g. Printer-URI) has been turned-off, an appropriate > RKD> http error code will be returned. > > Why impose that requirement? That would mean that a printer without > security (for whatever reason) would need to listen on the TLS port > and implement enough of the handshake to negotiate no security so > that it can send an HTTP error. Similarly, a secure-only server > would need to listen on the unsecured port just to send an HTTP > error. Just let TCP do the right thing - if they've constructed an > invalid URI (one with the wrong scheme or port number in it), then > it won't work, which is what should happen. It really isn't the > business of the IPP spec to say what will happen on a TCP port on > which IPP is not available. > > -- > Scott Lawrence EmWeb Embedded Server > Agranat Systems, Inc. Engineering http://www.agranat.com/ > From ipp-owner@pwg.org Thu Nov 13 16:53:35 1997 Delivery-Date: Thu, 13 Nov 1997 16:53:35 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA13303 for ; Thu, 13 Nov 1997 16:53:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA16012 for ; Thu, 13 Nov 1997 16:56:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12257 for ; Thu, 13 Nov 1997 16:53:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 16:49:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11692 for ipp-outgoing; Thu, 13 Nov 1997 16:37:32 -0500 (EST) Message-ID: From: "Turner, Randy" To: Robert.Herriot@Eng.Sun.COM Cc: ipp@pwg.org Subject: RE: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 Date: Thu, 13 Nov 1997 13:35:28 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org My recollection is the same as Bob's.... Randy > -----Original Message----- > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > Sent: Thursday, November 13, 1997 12:36 PM > To: ipp@pwg.org; lawrence@agranat.com > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. > 12, 1997 > > My recollection of the discussion was that we agreed that the client > should get standard TCP/IP and HTTP behavior for situations best > handled by those layers. > > > From lawrence@agranat.com Thu Nov 13 07:06:50 1997 > > To: ipp@pwg.org > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, > 1997 > > In-reply-to: <5030100013266059000002L092*@MHS> > > Date: Thu, 13 Nov 1997 09:41:24 -0500 > > From: "Scott Lawrence" > > Sender: ipp-owner@pwg.org > > Content-Length: 1051 > > X-Lines: 21 > > > > > > The agreement Roger describes sounds good; one minor nit... > > > > RKD> 9) If a client somehow derives a URI and tries to connect and > the > > RKD> service (e.g. Printer-URI) has been turned-off, an > appropriate > > RKD> http error code will be returned. > > > > Why impose that requirement? That would mean that a printer > without > > security (for whatever reason) would need to listen on the TLS > port > > and implement enough of the handshake to negotiate no security so > > that it can send an HTTP error. Similarly, a secure-only server > > would need to listen on the unsecured port just to send an HTTP > > error. Just let TCP do the right thing - if they've constructed > an > > invalid URI (one with the wrong scheme or port number in it), then > > it won't work, which is what should happen. It really isn't the > > business of the IPP spec to say what will happen on a TCP port on > > which IPP is not available. > > > > -- > > Scott Lawrence EmWeb Embedded Server > > > Agranat Systems, Inc. Engineering > http://www.agranat.com/ > > From ipp-owner@pwg.org Thu Nov 13 17:30:18 1997 Delivery-Date: Thu, 13 Nov 1997 17:30:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA13683 for ; Thu, 13 Nov 1997 17:30:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA16150 for ; Thu, 13 Nov 1997 17:33:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12961 for ; Thu, 13 Nov 1997 17:30:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 17:25:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12387 for ipp-outgoing; Thu, 13 Nov 1997 17:14:02 -0500 (EST) Message-ID: <346B7B82.7FEBE34A@underscore.com> Date: Thu, 13 Nov 1997 17:13:22 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" , Robert.Herriot@Eng.Sun.COM CC: ipp@pwg.org Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Sorry, but I can't tell whether both Randy and Bob are agreeing with Scott or not. Can someone make a *brief* statement on this issue in which the comments made by Scott are addressed? Thanks in advance. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > My recollection is the same as Bob's.... > > Randy > > > -----Original Message----- > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > Sent: Thursday, November 13, 1997 12:36 PM > > To: ipp@pwg.org; lawrence@agranat.com > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. > > 12, 1997 > > > > My recollection of the discussion was that we agreed that the client > > should get standard TCP/IP and HTTP behavior for situations best > > handled by those layers. > > > > > From lawrence@agranat.com Thu Nov 13 07:06:50 1997 > > > To: ipp@pwg.org > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, > > 1997 > > > In-reply-to: <5030100013266059000002L092*@MHS> > > > Date: Thu, 13 Nov 1997 09:41:24 -0500 > > > From: "Scott Lawrence" > > > Sender: ipp-owner@pwg.org > > > Content-Length: 1051 > > > X-Lines: 21 > > > > > > > > > The agreement Roger describes sounds good; one minor nit... > > > > > > RKD> 9) If a client somehow derives a URI and tries to connect and > > the > > > RKD> service (e.g. Printer-URI) has been turned-off, an > > appropriate > > > RKD> http error code will be returned. > > > > > > Why impose that requirement? That would mean that a printer > > without > > > security (for whatever reason) would need to listen on the TLS > > port > > > and implement enough of the handshake to negotiate no security so > > > that it can send an HTTP error. Similarly, a secure-only server > > > would need to listen on the unsecured port just to send an HTTP > > > error. Just let TCP do the right thing - if they've constructed > > an > > > invalid URI (one with the wrong scheme or port number in it), then > > > it won't work, which is what should happen. It really isn't the > > > business of the IPP spec to say what will happen on a TCP port on > > > which IPP is not available. > > > > > > -- > > > Scott Lawrence EmWeb Embedded Server > > > > > Agranat Systems, Inc. Engineering > > http://www.agranat.com/ > > > From ipp-owner@pwg.org Thu Nov 13 18:02:15 1997 Delivery-Date: Thu, 13 Nov 1997 18:02:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA14148 for ; Thu, 13 Nov 1997 18:02:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16280 for ; Thu, 13 Nov 1997 18:05:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14166 for ; Thu, 13 Nov 1997 18:02:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 17:53:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12958 for ipp-outgoing; Thu, 13 Nov 1997 17:30:16 -0500 (EST) Message-ID: From: "Turner, Randy" To: Jay Martin , "Turner, Randy" , Robert.Herriot@Eng.Sun.COM Cc: ipp@pwg.org Subject: RE: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 Date: Thu, 13 Nov 1997 14:28:10 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org There was a proposal to handle situations like the one expressed by Roger in his minutes, but others on the conference felt like we were trying to spec too much on how the servers handle every possible error (or error code). So we just said that the server will do the appropriate thing, depending upon which layer of the overall protocol stack at which a particular problem occurred...I think this is where we left it. Randy > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Thursday, November 13, 1997 2:13 PM > To: Turner, Randy; Robert.Herriot@Eng.Sun.COM > Cc: ipp@pwg.org > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. > 12, 1997 > > Sorry, but I can't tell whether both Randy and Bob are agreeing > with Scott or not. > > Can someone make a *brief* statement on this issue in which the > comments made by Scott are addressed? Thanks in advance. > > ...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 -- > ---------------------------------------------------------------------- > > > Turner, Randy wrote: > > > > My recollection is the same as Bob's.... > > > > Randy > > > > > -----Original Message----- > > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > > Sent: Thursday, November 13, 1997 12:36 PM > > > To: ipp@pwg.org; lawrence@agranat.com > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - > Nove. > > > 12, 1997 > > > > > > My recollection of the discussion was that we agreed that the > client > > > should get standard TCP/IP and HTTP behavior for situations best > > > handled by those layers. > > > > > > > From lawrence@agranat.com Thu Nov 13 07:06:50 1997 > > > > To: ipp@pwg.org > > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. > 12, > > > 1997 > > > > In-reply-to: <5030100013266059000002L092*@MHS> > > > > Date: Thu, 13 Nov 1997 09:41:24 -0500 > > > > From: "Scott Lawrence" > > > > Sender: ipp-owner@pwg.org > > > > Content-Length: 1051 > > > > X-Lines: 21 > > > > > > > > > > > > The agreement Roger describes sounds good; one minor nit... > > > > > > > > RKD> 9) If a client somehow derives a URI and tries to connect > and > > > the > > > > RKD> service (e.g. Printer-URI) has been turned-off, an > > > appropriate > > > > RKD> http error code will be returned. > > > > > > > > Why impose that requirement? That would mean that a printer > > > without > > > > security (for whatever reason) would need to listen on the TLS > > > port > > > > and implement enough of the handshake to negotiate no security > so > > > > that it can send an HTTP error. Similarly, a secure-only > server > > > > would need to listen on the unsecured port just to send an > HTTP > > > > error. Just let TCP do the right thing - if they've > constructed > > > an > > > > invalid URI (one with the wrong scheme or port number in it), > then > > > > it won't work, which is what should happen. It really isn't > the > > > > business of the IPP spec to say what will happen on a TCP port > on > > > > which IPP is not available. > > > > > > > > -- > > > > Scott Lawrence EmWeb Embedded Server > > > > > > > Agranat Systems, Inc. Engineering > > > http://www.agranat.com/ > > > > From ipp-owner@pwg.org Thu Nov 13 18:02:31 1997 Delivery-Date: Thu, 13 Nov 1997 18:02:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA14156 for ; Thu, 13 Nov 1997 18:02:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16283 for ; Thu, 13 Nov 1997 18:05:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14196 for ; Thu, 13 Nov 1997 18:02:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 17:53:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13037 for ipp-outgoing; Thu, 13 Nov 1997 17:32:33 -0500 (EST) Date: Thu, 13 Nov 1997 14:30:44 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711132230.OAA14187@woden.eng.sun.com> To: rturner@sharplabs.com, Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I am agreeing with Scott. > From jkm@underscore.com Thu Nov 13 14:27:22 1997 > Date: Thu, 13 Nov 1997 17:13:22 -0500 > From: Jay Martin > Organization: Underscore, Inc. > X-Mailer: Mozilla 4.02 [en] (WinNT; I) > MIME-Version: 1.0 > To: "Turner, Randy" , Robert.Herriot@Eng > CC: ipp@pwg.org > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 > References: > Content-Transfer-Encoding: 7bit > Sender: ipp-owner@pwg.org > X-Lines: 73 > > Sorry, but I can't tell whether both Randy and Bob are agreeing > with Scott or not. > > Can someone make a *brief* statement on this issue in which the > comments made by Scott are addressed? Thanks in advance. > > ...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 -- > ---------------------------------------------------------------------- > > > Turner, Randy wrote: > > > > My recollection is the same as Bob's.... > > > > Randy > > > > > -----Original Message----- > > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > > Sent: Thursday, November 13, 1997 12:36 PM > > > To: ipp@pwg.org; lawrence@agranat.com > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. > > > 12, 1997 > > > > > > My recollection of the discussion was that we agreed that the client > > > should get standard TCP/IP and HTTP behavior for situations best > > > handled by those layers. > > > > > > > From lawrence@agranat.com Thu Nov 13 07:06:50 1997 > > > > To: ipp@pwg.org > > > > Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, > > > 1997 > > > > In-reply-to: <5030100013266059000002L092*@MHS> > > > > Date: Thu, 13 Nov 1997 09:41:24 -0500 > > > > From: "Scott Lawrence" > > > > Sender: ipp-owner@pwg.org > > > > Content-Length: 1051 > > > > X-Lines: 21 > > > > > > > > > > > > The agreement Roger describes sounds good; one minor nit... > > > > > > > > RKD> 9) If a client somehow derives a URI and tries to connect and > > > the > > > > RKD> service (e.g. Printer-URI) has been turned-off, an > > > appropriate > > > > RKD> http error code will be returned. > > > > > > > > Why impose that requirement? That would mean that a printer > > > without > > > > security (for whatever reason) would need to listen on the TLS > > > port > > > > and implement enough of the handshake to negotiate no security so > > > > that it can send an HTTP error. Similarly, a secure-only server > > > > would need to listen on the unsecured port just to send an HTTP > > > > error. Just let TCP do the right thing - if they've constructed > > > an > > > > invalid URI (one with the wrong scheme or port number in it), then > > > > it won't work, which is what should happen. It really isn't the > > > > business of the IPP spec to say what will happen on a TCP port on > > > > which IPP is not available. > > > > > > > > -- > > > > Scott Lawrence EmWeb Embedded Server > > > > > > > Agranat Systems, Inc. Engineering > > > http://www.agranat.com/ > > > > > From ipp-owner@pwg.org Thu Nov 13 18:36:04 1997 Delivery-Date: Thu, 13 Nov 1997 18:36:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA14484 for ; Thu, 13 Nov 1997 18:36:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16406 for ; Thu, 13 Nov 1997 18:39:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14902 for ; Thu, 13 Nov 1997 18:36:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 18:31:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14351 for ipp-outgoing; Thu, 13 Nov 1997 18:20:19 -0500 (EST) Message-Id: <199711132319.PAA08687@bulletin> To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) cc: rturner@sharplabs.com, jkm@underscore.com, ipp@pwg.org Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 In-reply-to: Your message of "Thu, 13 Nov 1997 14:30:44 PST." <199711132230.OAA14187@woden.eng.sun.com> Date: Thu, 13 Nov 1997 15:19:37 PST From: "Steve Zilles" Sender: ipp-owner@pwg.org At the risk of muddying the waters and in an attempt to agree with Scott, Randy and Bob, I offer the following statement for clarification: If an IPP printer responds to any protocol when an attempt to use the protocol is made, then the responses to that protocol should be conforming responses. By this it is meant that (a) a printer does not need to respond to any attempt to use any protocol on any port that the printer is not supporting. (b) if the printer is capable of doing the protocol (say HTTP), but an administrator has configured the printer to not authorized use of that protocol, then the printer may either refuse to participate in the protocol or give an appropriate error message for that protocol. In the case of HTTP, the printer might respond with an error message 401 - Not Authorized. From ipp-owner@pwg.org Thu Nov 13 19:45:07 1997 Delivery-Date: Thu, 13 Nov 1997 19:45:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14868 for ; Thu, 13 Nov 1997 19:45:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16580 for ; Thu, 13 Nov 1997 19:48:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA15787 for ; Thu, 13 Nov 1997 19:44:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 19:40:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15212 for ipp-outgoing; Thu, 13 Nov 1997 19:28:45 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 13 Nov 1997 17:27:20 -0700 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>MOD Ambiguity in what groups should be in an operation Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org >>> Robert Herriot 11/12/97 08:39PM >>> > > 1) What should a printer do if an operation contains an unexpected > group, e.g. a printer-attributes-tag. > a) reject the operation always. > b) reject a create job operation if ipp-attribute-fidelity is > true and ignore the group for other operations and for > ipp-attribute-fidelity is false. Return a new attribute > 'unsupported-groups' with the tag values that were ignored. > > I favor b because it is similar to unrecognized operation attributes. I favor a. It is a BUG if this happens. The implementers on the client side did not read the spec correctly and they are not conforming. The server code has to be much more complex to handle them in any order. We keep burdening the poor server implementations ( I thought we were expecting that this might be embedded in network attached printers!?) > 2) What should a Printer do if the correct groups are present but > in the wrong order, e.g. Job Template attributes precede the > operation attributes. > a) reject the job > b) allow an implementation to accept or reject an operation > > I favor b. Client should be required to follow the order, but > servers/printers need not enforce the order. Again, I favor a. It is a bug. The implementer that sends them in the wrong order is not compliant. If we would allow option b we would be enabling poor software not interoperability. Why have a spec if everything is optional or can come in reverse order or weird stuff can come in any order, .... > 3) If Get-Attributes is returning no job/printer attributes, does it return > a) a Job/Printer group which is empty or > b) no Job/Printer group > > I favor a so that there is always an expected group. Now your talking. I favor a too. Scott Isaacson From ipp-owner@pwg.org Thu Nov 13 20:24:52 1997 Delivery-Date: Thu, 13 Nov 1997 20:24:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15009 for ; Thu, 13 Nov 1997 20:24:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA16640 for ; Thu, 13 Nov 1997 20:27:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17027 for ; Thu, 13 Nov 1997 20:24:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 20:11:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15867 for ipp-outgoing; Thu, 13 Nov 1997 19:48:39 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 13 Nov 1997 17:47:46 -0700 From: Scott Isaacson To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>MOD problem with MANDATORY support of operation attributes Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Bob, I have suggested in the past that I am in favor of very strict versioning rules (new operation attrtibute means reject). However, as I think about the principles of backwards compatiblity and versioning I come up with: 1. Reserver MAJOR version numbers for stuff that really breaks the protocol and requires both client and server upgrades or you just don't communicated (analogy: pick the human natural language for our conversation or we don't talk) 2. Reserve MINOR version numbers for bundling of new features which do not break clients or servers if the new features can successfully be ignored therefore DO NOT REQUIRE all implementations (clients and servers) to support ALL minor versions in sequence. You speak 2.5. I speak 2.6. I can choose to 1) revert to 2.5 and speak 2.5 with you or 2) just keep talking 2.6 (knowing you will not reject any deltas between 2.5 and 2.6) but at least we will still talk without forcing me to revert to 2.5. (analogy: we both choose French, but you throw in some German words now and then and I just ignore them, but the real language we are speaking is French). The same example above holds if 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, and 2.6 all exist and you support only 2.0 and I support 2.6. If I find out you only speak 2.0, I can choose to revert to 2.0, or still speak 2.6 to you knowing you will do your best up to 2.0 and you might ignore stuff. However, if I speak 2.6 and you only speak 1.2, then we just can't speak until I revert to something less than 2.0. 3. What if I support 2.5 and you support 2.6? Does this mean that I assume you support 2.5 as well? I submit, that if either of us support 2.x then we can both choose to communcate using 2.x and we should not break each other (protocol error out). 4. This means that, yes, I am in favor of generally "ignoring what you don't understand". However, I am not in favor of accepting anything from you in any order or missing tags. The tags must still be there even if the set is empty. 5. I am not in favor of adding an attribute to every operation that is like "ipp-attribute-fidelity". Summary: 1. Major version break stuff 2. Minor version are hints packaging of new features 3. Ignore stuff you don't understand (as much as possible) 4. Don't require all sides to implement all minor versions 5. Make version queriable in a way that never breaks across all versions major and minor (if it does break it is a new protocol, not a major version, ie., XXXng (next generation)) Scott >>> Robert Herriot 11/10/97 05:52PM >>> I have two concerns a) about an operation being rejected if it contains an unsupported operation-attribute, and b) the incrementing of the major version when an operation attribute is added. I think that the major version should be incremented only when a Printer is likely to make a major mistake, e.g. the syntax has changed. A new operation attribute might fall into this category, but wouldn't normally if a Printer is allowed to ignore unrecognized ones, as I suggest below. The current model document says that a Printer MUST support all operation-attributes and by implication that a Printer rejects an operation if the operation contains an unsupported operation attribute (though I cannot find such language and the algorithm in section 15.3 does not loop through operation attributes (a bug?)). But Scott and Tom believe this to be the case. This issue is much like the fidelity notion for Job-Template attributes and probably calls for two changes in the future: a) an operation attribute "ipp-operation-fidelity" which if false allows the Printer to ignore operation-attributes, and b) an unsupported-operation-attributes group in a response to hold those operation attributes that the Printer ignored. The current behavior of rejecting an operation with unsupported operation attributes is simple, but will lead to problems in the future when different versions are trying to interoperate and users prefer something to nothing. But if an operation ignores attributes without telling the client, that can create problems too. I think that we have painted ourselves into a corner here. a) If we keep the current behavior of rejecting operations that have unsupported operation attributes, we have to rev the major version with each new operation attribute which will create a lot of needless versions to deal with. b) If we allow operations with unsupported operation attributes, then all operations responses need to be able to contain a list of ignored operation attributes (yet another change); otherwise clients won't know how to interpret a response. c) If we believe that a client should be able to choose between a strict and forgiving operation, then we also need to add the operation attribute "ipp-operation-fidelity". Bob Herriot From ipp-owner@pwg.org Thu Nov 13 20:25:42 1997 Delivery-Date: Thu, 13 Nov 1997 20:25:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15015 for ; Thu, 13 Nov 1997 20:25:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA16652 for ; Thu, 13 Nov 1997 20:28:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17085 for ; Thu, 13 Nov 1997 20:25:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 20:13:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15856 for ipp-outgoing; Thu, 13 Nov 1997 19:47:23 -0500 (EST) Date: Thu, 13 Nov 1997 16:46:43 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711140046.QAA14346@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, SISAACSON@novell.com Subject: Re: IPP>MOD Ambiguity in what groups should be in an operation X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The reason that I favor b for 2 below is that it decreases server complexity. If a server decodes and validates in one step, then it is hard to process them out of order and the server should reject the operation, but if a server first decodes and then validates, it may be more of a burden for the server to check for order than to ignore it and the server should be free to accept such an operation. I agree that the client must follow the order, but the question is whether a server MUST reject an operation that is out of order. The reason that I favor b for 1 is so that a server will not reject operations that have unknown extensions, such as extra groups. This is another fidelity issue. If a user doesn't care about fidelity, then as long as the server can somewhat understand the operation, it should be free to try its best. > From SISAACSON@novell.com Thu Nov 13 16:28:17 1997 > > > > >>> Robert Herriot 11/12/97 08:39PM >>> > > > > 1) What should a printer do if an operation contains an unexpected > > group, e.g. a printer-attributes-tag. > > a) reject the operation always. > > b) reject a create job operation if ipp-attribute-fidelity is > > true and ignore the group for other operations and for > > ipp-attribute-fidelity is false. Return a new attribute > > 'unsupported-groups' with the tag values that were ignored. > > > > I favor b because it is similar to unrecognized operation attributes. > > I favor a. It is a BUG if this happens. The implementers on the client > side did not read the spec correctly and they are not conforming. The > server code has to be much more complex to handle them in any order. We > keep burdening the poor server implementations ( I thought we were expecting > that this might be embedded in network attached printers!?) > > > 2) What should a Printer do if the correct groups are present but > > in the wrong order, e.g. Job Template attributes precede the > > operation attributes. > > a) reject the job > > b) allow an implementation to accept or reject an operation > > > > I favor b. Client should be required to follow the order, but > > servers/printers need not enforce the order. > > Again, I favor a. It is a bug. The implementer that sends them in the > wrong order is not compliant. If we would allow option b we would be > enabling poor software not interoperability. Why have a spec if everything > is optional > or can come in reverse order or weird stuff can come in any order, .... > > > 3) If Get-Attributes is returning no job/printer attributes, does it > return > > a) a Job/Printer group which is empty or > > b) no Job/Printer group > > > > I favor a so that there is always an expected group. > > Now your talking. I favor a too. > > Scott Isaacson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Thu Nov 13 20:45:25 1997 Delivery-Date: Thu, 13 Nov 1997 20:45:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15088 for ; Thu, 13 Nov 1997 20:45:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA16679 for ; Thu, 13 Nov 1997 20:48:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17777 for ; Thu, 13 Nov 1997 20:45:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 20:37:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15913 for ipp-outgoing; Thu, 13 Nov 1997 20:06:57 -0500 (EST) Message-Id: <3.0.1.32.19971113171019.0111b320@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 13 Nov 1997 17:10:19 PST To: Jay Martin , Roger K Debry From: Tom Hastings Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 Cc: ipp@pwg.org In-Reply-To: <346B2880.68C1EB0E@underscore.com> References: <5030100013266059000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Let me try to explain what we meant by: 6) An administrator must be able to configure the security options. Support of http 1.1 is MANDATORY and implementation of TLS/SSL is OPTIONAL. But some customers may want to have a secure-only printer. Therefore, an implementor MUST NOT build a secure-only printer, but MUST allow the administrator (the customer) to be able to configure the Printer to be secure-only. Its like requiring TV manufacturers who choose to make a color TV set to make sure that that color set also accepts black and white. We are not allowing color-only sets. Does this help? Tom At 08:19 11/13/1997 PST, Jay Martin wrote: >Roger K Debry wrote: > >> Xavier Riley discussed his email outlining two approaches to handling >> security for IPP. There was a lot of good discussion on this topic with >> the following agreement: >> >> [...snip...] >> >> 6) An administrator must be able to configure the security options. > >What exactly is the significance of this statement? That is, what >kinds of thoughts were offered during the telecom regarding expected >methods for "configuring" the "security options"? > >This is not a challenge, but rather a request for clarification. It >would seem obvious (to some, anyway) that of course the administrator >must be able to configure a target element. But why mention this fact >in a list in which the other items are far more detailed? > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From ipp-owner@pwg.org Thu Nov 13 20:51:12 1997 Delivery-Date: Thu, 13 Nov 1997 20:51:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15126 for ; Thu, 13 Nov 1997 20:51:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA16702 for ; Thu, 13 Nov 1997 20:54:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18361 for ; Thu, 13 Nov 1997 20:51:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 13 Nov 1997 20:45:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16729 for ipp-outgoing; Thu, 13 Nov 1997 20:20:47 -0500 (EST) Message-Id: <3.0.1.32.19971113172410.00f65e10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 13 Nov 1997 17:24:10 PST To: Rick Yardumian , ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD - minor corrections Cc: xriley@cp10.es.xerox.com, cmanros@cp10.es.xerox.com, thastings@cp10.es.xerox.com In-Reply-To: <3.0.32.19971107082558.006cd49c@13.240.96.62> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Rick, This problem was fixed in the one we published late in the day on Nov 7 (after your comment). Thanks, Tom At 08:26 11/07/1997 -0800, Rick Yardumian wrote: >Assuming that document-charset is the newer version of content-charset, the following changes should be made to section 3.2.4 "Creat-Job Operation": > >Change "content-charset" to "document-charset" on lines 1012 & 1014 >Change "content-natural-language" to "document-natural-language" on lines 1012 and 1015. > >Rick >______________________________________________________________________ >Rick Yardumian >Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 >Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 >701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com >El Segundo, CA 90245 >______________________________________________________________________ > > From ipp-owner@pwg.org Fri Nov 14 00:21:13 1997 Delivery-Date: Fri, 14 Nov 1997 00:21:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA22353 for ; Fri, 14 Nov 1997 00:21:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA17014 for ; Fri, 14 Nov 1997 00:24:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19778 for ; Fri, 14 Nov 1997 00:21:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 00:14:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA19200 for ipp-outgoing; Fri, 14 Nov 1997 00:02:53 -0500 (EST) Date: Thu, 13 Nov 1997 19:59:57 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711140359.TAA14477@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD job-k-octets-supported issue X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Am I correct in assuming that if a client includes job-k-octets, it behaves like other job-template attributes, namely (the model document is silent) a) fidelity is true: if job-k-octets-supported is undefined in the printer or job-k-octets is out of range, reject the job and return job-k-octets in the unsupported-job-attributes group. b) fidelity is false: the job is accepted regardless of the value of job-k-octets or the presence or absence of job-k-octets-supported, but if the job-k-octets-supported is undefined in the printer or job-k-octets is out of range, return job-k-octets in the unsupported-job-attributes group. This behavior is perhaps a bit surprising in the fidelity = false case, because the job-k-octets-supported is intended to be a way for a printer to control the sizes allowed. So this means that someone with a really big job can bypass the job-size limit by setting fidelity = false. It would seem that job-k-octets and the other two related attributes don't really follow the rules of other job-template attributes. Comments? Bob Herriot From ipp-owner@pwg.org Fri Nov 14 10:57:58 1997 Delivery-Date: Fri, 14 Nov 1997 10:57:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA24949 for ; Fri, 14 Nov 1997 10:57:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18086 for ; Fri, 14 Nov 1997 11:00:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA20829 for ; Fri, 14 Nov 1997 10:57:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 10:47:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20249 for ipp-outgoing; Fri, 14 Nov 1997 10:35:24 -0500 (EST) Message-Id: <3.0.1.32.19971114073903.0111e670@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 07:39:03 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Rationale for why we dropped "document-charset" attribute Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org A Xerox developer asked me why we dropped the "document-charset" operation attribute from the IPP Model. This is my reply, which I'm passing on to the rest of you. My reply also indicates something for us to do when we register the Printer MIB interpreter family enums as (MIME) media types. Tom Each (MIME) media type should have a charset parameter, if a charset needs to be specified in order to interpret the data correctly. For example: text/plain; charset=utf-8 Maybe we should add some more description to that affect in Section 4.1.9. The RFC that defines text/plain says that if the charset parameter is omitted, then the charset SHALL be assumed to be us-ascii. In talking with Bob Pentecost about PCL, he verified that PCL drivers on Windows and Word Perfect do embed the charset escape sequence, so that there was no problem with dropping the "document-charset" IPP operation attribute as far as PCL was concerned. Bob also confirmed that drivers are pretty good at embedding the escape sequence in the data stream that indicates that the data stream is PCL. Consequently, we added the parenthetical note to application/vnd.hp-PCL that the charset escape sequence is embedded in the data. So there weren't any document-formats that we knew that needed a charset attribute, instead of the data stream always specifying the charset or the media type allowed the charset parameter. When we register the document formats from the Printer MIB as media MIME types, we need to make sure that the document formats that do need a charset parameter indicate such and whether the charset parameter is mandatory or optional. If it is optional, the registration also needs to specify what charset is assumed when the charset parameter is omitted. The only problem may be the media type 'applicatation/octet-stream' which does not allow a charset parameter. So the client can't specify the document charset, in case the document is auto-detected to be text/plain, since the application/octet-stream mime type doesn't allow the charset parameter. Bob didn't think that was a problem for them, because their auto-detect assumes the document is PCL, if it isn't PostScript. Tom From ipp-owner@pwg.org Fri Nov 14 11:09:09 1997 Delivery-Date: Fri, 14 Nov 1997 11:09:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25081 for ; Fri, 14 Nov 1997 11:09:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18124 for ; Fri, 14 Nov 1997 11:12:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21433 for ; Fri, 14 Nov 1997 11:09:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 11:05:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20527 for ipp-outgoing; Fri, 14 Nov 1997 10:51:00 -0500 (EST) Message-Id: <3.0.1.32.19971114075424.0111e670@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 07:54:24 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD job-k-octets-supported issue In-Reply-To: <199711140359.TAA14477@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hmmm... You have a good point here. I think this means that "job-k-octets", "job-impressions", and "job-media-sheets" should be moved from the Job Template group and become: OPTIONAL (for clients to submit and Printers to support) operation attributes with corresponding OPTIONAL Job Description attributes (same as "job-name", except that "job-name" is MANDATORY). and the corresponding "job-k-octets-supported", "job-impressions-supported", and "job-media-sheets-supported" would become Printer Description attributes. (There aren't any "xxx-default" for these three). NOTE that such a change has almost no effect on implementations, except that these three attributes are submitted in the Operation attributes group, instead of the Job Template attributes group (and their processing is handled without regards to ipp-attribute-fidelity, as Bob points out). Tom At 19:59 11/13/1997 PST, Robert Herriot wrote: >Am I correct in assuming that if a client includes job-k-octets, it behaves >like other job-template attributes, namely (the model document is silent) > > a) fidelity is true: if job-k-octets-supported is undefined in the > printer or job-k-octets is out of range, reject the job and > return job-k-octets in the unsupported-job-attributes group. > > b) fidelity is false: the job is accepted regardless of the value > of job-k-octets or the presence or absence of > job-k-octets-supported, but if the job-k-octets-supported is > undefined in the printer or job-k-octets is out of range, return > job-k-octets in the unsupported-job-attributes group. > >This behavior is perhaps a bit surprising in the fidelity = false case, >because the job-k-octets-supported is intended to be a way for a printer >to control the sizes allowed. > >So this means that someone with a really big job can bypass the job-size >limit by setting fidelity = false. > >It would seem that job-k-octets and the other two related attributes don't >really follow the rules of other job-template attributes. > >Comments? > >Bob Herriot > > From ipp-owner@pwg.org Fri Nov 14 11:53:48 1997 Delivery-Date: Fri, 14 Nov 1997 11:53:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25954 for ; Fri, 14 Nov 1997 11:53:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18324 for ; Fri, 14 Nov 1997 11:56:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22099 for ; Fri, 14 Nov 1997 11:53:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 11:49:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21568 for ipp-outgoing; Fri, 14 Nov 1997 11:37:46 -0500 (EST) Date: Fri, 14 Nov 1997 08:35:30 -0800 (Pacific Standard Time) From: Ron Bergman To: Robert Herriot cc: ipp@pwg.org, SISAACSON@novell.com Subject: Re: IPP>MOD Ambiguity in what groups should be in an operation In-Reply-To: <199711140046.QAA14346@woden.eng.sun.com> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I support Bob's position on number 1. This will allow new groups to be added to the protocol and servers that support older versions of the protocol will still be useable, as long as fidelity is false. This does not obsolete old equipment. As Bob stated this situation is "similar to unrecognized operation attributes." I would go further and say it is almost identical! I support Scott's position on number 2. If the order is specified, it must be followed and must be enforced by the server. For the case in Bob's examnple where the server "decodes and validates in one step" the order must be enforced. For clients to operate with this type of server they have no choice but to provide the proper order. I see no problem with someone designing a server to accept any order, but the specification should not recommend this approach. Ron Bergman Dataproducts Corp. On Thu, 13 Nov 1997, Robert Herriot wrote: > The reason that I favor b for 2 below is that it decreases server > complexity. If a server decodes and validates in one step, then it is > hard to process them out of order and the server should reject the > operation, but if a server first decodes and then validates, it may be > more of a burden for the server to check for order than to ignore it > and the server should be free to accept such an operation. I agree > that the client must follow the order, but the question is whether a > server MUST reject an operation that is out of order. > > The reason that I favor b for 1 is so that a server will not reject > operations that have unknown extensions, such as extra groups. This > is another fidelity issue. If a user doesn't care about fidelity, then > as long as the server can somewhat understand the operation, it should > be free to try its best. > > > From SISAACSON@novell.com Thu Nov 13 16:28:17 1997 > > > > > > > > >>> Robert Herriot 11/12/97 08:39PM >>> > > > > > > 1) What should a printer do if an operation contains an unexpected > > > group, e.g. a printer-attributes-tag. > > > a) reject the operation always. > > > b) reject a create job operation if ipp-attribute-fidelity is > > > true and ignore the group for other operations and for > > > ipp-attribute-fidelity is false. Return a new attribute > > > 'unsupported-groups' with the tag values that were ignored. > > > > > > I favor b because it is similar to unrecognized operation attributes. > > > > I favor a. It is a BUG if this happens. The implementers on the client > > side did not read the spec correctly and they are not conforming. The > > server code has to be much more complex to handle them in any order. We > > keep burdening the poor server implementations ( I thought we were expecting > > that this might be embedded in network attached printers!?) > > > > > > 2) What should a Printer do if the correct groups are present but > > > in the wrong order, e.g. Job Template attributes precede the > > > operation attributes. > > > a) reject the job > > > b) allow an implementation to accept or reject an operation > > > > > > I favor b. Client should be required to follow the order, but > > > servers/printers need not enforce the order. > > > > Again, I favor a. It is a bug. The implementer that sends them in the > > wrong order is not compliant. If we would allow option b we would be > > enabling poor software not interoperability. Why have a spec if everything > > is optional > > or can come in reverse order or weird stuff can come in any order, .... > > > > > 3) If Get-Attributes is returning no job/printer attributes, does it > > return > > > a) a Job/Printer group which is empty or > > > b) no Job/Printer group > > > > > > I favor a so that there is always an expected group. > > > > Now your talking. I favor a too. > > > > Scott Isaacson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Fri Nov 14 14:55:55 1997 Delivery-Date: Fri, 14 Nov 1997 14:55:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28519 for ; Fri, 14 Nov 1997 14:55:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19289 for ; Fri, 14 Nov 1997 14:58:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA24663 for ; Fri, 14 Nov 1997 14:55:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 14:47:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23765 for ipp-outgoing; Fri, 14 Nov 1997 14:26:47 -0500 (EST) Message-Id: <3.0.1.32.19971114111052.00cc5960@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 11:10:52 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: IPP WG Last Call for Requirements and LPD Mapping drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org OOPs, Slight mistake in the previous announcement. The correct version for final call is draft -01 not -00. It seems that only one person found out so far that the -00 document had been revomed from the IETF server. Does anybody request that we restart the Last Call period due to this? Otherwise I assume that we will still keep the Last Call deadline on November 19th as before. The corrected information appears below Carl-Uno > 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 : 21 > Date : 07/30/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. > >---- > >For retrieval: > >Internet-Drafts are available by anonymous FTP. Login wih 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-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-01.txt --- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Nov 14 14:58:01 1997 Delivery-Date: Fri, 14 Nov 1997 14:58:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28533 for ; Fri, 14 Nov 1997 14:58:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19299 for ; Fri, 14 Nov 1997 15:00:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA24930 for ; Fri, 14 Nov 1997 14:57:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 14:51:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23780 for ipp-outgoing; Fri, 14 Nov 1997 14:31:03 -0500 (EST) Message-Id: <3.0.1.32.19971114113152.00a49240@xmicro.cp10.es.xerox.com> X-Sender: xriley@xmicro.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 11:31:52 PST To: ipp@pwg.org From: "Xavier D. Riley" Subject: Re: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997 In-Reply-To: <199711131441.JAA07949@devnix.agranat.com> References: <5030100013266059000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I agree with Scott. I don't think we should mandate what should happen in this situation. It's not the existing Web model. --Xavier At 06:41 AM 11/13/97 PST, you wrote: > > The agreement Roger describes sounds good; one minor nit... > >RKD> 9) If a client somehow derives a URI and tries to connect and the >RKD> service (e.g. Printer-URI) has been turned-off, an appropriate >RKD> http error code will be returned. > > Why impose that requirement? That would mean that a printer without > security (for whatever reason) would need to listen on the TLS port > and implement enough of the handshake to negotiate no security so > that it can send an HTTP error. Similarly, a secure-only server > would need to listen on the unsecured port just to send an HTTP > error. Just let TCP do the right thing - if they've constructed an > invalid URI (one with the wrong scheme or port number in it), then > it won't work, which is what should happen. It really isn't the > business of the IPP spec to say what will happen on a TCP port on > which IPP is not available. > >-- >Scott Lawrence EmWeb Embedded Server >Agranat Systems, Inc. Engineering http://www.agranat.com/ > > ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Fri Nov 14 16:51:34 1997 Delivery-Date: Fri, 14 Nov 1997 16:51:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29761 for ; Fri, 14 Nov 1997 16:51:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA19847 for ; Fri, 14 Nov 1997 16:54:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26657 for ; Fri, 14 Nov 1997 16:51:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 14 Nov 1997 16:46:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26081 for ipp-outgoing; Fri, 14 Nov 1997 16:34:34 -0500 (EST) Date: Fri, 14 Nov 1997 13:33:41 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711142133.NAA15381@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, rbergma@dpc.com Subject: Re: IPP>MOD Ambiguity in what groups should be in an operation Cc: ipp@pwg.org, SISAACSON@novell.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The issue for #2 is what the model document says in terms of conformance. If a client sends a job with attribute groups in the wrong order, a Printer that rejects the job is certainly conforming to the standard. But if a Printer accepts such a job, I would like to believe that it is still conforming if the operation semantics are unaffected by the reordering. I think that the correct statement for the model document around line 598 is that "The client requests and Printer responses SHALL contain attribute groups in the order specified by the model, and that a Printer NEED NOT verify that the attribute groups are in the correct order. That is, a Printer may reject or accept an operation with attribute groups in the wrong order." ( line 598 perhaps suggests that a Printer MUST reject such as operation, but it isn't clear. ) Bob Herriot > From rbergma@dpc.com Fri Nov 14 08:37:32 1997 > > I support Bob's position on number 1. This will allow new groups to be > added to the protocol and servers that support older versions of the > protocol will still be useable, as long as fidelity is false. This does > not obsolete old equipment. As Bob stated this situation is "similar to > unrecognized operation attributes." I would go further and say it is > almost identical! > > I support Scott's position on number 2. If the order is specified, it > must be followed and must be enforced by the server. For the case in > Bob's examnple where the server "decodes and validates in one step" the > order must be enforced. For clients to operate with this type of server > they have no choice but to provide the proper order. I see no problem > with someone designing a server to accept any order, but the specification > should not recommend this approach. > > > Ron Bergman > Dataproducts Corp. > > > On Thu, 13 Nov 1997, Robert Herriot wrote: > > > The reason that I favor b for 2 below is that it decreases server > > complexity. If a server decodes and validates in one step, then it is > > hard to process them out of order and the server should reject the > > operation, but if a server first decodes and then validates, it may be > > more of a burden for the server to check for order than to ignore it > > and the server should be free to accept such an operation. I agree > > that the client must follow the order, but the question is whether a > > server MUST reject an operation that is out of order. > > > > The reason that I favor b for 1 is so that a server will not reject > > operations that have unknown extensions, such as extra groups. This > > is another fidelity issue. If a user doesn't care about fidelity, then > > as long as the server can somewhat understand the operation, it should > > be free to try its best. > > > > > From SISAACSON@novell.com Thu Nov 13 16:28:17 1997 > > > > > > > > > > > > >>> Robert Herriot 11/12/97 08:39PM >>> > > > > > > > > 1) What should a printer do if an operation contains an unexpected > > > > group, e.g. a printer-attributes-tag. > > > > a) reject the operation always. > > > > b) reject a create job operation if ipp-attribute-fidelity is > > > > true and ignore the group for other operations and for > > > > ipp-attribute-fidelity is false. Return a new attribute > > > > 'unsupported-groups' with the tag values that were ignored. > > > > > > > > I favor b because it is similar to unrecognized operation attributes. > > > > > > I favor a. It is a BUG if this happens. The implementers on the client > > > side did not read the spec correctly and they are not conforming. The > > > server code has to be much more complex to handle them in any order. We > > > keep burdening the poor server implementations ( I thought we were expecting > > > that this might be embedded in network attached printers!?) > > > > > > > > > 2) What should a Printer do if the correct groups are present but > > > > in the wrong order, e.g. Job Template attributes precede the > > > > operation attributes. > > > > a) reject the job > > > > b) allow an implementation to accept or reject an operation > > > > > > > > I favor b. Client should be required to follow the order, but > > > > servers/printers need not enforce the order. > > > > > > Again, I favor a. It is a bug. The implementer that sends them in the > > > wrong order is not compliant. If we would allow option b we would be > > > enabling poor software not interoperability. Why have a spec if everything > > > is optional > > > or can come in reverse order or weird stuff can come in any order, .... > > > > > > > 3) If Get-Attributes is returning no job/printer attributes, does it > > > return > > > > a) a Job/Printer group which is empty or > > > > b) no Job/Printer group > > > > > > > > I favor a so that there is always an expected group. > > > > > > Now your talking. I favor a too. > > > > > > Scott Isaacson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pwg-owner@pwg.org Sat Nov 15 16:44:04 1997 Delivery-Date: Sat, 15 Nov 1997 16:44:04 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA10817 for ; Sat, 15 Nov 1997 16:44:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA21881 for ; Sat, 15 Nov 1997 16:47:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28369 for ; Sat, 15 Nov 1997 16:43:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 15 Nov 1997 16:36:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28010 for pwg-outgoing; Sat, 15 Nov 1997 16:31:40 -0500 (EST) Message-ID: <346E13AC.315C0CB2@underscore.com> Date: Sat, 15 Nov 1997 16:27:08 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Jeff Schnitzer , Mailing List PWG , Mailing List IPP Subject: PWG> Re: I'm getting: "Message not deliverable" when I send to ipp DL References: <3.0.1.32.19971114112202.01090580@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pwg@pwg.org Tom, Please ignore these kinds of messages. (That is, please don't send us messages asking us to look into them.) Jeff Schnitzer (master web/list/ftp keeper) deals with these kinds of messages all the time, on a daily basis. It takes a considerable amount of work to stay on top of maintaining an Internet presence such as what we have with the PWG facilities. Tracking down repetitive failure messages is one of the most frequent jobs Jeff must deal with. (Interestingly, the most number of delivery failures comes from the Xerox world...) Normally you don't see too many of these kinds of messages, since Jeff usually catches them right away and does something about it. However, in the case of these failed messages from world.com, it turns out there's NOTHING we can do...since the world.com mail system--unlike every other mail system in the world--does not provide any failure information for us to analyze, eg, who the message was actually addressed to, the nature of the failure, etc. Instead, their stupid mail system merely sends you a copy of the original message...which is not very helpful at all. This is particularly annoying, since these kinds of delivery failures are frequent within the known universe, but world.com doesn't seem to understand the "typical" handling of such failures. Again, please ignore (and delete) such failure messages from world.com and just move on. Thanks in advance for your cooperation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Tom Hastings wrote: > > Jay, > > It started last Friday, Nov 7. > > Here is what I get back: > > I'm not getting them on other PWG DLs, suggesting that it is a problem > with an entry on the ipp DL. > > Is there someone on the ipp DL at worldcom.com that is having a problem? > > Thanks, > Tom > > >From: administrator@ccmail.worldcom.com > >Date: Thu, 13 Nov 1997 18:04:30 PST > >To: Tom Hastings > >Subject: Message not deliverable > > > >Let me try to explain what we meant by: > >6) An administrator must be able to configure the security options. > > > > > >Support of http 1.1 is MANDATORY and implementation of TLS/SSL is OPTIONAL. > > > >But some customers may want to have a secure-only printer. > > > >Therefore, an implementor MUST NOT build a secure-only printer, but > >MUST allow the administrator (the customer) to be able to configure > >the Printer to be secure-only. > > > >Its like requiring TV manufacturers who choose to make a color TV > >set to make sure that that color set also accepts black and white. > >We are not allowing color-only sets. > > > >Does this help? > > > >Tom > > > > > >At 08:19 11/13/1997 PST, Jay Martin wrote: > >>Roger K Debry wrote: > >> > >>> Xavier Riley discussed his email outlining two approaches to handling > >>> security for IPP. There was a lot of good discussion on this topic with > >>> the following agreement: > >>> > >>> [...snip...] > >>> > >>> 6) An administrator must be able to configure the security options. > >> > >>What exactly is the significance of this statement? That is, what > >>kinds of thoughts were offered during the telecom regarding expected > >>methods for "configuring" the "security options"? > >> > >>This is not a challenge, but rather a request for clarification. It > >>would seem obvious (to some, anyway) that of course the administrator > >>must be able to configure a target element. But why mention this fact > >>in a list in which the other items are far more detailed? > >> > >> ...jay > >> > >>---------------------------------------------------------------------- > >>-- JK Martin | Email: jkm@underscore.com -- > >>-- Underscore, Inc. | Voice: (603) 889-7000 -- > >>-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > >>-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > >>---------------------------------------------------------------------- > >> > >> > > > > > > From ipp-owner@pwg.org Sat Nov 15 16:54:57 1997 Delivery-Date: Sat, 15 Nov 1997 16:54:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA10838 for ; Sat, 15 Nov 1997 16:54:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA21905 for ; Sat, 15 Nov 1997 16:57:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28981 for ; Sat, 15 Nov 1997 16:54:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 15 Nov 1997 16:47:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28017 for ipp-outgoing; Sat, 15 Nov 1997 16:31:43 -0500 (EST) Message-ID: <346E13AC.315C0CB2@underscore.com> Date: Sat, 15 Nov 1997 16:27:08 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Jeff Schnitzer , Mailing List PWG , Mailing List IPP Subject: IPP> Re: I'm getting: "Message not deliverable" when I send to ipp DL References: <3.0.1.32.19971114112202.01090580@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom, Please ignore these kinds of messages. (That is, please don't send us messages asking us to look into them.) Jeff Schnitzer (master web/list/ftp keeper) deals with these kinds of messages all the time, on a daily basis. It takes a considerable amount of work to stay on top of maintaining an Internet presence such as what we have with the PWG facilities. Tracking down repetitive failure messages is one of the most frequent jobs Jeff must deal with. (Interestingly, the most number of delivery failures comes from the Xerox world...) Normally you don't see too many of these kinds of messages, since Jeff usually catches them right away and does something about it. However, in the case of these failed messages from world.com, it turns out there's NOTHING we can do...since the world.com mail system--unlike every other mail system in the world--does not provide any failure information for us to analyze, eg, who the message was actually addressed to, the nature of the failure, etc. Instead, their stupid mail system merely sends you a copy of the original message...which is not very helpful at all. This is particularly annoying, since these kinds of delivery failures are frequent within the known universe, but world.com doesn't seem to understand the "typical" handling of such failures. Again, please ignore (and delete) such failure messages from world.com and just move on. Thanks in advance for your cooperation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Tom Hastings wrote: > > Jay, > > It started last Friday, Nov 7. > > Here is what I get back: > > I'm not getting them on other PWG DLs, suggesting that it is a problem > with an entry on the ipp DL. > > Is there someone on the ipp DL at worldcom.com that is having a problem? > > Thanks, > Tom > > >From: administrator@ccmail.worldcom.com > >Date: Thu, 13 Nov 1997 18:04:30 PST > >To: Tom Hastings > >Subject: Message not deliverable > > > >Let me try to explain what we meant by: > >6) An administrator must be able to configure the security options. > > > > > >Support of http 1.1 is MANDATORY and implementation of TLS/SSL is OPTIONAL. > > > >But some customers may want to have a secure-only printer. > > > >Therefore, an implementor MUST NOT build a secure-only printer, but > >MUST allow the administrator (the customer) to be able to configure > >the Printer to be secure-only. > > > >Its like requiring TV manufacturers who choose to make a color TV > >set to make sure that that color set also accepts black and white. > >We are not allowing color-only sets. > > > >Does this help? > > > >Tom > > > > > >At 08:19 11/13/1997 PST, Jay Martin wrote: > >>Roger K Debry wrote: > >> > >>> Xavier Riley discussed his email outlining two approaches to handling > >>> security for IPP. There was a lot of good discussion on this topic with > >>> the following agreement: > >>> > >>> [...snip...] > >>> > >>> 6) An administrator must be able to configure the security options. > >> > >>What exactly is the significance of this statement? That is, what > >>kinds of thoughts were offered during the telecom regarding expected > >>methods for "configuring" the "security options"? > >> > >>This is not a challenge, but rather a request for clarification. It > >>would seem obvious (to some, anyway) that of course the administrator > >>must be able to configure a target element. But why mention this fact > >>in a list in which the other items are far more detailed? > >> > >> ...jay > >> > >>---------------------------------------------------------------------- > >>-- JK Martin | Email: jkm@underscore.com -- > >>-- Underscore, Inc. | Voice: (603) 889-7000 -- > >>-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > >>-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > >>---------------------------------------------------------------------- > >> > >> > > > > > > From ipp-owner@pwg.org Mon Nov 17 15:37:59 1997 Delivery-Date: Mon, 17 Nov 1997 15:37:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20584 for ; Mon, 17 Nov 1997 15:37:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04648 for ; Mon, 17 Nov 1997 15:40:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02194 for ; Mon, 17 Nov 1997 15:37:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 15:23:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01489 for ipp-outgoing; Mon, 17 Nov 1997 15:11:26 -0500 (EST) From: "Zehler,Peter" To: Keith Moore Cc: IPP@pwg.org, "IPP Development List (E-mail)" Subject: RE: IPP> Re: IPP developers mailing list established Date: Mon, 17 Nov 1997 11:21:19 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Nov17.113647pst."72233(5)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Keith, The main reason for a separate mailing list for the developers was to keep the main list free of tedious details. The implementers mailing list was intended to be a forum for very detailed discussions of implementation specific aspects of IPP clients/servers. This list would also be where individuals would post invitations to engage in pairwise testing across the internet. An additional side benefit of a separate list is it identifies the subset of individuals in IPP that have some type of interest in IPP prototyping. Previous request for interested individuals to step forward have not been as fruitful as establishing a mailing list. One of my responsibilities as whip of the IPP TES subgroup is to identify and track any issues identified during pairwise internet testing. Any issues would be posted to the general IPP list. The issues would also be forwarded to the appropriate whip. I would continue to monitor the issue to its resolution. If you feel this activity should be handled on the main list I have no objection. I will bring this matter up at the weekly phone conference. This email is intended to get feedback from the IPP community at large. 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 __________________________________ > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Thursday, November 06, 1997 4:31 PM > To: pzehler@channels.mc.xerox.com > Cc: moore@cs.utk.edu; IPP@pwg.org > Subject: IPP> Re: IPP developers mailing list established > > > Jeff Schnitzer created an mailing list for us. > > (thanks Jeff) This discussion list is for the exchange of > > information related to the development and implementation > > of IPP clients or servers/printers. > > Traditionally, discussion of development and implementation > happens on the main IETF working group list, to keep a tight > feedback loop. Also, customary IETF practice is to keep a > WG's mailing list open even after the WG is finished, to > facilitate discussion by implementors. > > Especially given that IPP's work is almost finished, > is there some reason this needs to be a separate list? > > Keith From pwg-owner@pwg.org Mon Nov 17 16:11:42 1997 Delivery-Date: Mon, 17 Nov 1997 16:11:42 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21160 for ; Mon, 17 Nov 1997 16:11:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04859 for ; Mon, 17 Nov 1997 16:14:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03061 for ; Mon, 17 Nov 1997 16:11:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 16:02:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02303 for pwg-outgoing; Mon, 17 Nov 1997 15:57:53 -0500 (EST) Message-Id: <3.0.1.32.19971117122313.009d8d80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Nov 1997 12:23:13 PST To: ipp@pwg.org, pwg@pwg.org, p1394@pwg.org From: Carl-Uno Manros Subject: PWG> ADM - PWG Meeting in LA, December 1 - 5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Hi all, I have just spoken to the hotel about availability of rooms at the Xerox room rate. They have graciously extended the booking period until the end of November, so you can still take advantage of it. To make sure you get the special rate, please contact the hotel directly - your travel agent may not be able to get the Xerox rate for you. Here is the information again: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 30, 1997 Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 17 16:23:16 1997 Delivery-Date: Mon, 17 Nov 1997 16:23:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21397 for ; Mon, 17 Nov 1997 16:23:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04914 for ; Mon, 17 Nov 1997 16:26:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03680 for ; Mon, 17 Nov 1997 16:23:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 16:15:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02310 for ipp-outgoing; Mon, 17 Nov 1997 15:57:57 -0500 (EST) Message-Id: <3.0.1.32.19971117122313.009d8d80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Nov 1997 12:23:13 PST To: ipp@pwg.org, pwg@pwg.org, p1394@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG Meeting in LA, December 1 - 5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, I have just spoken to the hotel about availability of rooms at the Xerox room rate. They have graciously extended the booking period until the end of November, so you can still take advantage of it. To make sure you get the special rate, please contact the hotel directly - your travel agent may not be able to get the Xerox rate for you. Here is the information again: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 30, 1997 Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 17 21:00:30 1997 Delivery-Date: Mon, 17 Nov 1997 21:00:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24317 for ; Mon, 17 Nov 1997 21:00:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05980 for ; Mon, 17 Nov 1997 21:03:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06311 for ; Mon, 17 Nov 1997 21:00:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 20:53:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05163 for ipp-outgoing; Mon, 17 Nov 1997 20:30:00 -0500 (EST) Message-Id: <3.0.1.32.19971117164923.00ac15b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Nov 1997 16:49:23 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Upcoming Deadlines Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Please note the following deadlines that are coming up soon: November 19: Comments on Last Call for Requirements and LPD to IPP Mapping docs November 21: Last day for I-Ds to the IETF December meeting (where is Rationale?) November 25: Comments on Last Call for Model & Samntics and Protocol Specification docs November 30: Last chance to get special rate at LA hotel for next PWG Meeting Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 17 21:00:34 1997 Delivery-Date: Mon, 17 Nov 1997 21:00:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24322 for ; Mon, 17 Nov 1997 21:00:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05983 for ; Mon, 17 Nov 1997 21:03:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06317 for ; Mon, 17 Nov 1997 21:00:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 20:51:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05164 for ipp-outgoing; Mon, 17 Nov 1997 20:30:01 -0500 (EST) Message-Id: <3.0.1.32.19971117165857.00ab2700@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Nov 1997 16:58:57 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD & PRO - Security terminology Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy and other looking at improving our text on security, In our earlier discussions, we have loosely spoken about "secure" and "insecure" URIs for IPP etc. I suggest that we need to come up with better terms for the actual text in the draft documents, such as: HTTP URI: TLS URI: Basic security Enhanced security Simple security Advanced security What I want to avoid is to call the first case "insecure" or "non-secure" as it contains the case where RFC 2069 is used, which by many is considered to be enough of security for a particular IPP printer. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 17 21:51:41 1997 Delivery-Date: Mon, 17 Nov 1997 21:51:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24470 for ; Mon, 17 Nov 1997 21:51:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA06037 for ; Mon, 17 Nov 1997 21:54:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07080 for ; Mon, 17 Nov 1997 21:51:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 21:47:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06508 for ipp-outgoing; Mon, 17 Nov 1997 21:35:13 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> MOD & PRO - Security terminology Date: Mon, 17 Nov 1997 18:32:46 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I'm at a point where I can work on this text but I was waiting on the minutes from the teleconference....have the minutes come out yet? Randy > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, November 17, 1997 4:59 PM > To: ipp@pwg.org > Subject: IPP> MOD & PRO - Security terminology > > > Randy and other looking at improving our text on security, > > In our earlier discussions, we have loosely spoken about "secure" and > "insecure" URIs for IPP etc. I suggest that we need to come up with > better > terms for the actual text in the draft documents, such as: > > HTTP URI: TLS URI: > > Basic security Enhanced security > Simple security Advanced security > > What I want to avoid is to call the first case "insecure" or > "non-secure" > as it contains the case where RFC 2069 is used, which by many is > considered > to be enough of security for a particular IPP printer. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 17 22:31:25 1997 Delivery-Date: Mon, 17 Nov 1997 22:31:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA26337 for ; Mon, 17 Nov 1997 22:31:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA06092 for ; Mon, 17 Nov 1997 22:34:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07737 for ; Mon, 17 Nov 1997 22:31:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 17 Nov 1997 22:27:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA07187 for ipp-outgoing; Mon, 17 Nov 1997 22:15:40 -0500 (EST) Message-ID: <3471083B.45B38AF8@parc.xerox.com> Date: Mon, 17 Nov 1997 19:15:07 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> MOD & PRO - Security terminology References: <3.0.1.32.19971117165857.00ab2700@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > I suggest that we need to come up with better > terms for the actual text in the draft documents, such as: > > HTTP URI: TLS URI: > > Basic security Enhanced security > Simple security Advanced security Making up new english words for technical situations seems risky. How about: HTTP URL: digest-authentication printer TLS security: HTTPS-secured printer From ipp-owner@pwg.org Tue Nov 18 03:13:29 1997 Delivery-Date: Tue, 18 Nov 1997 03:13:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id DAA02632 for ; Tue, 18 Nov 1997 03:13:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA06596 for ; Tue, 18 Nov 1997 03:16:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA09112 for ; Tue, 18 Nov 1997 03:13:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 03:09:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA08076 for ipp-outgoing; Tue, 18 Nov 1997 02:53:04 -0500 (EST) Message-Id: <199711180751.CAA19220@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zehler,Peter" cc: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Subject: Re: IPP> Re: IPP developers mailing list established In-reply-to: Your message of "Mon, 17 Nov 1997 11:21:19 PST." <97Nov17.113642pst."72228(3)"@alpha.xerox.com> Date: Tue, 18 Nov 1997 02:51:05 -0500 Sender: ipp-owner@pwg.org Peter, If the main IPP list has a high percentage of non-developers, the list has serious problems. Keith From daemon Tue Nov 18 09:46:49 1997 Delivery-Date: Tue, 18 Nov 1997 10:00:05 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA06401 for ietf-123-outbound.10@ietf.org; Tue, 18 Nov 1997 09:46:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06145; Tue, 18 Nov 1997 09:40:31 -0500 (EST) Message-Id: <199711181440.JAA06145@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-lzs-01.txt Date: Tue, 18 Nov 1997 09:40:31 -0500 Sender: cclark@cnri.reston.va.us --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 Using LZS Author(s) : R. Friend, R. Monsour Filename : draft-ietf-ippcp-lzs-01.txt Pages : 8 Date : 31-Jul-07 This document describes a IP compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. 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-lzs-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-lzs-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-lzs-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971117163312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-lzs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-lzs-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971117163312.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 18 15:39:47 1997 Delivery-Date: Tue, 18 Nov 1997 15:39:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13892 for ; Tue, 18 Nov 1997 15:39:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09075 for ; Tue, 18 Nov 1997 15:42:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13561 for ; Tue, 18 Nov 1997 15:39:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 15:34:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12907 for ipp-outgoing; Tue, 18 Nov 1997 15:22:24 -0500 (EST) Message-Id: <9711182019.AA07836@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jay Martin Cc: Keith Moore , "Zehler, Peter" , IPP@pwg.org, ippdev@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established In-Reply-To: Your message of "Tue, 18 Nov 1997 13:53:38 EST." <3471E432.BC16679D@underscore.com> Date: Tue, 18 Nov 1997 15:19:58 -0500 Sender: ipp-owner@pwg.org > I'm not sure what you mean about "serious problems" in your above > statement. Many, many folks monitor the IPP list for a number of > different reasons, not all having to do with the technology itself. There's no problem with people monitoring a WG list. There is a problem if the WG list is deliberately dumbed down to faciliate such monitoring. The purpose of the WG list is to do technical work, and such work is best accomplished when a high percentage of those doing the work are implementors. > As the official list-keepers for the PWG, we here at Underscore > monitor all changes to all PWG-oriented mailing lists. All too > many times we see folks unsubscribe from the IPP when a sudden > rash of messages are posted that deal with some very fine technical > point. That's a good sign! The list should be open to anyone, of course, but most people who aren't interested in doing the work will eventually get bored and unsubscribe. Keith From ipp-owner@pwg.org Tue Nov 18 16:20:40 1997 Delivery-Date: Tue, 18 Nov 1997 16:20:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA14662 for ; Tue, 18 Nov 1997 16:20:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09422 for ; Tue, 18 Nov 1997 16:23:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA14270 for ; Tue, 18 Nov 1997 16:20:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 16:16:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13687 for ipp-outgoing; Tue, 18 Nov 1997 16:04:44 -0500 (EST) Message-Id: <3.0.1.32.19971118100122.01067100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 18 Nov 1997 10:01:22 PST To: Carl-Uno Manros , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD & PRO - Security terminology In-Reply-To: <3.0.1.32.19971117165857.00ab2700@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I agree we need to be careful of the terminology. What about the name of the extra URI Printer attribute? The minutes suggest the name "secure-printer-uri" to go along with the existing "printer-uri" attribute. Same for the directory schema. Maybe we should go back to the name that was in the Model document: "printer-tls-uri" Here is the suggested text for both the "printer-uri" and the "printer-tls-uri" attributes. The current "printer-uri" description is: 4.4.1 printer-uri (uri) This MANDATORY Printer attribute contains the URI for the Printer object. An administrator determines a printer's URI and sets this attribute to that URI. This MUST be an HTTP schemed URI, however the precise format of a printer URI is implementation dependent. We need to add text to both about the 'no-value' case as agreed to in the telecon and described in Roger's minutes: 4.4.1 printer-uri (uri) This MANDATORY Printer attribute contains the URI for the Printer object. An administrator determines a printer's URI and sets this attribute to that URI. This MUST be an HTTP schemed URI, however the precise format of a printer URI is implementation dependent. If the administrator configures the Printer to use TLS security only, the Printer object SHALL return a 'no-value' for this attribute when queried (on the TLS security port - see Section 4.4.2). 4.4.2 printer-tls-uri (uri) This MANDATORY Printer attribute contains the TLS URI for the Printer object. An administrator determines a printer's TLS URI and sets this attribute to that URI. This MUST be an HTTPS schemed URI, however the precise format of a TLS printer URI is implementation dependent. If the administrator configures the Printer to not use TLS security or the implementation does not support TLS, the Printer object SHALL return a 'no-value' for this attribute when queried (on the HTTP port - see Section 4.4.1). Tom At 16:58 11/17/1997 PST, Carl-Uno Manros wrote: > >Randy and other looking at improving our text on security, > >In our earlier discussions, we have loosely spoken about "secure" and >"insecure" URIs for IPP etc. I suggest that we need to come up with better >terms for the actual text in the draft documents, such as: > > HTTP URI: TLS URI: > > Basic security Enhanced security > Simple security Advanced security > >What I want to avoid is to call the first case "insecure" or "non-secure" >as it contains the case where RFC 2069 is used, which by many is considered >to be enough of security for a particular IPP printer. > >Carl-Uno >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Tue Nov 18 16:53:34 1997 Delivery-Date: Tue, 18 Nov 1997 16:53:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA15099 for ; Tue, 18 Nov 1997 16:53:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09555 for ; Tue, 18 Nov 1997 16:54:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA15407 for ; Tue, 18 Nov 1997 16:51:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 16:45:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14349 for ipp-outgoing; Tue, 18 Nov 1997 16:29:52 -0500 (EST) Date: Tue, 18 Nov 1997 16:27:39 -0500 (Eastern Standard Time) From: Richard Marisa To: IPP@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established Message-Id: X-X-Sender: rjm2@cupid.cit.cornell.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Speaking as one monitoring this list, I thought I'd appreciate having the development discussion in a separate list so I can turn the "volume" up or down as I wish. HOWEVER: If two lists means that contributors are going to feel the need to crosspost to both lists and I have to wade through the same text twice (as in the message with this subject line), well... that is something "up with which I shall not put." Rich ----- Richard Marisa, Special Projects: Electronic Publishing Initiatives Office of Information Technology, Cornell University 110 Maple Avenue, Room 109, Ithaca, NY 14850 rjm2@cornell.edu (607) 255-7636 ---------- In reply to message ---------- Date: Tue, 18 Nov 1997 15:19:58 -0500 From: Keith Moore To: Jay Martin Cc: Keith Moore , "Zehler, Peter" , IPP@pwg.org, ippdev@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established There's no problem with people monitoring a WG list. There is a problem if the WG list is deliberately dumbed down to faciliate such monitoring. The purpose of the WG list is to do technical work, and such work is best accomplished when a high percentage of those doing the work are implementors. > As the official list-keepers for the PWG, we here at Underscore > monitor all changes to all PWG-oriented mailing lists. All too > many times we see folks unsubscribe from the IPP when a sudden > rash of messages are posted that deal with some very fine technical > point. That's a good sign! The list should be open to anyone, of course, but most people who aren't interested in doing the work will eventually get bored and unsubscribe. Keith From ipp-owner@pwg.org Tue Nov 18 17:48:57 1997 Delivery-Date: Tue, 18 Nov 1997 17:48:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA15664 for ; Tue, 18 Nov 1997 17:48:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09779 for ; Tue, 18 Nov 1997 17:51:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17388 for ; Tue, 18 Nov 1997 17:48:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 17:37:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15599 for ipp-outgoing; Tue, 18 Nov 1997 17:07:43 -0500 (EST) Message-ID: <34721139.A65AF6B0@underscore.com> Date: Tue, 18 Nov 1997 17:05:45 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Richard Marisa CC: IPP@pwg.org Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Rich, > Speaking as one monitoring this list, I thought I'd appreciate having the > development discussion in a separate list so I can turn the "volume" up or > down as I wish. HOWEVER: If two lists means that contributors are going to > feel the need to crosspost to both lists and I have to wade through the > same text twice (as in the message with this subject line), well... that > is something "up with which I shall not put." I couldn't agree with you more. There is *way* too much cross- posting on the various PWG lists. However, to date, there has been very little cross-posting to both the IPP and IPPDEV lists. Let's keep it that way, too! ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Nov 18 17:49:09 1997 Delivery-Date: Tue, 18 Nov 1997 17:49:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA15658 for ; Tue, 18 Nov 1997 17:48:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09771 for ; Tue, 18 Nov 1997 17:51:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17373 for ; Tue, 18 Nov 1997 17:48:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 17:37:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15709 for ipp-outgoing; Tue, 18 Nov 1997 17:09:37 -0500 (EST) Date: Tue, 18 Nov 1997 14:08:27 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711182208.OAA19133@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com Subject: IPP>MOD maximum lengths of some strings not explicitly stated in model X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The model document specifies the maximum lengths for text, name, keywords and octet-string, but NOT for charset, natural-language, mimeMediaType, uri and uri-scheme. Instead the model refers to other documents which specify no upper bound. Although in practice, all of these types except uri are short, probably less that 255 bytes, the question is what must all of the interoperable implementations minimally support. Bob Herriot From ipp-owner@pwg.org Tue Nov 18 18:03:27 1997 Delivery-Date: Tue, 18 Nov 1997 18:03:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA15744 for ; Tue, 18 Nov 1997 18:03:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09847 for ; Tue, 18 Nov 1997 18:06:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18468 for ; Tue, 18 Nov 1997 18:03:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 17:58:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16107 for ipp-outgoing; Tue, 18 Nov 1997 17:31:33 -0500 (EST) Date: Tue, 18 Nov 1997 12:51:16 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711182051.MAA19039@woden.eng.sun.com> To: jkm@underscore.com, moore@cs.utk.edu Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established Cc: pzehler@channels.mc.xerox.com, IPP@pwg.org, ippdev@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Although I understand Jay's point about the large audience of the IPP mailing list, I share Keith's concern about two separate mailing lists with little overlap. I am particulary concerned that there is no simple rule for determining whether an issue is large enough that it should go to the IPP mailing list rather than IPPDEV. In my experience, when architects of a standard are not closely involved in implementations (e.g. on the same mailing list), the implementations diverge from the standard. Bob Herriot > From moore@cs.utk.edu Tue Nov 18 12:22:47 1997 > X-Uri: http://www.cs.utk.edu/~moore/ > From: Keith Moore > To: Jay Martin > Cc: Keith Moore , > "Zehler, > Peter" , IPP@pwg.org, > ippdev@pwg.org > Subject: Re: IPPDEV> Re: IPP> Re: IPP developers mailing list established > In-Reply-To: Your message of "Tue, 18 Nov 1997 13:53:38 EST." > <3471E432.BC16679D@underscore.com> > Date: Tue, 18 Nov 1997 15:19:58 -0500 > Sender: ippdev-owner@pwg.org > Content-Length: 959 > X-Lines: 21 > > > I'm not sure what you mean about "serious problems" in your above > > statement. Many, many folks monitor the IPP list for a number of > > different reasons, not all having to do with the technology itself. > > There's no problem with people monitoring a WG list. > There is a problem if the WG list is deliberately dumbed down > to faciliate such monitoring. The purpose of the WG list is to do > technical work, and such work is best accomplished when a high > percentage of those doing the work are implementors. > > > As the official list-keepers for the PWG, we here at Underscore > > monitor all changes to all PWG-oriented mailing lists. All too > > many times we see folks unsubscribe from the IPP when a sudden > > rash of messages are posted that deal with some very fine technical > > point. > > That's a good sign! The list should be open to anyone, of course, > but most people who aren't interested in doing the work will eventually > get bored and unsubscribe. > > Keith > From ipp-owner@pwg.org Tue Nov 18 19:24:32 1997 Delivery-Date: Tue, 18 Nov 1997 19:24:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA16428 for ; Tue, 18 Nov 1997 19:24:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10075 for ; Tue, 18 Nov 1997 19:27:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20576 for ; Tue, 18 Nov 1997 19:24:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 19:16:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19913 for ipp-outgoing; Tue, 18 Nov 1997 19:04:02 -0500 (EST) Date: Tue, 18 Nov 1997 14:58:13 -0800 (PST) From: Ned Freed Subject: RE: IPP> Re: IPP developers mailing list established In-reply-to: "Your message dated Mon, 17 Nov 1997 11:21:19 -0800 (PST)" <"97Nov17.113647pst.72233(5)"@alpha.xerox.com> To: "Zehler,Peter" Cc: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Message-id: <01IQ5SYFLDDW9LUYEY@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Sender: ipp-owner@pwg.org > The main reason for a separate mailing list for the developers was to > keep the main list free of tedious details. The implementers mailing > list was intended to be a forum for very detailed discussions of > implementation specific aspects of IPP clients/servers. This list would > also be where individuals would post invitations to engage in pairwise > testing across the internet. I'm sorry, but I agree with Keith about this. The _entire_ purpose of an IETF list is to have such discussions. We are building protocols here and details are everything. If someone isn't comfortable with that, then they don't belong on the list. And if that then causes nontechnical looky-lous to unsubscribe, then that's a good thing, not a bad thing that warrants the creation of another list. My personal opinions about what discussions should happen where aside, I know of no rule in the IETF that WGs can't have more than one list. So if you want to do things this way then you can. However -- and now we're leaving personal opinion and getting into matters of formal procedure -- if protocol details and implementation experience are to be discussed elsewhere then that "elsewhere" is an IETF list. Period. And this then means that IETF rules apply to this other list. It therefore has to be mentioned in the WG charter and it has to be archived in accordance with IETF archiving practices. Neither of these conditions are being met for the IPPDEV at the present time as far as I can tell. Does any of this matter? The answer is yes, it most certainly does. Speaking as a member of the IETF directorate, and one who might well be asked to review this WG's output at some point by the Application ADs, I frequently review the details of the technical discussions that have taken place when I review a document, especially if I didn't participate in the discussion at the time. I normally do this by reviewing my own archives of the WG list. However, I didn't pick up on the 5-Nov-1997 announcement of the formation of this separate list, so now my archive of this WG's lists is incomplete. (I just took steps to rectify this.) And given that there are no other archives, at least as far as I can tell, I will say that should I be called upon to review this WGs output and I find that I cannot track down the specifics of some decision in the archives I have I would have no choice but to formally object to the advancement of the specification. In short, this is far from a laughing matter. This group has already seen fit to do much of its work in phone conversations rather than via email. That's fine as long as those conversations are summarized on the list (and as far as I can tell they have been), but it means even less documentation is present in the list archives and makes any additional of this sort even more problematic. Ned From ipp-owner@pwg.org Tue Nov 18 21:25:09 1997 Delivery-Date: Tue, 18 Nov 1997 21:25:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16923 for ; Tue, 18 Nov 1997 21:25:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10363 for ; Tue, 18 Nov 1997 21:28:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA21997 for ; Tue, 18 Nov 1997 21:25:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 21:20:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21459 for ipp-outgoing; Tue, 18 Nov 1997 21:08:30 -0500 (EST) Message-ID: <34724A05.B2E84BFF@parc.xerox.com> Date: Tue, 18 Nov 1997 18:08:05 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com Subject: Re: IPP>MOD maximum lengths of some strings not explicitly stated in model References: <199711182208.OAA19133@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > > The model document specifies the maximum lengths for text, name, > keywords and octet-string, but NOT for charset, natural-language, > mimeMediaType, uri and uri-scheme. Instead the model refers to other > documents which specify no upper bound. > > Although in practice, all of these types except uri are short, probably less > that 255 bytes, the question is what must all of the interoperable > implementations minimally support. Make it 100K bytes. That should hold them. Honestly, is there any reason to make the minimum any smaller? Given that the printers have to spool large documents, anyway? Larry From ipp-owner@pwg.org Tue Nov 18 22:16:59 1997 Delivery-Date: Tue, 18 Nov 1997 22:17:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA17114 for ; Tue, 18 Nov 1997 22:16:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10462 for ; Tue, 18 Nov 1997 22:19:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA22943 for ; Tue, 18 Nov 1997 22:16:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 22:05:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA22116 for ipp-outgoing; Tue, 18 Nov 1997 21:44:09 -0500 (EST) Date: Tue, 18 Nov 1997 18:43:26 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711190243.SAA19550@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com Subject: Re: IPP>MOD maximum lengths of some strings not explicitly stated in model Cc: ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From masinter@parc.xerox.com Tue Nov 18 18:08:15 1997 > > Robert Herriot wrote: > > > > The model document specifies the maximum lengths for text, name, > > keywords and octet-string, but NOT for charset, natural-language, > > mimeMediaType, uri and uri-scheme. Instead the model refers to other > > documents which specify no upper bound. > > > > Although in practice, all of these types except uri are short, probably less > > that 255 bytes, the question is what must all of the interoperable > > implementations minimally support. > > Make it 100K bytes. That should hold them. > > Honestly, is there any reason to make the minimum any smaller? Given > that the printers have to spool large documents, anyway? > > Larry > It just makes the code a bit more complex and adds yet another test case that may never be tested until a customer tries it. Other than that, it doesn't matter. From ipp-owner@pwg.org Tue Nov 18 22:34:35 1997 Delivery-Date: Tue, 18 Nov 1997 22:34:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18907 for ; Tue, 18 Nov 1997 22:34:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10505 for ; Tue, 18 Nov 1997 22:37:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA23702 for ; Tue, 18 Nov 1997 22:34:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 22:21:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA22332 for ipp-outgoing; Tue, 18 Nov 1997 21:53:10 -0500 (EST) Message-ID: <34725479.6CB11D15@parc.xerox.com> Date: Tue, 18 Nov 1997 18:52:41 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com Subject: Re: IPP>MOD maximum lengths of some strings not explicitly stated in model References: <199711190243.SAA19550@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > It just makes the code a bit more complex and adds yet another test > case that may never be tested until a customer tries it. Other > than that, it doesn't matter. No matter what the length limit is, you'll have to implement the limit and test the limit. Why is testing 1K bytes easier than testing 100K bytes? Larry From ipp-owner@pwg.org Tue Nov 18 22:44:34 1997 Delivery-Date: Tue, 18 Nov 1997 22:44:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18951 for ; Tue, 18 Nov 1997 22:44:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10520 for ; Tue, 18 Nov 1997 22:47:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA24335 for ; Tue, 18 Nov 1997 22:44:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 22:35:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA22361 for ipp-outgoing; Tue, 18 Nov 1997 22:03:14 -0500 (EST) Date: Tue, 18 Nov 1997 19:02:27 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711190302.TAA19571@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com Subject: Re: IPP>MOD maximum lengths of some strings not explicitly stated in model Cc: ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From masinter@parc.xerox.com Tue Nov 18 18:52:40 1997 > > > It just makes the code a bit more complex and adds yet another test > > case that may never be tested until a customer tries it. Other > > than that, it doesn't matter. > > No matter what the length limit is, you'll have to implement the limit > and test the limit. > > Why is testing 1K bytes easier than testing 100K bytes? > > Larry > I expect to read the URI string into a fixed size buffer which I would prefer not to be 100K bytes. If I have a limit of n, a single read into this fixed-size buffer of size n suffices. If I don't have a limit, I have to loop doing reads and concatenates of k bytes at a time. Bob Herriot From ipp-owner@pwg.org Tue Nov 18 22:50:41 1997 Delivery-Date: Tue, 18 Nov 1997 22:50:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18969 for ; Tue, 18 Nov 1997 22:50:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10535 for ; Tue, 18 Nov 1997 22:53:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA24973 for ; Tue, 18 Nov 1997 22:50:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 18 Nov 1997 22:46:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA23064 for ipp-outgoing; Tue, 18 Nov 1997 22:21:33 -0500 (EST) Message-ID: <34725B10.22914633@parc.xerox.com> Date: Tue, 18 Nov 1997 19:20:48 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: "Zehler,Peter" CC: Keith Moore , IPP@pwg.org, "IPP Development List (E-mail)" Subject: Re: IPP> Re: IPP developers mailing list established References: <97Nov17.113647pst."72233(5)"@alpha.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org For what it's worth, the W3C insisted on sponsoring a separate "HTTP implementors group" independent of the HTTP working group, in which implementation issues were supposed to be discussed. In truth, not much happened on the HTTP implementors mailing list, because we established that no decisions got made on the private list. There was a little bit of traffic about testing, but not much. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Nov 19 03:19:03 1997 Delivery-Date: Wed, 19 Nov 1997 03:19:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA25278 for ; Wed, 19 Nov 1997 03:19:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA11008 for ; Wed, 19 Nov 1997 03:21:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA26092 for ; Wed, 19 Nov 1997 03:18:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 19 Nov 1997 03:13:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA25527 for ipp-outgoing; Wed, 19 Nov 1997 03:01:00 -0500 (EST) Message-Id: <3.0.1.32.19971119000054.00e3ba80@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Nov 1997 00:00:54 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> Comments on Operation attributes and operation validation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I have posted as .doc .pdf and .txt some comments on the Operation attributes and operation validation from Bob, Scott, and myself. The file is in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-operation-attributes-and-validatio n.doc .pdf .txt I've also embedded the .txt file in this mail message. We'd like to discuss this paper at the IPP telecon, Wed, 11/19/97 1-3 pm PST. Send any comments as usual. Many of the ideas in these comments came from writing code to parse and validate operations according to the algorithms in Section 15.3 of the Model document. Thanks, Tom Subj: Notes on Operation attributes and operation validation From: Tom Hastings, Bob Herriot, Scott Isaacson Date: 11/18/97 File: ipp-operation-attributes-and-validation One goal of the validation is to maximize consistent behavior between clients and servers of different vendors, including different minor version numbers. It is a goal to try not to need a major version number change. Major version number changes are for changes that a client implementing one major version cannot interwork with an IPP object implementing another major version number (higher or lower). These comments on the IPP Model move us closer to that goal, especially with respect to Operation attributes. But first some comments on the Operation attributes: 1. Comments on Operation Attributes Here are some comments on the current draft of the Model document which will create Operation attributes that are OPTIONAL for a Printer object to support: 1. The following four Job Template attributes should move to become Operation attributes and Job Description attributes: "compression", "job-k-octets", "job- impressions", and "job-media-sheets". These attributes are describing the job, not requesting some type of processing. The corresponding "compression-supported", "job-k-octets- supported", "job-impressions-supported", and "job-media- sheets-supported" become Printer Description attributes. Also none of these four attributes had "xxx-default" attributes, further indicating that they are different from Job Template attributes. 2. These four Operation attributes are OPTIONAL for Printers to support, so some Operation attributes are OPTIONAL for a Printer to support and some are MANDATORY. Clients NEED NOT supply these Operation attributes, just as when they were Job Template attributes. 2. Validation of Operations Given the above here are some more steps for validating Operation attributes in all operations that should be added to section 15.3 in order to meet the interworking goal: 1. The validation of all Operation attributes is independent of the "ipp-attribute-fidelity" attribute. The "ipp-attribute-fidelity" only applies to Job Template attributes in create and Validate-Job requests. 2. For all operations: An IPP object SHALL validate that the length of each keyword and each attribute value meet the requirements in the Model document. If they don't, the IPP object SHALL reject the request and return either the (new) 'client-error-keyword-or-value-too-long' or the (new) 'client-error-wrong-length-value' status codes as appropriate. For example: a keyword that is 256 or more octets, or an integer that is not 4 octets long, respectively. 3. For all operations: Client requests and IPP object responses SHALL contain attribute groups in the order specified by the model. An IPP object SHALL verify that the attribute groups are in the correct order. If an IPP object receives a request with the attributes groups out of order, the IPP object SHALL reject the request and return the (new) 'client-error-attribute-groups-out-of-order' status code. 4. For all operations: If the client fails to supply an Operation attribute that clients MUST supply, the IPP object SHALL return the (new) 'client-error-missing-required- operation-attributes' status code with no indication of which attribute. This error is a development time error or a major version number mismatch, not an end-user run-time error and so a client SHOULD not display the status code to a user. Examples: "attribute-charset" and "attribute- natural-language" MUST be supplied in all operations. 5. For all operations: an IPP object SHALL ignore all unsupported Operation attributes, independent of the value of the "ipp-attribute-fidelity" attribute. An unsupported attribute is either one that is not in the Model document or that is in the Model document, but is not required to be supported. When the operation is otherwise successful, the IPP object SHALL return the (existing) 'successful-ok- ignored-or-substituted-attributes' status code. In order to inform the client of an unsupported Operation attribute, an IPP object SHALL return such an Operation attribute with the out-of-band 'unsupported' value copied to the (new) delimited group in the response, called 'unsupported- operation-attributes' (new delimiter tag in the Protocol document). This treatment of unsupported Operation attributes in all operations is analogous to the handling of unsupported Job Template attributes in the create and Validate-Job operations. Rationale: This rule is so that we can add OPTIONAL Operation attributes to future versions of IPP without affecting older clients. 6. For all operations: For supported Operation attributes, an IPP object SHALL validate that each supplied attribute value is among the set of supported values for that attribute. Such validation depends on the specification of the Operation attribute, not on the operation, and not on the value of the supplied "ipp-attribute-fidelity" attribute. Some Operation attribute specifications indicate that the IPP object SHALL ignore any unsupported values, while other attribute specifications indicate that the IPP object SHALL reject the operation for any unsupported values. See the tables in the next section for each Operation attribute. For example, the IPP object SHALL ignore any unsupported values of "attribute-natural- language", "attributes-requested" and "which-jobs" and SHALL reject the operation for any unsupported values of "attribute-charset", "compression", and "document-format". Such validation includes checking to see (1) that the attribute syntax tag is correct for the attribute, (2) that the value is in the range specified for that attribute syntax in the Model document, (3) the multiple values are not supplied for attributes that are single- valued (not 1setOf), and (4) that the value is one of the set of values that are supported by the IPP object. For some Operation attributes the set of supported values is specified by an "xxx-supported" Printer description attribute, such as "document-format-supported". For other Operation attributes, the supported values are hard coded into the implementation. If the Model document requires unsupported values to be ignored for the particular Operation attribute, the IPP object SHALL return the (existing) 'successful-ok-ignored- or-substituted-attributes' status code. If the Model document requires that unsupported values to be rejected for the particular Operation attribute, the IPP object SHALL return the (renamed) 'client-error-attributes-or- values-not-supported' status code. See the tables below for each attribute. In either case, the IPP object SHALL copy the attribute and value to the (new) 'unsupported- operation-attributes' delimited group in the response. Rationale: The reason for checking that the supplied values are supported and ignoring or rejecting, depending on the attribute, is so that a future version of IPP could extend the set of values without affecting older clients. 3. Summary of new syntax for the Model and Protocol Summary of new syntax to be added to the Model and Protocol: 1. New delimited group in responses: 'unsupported- operation-attributes' 2. New 'client-error-keyword-or-value-too-long' status code 3. New 'client-error-wrong-length-value' status code 4. New 'client-error-attribute-groups-out-of-order' status code 5. New 'client-error-missing-required-operation- attributes' status code 6. Rename 'client-error-attribute-not-supported' status code to 'client-error-attributes-or-values-not-supported', since it may include both unsupported attributes and unsupported attribute values. 4. Validation of Job Template and Operation Attributes This section contains a summary table of the validation of Job Template and Operation attributes for all operations. We propose that these tables be added to the Model document. 4.1 Validation of Job Template Attributes The table below lists the Job Template attributes and shows what the Printer SHALL do if a value is unsupported. All are OPTIONAL for a Printer to support. Each "xxx" attribute that the Printer recognizes is checked against a printer attribute with the name "xxx-supported" (after "copies- collated-supported" gets removed) to determine if the value is supported. If the Printer doesn't recognize/support an attribute, the Printer treats the attribute as an unknown attribute (see the unknown rows in the table below). Note that when a Job Template attribute is not supported, the value of the "ipp-attribute-fidelity" Operation attribute determines whether to reject the job (true) or accept it and ignore the attribute (false). Job Template Attribute value is supported if xxx- accept or xxx supported exists and if reject if the value is: value is unsupported job-priority the value is of the based on (integer(1:100)) correct type (value fidelity mapped to new priority value) job-hold-until the value is a member of based on (type4 keyword | name) the set fidelity job-sheets the value is a member of based on (type4 keyword | name) the set fidelity multiple-document- the value is a member of based on handling the set fidelity (type2 keyword) copies the value is xxx- based on (integer(1:MAX)) supported value fidelity finishings the value is a member of based on (1setOf type2 enum) the set fidelity page-ranges the boolean value is true based on (1setOf fidelity rangeOfInteger(1:MAX)) sides the value is a member of based on (type2 keyword) the set fidelity number-up the value is a member of based on (integer(0:MAX)) the set consisting of int fidelity and intRanges orientation the value is a member of based on (type2 enum) the set fidelity media the value is a member of based on (type4 keyword | name) the set fidelity printer-resolution the value is a member of based on (resolution) the set fidelity print-quality the value is a member of based on (type2 enum) the set fidelity unknown attribute the value is not based on supported fidelity 4.2 Validation of MANDATORY Operation Attributes The table below contains abbreviations for operations: Abbr Operation Abb Operation Abbr Operation r pj Print-Job sd Send-Document gap Get-Attribute (Printer) cj Create- su Send-URI gaj Get-Attribute Job (Job) vj Validate- caj Cancel-Job gj Get-Jobs Job pu Print-URI The table below lists operation attributes that are MANDATORY for a Printer to support, and shows what the Printer SHALL do if a value is unsupported. Each xxx attribute is checked against some public or private printer attribute which must exist because the attribute is MANDATORY. The check fails if its value is not among those supported. Operation Operatio value is supported if accept or Attributes ns the value is: reject if xxx value is unsupported attributes- all a member of the set in reject charset Printer's "charset- (client MUST (charset) supported", which is send) MANDATORY attributes- all any value of the accept always natural- correct type (client MUST language send) (naturalLangu age) document-uri (uri) pu, su a member of the set in reject the Printer's (client MUST "reference-uri-schemes- send) supported" job-id sd, su, a member of the set of reject (integer(1:MA caj, gaj jobIds (client MUST X)) send) document- pj, cj a member of the set in reject format Printer's "document- (client MAY (mimeMediaTyp format-supported" send) e) ISSUE: this doesn't seem to be MANDATORY for a printer to support. Is that an oversight? last-document sd, su any value of the reject (boolean) correct type (client MAY send) requested- gap, any value of the reject attributes gaj, gj correct type (client MAY (1setOf send) keyword) job-name pj, cj, any value of the reject (name) vj, pu correct type (client MAY send) document-name pj, sd, any value of the reject (name) su correct type (client MAY send) ipp-attribute- pj, cj, any value of the reject fidelity pu correct type (client MAY (type 2 send) keyword) limit gj any value of the reject (integer(1:MA correct type (client MAY X)) send) 4.3 Validation of OPTIONAL Operation Attributes The table below lists the operation attributes that are OPTIONAL for a Printer to support and shows what the Printer SHALL do if a value is unsupported. Each xxx attribute that the Printer recognizes is checked against some public or private printer attribute. If the Printer doesn't recognize/support an attribute, the Printer treats the attribute as an unknown attribute (see the unknown rows in the table below). For example, if a printer doesn't support job-k-octets (because of the implementation or because of some administrator's choice), the Printer treats job-k- octets as an unknown attribute. Operation Operation value is supported if accept or Attributes s the value is: reject if xxx value is unsupported document- pj, pu, any value of the accept always natural- sd, su correct type language (naturalLangu age) compression pj, cj, a member of the set in reject (type3 vj, pu Printer's "compression- (client MAY keyword) supported" send) job-k-octets pj, cj, a member of the reject (integer(0:MA vj, pu rangeOfInteger in the (client MAY X)) Printer's "job-k- send) octets-supported" job- pj, cj, a member of the reject impressions vj, pu rangeOfInteger in the (client MAY (integer(0:MA Printer's "job- send) X)) impressions-supported" job-media- pj, cj, a member of the reject sheets vj, pu rangeOfInteger in the (client MAY (integer(0:MA Printer's "job-media- send) X)) sheets-supported" message caj any value of the accept always (text) correct type (client MAY send) which- gap a member of the set in accept and document- Printer's "document- ignore format format-supported" and attribute (type2 the Printer supports (client MAY keyword) this Operation send) attribute Note: a printer may support several document-formats for printing but not support this operation attribute for Get- Attributes. which-jobs gj a member of the set of accept and (type2 values supported by ignore keyword) the operation (no attribute Printer attribute) (client MAY send) my-jobs gj a member of the set of accept and (boolean) values supported by ignore the operation (no attribute Printer attribute) (client MAY send) unknown all not applicable accept and attribute ignore attribute (client MAY send) ISSUE: the "document-format" Operation attribute is proposed to be changed to "which-document-format" in the Get Attributes (from Printer) operation, so that it isn't confused with the "document-format" Operation attribute that is used in pj, cj, vj, pu, sd, and su to identify the document format of the document being submitted. From ipp-owner@pwg.org Wed Nov 19 08:16:32 1997 Delivery-Date: Wed, 19 Nov 1997 08:16:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA26763 for ; Wed, 19 Nov 1997 08:16:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA11464 for ; Wed, 19 Nov 1997 08:19:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA27012 for ; Wed, 19 Nov 1997 08:16:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 19 Nov 1997 08:06:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA26423 for ipp-outgoing; Wed, 19 Nov 1997 07:54:54 -0500 (EST) From: don@lexmark.com Message-Id: <199711191254.AA03199@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Robert.Herriot@eng.sun.com, ipp@pwg.org, hastings@cp10.es.xerox.com, SISAACSON@novell.com, masinter@parc.xerox.com Date: Wed, 19 Nov 1997 07:54:18 -0500 Subject: Re: IPP>MOD maximum lengths of some strings not explicitly stated in model Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Larry Masinter said: > >Make it 100K bytes. That should hold them. > >Honestly, is there any reason to make the minimum any smaller? Given >that the printers have to spool large documents, anyway? Your assumption is incorrect. IPP is designed so that printers do not have to spool large documents. 100K is a ridiculous assumption; in fact with the exception of perhaps a URI 1K is probably going too far. Please put away your DocuTech and think about printers that cost less than $1000. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Nov 19 14:54:28 1997 Delivery-Date: Wed, 19 Nov 1997 14:54:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA03075 for ; Wed, 19 Nov 1997 14:54:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13405 for ; Wed, 19 Nov 1997 14:57:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA28497 for ; Wed, 19 Nov 1997 14:54:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 19 Nov 1997 14:49:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27823 for ipp-outgoing; Wed, 19 Nov 1997 14:36:51 -0500 (EST) Message-Id: <3.0.1.32.19971119104836.00ad9990@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Nov 1997 10:48:36 PST To: ipp@pwg.org, ippdev@pwg.org From: Carl-Uno Manros Subject: IPP> Separate IPPDEV list will cease to exist as of tomorrow Cc: Ned.Freed@innosoft.com, moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, The somewhat animated discussion that have taken place lately about the separate IPPDEV list is not worth spending our time to debate. In consultation with Peter Zehler (who owns the IPPDEV list) and Jay Martin (who runs our list service), I have decided that the IPPDEV list will be taken out of service as of tomorrow November 20, 1997. Attempts to send messages to that list will result in an error message. Please use the main IPP list for any future discussions about implementation and testing issues. In line with our existing WG rules, please start up the subject line with "TES -" for such messages to allow people to automatically sort out this kind of messages, if they so wish and their mail client has such a capability. The few messages that have been run over the IPPDEV list so far have mainly pointed out some errors in IBM client (to be fixed), and do not seem to qualify for resending over the main list again. I consider this discussion closed. Carl-Uno Manros IETF IPP WG Co-chair Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Nov 19 15:25:53 1997 Delivery-Date: Wed, 19 Nov 1997 15:25:54 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA03694 for ; Wed, 19 Nov 1997 15:25:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA13492 for ; Wed, 19 Nov 1997 15:28:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29231 for ; Wed, 19 Nov 1997 15:25:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 19 Nov 1997 15:21:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28651 for ipp-outgoing; Wed, 19 Nov 1997 15:09:04 -0500 (EST) From: "Zehler,Peter" To: "IPP Discussion List (E-mail)" Subject: IPP> TES>Anyone want to try an internet test with my IPP server and cl ient? Date: Wed, 19 Nov 1997 12:11:51 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Nov19.120814pst."53558(3)"@alpha.xerox.com> Sender: ipp-owner@pwg.org > All, > I am ready to see how a test across the internet would work. I have > tested it with my own code. The test I would like to try would be a > simple print. I have not implemented localization yet. The printer I > have is very low end, so the attributes supported is minimal. > Give me a call and we can set up a time and discuss the objective in > detail. The results will be posted to this list. Any > issues/misunderstandings will be captured and forwarded to the > appropriate individuals. > 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 > __________________________________ > From ipp-owner@pwg.org Thu Nov 20 11:47:02 1997 Delivery-Date: Thu, 20 Nov 1997 11:47:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25093 for ; Thu, 20 Nov 1997 11:47:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16627 for ; Thu, 20 Nov 1997 11:50:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA03803 for ; Thu, 20 Nov 1997 11:47:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 11:37:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA02286 for ipp-outgoing; Thu, 20 Nov 1997 11:21:50 -0500 (EST) From: Roger K Debry To: Subject: IPP>Comments on Operations Attributes Message-ID: <5030100013817454000002L042*@MHS> Date: Thu, 20 Nov 1997 11:21:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA25093 I have read through the comments posted by Tom, Bob, and Scott and have the following comments: In general, I think that the proposal is a good one, and I appreciate the work done by Tom, Bob and Scott to clarify the handling of operation attributes. Section 2.2: Do we need to get to the level of detail suggested in this paragraph in reporting errors? Why isn't it adequate to simply say "syntax error"? Don't these errors fall into the same category as paragraph 2.4, i.e. invalid length looks like a development time error, not an end user run-time. It seems that if code is buggy or there is a serious problem in generating or parsing the request stream, that more than one error of this type might occur. If we take this to its ultimate conclusion, we could get carried away with a very sophisticated error reporting scheme, listing all errors that coccured and where in the request stream they occured. I don't think we want to do this, so I'd just settle for "Syntax error" and leave it at that. Sections 2.3 and 2.4: Same comments as above. Section 2.5: The sentence "An unsupported attribute is either one that is not in the Model document or that is in the Model document but is not required to be supported" is troublesome. One could argue from this sentence that a supported attribute is therefore one that is in the Model document and mandatory. Clearly this is not true. Aren't implemented optional attributes "supported"? Doesn't supported have to do with what I implement, not what is in the document? For example, I can implement my own attributes as extensions to the standard, are these then unsupported according to the rules stated here? Also, using the logic implied by the sentence in 2.5, if I implement an optional attribute, even though it is in the model document, it is unsupported. Is that what you mean? Section 2.6: I'm somewhat concerned over the statement made in this section that validation depends upon the specification of the attribute. We ought to strive for a common rule, it would make the model much cleaner and I would expect therefore the processing would be simpler. Certainly there would be fewer opportunities for misreading or misinterpreting the spec. Section 4.1: What does the comment "after copies-collated-supported" gets removed mean? I know Bob had argued against this in the past, but we lose an important attribute of some devices if we take this out. Section 4.2: attributes-natural-languages seems to be the ONLY attribute in this entire set that has a different rule. Why? I don't understand the reasoning behind this. If the Printer supports French only, and I send it English text attributes, is that okay? on the other hand, job-name and document-name say that any correct value is "supported", but that the server should reject unsupported values. These two things seem contradictory. How do I get an unsupported value to reject??? Why would this case be different from attribute-natural-language which has the same rule for defining which values are supported? Section 4.3: Which-document-format attribute name does not match the model document, which lists this simply as document-format. If the client says "Give me the following printer attributes for document-format=IPDS and the printer doesn't support IPDS, why is the rule accept and ignore? What does ignore mean - not respond? Send back the listed attributes for some other (maybe the default) document-format? Either of these would be incorrect as far as the client was concerned. This comment applies to which-jobs and my-jobs as well. If I say send me job attributes for "queued", which is not a valid value, the paper suggests that the printer accept and ignore. Again, what does this mean? Do I respond with "completed" jobs instead? Not respond at all? Seems very strange to me! Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu Nov 20 13:12:35 1997 Delivery-Date: Thu, 20 Nov 1997 13:12:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA26378 for ; Thu, 20 Nov 1997 13:12:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17143 for ; Thu, 20 Nov 1997 13:15:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06869 for ; Thu, 20 Nov 1997 13:12:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 13:06:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05642 for ipp-outgoing; Thu, 20 Nov 1997 12:51:52 -0500 (EST) Message-Id: <3.0.1.32.19971120095354.00f20a00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 20 Nov 1997 09:53:54 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Minutes of the IPP telecon, Wed, 11/19/97 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org We've posted the minutes of the IPP 11/19/97 telecon at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-minutes-97-11-19.doc ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-minutes-97-11-19.pdf ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-minutes-97-11-19.txt (Putting the data in Big Endian order in the file names makes them sort by increasing date in directory listings). Attached is the .txt version as well. Calr-Uno and Tom Minutes from PWG IPP Phone Conference 971119 1. Attending: Roger deBry Lee Farrell Tom Hastings Bob Herriot Harry Lewis Carl-Uno Manros Ira McDonald Xavier Riley Randy Turner Peter Zehler Steve Zilles The following subjects were discussed. 2. Game plan for finalizing the IPP Model & Semantics and Protocol Specification documents a. Close of Last Call comments, Tuesday, November 25 b. PWG Phone Conference, November 26: summarize the Last Call comments. c. Rest of Thanksgiving week and the beginning of 12/1 week: work on resolutions to comments in preparation for IPP LA meeting, 12/3. d. PWG IPP meeting in LA, December 3: discuss and agree on resolutions to WG last call comments. Prepare for IETF meeting in Washington DC the following week. e. IETF IPP meeting in Washington DC, December 10 or 11: present Last Call results and suggested resolutions. f. Second half of December: final editing and submission to the IESG. 3. Status of the Rationale document Steve Zilles will be able to make the agreed updates (mostly resynchronization with the latest versions of Model and Protocol documents) to this and have it sent as an Internet- Draft to the IETF secretariat before the IETF Washington DC deadline on Friday, November 21, 5:00 PM EST (2:00 PM PST). ACTION ITEM: Carl-Uno will issue a WG Last Call, when the document is available from IETF. 4. Write up of security discussion from last week Randy is still working on some text to reflect our previous discussion on security implications due to changes in the latest TLS spec. He will call Scott for help on which section (3.1.5 or 8) in the Model document to update. ACTION ITEM: Randy expects to have it out this week to the DL as part of the Last Call comments. 5. MIME type definition for application/ipp There might be a need to update our current description to allow application/ipp to be sent over ESMTP. We may need to allow the Model attributes that are transmitted as HTTP headers to be in the body when using ESMTP. ACTION ITEM: Ira will look into this further. 6. Suggestion for improved text on operation processing procedures (section 15.3 in the Model document) The contribution from Tom, Bob, and Scott on validation of attributes in operations was briefly reviewed and discussed. It was agreed not to add new response group, but instead to return unsupported Operation attributes and Job Template attributes in the same Unsupported Attributes group. The response group will be renamed in the protocol document to remove the word "job" from the name (and to agree with the Model document). As a consequence, we agreed that the names of Operation attributes and Job Template attributes shall be unique, i.e., the same name will not be used for an Operation attribute and a Job Template attribute. The same name can be used for Operation attributes and Job Description attributes when the Operation attribute is being supplied to initialize the Job Description attribute. ACTION ITEM: Tom, Bob, and Scott will make a couple of revisions and re-issue the proposal to the DL as part of the Last Call comments. 7. Discussion about length boundaries for text strings (from recent DL discussion) Everybody seemed to agree that we want to have maximum lengths for all attribute syntaxes (see section 4.1 in the Model document), including the 'uri' attribute syntax, even if HTTP has not set such limits (pointed out by Larry Masinter). We have to make it explicit what the lengths mean and whether they apply to server, client or both. We reaffirmed that IPP is intended to be implemented by low-end printers that don't spool, as well as devices and servers that do spool. Therefore, these length conformance requirements need to be carefully reviewed as part of the WG last call. We reaffirmed that the maximums for read-write attributes required a conforming IPP object to support the full maximum length without truncation. There was concern that the current maximum for the 'text' attribute syntax of 4095 octets was too large. A maximum of 1023 was suggested, but no consensus was reached. The only read-write 'text' attribute is the 'message' Operation attribute in the Cancel- Job operation. However, since this Operation attribute is OPTIONAL for an IPP object to support, a conforming IPP object SHALL ignore the attribute if it is not supported. But the IPP object SHALL accept the maximum length without truncation if the "message" attribute is supported. There was also agreement that the maximum length for read- only attributes NEED NOT be supported by conforming IPP objects. Read-only attributes are ones set by the implementation and/or the system administrator when configuring the system. The entire list is: "status- message" OPTIONALLY returned in a response, "job-state- message", "job-message-from-operator", "printer-location", "printer-info", "printer-make-and-model", and "printer-state- message". Support for all of these read-only attributes is OPTIONAL for as IPP object. However, when they are supported, we agreed that the Model document needs to agree on minimums that MUST be supported for these read-only attributes. It was suggested that the minimums should agree with the Job Monitoring MIB. ACTION ITEM: Tom to draft a proposal for the maximums for those attribute syntaxes that don't have a maximum and for minimums for all attribute syntaxes discussion on the DL as part of the last call comments. 8. Changes to the Model and Protocol documents since Boulder It was suggested that the list of changes to the Model and Protocol documents be reviewed at the LA meeting, just to re- confirm agreement on the changes. ACTION ITEM: Tom to review the changes that were in Scott's e-mail announcement of the posting of the Model document for completeness and send out the list of changes this week to help Last Call review and for the LA meeting. 9. Next Telecon, Wed, 11/26 It was agreed to run a phone conference next week from 1-3 PM PST (4-6 EDT), even though this is close to Thanksgiving, considering that the Last Call closes on Tuesday and we want to see what needs to be done in the way of preparation for the PWG IPP LA meeting. Note Takers, Carl-Uno Manros and Tom Hastings From ipp-owner@pwg.org Thu Nov 20 15:10:13 1997 Delivery-Date: Thu, 20 Nov 1997 15:10:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA28700 for ; Thu, 20 Nov 1997 15:10:13 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA17892 for ; Thu, 20 Nov 1997 15:13:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11897 for ; Thu, 20 Nov 1997 15:10:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 15:05:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA10958 for ipp-outgoing; Thu, 20 Nov 1997 14:52:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> IPP protocol document... Date: Thu, 20 Nov 1997 11:50:22 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org By the way, I noticed in the current protocol draft, that we have a statement that says an implementation MUST support digest authentication in HTTP. In my opinion this wording would be better if we used SHOULD, since we have a goal for implementers to have secure and non-secure implementations. Also, digest (and basic auth for that matter) are not REQUIRED in order to HTTP 1.1 "compliant" (at least thats the way I understand it...). Randy From jmp-owner@pwg.org Thu Nov 20 15:39:24 1997 Delivery-Date: Thu, 20 Nov 1997 15:39:34 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29171 for ; Thu, 20 Nov 1997 15:39:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18075 for ; Thu, 20 Nov 1997 15:42:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13418 for ; Thu, 20 Nov 1997 15:39:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 15:32:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12439 for jmp-outgoing; Thu, 20 Nov 1997 15:27:03 -0500 (EST) Message-Id: <3.0.32.19971120122644.0085f510@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Nov 1997 12:26:58 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: JMP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pmp-owner@pwg.org Thu Nov 20 15:43:41 1997 Delivery-Date: Thu, 20 Nov 1997 15:43:46 -0500 Return-Path: pmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29255 for ; Thu, 20 Nov 1997 15:43:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18106 for ; Thu, 20 Nov 1997 15:46:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14008 for ; Thu, 20 Nov 1997 15:43:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 15:35:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12407 for pmp-outgoing; Thu, 20 Nov 1997 15:26:50 -0500 (EST) Message-Id: <3.0.32.19971120122644.0085f510@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Nov 1997 12:26:58 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: PMP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: pmp-owner@pwg.org Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pwg-owner@pwg.org Thu Nov 20 15:47:47 1997 Delivery-Date: Thu, 20 Nov 1997 15:47:53 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29314 for ; Thu, 20 Nov 1997 15:47:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18130 for ; Thu, 20 Nov 1997 15:50:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14373 for ; Thu, 20 Nov 1997 15:47:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 15:39:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12485 for pwg-outgoing; Thu, 20 Nov 1997 15:27:42 -0500 (EST) Message-Id: <3.0.32.19971120122644.0085f510@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Nov 1997 12:26:58 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: PWG> January Meeting Notice Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-owner@pwg.org Thu Nov 20 16:01:26 1997 Delivery-Date: Thu, 20 Nov 1997 16:01:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29533 for ; Thu, 20 Nov 1997 16:01:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18220 for ; Thu, 20 Nov 1997 16:04:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA15292 for ; Thu, 20 Nov 1997 16:01:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 15:55:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12456 for ipp-outgoing; Thu, 20 Nov 1997 15:27:20 -0500 (EST) Message-Id: <3.0.32.19971120122644.0085f510@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Nov 1997 12:26:58 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: IPP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hello, This is the official meeting notice for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting) This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan. Rather than have this meeting in Japan it was decided that it would be fairer to meet half way. Alaska is to cold and dark in January, so we thought that Hawaii was a better choice. The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-owner@pwg.org Thu Nov 20 19:21:43 1997 Delivery-Date: Thu, 20 Nov 1997 19:21:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA02131 for ; Thu, 20 Nov 1997 19:21:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA19107 for ; Thu, 20 Nov 1997 19:24:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA21844 for ; Thu, 20 Nov 1997 19:21:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 19:16:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20882 for ipp-outgoing; Thu, 20 Nov 1997 19:03:51 -0500 (EST) Date: Thu, 20 Nov 1997 16:03:09 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711210003.QAA22597@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest LPD document at PWG site and sent to IETF X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the latest update to the LPD document. The documents are in: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The files are: ipp-lpd-971120-rev.doc The MS-Word 6.0 with revision marks ipp-lpd-971120.doc The MS-Word 6.0 with no revision marks ipp-lpd-971120.txt The text document sent to the IETF as draft-ietf-ipp-lpd-ipp-map-02.txt From ipp-owner@pwg.org Thu Nov 20 20:04:29 1997 Delivery-Date: Thu, 20 Nov 1997 20:04:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA02377 for ; Thu, 20 Nov 1997 20:04:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19191 for ; Thu, 20 Nov 1997 20:07:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA23470 for ; Thu, 20 Nov 1997 20:04:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 19:59:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22506 for ipp-outgoing; Thu, 20 Nov 1997 19:46:16 -0500 (EST) Message-ID: <3474D9D4.9DDD1B1@zeno.com> Date: Thu, 20 Nov 1997 16:46:12 -0800 From: zhi-hong@zeno.com (Zhi-Hong Huang) Organization: Zenographics X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Processing Algorithm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I am a bit confused reading Session 15.3 in the model document. It says that processing continues step by step until a reject the request is encountered or the last step is reached. Does it mean that with HTTP 1.1, the client has to send and wait at each step for the server response? Since client may POST several IPP requests on a single HTTP 1.1 connection, if the server replys before consuming all the data the client sends, it would be difficult for the server to locate where the next message starts. There would be no problem if the client closes connection after each message. Is this a requirement? Zhi-Hong Huang Zenographics, Inc. From ipp-owner@pwg.org Thu Nov 20 20:29:48 1997 Delivery-Date: Thu, 20 Nov 1997 20:29:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA02541 for ; Thu, 20 Nov 1997 20:29:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19228 for ; Thu, 20 Nov 1997 20:32:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA24687 for ; Thu, 20 Nov 1997 20:29:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Nov 1997 20:24:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23738 for ipp-outgoing; Thu, 20 Nov 1997 20:12:04 -0500 (EST) Message-Id: <3.0.1.32.19971120165334.00f25db0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 20 Nov 1997 16:53:34 PST To: Roger K Debry , From: Tom Hastings Subject: Re: IPP>Comments on Operations Attributes In-Reply-To: <5030100013817454000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Roger, Thanks for making these comments. See replies below. We'll incorporate them into the updated version that we were assigned as an action item at the 11/19 telecon. Tom At 08:21 11/20/1997 PST, Roger K Debry wrote: >I have read through the comments posted by Tom, Bob, and Scott >and have the following comments: > >In general, I think that the proposal is a good one, and I appreciate >the work done by Tom, Bob and Scott to clarify the handling of >operation attributes. Thanks > >Section 2.2: Do we need to get to the level of detail suggested >in this paragraph in reporting errors? Why isn't it adequate to >simply say "syntax error"? Don't these errors fall into the same >category as paragraph 2.4, i.e. invalid length looks like a >development time error, not an end user run-time. > >It seems that if code is buggy or there is a serious problem in >generating or parsing the request stream, that more than one >error of this type might occur. If we take this to its ultimate >conclusion, we could get carried away with a very sophisticated >error reporting scheme, listing all errors that coccured and where >in the request stream they occured. I don't think we want to do this, >so I'd just settle for "Syntax error" and leave it at that. > >Sections 2.3 and 2.4: Same comments as above. Good point. We agreed on the telcon yesterday to combine 'client-error-keyword-or-value-too-long' with 'client-error-wrong-length-value' into 'client-error-incorrect-length'. So your suggestion is to combine all of the developer errors into one: 'client-error-syntax-error'. So your suggestion is to go even further and fold 'client-error-keyword-or-value-too-long', 'client-error-wrong-length-value', 'client-error-attributes-groups-out-of-order', and 'client-error-missing-required-operation-attributes' into one error: 'client-error-syntax-error'. Sounds good to me. > >Section 2.5: The sentence "An unsupported attribute is either >one that is not in the Model document or that is in the Model document >but is not required to be supported" is troublesome. One could argue >from this sentence that a supported attribute is therefore one that is >in the Model document and mandatory. Clearly this is not true. >Aren't implemented optional attributes "supported"? > >Doesn't supported have to do with what I implement, not what is >in the document? For example, I can implement my own attributes >as extensions to the standard, are these then unsupported according >to the rules stated here? Also, using the logic implied by the sentence >in 2.5, if I implement an optional attribute, even though it is in the model >document, it is unsupported. Is that what you mean? Good point. We were trying to indicate that "unsupported" covered several situations, but we didn't do a very good job. The easied fix is just to delete the incorrect definition of "unsupported": An unsupported attribute is either one that is not in the Model document or that is in the Model document but is not required to be supported. > >Section 2.6: I'm somewhat concerned over the statement made in >this section that validation depends upon the specification of the >attribute. We ought to strive for a common rule, it would make >the model much cleaner and I would expect therefore the >processing would be simpler. Certainly there would be fewer >opportunities for misreading or misinterpreting the spec. While I agree that it would be better to have a consistent rule, when we did the analysis, we couldn't come up with such a rule. There are some attributes, such as "attributes-char-set", that the recipient cannot just ignore an unsupported value. The recipient cannot do anything with a value that it doesn't understand. If I send you 'text' and 'name' attributes in ShiftJIS and you do not understand that charset, you will not be able to do what I ask. Same for "document-format". If you are a PCL printer and I send you a PostScript document, it doesn't do me any good for you to ignore my values and print it as PCL. On the other hand, if I ask you for just my jobs, but you can only return all jobs, it isn't too bad if you return all jobs and tell me that you are ignoring the "my-jobs" attribute. It seems better than returning an error and not returing any jobs. I can either ignore your entire response or present all of the results to my user. Same with "attribute-natural-language". If I tell you that my name is in Navajo and I would like your messages to be in Navajo, but you don't support Navajo, I'd rather get messages in your default language and still be able to print, than having the request rejected completely. (as long as you support the charset that I use). > >Section 4.1: What does the comment "after copies-collated-supported" >gets removed mean? I know Bob had argued against this in the past, >but we lose an important attribute of some devices if we take this out. We need to discuss this. The statement is because the validation of copies is against either the "copies-supported" or the "copies-collated-supported" attribute, depending on whether documents are being collated with a job (A, B, A, B, ... vs. A, A, ... B, B, ...) or not. So for this one case, the validation algorightm is not just compare "xxx" with "xxx-supported". But we need to talk, since the "copies-collated-supported" is probably talking about collating sheets within a single document copy using an output bin collator, not collating document copies within a job. We can see that the number of copies that an output bing collator has, might place an upperbound on the number of collated copies. But, since IPP doesn't currently have an attribute for controlling collation of sheets within a document copy, we wonder whether we really need "copies-collated-supported"? Lets discuss off-line and bring in something for the WG Last call. > >Section 4.2: attributes-natural-languages seems to be the ONLY >attribute in this entire set that has a different rule. Why? I don't >understand the reasoning behind this. If the Printer supports >French only, and I send it English text attributes, is that okay? Yes is it ok. Either you may understand French too in order to read the messages that I return, or the status codes that come back are sufficient for you to understand, since your client has to localize the status codes to French anyway. Also, we need to improve the presentation, since you are mis-lead by it into thinking that attributes-natural-languages is the only "forgiving" attribute. The following attributes are also "forgiving", in that the Printer MUST ignore values it doesn't support: Forgiving attributes: 4.2: "attributes-natural-language" "requested-attributes" 4.3: "document-natural-language" "job-k-octets" "job-impressions" "job-media-sheets" "message" "which-document-format" "which-jobs" "my-jobs" any unknown attributes Unforgiving attributes: 4.2: "attributes-charset" "document-uri" "job-id" "document-format" 4.3: "compression" So we have 5 unforgiving attributes vs. 11 forgiving attributes. I don't see a way to come up with a single way to handle them without making them all unforgiving or to add "ipp-attriute-fidelity" control to the 11 forgiving ones (which is added complexity). But the 5 unforgiving ones MUST always be unforgiving. > >on the other hand, job-name and document-name say that any >correct value is "supported", but that the server should reject >unsupported values. These two things seem contradictory. How >do I get an unsupported value to reject??? Why would this case >be different from attribute-natural-language which has the same >rule for defining which values are supported? To make the table simple, we lumped bad syntax in with unsupported. So a "job-name" that was too long or the wrong attribute syntax, was lumped into "unsupported". That is too confusing, so we'll change the table. In fact, it was so confusing, that I erroneously changed "attributes-natural-language" from reject to accept always. The entry should have been "reject", and yet we really want to indicate that "attributes-natural-langauge" is one of the forgiving operation attributes that SHALL accept any (syntactically legal) value, whether supported or not. > >Section 4.3: Which-document-format attribute name does not >match the model document, which lists this simply as >document-format. True. We had meant to suggest that the Get-Attributes (on a Printer) change the name of the "document-format" operation attribute to "which-document-format", to follow the principle that we ageed on the IPP 11/19 telecon, that we can't use the same name for an Operation attribute that is different in semantics from the Job Template attribute. >If the client says "Give me the following printer >attributes for document-format=IPDS and the printer doesn't >support IPDS, why is the rule accept and ignore? What does >ignore mean - not respond? Send back the listed attributes for >some other (maybe the default) document-format? Either of these >would be incorrect as far as the client was concerned. We suggest that the Printer does return the attributes for the default printer and also return the "which-document-format" attribute that is being ignored with its value. So the client gets the warning "successful-ok-ignored-or-substituted-attributes" status code. ISSUE: Perhaps this is a debatable point. The alternative would be to change the "which-document-attribute" into an unforgiving Operation attribute, so that it would reject the requeset for an unsupported value of the "which-document-format". The client must then query the printer and try again, or leave out the "which-document-attribute" and get the Printer's default document-format. The current Model document is silent on what to return when the "document-format" requested is not supported, though it hints that the Printer would return for the default document format in the second paragraph of 3.2.5.1 "document-format". We are suggesting the principle that for attributes that the client need not supply, so that the IPP object uses a default, that the IPP object use that same default for forgiving attributes when the supplied value is unsupported. This helps interworking with future minor versions that add additional values to forgiving Operation attributes. > >This comment applies to which-jobs and my-jobs as well. If I >say send me job attributes for "queued", which is not a valid >value, the paper suggests that the printer accept and ignore. >Again, what does this mean? Do I respond with "completed" >jobs instead? Not respond at all? Seems very strange to me! When an IPP object ignores an attribute it behaves as if the attribute had NOT been supplied, i.e., the IPP object uses its default behavior. Section 3.2.6.2 says if the client omits the "which-jobs" attribute, the Printer SHALL assume 'not-completed'. So we are proposing to extend that behavior to an unsupported value. > > > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > From ipp-owner@pwg.org Fri Nov 21 10:21:08 1997 Delivery-Date: Fri, 21 Nov 1997 10:21:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15271 for ; Fri, 21 Nov 1997 10:21:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA20906 for ; Fri, 21 Nov 1997 10:24:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15888 for ; Fri, 21 Nov 1997 10:21:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 10:12:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14699 for ipp-outgoing; Fri, 21 Nov 1997 09:58:26 -0500 (EST) Message-Id: <199711211447.JAA06431@devnix.agranat.com> To: zhi-hong@zeno.com (Zhi-Hong Huang) cc: ipp@pwg.org Subject: Re: IPP> Processing Algorithm In-reply-to: <3474D9D4.9DDD1B1@zeno.com> Date: Fri, 21 Nov 1997 09:47:39 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org >>>>> "ZH" == Zhi-Hong Huang writes: ZH> Since client may POST several IPP requests on a single HTTP 1.1 ZH> connection, if the server replys before consuming all the data ZH> the client sends, it would be difficult for the server to locate ZH> where the next message starts. I'm not entirely sure that I'm addressing the right concern here, but... an HTTP/1.1 server can detect the end of an entity body in any of three ways: a Content-Length header, Transfer-Encoding: chunked, or a Multipart encoding that is self-descriptive. It is true that an HTTP client using persistent connections (either 1.1-style or the Netscape Keep-Alive style) must keep track of the order of requests, and the server must preserve that order in sending responses as there is no transaction identifier. Did that answer your question? -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Fri Nov 21 10:39:20 1997 Delivery-Date: Fri, 21 Nov 1997 10:39:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15651 for ; Fri, 21 Nov 1997 10:39:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA20987 for ; Fri, 21 Nov 1997 10:42:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA16954 for ; Fri, 21 Nov 1997 10:39:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 10:34:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16008 for ipp-outgoing; Fri, 21 Nov 1997 10:21:51 -0500 (EST) Message-ID: <3475A705.1918115E@underscore.com> Date: Fri, 21 Nov 1997 10:21:41 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Scott Lawrence , Zhi-Hong Huang Subject: Re: IPP> Processing Algorithm References: <199711211447.JAA06431@devnix.agranat.com> Content-Type: multipart/mixed; boundary="------------99B48168D1A685467C47661C" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------99B48168D1A685467C47661C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think Zhi-Hong has raised a very valid concern here, one that we should address in a clean and unambiguous manner within IPP. If IPP allows multiple posts (requests) in which the client is expecting to receive multiple responses, then IPP should be clearly defined to do one (and only one) of the following: a) Ensure the order of responses is *exactly* in the same order as the requests, or b) Define and force mandatory usage of a client-specified transaction id (included as part of a request) that the server attaches to all responses. The transaction id would be considered completely opaque to the server (ie, no semantic meaning whatsoever). If we wish to provide maximum performance potential, then the second choice would be the second (b) option. Adding such a transaction id wouldn't add that much "baggage" to the protocol. ...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 -- ---------------------------------------------------------------------- --------------99B48168D1A685467C47661C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA21797; Fri, 21 Nov 1997 10:14:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15312; Fri, 21 Nov 1997 10:14:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 10:12:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14699 for ipp-outgoing; Fri, 21 Nov 1997 09:58:26 -0500 (EST) Message-Id: <199711211447.JAA06431@devnix.agranat.com> To: zhi-hong@zeno.com (Zhi-Hong Huang) cc: ipp@pwg.org Subject: Re: IPP> Processing Algorithm In-reply-to: <3474D9D4.9DDD1B1@zeno.com> Date: Fri, 21 Nov 1997 09:47:39 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org Content-Type: text >>>>> "ZH" == Zhi-Hong Huang writes: ZH> Since client may POST several IPP requests on a single HTTP 1.1 ZH> connection, if the server replys before consuming all the data ZH> the client sends, it would be difficult for the server to locate ZH> where the next message starts. I'm not entirely sure that I'm addressing the right concern here, but... an HTTP/1.1 server can detect the end of an entity body in any of three ways: a Content-Length header, Transfer-Encoding: chunked, or a Multipart encoding that is self-descriptive. It is true that an HTTP client using persistent connections (either 1.1-style or the Netscape Keep-Alive style) must keep track of the order of requests, and the server must preserve that order in sending responses as there is no transaction identifier. Did that answer your question? -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ --------------99B48168D1A685467C47661C-- From daemon Fri Nov 21 10:27:39 1997 Delivery-Date: Fri, 21 Nov 1997 10:48:18 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA14919 for ietf-123-outbound.10@ietf.org; Fri, 21 Nov 1997 10:04:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA14688; Fri, 21 Nov 1997 09:54:38 -0500 (EST) Message-Id: <199711211454.JAA14688@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-02.txt Date: Fri, 21 Nov 1997 09:54:36 -0500 Sender: cclark@cnri.reston.va.us --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) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-02.txt Pages : 8 Date : 20-Nov-97 This document describes a protocol intended to provide lossless compression for Internet Protocol 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971120154515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971120154515.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Nov 21 11:31:17 1997 Delivery-Date: Fri, 21 Nov 1997 11:31:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16664 for ; Fri, 21 Nov 1997 11:31:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21288 for ; Fri, 21 Nov 1997 11:34:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19258 for ; Fri, 21 Nov 1997 11:31:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 11:19:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA17437 for ipp-outgoing; Fri, 21 Nov 1997 10:54:47 -0500 (EST) Message-Id: <199711211555.KAA06673@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Processing Algorithm In-reply-to: <3475A705.1918115E@underscore.com> Date: Fri, 21 Nov 1997 10:55:47 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org >>>>> "JM" == Jay Martin writes: JM> If IPP allows multiple posts (requests) in which the client is JM> expecting to receive multiple responses, then IPP should be JM> clearly defined to do one (and only one) of the following: JM> a) Ensure the order of responses is *exactly* in the same JM> order as the requests, or You don't have any other alternative if you are running over HTTP. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Fri Nov 21 11:33:46 1997 Delivery-Date: Fri, 21 Nov 1997 11:33:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16710 for ; Fri, 21 Nov 1997 11:33:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21315 for ; Fri, 21 Nov 1997 11:36:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19523 for ; Fri, 21 Nov 1997 11:33:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 11:22:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA17522 for ipp-outgoing; Fri, 21 Nov 1997 10:57:39 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" , ipp@pwg.org Cc: Scott Lawrence , Zhi-Hong Huang Subject: RE: IPP> Processing Algorithm Date: Fri, 21 Nov 1997 07:55:24 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org In a very early protocol draft, I had a transaction identifier in the packet so that clients could pipeline requests to a server that, in theory, could be processed and responded to out of order. However, it was decided that requests over a single connection would be processed in order (FIFO), and that if overlapping requests are desired, then the client could open additional (separate) connections to the server and issue them. Randy > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, November 21, 1997 7:22 AM > To: ipp@pwg.org > Cc: Scott Lawrence; Zhi-Hong Huang > Subject: Re: IPP> Processing Algorithm > > I think Zhi-Hong has raised a very valid concern here, one that we > should address in a clean and unambiguous manner within IPP. > > If IPP allows multiple posts (requests) in which the client is > expecting to receive multiple responses, then IPP should be > clearly defined to do one (and only one) of the following: > > a) Ensure the order of responses is *exactly* in the same > order as the requests, or > > b) Define and force mandatory usage of a client-specified > transaction id (included as part of a request) that the > server attaches to all responses. The transaction id > would be considered completely opaque to the server (ie, > no semantic meaning whatsoever). > > If we wish to provide maximum performance potential, then the > second choice would be the second (b) option. Adding such a > transaction id wouldn't add that much "baggage" to the protocol. > > ...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 -- > ---------------------------------------------------------------------- > << Message: Re: IPP> Processing Algorithm >> From ipp-owner@pwg.org Fri Nov 21 11:46:22 1997 Delivery-Date: Fri, 21 Nov 1997 11:46:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16924 for ; Fri, 21 Nov 1997 11:46:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21394 for ; Fri, 21 Nov 1997 11:49:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20448 for ; Fri, 21 Nov 1997 11:46:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 11:41:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA18105 for ipp-outgoing; Fri, 21 Nov 1997 11:19:59 -0500 (EST) Message-ID: <3475B49A.3F451650@underscore.com> Date: Fri, 21 Nov 1997 11:19:38 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org, Scott Lawrence , Zhi-Hong Huang Subject: Re: IPP> Processing Algorithm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Randy, > In a very early protocol draft, I had a transaction identifier in > the packet so that clients could pipeline requests to > a server that, in theory, could be processed and responded > to out of order. > > However, it was decided that requests over a single > connection would be processed in order (FIFO), and that > if overlapping requests are desired, then the client could > open additional (separate) connections to the server and > issue them. Yes, I recall this situation. I thought your proposal to include a transaction id was very well founded, and reflected many, many protocol designs in use today. It bothers me, though, that the decision is to just "open another connection" (or two, or three) if the client wants to perform parallel actions. IHMO, this is far worse in terms of resource utilization than simply using a transaction id. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Nov 21 12:00:14 1997 Delivery-Date: Fri, 21 Nov 1997 12:00:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17175 for ; Fri, 21 Nov 1997 12:00:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21446 for ; Fri, 21 Nov 1997 12:03:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21394 for ; Fri, 21 Nov 1997 12:00:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 11:55:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20620 for ipp-outgoing; Fri, 21 Nov 1997 11:51:20 -0500 (EST) Message-ID: <3475BA46.DAE2FFC0@parc.xerox.com> Date: Fri, 21 Nov 1997 08:43:50 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Scott Lawrence CC: ipp@pwg.org Subject: Re: IPP> Processing Algorithm References: <199711211555.KAA06673@devnix.agranat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The HTTP-NG protocol design group is presupposing that while application software wants request/response matching, it is the function of lower level software to supply it. IPP is an important target for HTTP-NG. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Fri Nov 21 12:07:50 1997 Delivery-Date: Fri, 21 Nov 1997 12:07:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17285 for ; Fri, 21 Nov 1997 12:07:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21495 for ; Fri, 21 Nov 1997 12:10:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22028 for ; Fri, 21 Nov 1997 12:07:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:03:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21469 for ipp-outgoing; Fri, 21 Nov 1997 12:03:42 -0500 (EST) Message-ID: <3475BEEC.235F8666@zeno.com> Date: Fri, 21 Nov 1997 09:03:41 -0800 From: zhi-hong@zeno.com (Zhi-Hong Huang) Organization: Zenographics X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Processing Algorithm References: <199711211447.JAA06431@devnix.agranat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Scott Lawrence wrote: > I'm not entirely sure that I'm addressing the right concern here, > but... an HTTP/1.1 server can detect the end of an entity body in > any of three ways: a Content-Length header, Transfer-Encoding: > chunked, or a Multipart encoding that is self-descriptive. > > Did that answer your question? That should be fine if the server is required to consume all the client's data whether or not it decides to reject a request. One solution could be as follow: If the server rejects a request and will not further receive data from the client, it will close the connection. Zhi-Hong Huang Zenographics, Inc. From ipp-owner@pwg.org Fri Nov 21 12:34:00 1997 Delivery-Date: Fri, 21 Nov 1997 12:34:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17664 for ; Fri, 21 Nov 1997 12:34:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21573 for ; Fri, 21 Nov 1997 12:36:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23135 for ; Fri, 21 Nov 1997 12:33:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:28:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22574 for ipp-outgoing; Fri, 21 Nov 1997 12:28:25 -0500 (EST) Message-Id: <199711211729.MAA06957@devnix.agranat.com> To: zhi-hong@zeno.com (Zhi-Hong Huang) cc: ipp@pwg.org Subject: Re: IPP> Processing Algorithm In-reply-to: <3475BEEC.235F8666@zeno.com> Date: Fri, 21 Nov 1997 12:29:03 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org SL> Scott Lawrence wrote: SL> an HTTP/1.1 server can detect the end of an entity body in SL> any of three ways: a Content-Length header, Transfer-Encoding: SL> chunked, or a Multipart encoding that is self-descriptive. >>>>> "ZH" == Zhi-Hong Huang writes: ZH> That should be fine if the server is required to consume ZH> all the client's data whether or not it decides to reject ZH> a request. ZH> One solution could be as follow: If the server rejects a ZH> request and will not further receive data from the client, ZH> it will close the connection. Either party in an HTTP connection is free to close it at any time; in practice this can lead to cases in which the results of some requests may be unknown (because of interaction with TCP resets). The bad case is when the server closes the TCP connection after sending an error response based on the request headers, the TCP close causes the server to send an RST in response to the incoming body, and the servers response gets lost when the RST causes the client to flush received data without delivering it. [I realize that was a little confusing. ] The HTTP '100 Continue' status was intended to help with this situation; the client would send the headers for a request with a body, then wait for a '100 Continue' status before sending the body (or an error, in which case the body is not sent at all). This allows the server to send an error response when a problem is detectable strictly using the headers (such as lack of a valid 'Authorization' header field, or an invalid URL), before the TCP connection gets the body in it. It was decided in the HTTP/1.1 standard not to require that the client _always_ wait for the '100 Continue' response before transmitting the body - instead, the client MAY indicate that it will wait for a '100 Continue' response before transmitting the body by including an 'Expect: 100-continue' header in the request. It might be a good idea (IMHO) for IPP with its potentially large POST operations to require this behaviour. I would provide a pointer to the I-D for this, but a new one should be out today with different section numbers, so I'll wait a bit. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Fri Nov 21 12:47:57 1997 Delivery-Date: Fri, 21 Nov 1997 12:47:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17807 for ; Fri, 21 Nov 1997 12:47:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21618 for ; Fri, 21 Nov 1997 12:50:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23898 for ; Fri, 21 Nov 1997 12:47:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:41:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23271 for ipp-outgoing; Fri, 21 Nov 1997 12:41:52 -0500 (EST) Message-Id: <3.0.1.32.19971121094442.00ff03c0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Nov 1997 09:44:42 PST To: zhi-hong@zeno.com (Zhi-Hong Huang), ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Processing Algorithm In-Reply-To: <3475BEEC.235F8666@zeno.com> References: <199711211447.JAA06431@devnix.agranat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 09:03 11/21/1997 PST, Zhi-Hong Huang wrote: >Scott Lawrence wrote: > >> I'm not entirely sure that I'm addressing the right concern here, >> but... an HTTP/1.1 server can detect the end of an entity body in >> any of three ways: a Content-Length header, Transfer-Encoding: >> chunked, or a Multipart encoding that is self-descriptive. >> >> Did that answer your question? > >That should be fine if the server is required to consume >all the client's data whether or not it decides to reject >a request. >One solution could be as follow: If the server rejects a >request and will not further receive data from the client, >it will close the connection. We have agreed that servers SHOULD issue a reject response to a client as soon as the server knows that it is going to reject the create request because of Operation or Job Template attributes supplied up front by the client, rather than waiting until the client has sent all of the document data which follows and which could be large. There seems to be two ways to avoid sending all of the document data when the server rejects the create request: 1. The client gets the response and sees the reject, so the client stops sending the rest of the data. 2. The server sends the reject response and then close the connection, forcing the client to stop sending the rest of the document data. Scheme 1 would allow the connection to stay open. Are both schemes feasible with HTTP/1.1? Can an HTTP/1.1 client accept a response while sending a (long) request on the same connection? Tom > >Zhi-Hong Huang >Zenographics, Inc. > > > From ipp-owner@pwg.org Fri Nov 21 12:54:20 1997 Delivery-Date: Fri, 21 Nov 1997 12:54:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17875 for ; Fri, 21 Nov 1997 12:54:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21629 for ; Fri, 21 Nov 1997 12:57:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24544 for ; Fri, 21 Nov 1997 12:54:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:47:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23833 for ipp-outgoing; Fri, 21 Nov 1997 12:47:23 -0500 (EST) X-Sender: szilles@elroy (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1331988646==_============" Date: Fri, 21 Nov 1997 09:37:30 -0800 To: ipp@pwg.org From: szilles@Adobe.COM (Steve Zilles) Subject: IPP> Revision of Rationale Document Cc: szilles@Adobe.COM Sender: ipp-owner@pwg.org --============_-1331988646==_============ Content-Type: text/plain; charset="us-ascii" Attached is the unpaginated text of the revised Rationale document and a diff file that highlights the (non-typo) changes between -01 and -02. Comments received before 12PM PST will be incorporated in the draft sent to the IETF. Steve Zilles --============_-1331988646==_============ Content-Type: text/plain; name="draft-ietf-ipp-rat-02.txt"; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ipp-rat-02.txt" INTERNET DRAFT Stephen N. Zilles Adobe Systems Inc. November 21, 1997 Expires: May 21, 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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 protocol allows a client 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 of 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 [IPP-MOD]) 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 [IPP-PRO]) 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 [IPP-PRO]) 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. Another part of the IPP architecture is the Directory Schema (described in the model document).. 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 [RFC1905, RFC1906] 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 [IPP-MOD] 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 allows the Model data to be aligned with the (abstract) model used in the Printer [RFC1759], 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 [RFC1905, RFC1906] and the Printer/Job MIBs. There is one aspect of the Model that deserves some extra explanation. There are two ways for identifying a Job object: (a) with a Job URI and (b) using a combination of the Printer URI and a Job ID (a 32 bit positive integer). Allowing Job objects to have URIs allows for flexibility and scalability. For example a job could be moved from a printer with a large backlog to one with a smaller load and the job identification, the Job object URI, need not change. However, many existing printing systems have local models or interface constraints that force Job objects to be identified using only a 32-bit positive integer rather than a URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. In order to allow both types of client access to Jobs (either by Job URI or bynumeric Job ID), when the Printer object successfully processes a create request and creates a new Job, the Printer object SHALL generate both a Job URI and a Job ID for the new Job object. This requirement allows all clients to access Printer objects and Job objects no matter the local constraints imposed on the client implementation. 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 sequences of attributes. Each attribute has a name, prefixed by a name length, and a value.. The names are strings constrained to characters from a subset of ASCII. The values are either scalars or a sequence of scalars. Each scalar value has a length specification and a value tag which indicates the type of the value. The value type has two parts: a major class part, such as integer or string, and a minor class part which distinguishes the usage of the major class, such as dateTime string. Tagging of the values with type information allows for introducing new value types at some future time. 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 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 is being 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, HELP information, 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 HTTP proxies and not the implementation of HTTP 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. HTTP implementations provide support for handling URLs that would have to be provided if a new protocol were defined. 6. An HTTP based solution fits well with the Internet security mechanism that are currently deployed or being deployed. HTTP will run over TLS/SSL. 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. 7. HTTP provides an extensibility model that a new protocol would have to develop independently. In particular, the headers, content-types (via Internet Media Types) and error codes have wide acceptance and a useful set of definitions and methods for extension. 8. Although not strictly a reason why IPP should use HTTP as the transmission protocol, it is extremely helpful that there are many prototyping tools that work with HTTP and that CGI scripts can be used to test and debug parts of the protocol. 9. Finally, the POST method was chosen to carry the print data because its usage for data transmission has been established, it works and the results are available via CGI scripts where that is relevant. Creating a new method would have better identified the intended use of the POSTed data, but a new method would be more difficult to deploy. Because there were no strong arguments for or against using a new method, the POST method was used. 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 TLS/SSL [TLS-PRO] secure communication mechanism. To provide access to both HTTP security and TLS security, IPP Printers provide two URLs for accessing the Printer object: one URL for which the scheme is HTTP for normal HTTP 1.1 access and one URL for which the scheme is HTTPS for access to the Printer using TLS/SSL protected communication. Two URLs are necessary because all allowed modes of TLS require some level of security beyond HTTP security so a TLS capable URL cannot be used to negotiate down to HTTP security. 7. COPYRIGHT This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. REFERENCES [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. [RFC1905] J. Case, et al. "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] J. Case, et al. "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [IPP-MOD] Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell, P, "Internet Printing Protocol/1.0: Model and Semantics" draft-ipp-mod-07.txt, November, 1997. [IPP-PRO] Herriot, R., Butler, S., Moore, P., Tuner, R., " Internet Printing Protocol/1.0: Protocol Specifications", draft-ipp-pro- 03.txt, November, 1997. [IPP-REQ] Wright, D., "Requirements for an Internet Printing Protocol", draft-ipp-req-01.txt, November, 1997. [TLS-PRO] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", , November, 1997 9. 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 --============_-1331988646==_============ Content-Type: text/plain; name="diff2"; charset="us-ascii" Content-Disposition: attachment; filename="diff2" 4c4 < Adobe Systems Inc. --- > Adobe Systems Inc. 6c6 < July 30, 1997 Expires: Jan 30, 1998 --- > November 21, 1997 Expires: May 21, 1998 47,52c47,51 < 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 --- > Requirements for an Internet Printing Protocol > Internet Printing Protocol/1.0: Model and Semantics > Internet Printing Protocol/1.0: Protocol Specification > Rationale for the Structure of the Model and Protocol for > the Internet Printing Protocol 103,107c103,107 < 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. --- > Another part of the IPP architecture is the Directory Schema > (described in the model document).. 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. 112c112 < --- > 116,126c116,126 < 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. --- > 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 [RFC1905, > RFC1906] 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. 161,165c160,186 < 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. --- > aligned with the (abstract) model used in the Printer > [RFC1759], 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 [RFC1905, RFC1906] and the Printer/Job MIBs. > > There is one aspect of the Model that deserves some extra > explanation. There are two ways for identifying a Job > object: (a) with a Job URI and (b) using a combination of > the Printer URI and a Job ID (a 32 bit positive integer). > Allowing Job objects to have URIs allows for flexibility and > scalability. For example a job could be moved from a printer > with a large backlog to one with a smaller load and the job > identification, the Job object URI, need not change. > However, many existing printing systems have local models or > interface constraints that force Job objects to be > identified using only a 32-bit positive integer rather than > a URI. This numeric Job ID is only unique within the > context of the Printer object to which the create request > was originally submitted. In order to allow both types of > client access to Jobs (either by Job URI or bynumeric Job > ID), when the Printer object successfully processes a create > request and creates a new Job, the Printer object SHALL > generate both a Job URI and a Job ID for the new Job object. > This requirement allows all clients to access Printer > objects and Job objects no matter the local constraints > imposed on the client implementation. 177,183c198,210 < 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. --- > adequate to represent the kinds of data that occur within > the Model. It has a simple structure consisting of sequences > of attributes. Each attribute has a name, prefixed by a name > length, and a value.. The names are strings constrained to > characters from a subset of ASCII. The values are either > scalars or a sequence of scalars. Each scalar value has a > length specification and a value tag which indicates the > type of the value. The value type has two parts: a major > class part, such as integer or string, and a minor class > part which distinguishes the usage of the major class, such > as dateTime string. Tagging of the values with type > information allows for introducing new value types at some > future time. 207c234 < recent evidence, HTTP 1.1 will be widely deployed as the --- > recent evidence, HTTP 1.1 is being widely deployed as the 240,245c268,277 < 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. --- > 4. Most of the complexity of HTTP 1.1 is concerned with > the implementation of HTTP proxies and not the > implementation of HTTP 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. HTTP implementations provide support for handling URLs > that would have to be provided if a new protocol were > defined. 247c279 < 5. An HTTP based solution fits well with the Internet --- > 6. An HTTP based solution fits well with the Internet 249c281 < deployed. HTTP will run over SSL/TLS. The digest --- > deployed. HTTP will run over TLS/SSL. The digest 255a288,309 > 7. HTTP provides an extensibility model that a new > protocol would have to develop independently. In > particular, the headers, content-types (via Internet > Media Types) and error codes have wide acceptance and > a useful set of definitions and methods for extension. > > 8. Although not strictly a reason why IPP should use HTTP > as the transmission protocol, it is extremely helpful > that there are many prototyping tools that work with > HTTP and that CGI scripts can be used to test and > debug parts of the protocol. > > 9. Finally, the POST method was chosen to carry the print > data because its usage for data transmission has been > established, it works and the results are available > via CGI scripts where that is relevant. Creating a new > method would have better identified the intended use > of the POSTed data, but a new method would be more > difficult to deploy. Because there were no strong > arguments for or against using a new method, the POST > method was used. > 280,283c334 < and the SSL/TLS secure communication mechanism, which also < includes authorization. < < 7. REFERENCES --- > and the TLS/SSL [TLS-PRO] secure communication mechanism. 284a336,408 > To provide access to both HTTP security and TLS security, > IPP Printers provide two URLs for accessing the Printer > object: one URL for which the scheme is HTTP for normal HTTP > 1.1 access and one URL for which the scheme is HTTPS for > access to the Printer using TLS/SSL protected communication. > Two URLs are necessary because all allowed modes of TLS > require some level of security beyond HTTP security so a TLS > capable URL cannot be used to negotiate down to HTTP > security. > > 7. COPYRIGHT > > This document and translations of it may be copied and > furnished to others, and derivative works that comment on or > otherwise explain it or assist in its implementation may be > prepared, copied, published and distributed, in whole or in > part, without restriction of any kind, provided that the > above copyright notice and this paragraph are included on > all such copies and derivative works. However, this > document itself may not be modified in any way, such as by > removing the copyright notice or references to the Internet > Society or other Internet organizations, except as needed > for the purpose of developing Internet standards in which > case the procedures for copyrights defined in the Internet > Standards process must be followed, or as required to > translate it into languages other than English. > > The limited permissions granted above are perpetual and will > not be revoked by the Internet Society or its successors or > assigns. > > This document and the information contained herein is > provided on an "AS IS" basis and THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO > ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > 8. REFERENCES > > [RFC1759] > Smith, R., Wright, F., Hastings, T., Zilles, S., and > Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. > > [RFC1905] > J. Case, et al. "Protocol Operations for Version 2 of > the Simple Network Management Protocol (SNMPv2)", RFC 1905, > January 1996. > > [RFC1906] > J. Case, et al. "Transport Mappings for Version 2 of > the Simple Network Management Protocol (SNMPv2)", RFC 1906, > January 1996. > > [IPP-MOD] > Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell, > P, "Internet Printing Protocol/1.0: Model and Semantics" > draft-ipp-mod-07.txt, November, 1997. > > > [IPP-PRO] > Herriot, R., Butler, S., Moore, P., Tuner, R., " Internet > Printing Protocol/1.0: Protocol Specifications", draft-ipp-pro- > 03.txt, November, 1997. > > [IPP-REQ] > Wright, D., "Requirements for an Internet Printing Protocol", > draft-ipp-req-01.txt, November, 1997. > > [TLS-PRO] > Dierks, T., Allen, C., "The TLS Protocol Version 1.0", > , November, 1997 --============_-1331988646==_============ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com | Adobe Systems Inc. | | Mailstop W14 | tel: (work) (408) 536-4766 | 345 Park Avenue | (Admin) (408) 536-4751 | San Jose, CA 95110-2704 | fax: (408) 537-4042 | -------------------------------------------------------------- --============_-1331988646==_============-- From ipp-owner@pwg.org Fri Nov 21 13:01:05 1997 Delivery-Date: Fri, 21 Nov 1997 13:01:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA18007 for ; Fri, 21 Nov 1997 13:01:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21645 for ; Fri, 21 Nov 1997 13:04:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25357 for ; Fri, 21 Nov 1997 13:01:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:55:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24613 for ipp-outgoing; Fri, 21 Nov 1997 12:55:18 -0500 (EST) Message-Id: <199711211756.MAA07020@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> Processing Algorithm In-reply-to: <3.0.1.32.19971121094442.00ff03c0@garfield> Date: Fri, 21 Nov 1997 12:56:12 -0500 From: "Scott Lawrence" Sender: ipp-owner@pwg.org >>>>> "TH" == Tom Hastings writes: TH> We have agreed that servers SHOULD issue a reject response to a client TH> as soon as the server knows that it is going to reject the create request TH> because of Operation or Job Template attributes supplied up front by the TH> client, rather than waiting until the client has sent all of the document TH> data which follows and which could be large. TH> There seems to be two ways to avoid sending all of the document data TH> when the server rejects the create request: TH> 1. The client gets the response and sees the reject, so the client stops TH> sending the rest of the data. If the HTTP request headers included a Content-Length, then the only way for the client to abort the request is to close the TCP connection. If the HTTP request is sent with 'Transfer-Encoding: chunked' instead, and the server sends a reject, then the client can abort a body already started by sending a zero-length chunk. Having rejected the HTTP method, the server will just discard any body. The use of the chunked body with POST or PUT allows the server to keep the connection open in this case. TH> 2. The server sends the reject response and then close the connection, TH> forcing the client to stop sending the rest of the document data. Leads to the bad case I described in my last note - the client IPP layer may never see the error response. TH> Can an HTTP/1.1 client accept a response while sending a (long) request TH> on the same connection? Implementation detail, but I would suggest that it is a good idea. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Fri Nov 21 13:05:21 1997 Delivery-Date: Fri, 21 Nov 1997 13:05:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA18101 for ; Fri, 21 Nov 1997 13:05:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21658 for ; Fri, 21 Nov 1997 13:08:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25877 for ; Fri, 21 Nov 1997 13:05:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 12:58:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25020 for ipp-outgoing; Fri, 21 Nov 1997 12:58:44 -0500 (EST) Date: Fri, 21 Nov 1997 10:02:56 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711211802.AA03395@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> MOD - Issue on "application/ipp" media type Sender: ipp-owner@pwg.org Hi folks, Friday (21 November 1997) At our IPP Telecon on Wednesday (19 November), I got the action item to address possible objections from MIME experts to registration by the IPP Working Group of the MIME (Multipurpose Internet Mail Extensions) media type "application/ipp" (the proposed registration text I posted, on 24 October 1997, is included below). ISSUE: The body of an IPP create request (eg, "Print-URI") is NOT useful as an email (SMTP/ESMTP) "Content-Type", because some IPP attributes are conveyed (in the IPP/1.0 transport mapping over HTTP/1.1) in header fields of the HTTP POST operation and NOT in the HTTP POST message body. For example, the HTTP header field "Request-URI" is used to convey the target "printer-URI" (critical to building an SMTP/IPP gateway). PROPOSAL: The IPP/1.0 specifications should PERMIT the inclusion of any 'orphaned' IPP attributes in the BODY of the "application/ipp" media type, to make this media type complete and self-contained. This would facilitate the use of "Content-Disposition" headers (in HTTP or SMTP) to request the 'local' storage of the 'job specification' (eg, for later reuse via a 'file:' scheme URI). This would also facilitate other standard IPP transport protocol mappings (eg, directly over TCP/TLS) in the future. If no objections are stated on the IPP WG mailing list, then my above proposal will be our official answer to any possible criticisms from MIME experts at the IETF meeting on 10 December in Washington, DC. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc 716-442-0609 (home in Rochester, NY until April 1998, w/ voice mail) ========================== Original Message ============================ Copies To: masinter@parc.xerox.com imcdonal@eso.mc.xerox.com ipp@pwg.org Hi folks, Friday (24 October 1997) At our IPP Telecon on Wednesday (22 October), I got the action item to write up new text for registration of MIME media type "application/ipp". This template came from the IETF MIME Part Four: Registration Procedures (RFC 2048, November 1996). Note_1: We need not actually apply for registration of this media-type until the IPP/1.0 specs are accepted by the IESG onto the 'standards track'. The application is made by mail (see below) and need not be supported by a separate Informational RFC. Note_2: The 'Intended usage' of 'LIMITED USE' (rather than 'COMMON') is based on advice earlier this month from Larry Masinter. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------------------------------------------------------ To: ietf-types@iana.org Subject: Registration of MIME media type "application/ipp" MIME type name: application MIME subtype name: ipp A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.0, described in [IPP-MOD] and [IPP-PRO]. Required parameters: none Optional parameters: none Encoding considerations: IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths). Security considerations: IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in underlying transport protocols. Interoperability considerations: IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [IPP-MOD] and [IPP-PRO]. Protocol encoding rules specified in [IPP-PRO] are complete and unambiguous so interoperability between conforming implementations is ensured (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.0 attribute values of syntax "text" or "name" are explicit within IPP protocol requests/responses (without recourse to any external information in MIME, HTTP, or other message transport headers). Published specification: [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", work in progress , October 1997. [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner, "Internet Printing Protocol/1.0: Protocol Specification", work in progress , October 1997. Applications which use this media type: Internet Printing Protocol (IPP) print clients and print servers. Person & email address to contact for further information: Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 Email: scott_isaacson@novell.com or Robert Herriot Sun Microsystems Inc. 901 San Antonio Road, MPK-17 Palo Alto, CA 94303 Phone: 650-786-8995 Fax: 650-786-7077 Email: robert.herriot@eng.sun.com Intended usage: LIMITED USE ------------------------------------------------------------------------ From ipp-owner@pwg.org Fri Nov 21 13:19:51 1997 Delivery-Date: Fri, 21 Nov 1997 13:19:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA18319 for ; Fri, 21 Nov 1997 13:19:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21707 for ; Fri, 21 Nov 1997 13:22:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA26917 for ; Fri, 21 Nov 1997 13:19:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 13:15:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26326 for ipp-outgoing; Fri, 21 Nov 1997 13:15:02 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Tom Hastings'" , zhi-hong@zeno.com, ipp@pwg.org Subject: RE: IPP> Processing Algorithm Date: Fri, 21 Nov 1997 10:12:49 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org We agreed that the server would immediately send back an error response once it had determined an error condition. The server would not wait until the client delivered all of the current request. I believe most TCP/IP API services allow the client to detect input on a socket during successive "send" calls... Randy > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Friday, November 21, 1997 9:45 AM > To: zhi-hong@zeno.com; ipp@pwg.org > Subject: Re: IPP> Processing Algorithm > > At 09:03 11/21/1997 PST, Zhi-Hong Huang wrote: > >Scott Lawrence wrote: > > > >> I'm not entirely sure that I'm addressing the right concern here, > >> but... an HTTP/1.1 server can detect the end of an entity body in > >> any of three ways: a Content-Length header, Transfer-Encoding: > >> chunked, or a Multipart encoding that is self-descriptive. > >> > >> Did that answer your question? > > > >That should be fine if the server is required to consume > >all the client's data whether or not it decides to reject > >a request. > >One solution could be as follow: If the server rejects a > >request and will not further receive data from the client, > >it will close the connection. > > We have agreed that servers SHOULD issue a reject response to a client > > as soon as the server knows that it is going to reject the create > request > because of Operation or Job Template attributes supplied up front by > the > client, rather than waiting until the client has sent all of the > document > data which follows and which could be large. > > There seems to be two ways to avoid sending all of the document data > when the server rejects the create request: > > 1. The client gets the response and sees the reject, so the client > stops > sending the rest of the data. > > 2. The server sends the reject response and then close the connection, > forcing the client to stop sending the rest of the document data. > > Scheme 1 would allow the connection to stay open. > > Are both schemes feasible with HTTP/1.1? > > Can an HTTP/1.1 client accept a response while sending a (long) > request > on the same connection? > > Tom > > > > >Zhi-Hong Huang > >Zenographics, Inc. > > > > > > From ipp-owner@pwg.org Fri Nov 21 13:53:22 1997 Delivery-Date: Fri, 21 Nov 1997 13:53:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA18958 for ; Fri, 21 Nov 1997 13:53:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21870 for ; Fri, 21 Nov 1997 13:56:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27651 for ; Fri, 21 Nov 1997 13:53:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 13:48:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27099 for ipp-outgoing; Fri, 21 Nov 1997 13:48:33 -0500 (EST) Date: Fri, 21 Nov 1997 10:52:58 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711211852.AA03487@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> Re: Revision of Rationale Document Sender: ipp-owner@pwg.org Hi Steve, The text you sent out had EVERY line broken in half. It's pretty near unreadable. Tom Hastings offered just now (on the phone) to help you with MS Word to ASCII Text formatting problems (the Internet-Drafts editors will NOT accept a badly formed document - be careful of the 72 column line length restriction too. Cheers, - Ira McDonald 716-442-0609 (home in Rochester, NY until April 1998 w/ voice mail) PS - Your voice mail is still full and hangs up on all callers. From ipp-owner@pwg.org Fri Nov 21 16:10:18 1997 Delivery-Date: Fri, 21 Nov 1997 16:10:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21427 for ; Fri, 21 Nov 1997 16:10:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA22478 for ; Fri, 21 Nov 1997 16:13:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA29043 for ; Fri, 21 Nov 1997 16:09:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 16:04:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28475 for ipp-outgoing; Fri, 21 Nov 1997 16:04:13 -0500 (EST) Message-Id: <199711212103.NAA02743@bulletin> To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) cc: ipp@pwg.org Subject: Re: IPP> Re: Revision of Rationale Document In-reply-to: Your message of "Fri, 21 Nov 1997 10:52:58 PST." <9711211852.AA03487@snorkel.eso.mc.xerox.com> Date: Fri, 21 Nov 1997 13:03:33 PST From: "Steve Zilles" Sender: ipp-owner@pwg.org As Ira points out, the text I sent out had strange splits in it. As this was an already formatted text file (which the diff file as the second attachment clearly shows) it was Eudora that did it not the original file. I will try to avoid this problem in the ietf submission. Here is the raw text once again. INTERNET DRAFT Stephen N. Zilles Adobe Systems Inc. November 21, 1997 Expires: May 21, 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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 protocol allows a client 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 of 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 [IPP-MOD]) 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 [IPP-PRO]) 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 [IPP-PRO]) 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. Another part of the IPP architecture is the Directory Schema (described in the model document).. 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 [RFC1905, RFC1906] 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 [IPP-MOD] 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 allows the Model data to be aligned with the (abstract) model used in the Printer [RFC1759], 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 [RFC1905, RFC1906] and the Printer/Job MIBs. There is one aspect of the Model that deserves some extra explanation. There are two ways for identifying a Job object: (a) with a Job URI and (b) using a combination of the Printer URI and a Job ID (a 32 bit positive integer). Allowing Job objects to have URIs allows for flexibility and scalability. For example a job could be moved from a printer with a large backlog to one with a smaller load and the job identification, the Job object URI, need not change. However, many existing printing systems have local models or interface constraints that force Job objects to be identified using only a 32-bit positive integer rather than a URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. In order to allow both types of client access to Jobs (either by Job URI or bynumeric Job ID), when the Printer object successfully processes a create request and creates a new Job, the Printer object SHALL generate both a Job URI and a Job ID for the new Job object. This requirement allows all clients to access Printer objects and Job objects no matter the local constraints imposed on the client implementation. 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 sequences of attributes. Each attribute has a name, prefixed by a name length, and a value.. The names are strings constrained to characters from a subset of ASCII. The values are either scalars or a sequence of scalars. Each scalar value has a length specification and a value tag which indicates the type of the value. The value type has two parts: a major class part, such as integer or string, and a minor class part which distinguishes the usage of the major class, such as dateTime string. Tagging of the values with type information allows for introducing new value types at some future time. 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 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 is being 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, HELP information, 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 HTTP proxies and not the implementation of HTTP 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. HTTP implementations provide support for handling URLs that would have to be provided if a new protocol were defined. 6. An HTTP based solution fits well with the Internet security mechanism that are currently deployed or being deployed. HTTP will run over TLS/SSL. 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. 7. HTTP provides an extensibility model that a new protocol would have to develop independently. In particular, the headers, content-types (via Internet Media Types) and error codes have wide acceptance and a useful set of definitions and methods for extension. 8. Although not strictly a reason why IPP should use HTTP as the transmission protocol, it is extremely helpful that there are many prototyping tools that work with HTTP and that CGI scripts can be used to test and debug parts of the protocol. 9. Finally, the POST method was chosen to carry the print data because its usage for data transmission has been established, it works and the results are available via CGI scripts where that is relevant. Creating a new method would have better identified the intended use of the POSTed data, but a new method would be more difficult to deploy. Because there were no strong arguments for or against using a new method, the POST method was used. 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 TLS/SSL [TLS-PRO] secure communication mechanism. To provide access to both HTTP security and TLS security, IPP Printers provide two URLs for accessing the Printer object: one URL for which the scheme is HTTP for normal HTTP 1.1 access and one URL for which the scheme is HTTPS for access to the Printer using TLS/SSL protected communication. Two URLs are necessary because all allowed modes of TLS require some level of security beyond HTTP security so a TLS capable URL cannot be used to negotiate down to HTTP security. 7. COPYRIGHT This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. REFERENCES [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. [RFC1905] J. Case, et al. "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] J. Case, et al. "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [IPP-MOD] Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell, P, "Internet Printing Protocol/1.0: Model and Semantics" draft-ipp-mod-07.txt, November, 1997. [IPP-PRO] Herriot, R., Butler, S., Moore, P., Tuner, R., " Internet Printing Protocol/1.0: Protocol Specifications", draft-ipp-pro- 03.txt, November, 1997. [IPP-REQ] Wright, D., "Requirements for an Internet Printing Protocol", draft-ipp-req-01.txt, November, 1997. [TLS-PRO] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", , November, 1997 9. 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 From ipp-owner@pwg.org Fri Nov 21 16:42:09 1997 Delivery-Date: Fri, 21 Nov 1997 16:42:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22106 for ; Fri, 21 Nov 1997 16:42:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA22671 for ; Fri, 21 Nov 1997 16:45:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA29893 for ; Fri, 21 Nov 1997 16:42:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 16:36:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29336 for ipp-outgoing; Fri, 21 Nov 1997 16:36:32 -0500 (EST) Date: Fri, 21 Nov 1997 13:40:58 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711212140.AA03578@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, szilles@Adobe.COM Subject: Re: IPP> Re: Revision of Rationale Document Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Hi Steve, Thanks for the resend. Note that you STILL have 10 space characters at the front of every line (I used UNIX tool 'od -c | more' to make sure what I was seeing), so that the lines exceed the 72 column maximum in the IETF style guide (the RFC number escapes me at the moment). But now we can read the text. Thanks very much. Cheers, - Ira McDonald From ipp-owner@pwg.org Fri Nov 21 18:53:49 1997 Delivery-Date: Fri, 21 Nov 1997 18:53:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA24294 for ; Fri, 21 Nov 1997 18:53:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA23145 for ; Fri, 21 Nov 1997 18:56:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00737 for ; Fri, 21 Nov 1997 18:53:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 18:47:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00167 for ipp-outgoing; Fri, 21 Nov 1997 18:47:13 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Update on security text (forthcoming) Date: Fri, 21 Nov 1997 15:45:09 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I had a high priority interrupt yesterday that delayed my release of the new security text but it will go out early this evening (PST). I will send it to Scott and Bob but CC the main list. Randy From ipp-owner@pwg.org Fri Nov 21 21:37:56 1997 Delivery-Date: Fri, 21 Nov 1997 21:37:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25268 for ; Fri, 21 Nov 1997 21:37:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA23436 for ; Fri, 21 Nov 1997 21:40:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA01569 for ; Fri, 21 Nov 1997 21:37:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 21:31:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01001 for ipp-outgoing; Fri, 21 Nov 1997 21:31:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Model Document Security Text (PROPOSED) Date: Fri, 21 Nov 1997 18:29:21 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCF6AB.6350EE20" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BCF6AB.6350EE20 Content-Type: text/plain Please review the Word 2.x attachment for a proposed reformatting of the security considerations section of the model document. A subsequent mail message will contain an additional proposed wording for security considerations of the IPP-protocol document. Randy ------ =_NextPart_000_01BCF6AB.6350EE20 Content-Type: application/msword; name="ipp-mod-sec.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipp-mod-sec.doc" 26UtAAAACQQAAAAAAAAAAAAAAAAAAAAAgAEAAOkiAAAqKQAAAAAAAAAAAAAAAAAAAAAAAGkhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAA4AAAoAAA4ADgoAAAAADgoAAAAADgo AAAAADgoAAAAADgoAAAOAEYoAAAAAAAAAAAAAEYoAAAAAEYoAAAAAEYoAAAAAEYoAAAKAFAoAAAK AAAAAAAAAFooAABBAJwoAAAAAJwoAAAAAJwoAAAAAJwoAAAAAJwoAAAAAJwoAAAAAJwoAAAAAJwo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwoAAA0ANAoAABa ACopAAAAACopAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgATAAEAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQpQcm9wb3NlZCBDaGFu Z2VzIHRvIElQUCBNb2RlbCBEb2N1bWVudCBTZWN1cml0eSBTZWN0aW9ucw0KDQpbUHJvcG9zYWw6 IEkgd291bGQgbGlrZSB0byBtb3ZlIHNlY3Rpb24gOCAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMp IHRvIHNlY3Rpb24gMy41IGFuZCBvbmx5IGhhdmUgb25lICJTZWN1cml0eSBDb25zaWRlcmF0aW9u cyIgc2VjdGlvbiBpbiB0aGUgZG9jdW1lbnQuICBIYXZpbmcgdGhpcyBzZWN0aW9uIGVhcmxpZXIg aW4gdGhlIGRvY3VtZW50IHdvdWxkIGFsc28gbWFrZSBzZW5zZSBkdWUgdG8gdGhlIG51bWVyb3Vz IHBsYWNlcyBpbiB0aGUgcmVtYWluZGVyIG9mIHRoZSBkb2N1bWVudCB0aGF0LCBhdCB0aGUgbW9t ZW50LCAiZm9yd2FyZCIgcmVmZXJlbmNlcyBzZWN1cml0eSBkZXRhaWxzLiBUaGlzIHdvdWxkIG1h a2UgdGhlIG1vZGVsIGRvY3VtZW50IGVhc2llciB0byByZWFkLCB3aXRob3V0IHNjYXR0ZXJpbmcg c2VjdXJpdHkgaW5mb3JtYXRpb24gYWxsIG92ZXIgZGlmZmVyZW50IHBsYWNlcy4gVGhpcyBkb2N1 bWVudCBjb250YWlucyBwcm9wb3NlZCBjb250ZW50IGZvciB0aGUgY29tYmluZWQgc2VjdGlvboUu LmNvbW1lbnRzP10NCg0KW1Byb3Bvc2FsOiBBbHNvLCBJIHdvdWxkIGxpa2UgdG8gZWxpbWluYXRl IHRoZSBSRVFVSVJFTUVOVCB0aGF0IElQUCBvdmVyIEhUVFAgc3VwcG9ydCBSRkMgMjA2OSBvciBi YXNpYyBhdXRoZW50aWNhdGlvbi4gVGhpcyB3b3VsZCBiZSBrZWVwaW5nIG91ciBjdXJyZW50IHBo aWxvc29waHkgd2l0aCBpbXBsZW1lbnRhdGlvbnMgTk9UIHJlcXVpcmVkIHRvIGltcGxlbWVudCBz ZWN1cml0eV0NCg0KDQoNCg0KMy4xLjUJU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KSVBQIGlt cGxlbWVudGF0aW9ucyBjYW4gYmUgZXhwbGljaXRseSAic2VjdXJlIiBvciAibm9uLXNlY3VyZSIu IFdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRvY3VtZW50LCBhICJzZWN1cmUiIGltcGxlbWVu dGF0aW9uIGlzIG9uZSB0aGF0IHV0aWxpemVzIGEgdHJhbnNwb3J0IGxheWVyIHRoYXQgc3VwcG9y dHMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFZlcnNpb24gMS4wLiBBICJub24tc2Vj dXJlIiBpbXBsZW1lbnRhdGlvbiBtYXkgb3IgbWF5IG5vdCBzdXBwb3J0IHNlY3VyaXR5LiBBICJu b24tc2VjdXJlIiBpbXBsZW1lbnRhdGlvbiBNQVkgZWxlY3QgdG8gc3VwcG9ydCBhIHRyYW5zcG9y dCBsYXllciB0aGF0IHByb3ZpZGVzIGluaGVyZW50IHNlY3VyaXR5IG1lY2hhbmlzbXMgKHN1Y2gg YXMgSFRUUCkuIFNlY3VyZSBJUFAgaW1wbGVtZW50YXRpb25zIGFyZSBjYXBhYmxlIG9mIHN1cHBv cnRpbmcgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFzIHdlbGwgYXMgcHJpdmFjeSBvZiBtZXNzYWdl cyB2aWEgbXVsdGlwbGUgZW5jcnlwdGlvbiBzY2hlbWVzLg0KDQpJdCBpcyBkaWZmaWN1bHQgdG8g YW50aWNpcGF0ZSB0aGUgc2VjdXJpdHkgcmlza3MgdGhhdCBtaWdodCBleGlzdCBpbiBhbnkgZ2l2 ZW4gSVBQIGVudmlyb25tZW50LiBGb3IgZXhhbXBsZSwgaWYgSVBQIGlzIHVzZWQgd2l0aGluIGEg Z2l2ZW4gY29ycG9yYXRpb24gb3ZlciBhIHByaXZhdGUgbmV0d29yaywgdGhlIHJpc2tzIG9mIGV4 cG9zaW5nIGRvY3VtZW50IGRhdGEgbWF5IGJlIGxvdyBlbm91Z2ggdGhhdCB0aGUgY29ycG9yYXRp b24gd2lsbCBjaG9vc2Ugbm90IHRvIHVzZSBlbmNyeXB0aW9uIG9uIHRoYXQgZGF0YS4gIEhvd2V2 ZXIsIGlmIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIElQUCBvYmpl Y3QgaXMgb3ZlciBhIHB1YmxpYyBuZXR3b3JrLCB0aGUgY2xpZW50IG1heSB3aXNoIHRvIHByb3Rl Y3QgdGhlIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uIGR1cmluZyB0cmFuc21pc3Npb24gdGhy b3VnaCB0aGUgbmV0d29yayB3aXRoIGVuY3J5cHRpb24uDQoNCkZ1cnRoZXJtb3JlLCB0aGUgdmFs dWUgb2YgdGhlIGluZm9ybWF0aW9uIGJlaW5nIHByaW50ZWQgbWF5IHZhcnkgZnJvbSBvbmUgSVBQ IGVudmlyb25tZW50IHRvIHRoZSBuZXh0LiBQcmludGluZyBwYXlyb2xsIGNoZWNrcywgZm9yIGV4 YW1wbGUsIHdvdWxkIGhhdmUgYSBkaWZmZXJlbnQgdmFsdWUgdGhhbiBwcmludGluZyBwdWJsaWMg aW5mb3JtYXRpb24gZnJvbSBhIGZpbGUuICBUaGVyZSBpcyBhbHNvIHRoZSBwb3NzaWJseSBvZiBk ZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLCBidXQgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcyBh Z2FpbnN0IHByaW50aW5nIHJlc291cmNlcyBhcmUgbm90IHdlbGwgdW5kZXJzdG9vZCBhbmQgdGhl cmUgaXMgbm8gcHVibGlzaGVkIHByZWNlZGVudHMgcmVnYXJkaW5nIHRoaXMgc2NlbmFyaW8NCjMu MS41LjEgQXV0aGVudGljYXRlZCBDbGllbnRzDQoNCkFuIElQUCBzZXJ2ZXIgTUFZIHV0aWxpemUg VHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIHRoYXQsIGFtb25nIG90aGVyIHRoaW5ncywg c3VwcGxpZXMgdGhlIGNyZWRlbnRpYWxzIG9mIGEgY2xpZW50LiBPbmNlIHRoZSBhdXRoZW50aWNh dGVkIGlkZW50aXR5IG9mIHRoZSByZXF1ZXN0ZXIgaGFzIGJlZW4gc3VwcGxpZWQgdG8gdGhlIElQ UCBpbXBsZW1lbnRhdGlvbiwgdGhlIGltcGxlbWVudGF0aW9uIHVzZXMgdGhhdCBpZGVudGl0eSB0 byBlbmZvcmNlIGFueSBhdXRob3JpemF0aW9uIHBvbGljeSB0aGF0IG1pZ2h0IGJlIGluIHBsYWNl LiAgQW4gaW1wb3J0YW50IHBvaW50IGFib3V0IHNlY3VyaXR5IHJlbGF0ZWQgaW5mb3JtYXRpb24g aXMgdGhhdCwgZm9yIGEgInNlY3VyZSIgSVBQIHNlcnZlciwgdGhlIHNlY3VyaXR5LXJlbGF0ZWQg cGFyYW1ldGVycyAoYXV0aGVudGljYXRpb24sIGVuY3J5cHRpb24ga2V5cywgZXRjLikgYXJlICJv dXQtb2YtYmFuZCIgdG8gdGhlIGFjdHVhbCBJUFAgcHJvdG9jb2wuIER1cmluZyBhIGNyZWF0ZS1q b2Igb3BlcmF0aW9uLCB0aGUgY2xpZW50J3MgY3JlZGVudGlhbHMgYXJlIHJlY29yZGVkIGluIHRo ZSBKb2Igb2JqZWN0IGluIGFuIGltcGxlbWVudGF0aW9uLWRlZmluZWQgYXR0cmlidXRlLiBUaGlz IGluZm9ybWF0aW9uIGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBhIGNsaWVudCdzIGlkZW50aXR5IGZv ciBzdWJzZXF1ZW50IG9wZXJhdGlvbnMgb24gdGhhdCBKb2Igb2JqZWN0IGluIG9yZGVyIHRvIGVu Zm9yY2UgYW55IGFjY2VzcyBjb250cm9sIHBvbGljeSB0aGF0IG1pZ2h0IGJlIGluIGVmZmVjdC4g Rm9yIGV4YW1wbGUsIG9uZSBzaXRlJ3MgcG9saWN5IG1pZ2h0IGJlIHRoYXQgb25seSB0aGUgam9i IG93bmVyIGlzIGFsbG93ZWQgdG8gY2FuY2VsIGEgam9iLiBUaGVyZSBhcmUgb3BlcmF0aW9uIHN0 YXR1cyBjb2RlcyB0aGF0IGFsbG93IGFuIElQUCBzZXJ2ZXIgdG8gcmV0dXJuIGluZm9ybWF0aW9u IGJhY2sgdG8gYSBjbGllbnQgYWJvdXQgYW55IHBvdGVudGlhbCBhY2Nlc3MgY29udHJvbCB2aW9s YXRpb25zIGZvciBhbiBJUFAgb2JqZWN0Lg0KDQpUaGUgZGV0YWlscyBhbmQgbWVjaGFuaXNtcyB0 byBzZXQgdXAgYSBwYXJ0aWN1bGFyIGFjY2VzcyBjb250cm9sIHBvbGljeSBhcmUgbm90IHBhcnQg b2YgSVBQLzEuMCwgYW5kIG11c3QgYmUgZXN0YWJsaXNoZWQgdmlhIHNvbWUgb3RoZXIgdHlwZSBv ZiBhZG1pbmlzdHJhdGl2ZSBvciBhY2Nlc3MgY29udHJvbCBmcmFtZXdvcmsNCg0KU2luY2UgdGhl IHNlY3VyaXR5IGxldmVscyBvciB0aGUgc3BlY2lmaWMgdGhyZWF0cyB0aGF0IGFueSBnaXZlbiBJ UFAgc3lzdGVtIGFkbWluaXN0cmF0b3IgbWF5IGJlIGNvbmNlcm5lZCB3aXRoIGNhbm5vdCBiZSBh bnRpY2lwYXRlZCwgSVBQIE1VU1QgYmUgY2FwYWJsZSBvZiBvcGVyYXRpbmcgd2l0aCBkaWZmZXJl bnQgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbmQgc2VjdXJpdHkgcG9saWNpZXMgYXMgcmVxdWlyZWQg YnkgdGhlIGluZGl2aWR1YWwgaW5zdGFsbGF0aW9uLiBTZWN1cml0eSBwb2xpY2llcyBtaWdodCB2 YXJ5IGZyb20gdmVyeSBzdHJvbmcsIHRvIHZlcnkgd2VhaywgdG8gbm9uZSBhdCBhbGwsIGFuZCBj b3JyZXNwb25kaW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgd2lsbCBiZSByZXF1aXJlZC4gVExTIFZl cnNpb24gMS4wIHN1cHBvcnRzIHRoZSB0eXBlIG9mIG5lZ290aWF0ZWQgbGV2ZWxzIG9mIHNlY3Vy aXR5IHJlcXVpcmVkIGJ5IG1vc3QsIGlmIG5vdCBhbGwsIHBvdGVudGlhbCBJUFAgZW52aXJvbm1l bnRzLiBJUFAgZW52aXJvbm1lbnRzIHRoYXQgcmVxdWlyZSBubyBzZWN1cml0eSBjYW4gZWxlY3Qg dG8gZGVwbG95IElQUCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgdXRpbGl6ZSB0aGUgb3B0 aW9uYWwgVExTIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQoNClRoZSBmb2xsb3dpbmcgc2VjdGlvbnMg ZGVzY3JpYmUgc3BlY2lmaWMgc2VjdXJpdHkgYXR0YWNrcyBmb3IgSVBQIGVudmlyb25tZW50cy4g IFdoZXJlIGV4YW1wbGVzIGFyZSBwcm92aWRlZCB0aGV5IHNob3VsZCBiZSBjb25zaWRlcmVkIGls bHVzdHJhdGl2ZSBvZiB0aGUgZW52aXJvbm1lbnQgYW5kIG5vdCBhbiBleGhhdXN0aXZlIHNldC4g Tm90IGFsbCBvZiB0aGVzZSBlbnZpcm9ubWVudHMgd2lsbCBuZWNlc3NhcmlseSBiZSBhZGRyZXNz ZWQgaW4gaW5pdGlhbCBpbXBsZW1lbnRhdGlvbnMgb2YgSVBQLg0KDQoNCjMuMS41LjEgQ2xpZW50 IGFuZCBTZXJ2ZXIgaW4gdGhlIFNhbWUgU2VjdXJpdHkgRG9tYWluDQoNClRoaXMgZW52aXJvbm1l bnQgaXMgdHlwaWNhbCBvZiBpbnRlcm5hbCBuZXR3b3JrcyB3aGVyZSB0cmFkaXRpb25hbCBvZmZp Y2Ugd29ya2VycyBwcmludCB0aGUgb3V0cHV0IG9mIHBlcnNvbmFsIHByb2R1Y3Rpdml0eSBhcHBs aWNhdGlvbnMgb24gc2hhcmVkIHdvcmstZ3JvdXAgcHJpbnRlcnMsIG9yIHdoZXJlIGJhdGNoIGFw cGxpY2F0aW9ucyBwcmludCB0aGVpciBvdXRwdXQgb24gbGFyZ2UgcHJvZHVjdGlvbiBwcmludGVy cy4gQWx0aG91Z2ggdGhlIGlkZW50aXR5IG9mIHRoZSB1c2VyIG1heSBiZSB0cnVzdGVkIGluIHRo aXMgZW52aXJvbm1lbnQsIGEgdXNlciBtaWdodCB3YW50IHRvIHByb3RlY3QgdGhlIGNvbnRlbnQg b2YgYSBkb2N1bWVudCBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBhcyBlYXZlc2Ryb3BwaW5nLCByZXBs YXlpbmcgb3IgdGFtcGVyaW5nLg0KDQozLjEuNS4yIENsaWVudCBhbmQgU2VydmVyIGluIERpZmZl cmVudCBTZWN1cml0eSBEb21haW5zDQoNCkV4YW1wbGVzIG9mIHRoaXMgZW52aXJvbm1lbnQgaW5j bHVkZSBwcmludGluZyBhIGRvY3VtZW50IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCBvbiBhIHB1Ymxp Y2x5IGF2YWlsYWJsZSBwcmludGVyLCBzdWNoIGFzIGF0IGEgY29tbWVyY2lhbCBwcmludCBzaG9w OyBvciBwcmludGluZyBhIGRvY3VtZW50IHJlbW90ZWx5IG9uIGEgYnVzaW5lc3MgYXNzb2NpYXRl cydzIHByaW50ZXIuIFRoaXMgbGF0dGVyIG9wZXJhdGlvbiBpcyBmdW5jdGlvbmFsbHkgZXF1aXZh bGVudCB0byBzZW5kaW5nIHRoZSBkb2N1bWVudCB0byB0aGUgYnVzaW5lc3MgYXNzb2NpYXRlIGFz IGEgZmFjc2ltaWxlLiBQcmludGluZyBzZW5zaXRpdmUgaW5mb3JtYXRpb24gb24gYSBQcmludGVy IGluIGEgZGlmZmVyZW50IHNlY3VyaXR5IGRvbWFpbiByZXF1aXJlcyBzdHJvbmcgc2VjdXJpdHkg bWVhc3VyZXMuIEluIHRoaXMgZW52aXJvbm1lbnQgYXV0aGVudGljYXRpb24gb2YgdGhlIHByaW50 ZXIgaXMgcmVxdWlyZWQgYXMgd2VsbCBhcyBwcm90ZWN0aW9uIGFnYWluc3QgdW5hdXRob3JpemVk IHVzZSBvZiBwcmludCByZXNvdXJjZXMuIFNpbmNlIHRoZSBkb2N1bWVudCBjcm9zc2VzIHNlY3Vy aXR5IGRvbWFpbnMsIHByb3RlY3Rpb24gYWdhaW5zdCBlYXZlc2Ryb3BwaW5nIGFuZCBkb2N1bWVu dCB0YW1wZXJpbmcgYXJlIGFsc28gcmVxdWlyZWQuIEl0IHdpbGwgYWxzbyBiZSBpbXBvcnRhbnQg aW4gdGhpcyBlbnZpcm9ubWVudCB0byBwcm90ZWN0IFByaW50ZXJzIGFnYWluc3QgInNwYW1taW5n IiBhbmQgbWFsaWNpb3VzIGRvY3VtZW50IGNvbnRlbnQuDQoNCjMuMS41LjMgUHJpbnQgYnkgUmVm ZXJlbmNlDQoNCldoZW4gdGhlIGRvY3VtZW50IGlzIG5vdCBzdG9yZWQgb24gdGhlIGNsaWVudCwg cHJpbnRpbmcgY2FuIGJlIGRvbmUgYnkgcmVmZXJlbmNlLiBUaGF0IGlzLCB0aGUgcHJpbnQgcmVx dWVzdCBjYW4gY29udGFpbiBhIHJlZmVyZW5jZSwgb3IgcG9pbnRlciwgdG8gdGhlIGRvY3VtZW50 IGluc3RlYWQgb2YgdGhlIGFjdHVhbCBkb2N1bWVudCBpdHNlbGYuIFN0YW5kYXJkIG1ldGhvZHMg Y3VycmVudGx5IGRvIG5vdCBleGlzdCBmb3IgcmVtb3RlIGVudGl0aWVzIHRvICJhc3N1bWUiIHRo ZSBjcmVkZW50aWFscyBvZiBhIGNsaWVudCBmb3IgZm9yd2FyZGluZyByZXF1ZXN0cyB0byBhIDNy ZCBwYXJ0eS4gSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCBQcmludC1CeS1SZWZlcmVuY2Ugd2lsbCBi ZSB1c2VkIHRvIGFjY2VzcyAicHVibGljIiBkb2N1bWVudHMgYW5kIHRoYXQgc29waGlzdGljYXRl ZCBtZXRob2RzIGZvciBhdXRoZW50aWNhdGluZyAicHJveGllcyIgd2lsbCBub3QgYmUgcmVxdWly ZWQgZm9yIHZlcnNpb24gMSBvZiBJUFAuDQoNCg0KDQozLjEuNS40IFRoZSAicmVxdWVzdGluZy11 c2VyLW5hbWUiIE9wZXJhdGlvbiBBdHRyaWJ1dGUNCg0KQW4gSVBQIHNlcnZlciBTSEFMTCBzdXBw b3J0IHRoZSBNQU5EQVRPUlkgInJlcXVlc3RpbmctdXNlci1uYW1lIiBvcGVyYXRpb24gYXR0cmli dXRlLiBUaGUgY2xpZW50IFNIT1VMRCBpbmNsdWRlIHRoaXMgYXR0cmlidXRlIGluIGFsbCBhcHBy b3ByaWF0ZSBJUFAgb3BlcmF0aW9ucy4gTm9uLXNlY3VyZSBJUFAgc2VydmVycyBNQVkgdXNlIHRo ZSByZXF1ZXN0aW5nLXVzZXItbmFtZSBhdHRyaWJ1dGUgdG8gYXBwbHkgc2ltcGxlIGFjY2VzcyBj b250cm9sIGZvciBJUFAgb3BlcmF0aW9ucy4gQW4gSVBQIGNsaWVudCBpbXBsZW1lbnRhdGlvbiBT SEFMTCBvYnRhaW4gdGhlIHZhbHVlIGZvciB0aGlzIGF0dHJpYnV0ZSBmcm9tIGFuIGVudmlyb25t ZW50YWwgb3IgbmV0d29yayBsb2dpbiBuYW1lIGZvciB0aGUgdXNlciwgcmF0aGVyIHRoYW4gYWxs b3dpbmcgdGhlIHVzZXIgdG8gc3VwcGx5IGFueSB2YWx1ZSB0aHJvdWdoIGEgdXNlciBpbnRlcmZh Y2UgbWVjaGFuaXNtLiANCg0KRm9yIGNyZWF0ZS1qb2IgcmVxdWVzdHMgdGhlIFByaW50ZXIgb2Jq ZWN0LCB1cG9uIGNyZWF0aW5nIGEgbmV3IEpvYiBvYmplY3QsIFNIQUxMIHN0b3JlIHRoZSBvcmln aW5hdGluZyB1c2VyJ3MgbmFtZSBpbiB0aGUgTUFOREFUT1JZICJqb2Igb3JpZ2luYXRpbmctdXNl ci1uYW1lIiBKb2IgRGVzY3JpcHRpb24gYXR0cmlidXRlLiAgVGhlICJqb2Itb3JpZ2luYXRpbmct dXNlci1uYW1lIiBhdHRyaWJ1dGUgaXMgdXNlZCBmb3IgcHJlc2VudGF0aW9uIG9ubHksIHN1Y2gg YXMgcmV0dXJuaW5nIGluIHF1ZXJpZXMgb3IgcHJpbnRpbmcgb24gam9iIHNlcGFyYXRvciBwYWdl cy4gSWYgbm8gdHJhbnNwb3J0IGxheWVyIHNlY3VyaXR5IGV4aXN0cywgbm9uLXNlY3VyZSBJUFAg c2VydmVycyBNQVkgdXRpbGl6ZSB0aGUgIm9yaWdpbmF0aW5nLXVzZXItbmFtZSIgYW5kICJyZXF1 ZXN0aW5nLXVzZXItbmFtZSIgdG8gZW5hYmxlIHNpbXBsZSBhY2Nlc3MgY29udHJvbCB0byBJUFAg b2JqZWN0cy4gSWYgc29tZSB0eXBlIG9mIHRyYW5zcG9ydCBsYXllciBhdXRoZW50aWNhdGlvbiBp cyBhdmFpbGFibGUsIHRoZW4gdHJhbnNwb3J0IGxheWVyIGF1dGhlbnRpY2F0aW9uIE1VU1QgYmUg dXNlZC4gVHJhbnNwb3J0IGxheWVyIGF1dGhlbnRpY2F0aW9uIGNhbiBiZSBwcm92aWRlZCBieSBh IGZ1bGx5IHNlY3VyZSBUTFMgSVBQIGltcGxlbWVudGF0aW9uLCBvciB0aHJvdWdoIHNvbWUgbm9u LUlQUCBzdGFuZGFyZCBmb3JtIG9mIHRyYW5zcG9ydCBhdXRoZW50aWNhdGlvbiBwcm92aWRlZCBi eSBwcm90b2NvbHMgc3VjaCBhcyBIVFRQIDEuMS4NCg0KMy4xLjUuNSBSZXN0cmljdGVkIFF1ZXJp ZXMNCg0KSW4gbWFueSBJUFAgb3BlcmF0aW9ucywgYSBjbGllbnQgc3VwcGxpZXMgYSBsaXN0IG9m IGF0dHJpYnV0ZXMgdG8gYmUgcmV0dXJuZWQgaW4gdGhlIHJlc3BvbnNlLiAgRm9yIHNlY3VyaXR5 IHJlYXNvbnMsIGFuIElQUCBvYmplY3QgbWF5IGJlIGNvbmZpZ3VyZWQgbm90IHRvIHJldHVybiBh bGwgYXR0cmlidXRlcyB0aGF0IGEgY2xpZW50IHJlcXVlc3RzLiAgVGhlIGpvYiBhdHRyaWJ1dGVz IHJldHVybmVkIE1BWSBkZXBlbmQgb24gd2hldGhlciB0aGUgcmVxdWVzdGluZyB1c2VyIGlzIHRo ZSBzYW1lIGFzIHRoZSB1c2VyIHRoYXQgc3VibWl0dGVkIHRoZSBqb2IuIFRoZSBJUFAgb2JqZWN0 IE1BWSBldmVuIHJldHVybiBub25lIG9mIHRoZSByZXF1ZXN0ZWQgYXR0cmlidXRlcy4gSW4gc3Vj aCBjYXNlcywgdGhlIHN0YXR1cyByZXR1cm5lZCBpcyB0aGUgc2FtZSBhcyBpZiB0aGUgb2JqZWN0 IGhhZCByZXR1cm5lZCBhbGwgcmVxdWVzdGVkIGF0dHJpYnV0ZXMuICBUaGUgY2xpZW50IGNhbm5v dCB0ZWxsIGJ5IHN1Y2ggYSByZXNwb25zZSB3aGV0aGVyIHRoZSByZXF1ZXN0ZWQgYXR0cmlidXRl IHdhcyBwcmVzZW50IG9yIGFic2VudCBvbiB0aGUgb2JqZWN0Lg0KDQoNCg0KA4gBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIIBAAC8AQAAvwQAAN4E AADgBAAArAoAAK4KAADNCgAAzwoAAEUaAABHGgAA4yIAAOkiAAAAAAD8APkA9gDz7eoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAgAE CwAAFgAEABAAAAAKBQAAAgAEBQAAAgAEBQAAAgAEBQAAAgAEAA2AAQAAggEAALwBAAC+AQAA1gMA ANgDAAC3BAAAuQQAALsEAAC9BAAAvwQAAN4EAADgBAAACwcAAA0HAAALCQAADQkAAK4KAADNCgAA zwoAAAYPAAAIDwAAxA8AAMYPAABiEgAAZBIAAIYTAACIEwAAihMAAMETAADDEwAAdRUAAHcVAACw FQAAshUAANoYAADcGAAA+BgAAPoYAAALGwAADRsAAA8bAAARGwAASRsAAEsbAAA7HQAAPR0AAGgg AABqIAAAhiAAAIggAADjIgAA5SIAAOciAADpIgAAAPsAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAAAAAAAAAA8FAAHQAgAR0AITMP0ABP4AAAAAAAAANgIABQAA/wAUAAEB/w4AAEYAAwAU AAAAAAAJBBUACf4AAAAAAAAIAf8HAAAAAAAAAAMAAAAAAADeAAAAAGkhAAAAAOkiAACAAQAA6SIA ABIAgAEAAOkiAAATAEEAChAAVG1zIFJtbgAJYABTeW1ib2wAByAASGVsdgASEABUaW1lcyBOZXcg Um9tYW4ADjAAQ291cmllciBOZXcAACIAAgADAwAAAADQAgAAAAAAAAAAo6wbBqOsGwYAAAAAAgAA AAAAAwAAAMwEAABbGwAAAABaAAAAOFByb3Bvc2VkIENoYW5nZXMgdG8gSVBQIE1vZGVsIERvY3Vt ZW50IFNlY3VyaXR5IFNlY3Rpb25zAAAADFJhbmR5IFR1cm5lcgxSYW5keSBUdXJuZXIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------ =_NextPart_000_01BCF6AB.6350EE20-- From ipp-owner@pwg.org Fri Nov 21 21:52:41 1997 Delivery-Date: Fri, 21 Nov 1997 21:52:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25313 for ; Fri, 21 Nov 1997 21:52:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA23455 for ; Fri, 21 Nov 1997 21:55:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA02218 for ; Fri, 21 Nov 1997 21:52:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 21:47:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01674 for ipp-outgoing; Fri, 21 Nov 1997 21:47:30 -0500 (EST) Message-Id: <3.0.1.32.19971121185107.00b2e810@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Nov 1997 18:51:07 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO latest LPD document at PWG site and sent to IETF [.pdf files] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've loaded the .pdf files: ipp-lpd-971120-rev-red.pdf ipp-lpd-971120-rev-black.pdf ipp-lpd-971120.pdf Tom >Date: Thu, 20 Nov 1997 16:03:09 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO latest LPD document at PWG site and sent to IETF >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I have just downloaded the latest update to the LPD document. > >The documents are in: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > >The files are: > > ipp-lpd-971120-rev.doc The MS-Word 6.0 with revision marks > ipp-lpd-971120.doc The MS-Word 6.0 with no revision marks > ipp-lpd-971120.txt The text document sent to the IETF as > draft-ietf-ipp-lpd-ipp-map-02.txt > > > From ipp-owner@pwg.org Fri Nov 21 22:47:15 1997 Delivery-Date: Fri, 21 Nov 1997 22:47:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA27552 for ; Fri, 21 Nov 1997 22:47:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA23537 for ; Fri, 21 Nov 1997 22:50:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA02943 for ; Fri, 21 Nov 1997 22:47:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 22:41:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02392 for ipp-outgoing; Fri, 21 Nov 1997 22:41:48 -0500 (EST) Message-Id: <3.0.1.32.19971121194526.00b2ade0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Nov 1997 19:45:26 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Proposed Minimums and Maximums for IPP attribute syntaxes Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id WAA27552 Subj: Proposed Minimums and Maximums for IPP attribute syntaxes. From: Tom Hastings Date: 10/20/97 File: ipp-min-max.doc I was given an action item to propose: 1. maximums for those IPP attribute syntaxes that don't have maximum octet lengths 2. revisit the maximum length of the 'text' attribute syntax which is 4095 octets 3. minimums for those attributes that are read-only in IPP/1.0. >From the minutes of the 11/19/97 telecon: 1. Discussion about length boundaries for text strings (from recent DL discussion) Everybody seemed to agree that we want to have maximum lengths for all attribute syntaxes (see section 4.1 in the Model document), including the 'uri' attribute syntax, even if HTTP has not set such limits (pointed out by Larry Masinter). We have to make it explicit what the lengths mean and whether they apply to server, client or both. We reaffirmed that IPP is intended to be implemented by low-end printers that don't spool, as well as devices and servers that do spool. Therefore, these length conformance requirements need to be carefully reviewed as part of the WG last call. We reaffirmed that the maximums for read-write attributes required a conforming IPP object to support the full maximum length without truncation. There was concern that the current maximum for the 'text' attribute syntax of 4095 octets was too large. A maximum of 1023 was suggested, but no consensus was reached. The only read-write 'text' attribute is the 'message' Operation attribute in the Cancel- Job operation. However, since this Operation attribute is OPTIONAL for an IPP object to support, a conforming IPP object SHALL ignore the attribute if it is not supported. But the IPP object SHALL accept the maximum length without truncation if the "message" attribute is supported. There was also agreement that the maximum length for read- only attributes NEED NOT be supported by conforming IPP objects. Read-only attributes are ones set by the implementation and/or the system administrator when configuring the system. The entire list is: "status- message" OPTIONALLY returned in a response, "job-state- message", "job-message-from-operator", "printer-location", "printer-info", "printer-make-and-model", and "printer-state- message". Support for all of these read-only attributes is OPTIONAL for as IPP object. However, when they are supported, we agreed that the Model document needs to agree on minimums that MUST be supported for these read-only attributes. It was suggested that the minimums should agree with the Job Monitoring MIB. ACTION ITEM: Tom to draft a proposal for the maximums for those attribute syntaxes that don't have a maximum and for minimums for all attribute syntaxes discussion on the DL as part of the last call comments. 2. Strategy Lets make the minimums for read-only be the same as the Job Monitoring MIB minimum/maximum, which is 63 octets for the jmAttributesAsOctets object. Then there is no loss when using the Job Monitoring MIB for an implementation that supports the minimum for IPP for read-only attributes. There will still be loss for read-write objects when using the Job Monitoring MIB, but the only read-write 'text' attribute is the OPTIONAL "message" Operation attribute in the Cancel-Job operation and that attributes isn't stored on the job object, so an application can't read it with the Job Monitoring MIB anyway. The Job Monitoring MIB (incorrectly) specifies that the jobURI(20) attribute is 255 octets long. But its contained in a jmAttributeAsOctets object which is only 63 octets long. So lets make the JMP jobURI(20) a MULTI VALUEE attribute in which each piece is the next 63 octets of the URI up to 1023 octets which is the minimum for read-only that I propose below for IPP. 3. Proposed Maximum octet lengths The following table show the current maximum, and the proposed maximum. For read-write attributes the maximum is also the minimum. For read-only attributes the proposed minimum is also shown. Name Current Proposed Proposed min/max octets min/max min for for read-write for read- read- and read-only write only 'text' 4095 1023 63 'name' 255 255 63 'keyword' 255 255 63 'enum' 4 (protocol 4 4 doc) 'uri' - 1023 1023 'uriScheme' - 63 63 'charset' - 63 63 'naturalLanguage - 63 63 ' 'mimeMediaType' - 63 63 'octetString' 4095 1023 63 'boolean' 1 (protocol 1 1 doc) 'integer' 4 (protocol 4 4 doc) 'rangeOfInteger' 8 (protocol 8 8 doc) 'dateTime' 11 11 11 'resolution' 9 9 9 '1setOf X' … From ipp-owner@pwg.org Fri Nov 21 22:54:25 1997 Delivery-Date: Fri, 21 Nov 1997 22:54:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA27628 for ; Fri, 21 Nov 1997 22:54:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA23550 for ; Fri, 21 Nov 1997 22:57:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA03591 for ; Fri, 21 Nov 1997 22:54:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 22:49:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA03030 for ipp-outgoing; Fri, 21 Nov 1997 22:49:23 -0500 (EST) Date: Fri, 21 Nov 1997 19:48:44 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711220348.TAA24472@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: IPP>MOD add another issue X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org As I am implementing the CompoundValue, I am finding problems that make me think it should be changed. It requires too much special-casing and in its current form it will introduce bugs where the value of the CompoundValue exceeds the number of remaining attributes for the attribute name or attribute group. To avoid those bugs, checks have to be made in several places. I suggest we reexamine the other possible solutions, one simple with no room for extension, the other with room for extension. a) add two new value types: text-language and name-language each of which is a single value in the protocol but which consists of 4 subfields: a text/name length field, a text/name field, a language length field, and a language field, . b) add a single new type: compound-value which consists of a single value in the protocol but which consists of a value-tag field followed by any number of groups-of-three subfields. Each group-of-three consists of a value tag, a value length and a value. The text-language solution of a) is represented by a text-language tag, a text tag, a text length, a text value, a natural-language-tag, a natural-language length and a natural-language value. I prefer b) because it offers room for extension and an implementation can determine if it supports the compound value by examining the initial tag in the compoundValue. From daemon Sat Nov 22 09:59:59 1997 Delivery-Date: Sat, 22 Nov 1997 10:05:29 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA05455 for ietf-123-outbound.10@ietf.org; Sat, 22 Nov 1997 09:59:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA05410; Sat, 22 Nov 1997 09:59:35 -0500 (EST) Message-Id: <199711221459.JAA05410@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-loss-01.txt Date: Sat, 22 Nov 1997 09:59:34 -0500 Sender: scoya@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Packet Loss Metric for IPPM Author(s) : G. Almes, S. Kalidindi Filename : draft-ietf-ippm-loss-01.txt Pages : 10 Date : 21-Nov-97 This memo defines a metric for packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework doc- ument (currently ''Framework for IP Performance Metrics'' ); the reader is assumed to be familiar with that document. This memo is intended to be very parallel in structure to a companion document for One-way Delay (currently ''A One-way Delay Metric for IPPM'' ); the reader is assumed to be familiar with that document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-loss-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippm-loss-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-loss-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971122092605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-loss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-loss-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971122092605.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Sat Nov 22 09:59:36 1997 Delivery-Date: Sat, 22 Nov 1997 10:05:32 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA05364 for ietf-123-outbound.10@ietf.org; Sat, 22 Nov 1997 09:59:12 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA05337; Sat, 22 Nov 1997 09:59:06 -0500 (EST) Message-Id: <199711221459.JAA05337@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-delay-01.txt Date: Sat, 22 Nov 1997 09:59:04 -0500 Sender: scoya@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-way Delay Metric for IPPM Author(s) : G. Almes, S. Kalidindi Filename : draft-ietf-ippm-delay-01.txt Pages : 12 Date : 21-Nov-97 This memo defines a metric for one-way delay of packets across Inter- net paths. It builds on notions introduced and discussed in the IPPM Framework document (currently ''Framework for IP Performance Metrics'' ); the reader is assumed to be familiar with that document. This memo is intended to be very parallel in structure to a companion document for Packet Loss (''A Packet Loss Metric for IPPM'' ). 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-ippm-delay-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippm-delay-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-delay-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971122092550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-delay-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-delay-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971122092550.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Sat Nov 22 10:01:20 1997 Delivery-Date: Sat, 22 Nov 1997 10:06:48 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA05565 for ietf-123-outbound.10@ietf.org; Sat, 22 Nov 1997 10:01:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA05531; Sat, 22 Nov 1997 10:01:02 -0500 (EST) Message-Id: <199711221501.KAA05531@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-framework-01.txt Date: Sat, 22 Nov 1997 10:01:01 -0500 Sender: scoya@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Framework for IP Performance Metrics Author(s) : G. Almes, M. Mathis, J. Mahdavi, V. Paxson Filename : draft-ietf-ippm-framework-01.txt Pages : 36 Date : 21-Nov-97 The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Performance Metrics Working Group (IPPM) of the Transport Area. 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-ippm-framework-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippm-framework-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-framework-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971122092621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-framework-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971122092621.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Sat Nov 22 22:17:50 1997 Delivery-Date: Sat, 22 Nov 1997 22:17:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA14375 for ; Sat, 22 Nov 1997 22:17:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA25370 for ; Sat, 22 Nov 1997 22:20:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA12347 for ; Sat, 22 Nov 1997 22:17:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 22 Nov 1997 22:09:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA11759 for ipp-outgoing; Sat, 22 Nov 1997 21:57:15 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Security text for IPP protocol doc (PROPOSED) Date: Sat, 22 Nov 1997 18:55:07 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCF778.27D025A0" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BCF778.27D025A0 Content-Type: text/plain Please review the attached Word 2.x file for proposed "Security Considerations" section of the IPP Protocol document. Randy ------ =_NextPart_000_01BCF778.27D025A0 Content-Type: application/msword; name="ipp-pro-sec.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipp-pro-sec.doc" 26UtAAAACQQAAAAAAAAAAAAAAAAAAAAAgAEAAJUKAADfEAAAAAAAAAAAAAAAAAAAAAAAABUJAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAkAAAQAAAkACQQAAAAACQQAAAAACQQ AAAAACQQAAAAACQQAAAOADIQAAAAAAAAAAAAADIQAAAAADIQAAAAADIQAAAAADIQAAAKADwQAAAK AAAAAAAAAEYQAABBAIgQAAAAAIgQAAAAAIgQAAAAAIgQAAAAAIgQAAAAAIgQAAAAAIgQAAAAAIgQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgQAAA0ALwQAAAj AN8QAAAAAN8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAHAAEAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANS4gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCg0KVGhlIElQUCBNb2RlbCBkb2N1bWVudCBkZWZpbmVzIGEgInNlY3VyZSIg SVBQIGltcGxlbWVudGF0aW9uIGFzIG9uZSB0aGF0IGltcGxlbWVudHMgVHJhbnNwb3J0IExheWVy IFNlY3VyaXR5IChUTFMpIFZlcnNpb24gMS4wLiBUTFMgbWVldHMgdGhlIHJlcXVpcmVtZW50cyBm b3IgSVBQIHNlY3VyaXR5IHdpdGggcmVnYXJkcyB0byBmZWF0dXJlcyBzdWNoIGFzIG11dHVhbCBh dXRoZW50aWNhdGlvbiBhbmQgcHJpdmFjeSAodmlhIGVuY3J5cHRpb24pLiBUaGUgSVBQIE1vZGVs IGRvY3VtZW50IGFsc28gb3V0bGluZXMgSVBQLXNwZWNpZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGFuZCBzaG91bGQgYmUgdGhlIHByaW1hcnkgcmVmZXJlbmNlIGZvciBzZWN1cml0eSBpbXBs aWNhdGlvbnMgd2l0aCByZWdhcmRzIHRvIHRoZQ0KSVBQIHByb3RvY29sIGl0c2VsZi4NCg0KVGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgc3RhbmRhcmQgd2F5IGZvciB0cmFuc3BvcnRpbmcgSVBQIG1l c3NhZ2VzIHdpdGhpbiBIVFRQIDEuMSwgYW5kIGFzIGEgcmVzdWx0LCB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgb3V0bGluZWQgaW4gdGhlIEhUVFAgMS4xIHN0YW5kYXJkIGRvY3VtZW50IFtS RkMyMDY4XSBhcHBseSB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0K DQpIVFRQIDEuMSBpbmNsdWRlcyBzaW1wbGUgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGF1dGhlbnRp Y2F0aW9uIGNoYWxsZW5nZXMgZm9yIHdoaWNoIElQUCBzZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0LCBh bmQgZm9yIHdoaWNoIElQUCBjbGllbnRzIFNIT1VMRCBiZSBwcmVwYXJlZCB0byBhbnN3ZXIuIEhv d2V2ZXIsIHdpdGhpbiBIVFRQIG1lc3NhZ2VzLCB0aGlzICJiYXNpYyIgYXV0aGVudGljYXRpb24g YWxsb3dzIHRoZSB1c2VyJ3MgY3JlZGVudGlhbHMgdG8gYmUgcGFzc2VkIGFzIGNsZWFyLCBodW1h bi1yZWFkYWJsZSB0ZXh0IHN0cmluZ3MuIFRoZXJlZm9yZSwgc29tZSBhbmFseXNpcyBvZiB0aGUg ZGVzaWduYXRlZCBJUFAgbmV0d29yayBlbnZpcm9ubWVudCAoYm90aCBwaHlzaWNhbCBhbmQgbG9n aWNhbCkgc2hvdWxkIGJlIHBlcmZvcm1lZCBiZWZvcmUgZGVwbG95aW5nIElQUCBzZXJ2aWNlcyB1 c2luZyBIVFRQICJiYXNpYyIgYXV0aGVudGljYXRpb24uDQoNCkRpZ2VzdCBBdXRoZW50aWNhdGlv biBbUkZDMjA2OV0gaXMgYW4gZXh0ZW5zaW9uIHRvIEhUVFAgMS4xIHRoYXQgZG9lcyBub3QgZW1w bG95IGNsZWFyIHRleHQgY3JlZGVudGlhbHMsIGJ1dCBpbnN0ZWFkIHV0aWxpemVzIGEgbW9yZSBy b2J1c3QgZm9ybSBvZiBhdXRoZW50aWNhdGlvbiB2aWEgTUQ1IFtSRUZdIGRpZ2VzdCBjYWxjdWxh dGlvbnMuIElQUCBjbGllbnQgYW5kIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHN1cHBv cnQgZGlnZXN0IGF1dGhlbnRpY2F0aW9uLg0KDQpUaGUgY3VycmVudCBIVFRQIGluZnJhc3RydWN0 dXJlIHN1cHBvcnRzIEhUVFAgb3ZlciBUQ1AgcG9ydCA4MC4gSVBQIHNlcnZlcnMgTVVTVCBvZmZl ciBJUFAgc2VydmljZXMgdXNpbmcgSFRUUCBvdmVyIHRoaXMgcG9ydC4gSVBQIHNlcnZlcnMgYXJl IGZyZWUgdG8gYWR2ZXJ0aXNlIHNlcnZpY2VzIG92ZXIgb3RoZXIgcG9ydHMsIGluIGFkZGl0aW9u IHRvIHRoaXMgcG9ydCwgYnV0IFRDUCBwb3J0IDgwIE1VU1QgbWluaW1hbGx5IGJlIHN1cHBvcnRl ZCBmb3IgSVBQLW92ZXItSFRUUCBzZXJ2aWNlcy4NCg0KV2hlbiAic2VjdXJlIiBJUFAtb3Zlci1I VFRQIGltcGxlbWVudGF0aW9ucyBhcmUgZGVwbG95ZWQsIHRoZXNlIHNlY3VyZSBJUFAgaW1wbGVt ZW50YXRpb25zIE1VU1QgdXNlIFRDUCBwb3J0IDQ0My4gU2VjdXJlIElQUC1vdmVyLUhUVFAgc2Vy dmVycyBNVVNUIGFkdmVydGlzZSB0aGVpciBzZWN1cmUgSVBQIHNlcnZpY2UgVVJJIHVzaW5nIGFu ICJIVFRQUyIgVVJJIHNjaGVtZS4NCg0KTm90ZSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIHRoYXQg dXRpbGl6ZXMgYm90aCBIVFRQIGJhc2ljIGFuZCBkaWdlc3QgYXV0aGVudGljYXRpb24gaXMgbm90 IGNvbnNpZGVyZWQgInNlY3VyZSIgYnkgdGhlIHN0cmljdCBJUFAgTW9kZWwgZG9jdW1lbnQgZGVm aW5pdGlvbi4gVG8gcHJvdmlkZSBhIHNlY3VyZSBIVFRQIHRyYW5zcG9ydCBmb3IgSVBQLCB0aGUg SFRUUCBpbXBsZW1lbnRhdGlvbiBNVVNUIHByb3ZpZGUgc3VwcG9ydCBmb3IgVExTIDEuMC4NCg0K U2VlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiBJUFAgc2VjdXJpdHkgY29uY2VwdHMgaW4gdGhlIG1v ZGVsIGRvY3VtZW50DQpbaXBwLW1vZF0uDQoNCg0KBX4AiAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAJMK AACVCgAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAgAEAAKAAQAAnAEA AJ4BAAA8AwAAUgMAAFQDAAA7BAAAPQQAACYGAAAoBgAAOwcAAD0HAABcCAAAXggAADcJAAA5CQAA PAoAAD4KAACFCgAAkQoAAJMKAACVCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAAAwAAEQAO AABGAAMAFAAAAAAACQQKAAcAAAAAAAAAAQAA3gAAAAAVCQAAAACVCgAAgAEAAJUKAAAGAIABAACV CgAABwBBAAoQAFRtcyBSbW4ACWAAU3ltYm9sAAcgAEhlbHYAEhAAVGltZXMgTmV3IFJvbWFuAA4w AENvdXJpZXIgTmV3AAAiAAIAAwMAAAAA0AIAAAAAAAAAALO0GwaztBsGAAAAAAIAAQAAAAEAAABN AQAAawcAAAAAIwAAAAE1AAAADFJhbmR5IFR1cm5lcgxSYW5keSBUdXJuZXIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------ =_NextPart_000_01BCF778.27D025A0-- From ipp-owner@pwg.org Mon Nov 24 10:40:12 1997 Delivery-Date: Mon, 24 Nov 1997 10:40:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15232 for ; Mon, 24 Nov 1997 10:40:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02534 for ; Mon, 24 Nov 1997 10:43:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA17194 for ; Mon, 24 Nov 1997 10:40:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 10:29:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16599 for ipp-outgoing; Mon, 24 Nov 1997 10:17:46 -0500 (EST) From: Roger K Debry To: Cc: Subject: IPP> IPP > Chunking Message-ID: <5030100014036220000002L002*@MHS> Date: Mon, 24 Nov 1997 10:18:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA15232 We have been working hard to close on issues which can affect inter-operability of IPP implementations. One of the areas that looks like a possible problem area is that of chunking. I have also seen several emails on this in the past couple of days. I would like to suggest an appendix (or something similar) in the protocol document that clearly lays out how http chunking works with IPP, so that we all get it right. Bob, could you do this??? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Mon Nov 24 13:20:23 1997 Delivery-Date: Mon, 24 Nov 1997 13:20:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA17637 for ; Mon, 24 Nov 1997 13:20:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03622 for ; Mon, 24 Nov 1997 13:23:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19260 for ; Mon, 24 Nov 1997 13:20:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 13:15:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18630 for ipp-outgoing; Mon, 24 Nov 1997 13:02:50 -0500 (EST) From: Keith Carter To: Cc: Roger K Debry , Subject: IPP> MOD - Comments on Internationalization Message-ID: <5040300008867833000002L032*@MHS> Date: Mon, 24 Nov 1997 13:02:03 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I hope everyone is doing well! The purpose of this note is to clarify several aspects of the Internationalization sections in the Model and Semantics document dated November 7, 1997. 1. In lines 675-677, the document states "However, the Printer object's "natural-language-supported" attribute SHALL list the natural languages supported by the Printer object and any contained Job objects, so that the client MAY query which natural language(s) are supported." In lines 697-704, the document states "The IPP object SHALL accept any natural language and any Natural Language Override, whether the IPP object supports that natural language or not ... the IPP object SHALL remember that natural language for that attribute, and SHALL indicate the natural language when returning the attribute in response to a query." Question: Since a Printer object MUST accept and store natural languages that it does not support for Jobs created with unsupported natural languages, it seems a client or application can be misled if the Printer object includes these unsupported natural languages in a query on the attribute "natural-language-supported" by a Printer. Is this misleading? If so, then I propose removing the phrase "and any contained Job objects" in line 676. 2. In lines 692-695, the document explains the usage of Natural Language Override. Question: What is the compelling rationale and scenario(s) that make this capability for client requests meet the "80-20 test"? For example, on a client request does specifying a "job-name" attribute in a different natural language than "attributes-natural-language" justify this capability? Please clarify. 3. Scenario: The Printer object returns "charset-supported" = UTF-8, ISO-8859-1 and ISO-8859-7. The Printer object returns "natural-language-supported" = en (english), fr (french) and el (greek). The client specifies "attributes-charset" = ISO-8859-1 and "attributes-natural-language" = el which in combination are invalid. Question: How does the Printer object handle this situation? I expect the Printer object rejects the request with a status code of "client-error-conflicting-attributes". Question: Does IPP assert that an IPP client will avoid the above situation based on its knowledge of valid charset and natural language combinations? If so, then should we state this in the model document? Because I am not sure how often this situation will occur, I do not want to design a complex solution but rather document the appropriate behavior of the client and Printer object in this situation. 4. The following comment is from Gary Miller who is an IBM Internationalization Architect. Gary is on vacation until 12/1 so I'm sending this comment on his behalf to make the 11/25 deadline. Scenario: A server (or printer) supports a charset(s) other than UTF-8 as its native charset. However, the server has the facilities to map UTF-8 to its native charset(s) so its Printer objects publicize UTF-8 as the supported charset. The server is doing the conversion to show these attributes via non-IPP means such as an operating system Print Object (or maybe a MIB?). Question: How does such a server know how to convert the text and name attributes from UTF-8 into its appropriate native charset? Is the "attributes-natural-language" attribute intended to indicate (in ISO terms) "the repertoire" (e.g. the characters that make up ISO-Latin-1) of the charset so the server can make the appropriate conversion? If that is an intent for the "attributes-natural-language" attribute, then this should be documented in the model document. Thanks in advance for your help! Keith Carter Senior Programmer IBM Network Computing Software Division carterk@us.ibm.com 1-512-838-2155 From ipp-owner@pwg.org Mon Nov 24 14:40:33 1997 Delivery-Date: Mon, 24 Nov 1997 14:40:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA19910 for ; Mon, 24 Nov 1997 14:39:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03975 for ; Mon, 24 Nov 1997 14:42:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20870 for ; Mon, 24 Nov 1997 14:39:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 14:27:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19646 for ipp-outgoing; Mon, 24 Nov 1997 14:04:21 -0500 (EST) Message-Id: <3.0.1.32.19971124092221.00fcd430@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 24 Nov 1997 09:22:21 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD add another issue [encoding of CompoundValue] In-Reply-To: <199711220348.TAA24472@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org As long as you've re-opened this issue, I'd like to add several other alternatives into the mix. (A committee is better able to pick between alternatives, than to design one on the fly). On the other hand, it may be better to live with the current scheme than to try to pick a new one. At 19:48 11/21/1997 PST, Robert Herriot wrote: > >As I am implementing the CompoundValue, I am finding problems that make >me think it should be changed. It requires too much special-casing and >in its current form it will introduce bugs where the value of the >CompoundValue exceeds the number of remaining attributes for the >attribute name or attribute group. To avoid those bugs, checks have to >be made in several places. Please explain this problem more. > >I suggest we reexamine the other possible solutions, one simple with >no room for extension, the other with room for extension. > > a) add two new value types: text-language and name-language each of which > is a single value in the protocol but which consists of 4 subfields: > a text/name length field, a text/name field, a language length field, > and a language field, . > > b) add a single new type: compound-value which consists of a single value > in the protocol but which consists of a value-tag field followed by > any number of groups-of-three subfields. Each group-of-three > consists of a value tag, a value length and a value. The text-language > solution of a) is represented by a text-language tag, a text tag, a > text length, a text value, a natural-language-tag, a natural-language > length and a natural-language value. > >I prefer b) because it offers room for extension and an implementation can >determine if it supports the compound value by examining the initial >tag in the compoundValue. Here are my additional alternatives: c) Amplify the 'text' and 'name' attribute syntaxes to allow a second natural language override value to precede the actual value which indicates the language of the immediately following value. The attribute syntax of the first value, when present, is: 'naturalLanguage' as defined in the current spec. Advantages: simple Disadvantages: a single-valued attribute sometimes has two values, making the validation of single-valued attributes more adhoc. Also counting attribute values is more adhoc. d) have two data types for each of 'text' and 'name': 'text' (same as current) and 'taggedText' 'name' (same as current) and 'taggedName' The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging in the beginning of the data (but for language only, not charset) to indicate natural language override: en'... en-us'... to indicate English and U.S. English Those attributes which currently have 'text' and 'name' would be changed to require support of both 'text' and 'taggedText' and 'name' and 'taggedName' For example: job-name (name | taggedName) Advantages: most request/response instances would not need to use the taggedText and taggedName in most interchanges. Disadvantages: clients and IPP objects would still have to support both forms. e) Change the spec for 'text' and 'name' to always require the RFC 2184 natural language prefix (but not charset). Advantages: simple, natural language tag is always stored with the data. Only one protocol value for each attribute value. Disadvantages: tag has to be skipped over when processing or displaying the data. f) Same as e) except include the charset tag as well, so in full compliance with RFC 2184 (same as we had in the Model document after the Atlanta meeting). Example: us-ascii'en'... utf-8'en-us'... Advantages: simple, charset and natural language tag is always stored with the data. Only one protocol value for each attribute value. IPP object doesn't need to charset convert data to a single charset. Disadvantage: tags have to be skipped over when processing or displaying the data. g) Add the dictionary attribute syntax that we postponed. Advantages: It is even more general than your alternative b) and is something we have agreed is something we want. I'd hate to see us put in something that is half a dictionary. I think that the dictionary also fixes the length checking problem that the current CompoundValue has, correct? Disadvantages: None. Tom From ipp-owner@pwg.org Mon Nov 24 14:44:21 1997 Delivery-Date: Mon, 24 Nov 1997 14:44:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20029 for ; Mon, 24 Nov 1997 14:44:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03998 for ; Mon, 24 Nov 1997 14:46:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21151 for ; Mon, 24 Nov 1997 14:42:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 14:31:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19637 for ipp-outgoing; Mon, 24 Nov 1997 14:04:17 -0500 (EST) Message-Id: <3.0.1.32.19971102022347.00cd4610@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 2 Nov 1997 02:23:47 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Randy's proposal in ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA20029 To comply with the IETF rules, I give you the content of Randy's recent security text in ASCII below. Carl-Uno --- Proposed Changes to IPP Model Document Security Sections [Proposal: I would like to move section 8 (Security Considerations) to section 3.5 and only have one "Security Considerations" section in the document. Having this section earlier in the document would also make sense due to the numerous places in the remainder of the document that, at the moment, "forward" references security details. This would make the model document easier to read, without scattering security information all over different places. This document contains proposed content for the combined section…..comments?] [Proposal: Also, I would like to eliminate the REQUIREMENT that IPP over HTTP support RFC 2069 or basic authentication. This would be keeping our current philosophy with implementations NOT required to implement security] 3.1.5 Security Considerations IPP implementations can be explicitly "secure" or "non-secure". Within the context of this document, a "secure" implementation is one that utilizes a transport layer that supports Transport Layer Security (TLS) Version 1.0. A "non-secure" implementation may or may not support security. A "non-secure" implementation MAY elect to support a transport layer that provides inherent security mechanisms (such as HTTP). Secure IPP implementations are capable of supporting mutual authentication as well as privacy of messages via multiple encryption schemes. It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given corporation over a private network, the risks of exposing document data may be low enough that the corporation will choose not to use encryption on that data. However, if the connection between the client and the IPP object is over a public network, the client may wish to protect the content of the information during transmission through the network with encryption. Furthermore, the value of the information being printed may vary from one IPP environment to the next. Printing payroll checks, for example, would have a different value than printing public information from a file. There is also the possibly of denial-of-service attacks, but denial-of-service attacks against printing resources are not well understood and there is no published precedents regarding this scenario 3.1.5.1 Authenticated Clients An IPP server MAY utilize Transport Layer Security (TLS) that, among other things, supplies the credentials of a client. Once the authenticated identity of the requester has been supplied to the IPP implementation, the implementation uses that identity to enforce any authorization policy that might be in place. An important point about security related information is that, for a "secure" IPP server, the security-related parameters (authentication, encryption keys, etc.) are "out-of-band" to the actual IPP protocol. During a create-job operation, the client's credentials are recorded in the Job object in an implementation-defined attribute. This information can be used to verify a client's identity for subsequent operations on that Job object in order to enforce any access control policy that might be in effect. For example, one site's policy might be that only the job owner is allowed to cancel a job. There are operation status codes that allow an IPP server to return information back to a client about any potential access control violations for an IPP object. The details and mechanisms to set up a particular access control policy are not part of IPP/1.0, and must be established via some other type of administrative or access control framework Since the security levels or the specific threats that any given IPP system administrator may be concerned with cannot be anticipated, IPP MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required. TLS Version 1.0 supports the type of negotiated levels of security required by most, if not all, potential IPP environments. IPP environments that require no security can elect to deploy IPP implementations that do not utilize the optional TLS security mechanisms. The following sections describe specific security attacks for IPP environments. Where examples are provided they should be considered illustrative of the environment and not an exhaustive set. Not all of these environments will necessarily be addressed in initial implementations of IPP. 3.1.5.1 Client and Server in the Same Security Domain This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared work-group printers, or where batch applications print their output on large production printers. Although the identity of the user may be trusted in this environment, a user might want to protect the content of a document against such attacks as eavesdropping, replaying or tampering. 3.1.5.2 Client and Server in Different Security Domains Examples of this environment include printing a document created by the client on a publicly available printer, such as at a commercial print shop; or printing a document remotely on a business associates's printer. This latter operation is functionally equivalent to sending the document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment authentication of the printer is required as well as protection against unauthorized use of print resources. Since the document crosses security domains, protection against eavesdropping and document tampering are also required. It will also be important in this environment to protect Printers against "spamming" and malicious document content. 3.1.5.3 Print by Reference When the document is not stored on the client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the document instead of the actual document itself. Standard methods currently do not exist for remote entities to "assume" the credentials of a client for forwarding requests to a 3rd party. It is anticipated that Print-By-Reference will be used to access "public" documents and that sophisticated methods for authenticating "proxies" will not be required for version 1 of IPP. 3.1.5.4 The "requesting-user-name" Operation Attribute An IPP server SHALL support the MANDATORY "requesting-user-name" operation attribute. The client SHOULD include this attribute in all appropriate IPP operations. Non-secure IPP servers MAY use the requesting-user-name attribute to apply simple access control for IPP operations. An IPP client implementation SHALL obtain the value for this attribute from an environmental or network login name for the user, rather than allowing the user to supply any value through a user interface mechanism. For create-job requests the Printer object, upon creating a new Job object, SHALL store the originating user's name in the MANDATORY "job originating-user-name" Job Description attribute. The "job-originating-user-name" attribute is used for presentation only, such as returning in queries or printing on job separator pages. If no transport layer security exists, non-secure IPP servers MAY utilize the "originating-user-name" and "requesting-user-name" to enable simple access control to IPP objects. If some type of transport layer authentication is available, then transport layer authentication MUST be used. Transport layer authentication can be provided by a fully secure TLS IPP implementation, or through some non-IPP standard form of transport authentication provided by protocols such as HTTP 1.1. 3.1.5.5 Restricted Queries In many IPP operations, a client supplies a list of attributes to be returned in the response. For security reasons, an IPP object may be configured not to return all attributes that a client requests. The job attributes returned MAY depend on whether the requesting user is the same as the user that submitted the job. The IPP object MAY even return none of the requested attributes. In such cases, the status returned is the same as if the object had returned all requested attributes. The client cannot tell by such a response whether the requested attribute was present or absent on the object. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 24 15:06:09 1997 Delivery-Date: Mon, 24 Nov 1997 15:06:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20599 for ; Mon, 24 Nov 1997 15:06:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04139 for ; Mon, 24 Nov 1997 15:09:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA21905 for ; Mon, 24 Nov 1997 15:05:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 14:56:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA19889 for ipp-outgoing; Mon, 24 Nov 1997 14:27:54 -0500 (EST) From: Keith Carter To: Cc: Roger K Debry , Subject: IPP> MOD - Comments on Internationalization (RESEND) Message-ID: <5040300008874556000002L062*@MHS> Date: Mon, 24 Nov 1997 14:26:55 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I hope everyone is doing well! The purpose of this note is to clarify several aspects of the Internationalization sections in the Model and Semantics document dated November 7, 1997. 1. In lines 675-677, the document states "However, the Printer object's "natural-language-supported" attribute SHALL list the natural languages supported by the Printer object and any contained Job objects, so that the client MAY query which natural language(s) are supported." In lines 697-704, the document states "The IPP object SHALL accept any natural language and any Natural Language Override, whether the IPP object supports that natural language or not ... the IPP object SHALL remember that natural language for that attribute, and SHALL indicate the natural language when returning the attribute in response to a query." Question: Since a Printer object MUST accept and store natural languages that it does not support for Jobs created with unsupported natural languages, it seems a client or application can be misled if the Printer object includes these unsupported natural languages in a query on the attribute "natural-language-supported" by a Printer. Is this misleading? If so, then I propose removing the phrase "and any contained Job objects" in line 676. 2. In lines 692-695, the document explains the usage of Natural Language Override. Question: What is the compelling rationale and scenario(s) that make this capability for client requests meet the "80-20 test"? For example, on a client request does specifying a "job-name" attribute in a different natural language than "attributes-natural-language" justify this capability? Please clarify. 3. Scenario: The Printer object returns "charset-supported" = UTF-8, ISO-8859-1 and ISO-8859-7. The Printer object returns "natural-language-supported" = en (english), fr (french) and el (greek). The client specifies "attributes-charset" = ISO-8859-1 and "attributes-natural-language" = el which in combination are invalid. Question: How does the Printer object handle this situation? I expect the Printer object rejects the request with a status code of "client-error-conflicting-attributes". Question: Does IPP assert that an IPP client will avoid the above situation based on its knowledge of valid charset and natural language combinations? If so, then should we state this in the model document? Because I am not sure how often this situation will occur, I do not want to design a complex solution but rather document the appropriate behavior of the client and Printer object in this situation. 4. The following comment is from Gary Miller who is an IBM Internationalization Architect. Gary is on vacation until 12/1 so I'm sending this comment on his behalf to make the 11/25 deadline. Scenario: A server (or printer) supports a charset(s) other than UTF-8 as its native charset. However, the server has the facilities to map UTF-8 to its native charset(s) so its Printer objects publicize UTF-8 as the supported charset. The server is doing the conversion to show these attributes via non-IPP means such as an operating system Print Object (or maybe a MIB?). Question: How does such a server know how to convert the text and name attributes from UTF-8 into its appropriate native charset? Is the "attributes-natural-language" attribute intended to indicate (in ISO terms) "the repertoire" (e.g. the characters that make up ISO-Latin-1) of the charset so the server can make the appropriate conversion? If that is an intent for the "attributes-natural-language" attribute, then this should be documented in the model document. Thanks in advance for your help! Keith Carter Senior Programmer IBM Network Computing Software Division carterk@us.ibm.com 1-512-838-2155 From ipp-owner@pwg.org Mon Nov 24 15:20:00 1997 Delivery-Date: Mon, 24 Nov 1997 15:20:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20811 for ; Mon, 24 Nov 1997 15:20:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04202 for ; Mon, 24 Nov 1997 15:22:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA22888 for ; Mon, 24 Nov 1997 15:19:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 15:08:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21188 for ipp-outgoing; Mon, 24 Nov 1997 14:43:36 -0500 (EST) Message-Id: <3.0.1.32.19971124114651.01128100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 24 Nov 1997 11:46:51 PST To: Roger K Debry , From: Tom Hastings Subject: Re: IPP> Making [which-]document-format MANDATORY for Get-Attributes In-Reply-To: <5030100013817454000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 08:21 11/20/1997 PST, Roger K Debry wrote: >I have read through the comments posted by Tom, Bob, and Scott >and have the following comments: > >In general, I think that the proposal is a good one, and I appreciate >the work done by Tom, Bob and Scott to clarify the handling of >operation attributes. snip... >Section 4.3: Which-document-format attribute name does not >match the model document, which lists this simply as >document-format. If the client says "Give me the following printer >attributes for document-format=IPDS and the printer doesn't >support IPDS, why is the rule accept and ignore? What does >ignore mean - not respond? Send back the listed attributes for >some other (maybe the default) document-format? Either of these >would be incorrect as far as the client was concerned. After thinking about this some more, I'd like to make the following proposal: 1. Rename "document-format" to "which-document-format" as agreed to on the 11/19 telecon, not to use the same name for an Operation attribute as for a Job Template attribute when the semantics are different. 2. Clarify that the "which-document-format" Operation attribute is MANDATORY for a Printer object to support (so clients can always supply). 3. Clarify that the Printer object SHALL return the 'client-error-document-format-not-supported' status code, if the supplied document format is not supported (so that the client isn't mislead). 4. Continue recommending that a client SHOULD supply it, else they get the results for the Printer's default which may be 'application/octet-stream' which is the "or" of the supported values of the several document formats that are auto-sensed. 5. Change what support of the "which-document-format" means. Instead of requiring Printer objects to validate only for the specified document format, which not many current system do, require the Printer object to return the supported values that correspond to the validation that it performs on the create operations: If the Printer validates according to the document-format supplied in the create, then the Printer SHALL also return values that are applicable only to the document format requested in the Get-Attributes operation. However, if the Printer oject is not that sophiscated (most aren't yet), then the Printer returns the attributes for the union of document formats that it supports. In other words, if a client queries the Printer, the client can find all values that the Printer will accept in a create operation with "ipp-attribte-fidelity" 'true' when the client supplies the same "document-format" value in the create as it supplies in the "which-document-format" in the Get-Attributes operation. snip... Tom > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > From ipp-owner@pwg.org Mon Nov 24 15:32:09 1997 Delivery-Date: Mon, 24 Nov 1997 15:32:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21064 for ; Mon, 24 Nov 1997 15:32:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04263 for ; Mon, 24 Nov 1997 15:35:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23846 for ; Mon, 24 Nov 1997 15:32:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 15:27:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21762 for ipp-outgoing; Mon, 24 Nov 1997 15:03:08 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> FW: Protocol Action: The TLS Protocol Version 1.0 to Proposed St andard Date: Mon, 24 Nov 1997 12:00:46 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ns.ietf.org] > Sent: Monday, November 24, 1997 11:38 AM > Cc: RFC Editor; Internet Architecture Board; ietf-tls@consensus.com > Subject: Protocol Action: The TLS Protocol Version 1.0 to > Proposed Standard > > > > [Private Note to IESG: This is a re-issue of an old ballot. Version > -05 > addresses the concerns raised by the IESG and others during the first > balloting procedure. Specifically this version mandates that > implementers at > least support a Diffie-Hellman (non-proprietary) cipher suite). The > current > version on-line is version -04 which is not significantly different > from > version -05 which has been sent in to Internet Drafts and I hope will > be > on-line shortly.] > > The IESG has approved the Internet-Draft "The TLS Protocol Version > 1.0" > as a Proposed Standard. This > document is > the product of the Transport Layer Security Working Group. The IESG > contact person is Jeffrey Schiller. > > > Technical Summary > > This document specifies Version 1.0 of the Transport Layer > Security > (TLS) protocol. The TLS protocol provides communications privacy > over > the Internet. The protocol allows client/server applications > to > communicate in a way that is designed to prevent > eavesdropping, > tampering, or message forgery. > > Working Group Summary > > This document reflects the consensus of the working group. There > were > no issues raised during the last call. > > Protocol Quality > > This document was reviewed by for the IESG by Jeff Schiller. > It > appears to properly provide the security services it claims. > Perhaps > more importantly it is the product of an evolutionary process > where > implementations have been coded and tested in the real world. > This > protocol is based on the Secure Sockets Layer (SSL), which is > deployed > in commercially available Web browsers from Netscape and > Microsoft. > In addition several toolkits are available for implementers > to > incorporate into other Internet tools. > From jmp-owner@pwg.org Mon Nov 24 16:15:28 1997 Delivery-Date: Mon, 24 Nov 1997 16:15:28 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22006 for ; Mon, 24 Nov 1997 16:15:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04445 for ; Mon, 24 Nov 1997 16:18:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24747 for ; Mon, 24 Nov 1997 16:15:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 16:10:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24129 for jmp-outgoing; Mon, 24 Nov 1997 16:07:26 -0500 (EST) From: don@lexmark.com Message-Id: <199711242107.AA29754@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, sense@pwg.org, fin@pwg.org, jmp@pwg.org, p1394@pwg.org Date: Mon, 24 Nov 1997 15:59:11 -0500 Subject: JMP> LA Schedule Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org Given that Jay will not be able to attend the LA meeting, the following is the schedule for the week. Changes are only to Thursday and Friday. Mon/Tues 1394 Printing Wednesday IPP Thursday Finisher MIB Friday Job MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From pwg-owner@pwg.org Mon Nov 24 16:22:58 1997 Delivery-Date: Mon, 24 Nov 1997 16:22:59 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22146 for ; Mon, 24 Nov 1997 16:22:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04475 for ; Mon, 24 Nov 1997 16:25:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25397 for ; Mon, 24 Nov 1997 16:21:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 16:14:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24198 for pwg-outgoing; Mon, 24 Nov 1997 16:08:11 -0500 (EST) From: don@lexmark.com Message-Id: <199711242107.AA29754@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, sense@pwg.org, fin@pwg.org, jmp@pwg.org, p1394@pwg.org Date: Mon, 24 Nov 1997 15:59:11 -0500 Subject: PWG> LA Schedule Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Given that Jay will not be able to attend the LA meeting, the following is the schedule for the week. Changes are only to Thursday and Friday. Mon/Tues 1394 Printing Wednesday IPP Thursday Finisher MIB Friday Job MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Nov 24 16:35:58 1997 Delivery-Date: Mon, 24 Nov 1997 16:35:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22452 for ; Mon, 24 Nov 1997 16:35:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04513 for ; Mon, 24 Nov 1997 16:38:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26091 for ; Mon, 24 Nov 1997 16:35:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 16:30:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24179 for ipp-outgoing; Mon, 24 Nov 1997 16:07:57 -0500 (EST) From: don@lexmark.com Message-Id: <199711242107.AA29754@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, sense@pwg.org, fin@pwg.org, jmp@pwg.org, p1394@pwg.org Date: Mon, 24 Nov 1997 15:59:11 -0500 Subject: IPP> LA Schedule Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Given that Jay will not be able to attend the LA meeting, the following is the schedule for the week. Changes are only to Thursday and Friday. Mon/Tues 1394 Printing Wednesday IPP Thursday Finisher MIB Friday Job MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Nov 24 16:55:52 1997 Delivery-Date: Mon, 24 Nov 1997 16:55:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22888 for ; Mon, 24 Nov 1997 16:55:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04606 for ; Mon, 24 Nov 1997 16:58:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26856 for ; Mon, 24 Nov 1997 16:55:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 16:51:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26177 for ipp-outgoing; Mon, 24 Nov 1997 16:39:22 -0500 (EST) From: don@lexmark.com Message-Id: <199711242139.AA01684@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 24 Nov 1997 16:33:47 -0500 Subject: IPP> 11/26 Conference Call Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I have set up one more conference calls as follows. Call dates: 11/26 Dial-in: 608-250-1828 Time: 4PM EST (1PM PST) Duration: 2 hours Access Code: 190148 ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Nov 24 19:18:56 1997 Delivery-Date: Mon, 24 Nov 1997 19:18:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25261 for ; Mon, 24 Nov 1997 19:18:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05185 for ; Mon, 24 Nov 1997 19:21:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA27993 for ; Mon, 24 Nov 1997 19:18:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 19:13:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27407 for ipp-outgoing; Mon, 24 Nov 1997 19:01:21 -0500 (EST) Message-Id: <3.0.1.32.19971102075238.009e5bd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 2 Nov 1997 07:52:38 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference - 971126 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference - 971126 Although a number of people will be away this week considering the upcoming holiday, it was decided in last week's call to hold a conference this week to look over the comments received on the Last Call for the Model and Protocol ducuments (closing Tuesday November 25) and possibly hand out some further home work assignments as preparation for our face-to-face meeting in LA on December 3. Here are the phone details: Call date: 11/26 Dial-in: 608-250-1828 Time: 4PM EST (1PM PST) Duration: 2 hours Access Code: 190148 Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Nov 24 21:13:32 1997 Delivery-Date: Mon, 24 Nov 1997 21:13:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25817 for ; Mon, 24 Nov 1997 21:13:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05425 for ; Mon, 24 Nov 1997 21:16:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29039 for ; Mon, 24 Nov 1997 21:13:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 21:01:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28318 for ipp-outgoing; Mon, 24 Nov 1997 20:38:21 -0500 (EST) Date: Mon, 24 Nov 1997 17:42:41 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711250142.AA04220@snorkel.eso.mc.xerox.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD - Randy's proposal in ASCII Sender: ipp-owner@pwg.org Hi Carl-Uno, Thanks! In addition to complying with IETF working group rules, it let's those of us without MS Word see Randy's proposal. Cheers, - Ira McDonald From ipp-owner@pwg.org Mon Nov 24 21:26:44 1997 Delivery-Date: Mon, 24 Nov 1997 21:26:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25856 for ; Mon, 24 Nov 1997 21:26:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05457 for ; Mon, 24 Nov 1997 21:29:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00313 for ; Mon, 24 Nov 1997 21:26:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 21:19:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28374 for ipp-outgoing; Mon, 24 Nov 1997 20:48:03 -0500 (EST) Date: Mon, 24 Nov 1997 17:52:25 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711250152.AA04234@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> MOD - MIME Parameter Charset/Language is RFC 2231 Sender: ipp-owner@pwg.org Hi folks, RFC 2231 is the new IETF Proposed Standard for MIME Parameter Value Charsets and Languages (obsoletes RFC 2184). Cheers, - Ira McDonald (outside consultant at Xerox) From ipp-owner@pwg.org Mon Nov 24 21:26:44 1997 Delivery-Date: Mon, 24 Nov 1997 21:26:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25859 for ; Mon, 24 Nov 1997 21:26:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05458 for ; Mon, 24 Nov 1997 21:29:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00316 for ; Mon, 24 Nov 1997 21:26:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 24 Nov 1997 21:18:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28363 for ipp-outgoing; Mon, 24 Nov 1997 20:45:36 -0500 (EST) Date: Mon, 24 Nov 1997 17:49:58 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9711250149.AA04227@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> MOD - ABNF is RFC 2234 Sender: ipp-owner@pwg.org Hi folks, RFC 2234 (November 1997) is the new IETF Proposed Standard for ABNF, for you references (and to check you ABNF). Cheers, - Ira McDonald (outside consultant at Xerox) From ipp-owner@pwg.org Tue Nov 25 01:39:16 1997 Delivery-Date: Tue, 25 Nov 1997 01:39:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA05275 for ; Tue, 25 Nov 1997 01:39:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA05904 for ; Tue, 25 Nov 1997 01:42:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA02115 for ; Tue, 25 Nov 1997 01:39:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 01:34:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA01485 for ipp-outgoing; Tue, 25 Nov 1997 01:20:24 -0500 (EST) From: kawasima@rsk-kitami.grp.ricoh.co.jp Message-Id: <9711250619.AA00362@astrea.rsk-kitami.grp.ricoh.co.jp> Date: Tue, 25 Nov 1997 15:19:36 +0900 To: ipp@pwg.org Subject: IPP> IBM's IPP Client Prototype Problems MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Hello. I am now working to develop prototypes with IPP documents. IBM's client sent these data to ipp server as follows. result of analysis: 01 00 00 02 01 29 00 08 6A 6F 62 2D 6E 61 6D 65 .....)..job-name ~~1~~ ~~2~~ ~3 ~4 ~~5~~ ~~~~~~~~~~~6~~~~~~~~~~~ 00 04 6A 6F 62 31 29 00 16 69 70 70 2D 61 74 74 ..job1)..ipp-att ~~7~~ ~~~~~8~~~~~ ~9 ~~10~ ~~~~~~~~~~11~~~~~~~~ 72 69 62 75 74 65 2D 66 69 64 65 6C 69 74 79 00 ribute-fidelity. ~~~~~~~~~~~~~~~~~~~11~~~~~~~~~~~~~~~~~~~~~~~ ~12 05 66 61 6C 73 65 29 00 0D 64 6F 63 75 6D 65 6E .false)..documen ~~ ~~~~~~13~~~~~~ 14 ~~15~ ~~~~~~~~~16~~~~~~~~~ 74 2D 6E 61 6D 65 00 09 64 6F 63 75 6D 65 6E 74 t-name..document ~~~~~~~~16~~~~~~~ ~~17~ ~~~~~~~~~~~18~~~~~~~~~~ 31 02 15 00 06 63 6F 70 69 65 73 00 01 01 15 00 1....copies..... ~~ 19 20 ~~21~ ~~~~~~~~22~~~~~~~ ~~23~ 24 25 ~26 0C 6A 6F 62 2D 70 72 69 6F 72 69 74 79 00 01 01 .job-priority... ~~ ~~~~~~~~~~~~~~~~~27~~~~~~~~~~~~~~~~ ~~28~ ~29 03 . ~30 1: IPP version 0x0100 -> IPP/1.0 2: operation number 0x0002 -> Print-Job 3: tag 0x01 -> operation-attributes-tag 4: tag 0x29 -> this tag is reserved for future integer types 5: length of attribute-name 0x0008 -> 8bytes 6: attribute-name -> "job-name" 7: length of attribute-value 0x0004 -> 4bytes 8: attribute-value -> "job1" 9: tag 0x29 -> this tag does not exist in IPP protocol specification 10: length of attribute-name 0x0016 -> 22bytes 11: attribute-name -> "ipp-attribute-fidelity" 12: length of attribute-value 0x0005 -> 5bytes 13: attribute-value -> false, In IPP model specification, ipp-attribute-fidelity is boolean type. And in IPP protocol specification, if 'false' then 0x00, if 'true' then 0x01. 14: tag 0x29 -> this tag does not exist in IPP protocol specification 15: length of attribute-name 0x000D -> 13bytes 16: attribute-name -> "document-name" 17: length of attribute-value 0x0009 -> 9bytes 18: attribute-value -> "document1" 19: tag 0x02 -> job-attributes-tag 20: tag 0x15 -> this tag is reserved for future "out-of-band" values 21: length of attribute-name 0x0006 -> 6bytes 22: attribute-name -> "copies" 23: length of attribute-value 0x0001 -> 1byte 24: attribute-value -> 1 25: tag 0x15 -> this tag does not exist in IPP protocol specification 26: length of attribute-name 0x000C -> 12bytes 27: attribute-name -> "job-priority" 28: length of attribute-value 0x0001 -> 1byte 29: attribute-value -> 1 30: tag 0x03 -> data-tag Item 4, 9, 12, 13, 14, 20, 25 are not based on IPP protocol specification. So IBM Client can not access to ipp server. Best Regards, Norimi Kawashima ---------------- Norimi Kawashima Ricoh System Kaihatsu(Kitami) Co.Ltd. 592-7, hakuyou-cho, kitami, Hokkaido, Japan 090-0013 e-mail:kawasima@rsk-kitami.grp.ricoh.co.jp phone :+81-157-22-2201 facsimile:+81-157-22-2202 From ipp-owner@pwg.org Tue Nov 25 09:52:56 1997 Delivery-Date: Tue, 25 Nov 1997 09:52:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08402 for ; Tue, 25 Nov 1997 09:52:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA06589 for ; Tue, 25 Nov 1997 09:55:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA04496 for ; Tue, 25 Nov 1997 09:52:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 09:42:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA03827 for ipp-outgoing; Tue, 25 Nov 1997 09:29:49 -0500 (EST) From: Roger K Debry To: Cc: , Keith Carter Subject: IPP>IPP Last Call - need advance list of issues Message-ID: <5030100014144270000002L002*@MHS> Date: Tue, 25 Nov 1997 09:28:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA08402 Carl-Uno, It would be extremely helpful if we all could have a list of the last call issues we intend to discuss in Los Angeles a day or two prior to the meeting so that we have a chance to think about them a bit prior to the meeting. Even if this came out on monday afternoon this would make the discussion at Wednesday's IPP meeting a lot more productive. Given where we are in the process, we need to make our meeting as effective as possible. Thanks ... Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From daemon Tue Nov 25 09:47:31 1997 Delivery-Date: Tue, 25 Nov 1997 09:53:24 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA08290 for ietf-123-outbound.10@ietf.org; Tue, 25 Nov 1997 09:47:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08251; Tue, 25 Nov 1997 09:46:43 -0500 (EST) Message-Id: <199711251446.JAA08251@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-lpd-ipp-map-02.txt Date: Tue, 25 Nov 1997 09:46:43 -0500 Sender: cclark@cnri.reston.va.us --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) : R. Herriot, T. Hastings, N. Jacobs, J. Martin Filename : draft-ietf-ipp-lpd-ipp-map-02.txt Pages : 22 Date : 24-Nov-97 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971124114339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124114339.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 25 10:06:42 1997 Delivery-Date: Tue, 25 Nov 1997 10:06:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA09011 for ; Tue, 25 Nov 1997 10:06:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA06645 for ; Tue, 25 Nov 1997 10:09:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA05176 for ; Tue, 25 Nov 1997 10:06:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 10:01:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA04232 for ipp-outgoing; Tue, 25 Nov 1997 09:47:28 -0500 (EST) Message-Id: <199711251446.JAA08251@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-lpd-ipp-map-02.txt Date: Tue, 25 Nov 1997 09:46:43 -0500 Sender: ipp-owner@pwg.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) : R. Herriot, T. Hastings, N. Jacobs, J. Martin Filename : draft-ietf-ipp-lpd-ipp-map-02.txt Pages : 22 Date : 24-Nov-97 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971124114339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124114339.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Tue Nov 25 10:27:08 1997 Delivery-Date: Tue, 25 Nov 1997 10:32:43 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA09965 for ietf-123-outbound.10@ietf.org; Tue, 25 Nov 1997 10:26:54 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA09933; Tue, 25 Nov 1997 10:26:48 -0500 (EST) Message-Id: <199711251526.KAA09933@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-connectivity-01.txt Date: Tue, 25 Nov 1997 10:26:47 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Connectivity Author(s) : J. Mahdavi, V. Paxson Filename : draft-ietf-ippm-connectivity-01.txt Pages : 9 Date : 24-Nov-97 Connectivity is the basic stuff from which the Internet is made. Therefore, metrics determining whether pairs of hosts (IP addresses) can reach each other must form the base of a measurement suite. We define several such metrics, some of which serve mainly as building blocks for the others. This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in the revised IPPM Framework document (currently ); the reader is assumed to be familiar with that document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-connectivity-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippm-connectivity-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-connectivity-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971124154749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-connectivity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-connectivity-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124154749.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Nov 25 12:34:59 1997 Delivery-Date: Tue, 25 Nov 1997 12:56:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA15232 for ; Tue, 25 Nov 1997 12:34:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07399 for ; Tue, 25 Nov 1997 12:29:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06099 for ; Tue, 25 Nov 1997 12:26:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 12:20:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05519 for ipp-outgoing; Tue, 25 Nov 1997 12:08:17 -0500 (EST) Message-Id: <3.0.1.32.19971125091142.0109db00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Nov 1997 09:11:42 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - My last call comments on the Protocol document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Subj: Last Call Protocol Comments from T. Hastings From: Tom Hastings Date: 11/25/97 File: ipp-pro-last-call-comments-th.doc 1. Section 3.2, 3.6.1, 3.8: Remove "job-" from the "unsupported-job-attributes-tag", so that other kinds of unsupported attributes can be returned in the same group and align with the 11/7/97 Model document. 2. Section 3.6.1, 3.8: The "data-tag" corresponds to the "Document Content" group in the Model document, sort of. In the protocol, the "data-tag" is also an "end of operation tag and is required in all operations and has to be last. Section 3.8 indicates that the "data-tag" corresponds to the "document-content" attribute which no longer exists in the Model document. Should be changed to the "Document Content group". Section 3.8 lists an issue to coordinate with the Model document. 3. Section 3.6.1: The protocol document needs to require the client and server to ignore delimiter tags and the following contents that are reserved for the future (0x06-j0x0f). 4. Section 3.6.1: Change "that the zero" to "that zero". 5. Section 3.6.2, second sentence: Change "is the that" to "is that". 6. Section 3.6.2, second sentence: Change the second occurrence of "type" to "attribute syntax" to agree with the terminology in the Model document. 7. Section 3.6.2, second sentence: add to the end of the sentence: "as specified in the Model document for the attribute", so that the sentence reads: " If the value-tag specifies a type of compoundValue, it represents a compound value whose attribute syntax is that of the last member of the compound value as specified in the Model document for the attribute." 8. Section 3.10: CompoundValue: Similarly change the description from: "If the value of a compoundValue is n, then the n following values of the attribute form a single value whose type is that of the last member of the compound value." to: " If the value of a compoundValue is n, then the n following values of the attribute form a single value whose attribute syntax is that of the last member of the compound value as specified in the Model document for the attribute." 9. Section 3.10: dateTime: Remove the sentence: "Although RFC 1903 also defines an eight octet format which omits the time zone, a value of this type in the IPP protocol MUST use the eleven octet format. [ transfer to model]." Its already in the Model document, 11/7/97. 10. Section 10.7, Get-Jobs response: The Printer is returning no information about job 2, is the job-attributes-tag REQUIRED? Or MAY a Printer object omit the job-attributes-tag for any job that it is not returning, perhaps for security reasons. The answer ought to go in the Model document. 11. Section 12, Appendix C: "Hints to implementors using IPP with SSL3". May need some re-wording now that we are requiring TLS. From ipp-owner@pwg.org Tue Nov 25 13:09:30 1997 Delivery-Date: Tue, 25 Nov 1997 13:24:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA16297 for ; Tue, 25 Nov 1997 13:09:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07542 for ; Tue, 25 Nov 1997 13:10:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06807 for ; Tue, 25 Nov 1997 13:07:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 13:03:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06235 for ipp-outgoing; Tue, 25 Nov 1997 12:51:06 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> IBM's IPP Client Prototype Problems Message-ID: <5030100014161335000002L052*@MHS> Date: Tue, 25 Nov 1997 12:50:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA16297 Norimi- I agree with your analysis. Looks like we accidently used decimal instead of hex for our type tags. So, for example, at 4: tag 0x29 -> this tag is reserved for future integer types we sent Dec Hex Char 41 29 ) instead of Dec Hex Char 65 41 A when we were trying to sepcify Tag Value (Hex) Meaning 0x41 text I'm working on a fix. Send me email directly at kugler@us.ibm.com if you'd like an updated copy. Carl Kugler IBM ipp-owner@pwg.org on 11/24/97 11:38:27 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> IBM's IPP Client Prototype Problems Hello. I am now working to develop prototypes with IPP documents. IBM's client sent these data to ipp server as follows. result of analysis: 01 00 00 02 01 29 00 08 6A 6F 62 2D 6E 61 6D 65 .....)..job-name ~~1~~ ~~2~~ ~3 ~4 ~~5~~ ~~~~~~~~~~~6~~~~~~~~~~~ 00 04 6A 6F 62 31 29 00 16 69 70 70 2D 61 74 74 ..job1)..ipp-att ~~7~~ ~~~~~8~~~~~ ~9 ~~10~ ~~~~~~~~~~11~~~~~~~~ 72 69 62 75 74 65 2D 66 69 64 65 6C 69 74 79 00 ribute-fidelity. ~~~~~~~~~~~~~~~~~~~11~~~~~~~~~~~~~~~~~~~~~~~ ~12 05 66 61 6C 73 65 29 00 0D 64 6F 63 75 6D 65 6E .false)..documen ~~ ~~~~~~13~~~~~~ 14 ~~15~ ~~~~~~~~~16~~~~~~~~~ 74 2D 6E 61 6D 65 00 09 64 6F 63 75 6D 65 6E 74 t-name..document ~~~~~~~~16~~~~~~~ ~~17~ ~~~~~~~~~~~18~~~~~~~~~~ 31 02 15 00 06 63 6F 70 69 65 73 00 01 01 15 00 1....copies..... ~~ 19 20 ~~21~ ~~~~~~~~22~~~~~~~ ~~23~ 24 25 ~26 0C 6A 6F 62 2D 70 72 69 6F 72 69 74 79 00 01 01 .job-priority... ~~ ~~~~~~~~~~~~~~~~~27~~~~~~~~~~~~~~~~ ~~28~ ~29 03 . ~30 1: IPP version 0x0100 -> IPP/1.0 2: operation number 0x0002 -> Print-Job 3: tag 0x01 -> operation-attributes-tag 4: tag 0x29 -> this tag is reserved for future integer types 5: length of attribute-name 0x0008 -> 8bytes 6: attribute-name -> "job-name" 7: length of attribute-value 0x0004 -> 4bytes 8: attribute-value -> "job1" 9: tag 0x29 -> this tag does not exist in IPP protocol specification 10: length of attribute-name 0x0016 -> 22bytes 11: attribute-name -> "ipp-attribute-fidelity" 12: length of attribute-value 0x0005 -> 5bytes 13: attribute-value -> false, In IPP model specification, ipp-attribute-fidelity is boolean type. And in IPP protocol specification, if 'false' then 0x00, if 'true' then 0x01. 14: tag 0x29 -> this tag does not exist in IPP protocol specification 15: length of attribute-name 0x000D -> 13bytes 16: attribute-name -> "document-name" 17: length of attribute-value 0x0009 -> 9bytes 18: attribute-value -> "document1" 19: tag 0x02 -> job-attributes-tag 20: tag 0x15 -> this tag is reserved for future "out-of-band" values 21: length of attribute-name 0x0006 -> 6bytes 22: attribute-name -> "copies" 23: length of attribute-value 0x0001 -> 1byte 24: attribute-value -> 1 25: tag 0x15 -> this tag does not exist in IPP protocol specification 26: length of attribute-name 0x000C -> 12bytes 27: attribute-name -> "job-priority" 28: length of attribute-value 0x0001 -> 1byte 29: attribute-value -> 1 30: tag 0x03 -> data-tag Item 4, 9, 12, 13, 14, 20, 25 are not based on IPP protocol specification. So IBM Client can not access to ipp server. Best Regards, Norimi Kawashima ---------------- Norimi Kawashima Ricoh System Kaihatsu(Kitami) Co.Ltd. 592-7, hakuyou-cho, kitami, Hokkaido, Japan 090-0013 e-mail:kawasima@rsk-kitami.grp.ricoh.co.jp phone :+81-157-22-2201 facsimile:+81-157-22-2202 From ipp-owner@pwg.org Tue Nov 25 17:03:45 1997 Delivery-Date: Tue, 25 Nov 1997 17:03:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA21649 for ; Tue, 25 Nov 1997 17:03:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA08883 for ; Tue, 25 Nov 1997 17:06:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07949 for ; Tue, 25 Nov 1997 17:03:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 16:58:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07172 for ipp-outgoing; Tue, 25 Nov 1997 16:44:26 -0500 (EST) From: Keith Carter To: Subject: Re: IPP>MOD job-k-octets-supported issue Message-ID: <5040300008961432000002L022*@MHS> Date: Tue, 25 Nov 1997 16:09:52 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org I agree with Tom's proposal. Keith Carter ---------------------- Forwarded by Keith Carter/Austin/IBM on 11-25-97 02:32 PM --------------------------- ipp-owner@pwg.org 11-14-97 10:10 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, Robert.Herriot@Eng.Sun.COM @ internet cc: Subject: Re: IPP>MOD job-k-octets-supported issue Hmmm... You have a good point here. I think this means that "job-k-octets", "job-impressions", and "job-media-sheets" should be moved from the Job Template group and become: OPTIONAL (for clients to submit and Printers to support) operation attributes with corresponding OPTIONAL Job Description attributes (same as "job-name", except that "job-name" is MANDATORY). and the corresponding "job-k-octets-supported", "job-impressions-supported", and "job-media-sheets-supported" would become Printer Description attributes. (There aren't any "xxx-default" for these three). NOTE that such a change has almost no effect on implementations, except that these three attributes are submitted in the Operation attributes group, instead of the Job Template attributes group (and their processing is handled without regards to ipp-attribute-fidelity, as Bob points out). Tom At 19:59 11/13/1997 PST, Robert Herriot wrote: >Am I correct in assuming that if a client includes job-k-octets, it behaves >like other job-template attributes, namely (the model document is silent) > > a) fidelity is true: if job-k-octets-supported is undefined in the > printer or job-k-octets is out of range, reject the job and > return job-k-octets in the unsupported-job-attributes group. > > b) fidelity is false: the job is accepted regardless of the value > of job-k-octets or the presence or absence of > job-k-octets-supported, but if the job-k-octets-supported is > undefined in the printer or job-k-octets is out of range, return > job-k-octets in the unsupported-job-attributes group. > >This behavior is perhaps a bit surprising in the fidelity = false case, >because the job-k-octets-supported is intended to be a way for a printer >to control the sizes allowed. > >So this means that someone with a really big job can bypass the job-size >limit by setting fidelity = false. > >It would seem that job-k-octets and the other two related attributes don't >really follow the rules of other job-template attributes. > >Comments? > >Bob Herriot > > From ipp-owner@pwg.org Tue Nov 25 17:50:43 1997 Delivery-Date: Tue, 25 Nov 1997 17:50:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA01263 for ; Tue, 25 Nov 1997 17:50:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09378 for ; Tue, 25 Nov 1997 17:53:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08698 for ; Tue, 25 Nov 1997 17:50:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 17:46:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08084 for ipp-outgoing; Tue, 25 Nov 1997 17:33:49 -0500 (EST) From: Keith Carter To: Cc: Roger K Debry Subject: IPP> MOD - Comment on handling version numbers Message-ID: <5040300008967509000002L092*@MHS> Date: Tue, 25 Nov 1997 17:32:47 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Roger deBry and I were discussing how requests and responses will be handled between clients and servers that support different version numbers. We concluded that every major and minor protocol version MUST support the version and operation/status code fields in the first 4 bytes of the protocol as currently defined in the IPP 1.0 protocol document. Scenario 1: An IPP client at version 1.0 sends a request to an IPP server at version 2.0. The server does not support 1.0. The server responds with version=2.0 and status-code=ipp-server-error-version-not-supported (0x0503). The client now understands the server does not support 1.0 and the server supports 2.0. Scenario 2: An IPP client at version 2.0 sends a request to an IPP server at version 1.0. The server responds with version=1.0 and status-code=ipp-server-error-version-not-supported (0x0503). The client now understands the server does not support 2.0 and the server supports 1.0. Scenario 3: An IPP client at version 2.6 sends a request to an IPP server at version 2.1. The server successfully processes the request, ignoring what it does not understand, and responds with version=2.1 and status-code=successful-ok-ignored-or-substituted-attributes (0x0001). This behavior seems consistent with Scott's comments in the attached note. We also could not find any statement that requires clients and servers to be downward compatible across major versions although an implementation may choose to do so. Comments? Keith Carter - - - - Attached Note - - - - To: ipp@pwg.org @ internet, Robert.Herriot@Eng.Sun.COM @ internet cc: Subject: Re: IPP>MOD problem with MANDATORY support of operation attr Bob, I have suggested in the past that I am in favor of very strict versioning rules (new operation attrtibute means reject). However, as I think about the principles of backwards compatiblity and versioning I come up with: 1. Reserver MAJOR version numbers for stuff that really breaks the protocol and requires both client and server upgrades or you just don't communicated (analogy: pick the human natural language for our conversation or we don't talk) 2. Reserve MINOR version numbers for bundling of new features which do not break clients or servers if the new features can successfully be ignored therefore DO NOT REQUIRE all implementations (clients and servers) to support ALL minor versions in sequence. You speak 2.5. I speak 2.6. I can choose to 1) revert to 2.5 and speak 2.5 with you or 2) just keep talking 2.6 (knowing you will not reject any deltas between 2.5 and 2.6) but at least we will still talk without forcing me to revert to 2.5. (analogy: we both choose French, but you throw in some German words now and then and I just ignore them, but the real language we are speaking is French). The same example above holds if 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, and 2.6 all exist and you support only 2.0 and I support 2.6. If I find out you only speak 2.0, I can choose to revert to 2.0, or still speak 2.6 to you knowing you will do your best up to 2.0 and you might ignore stuff. However, if I speak 2.6 and you only speak 1.2, then we just can't speak until I revert to something less than 2.0. 3. What if I support 2.5 and you support 2.6? Does this mean that I assume you support 2.5 as well? I submit, that if either of us support 2.x then we can both choose to communcate using 2.x and we should not break each other (protocol error out). 4. This means that, yes, I am in favor of generally "ignoring what you don't understand". However, I am not in favor of accepting anything from you in any order or missing tags. The tags must still be there even if the set is empty. 5. I am not in favor of adding an attribute to every operation that is like "ipp-attribute-fidelity". Summary: 1. Major version break stuff 2. Minor version are hints packaging of new features 3. Ignore stuff you don't understand (as much as possible) 4. Don't require all sides to implement all minor versions 5. Make version queriable in a way that never breaks across all versions major and minor (if it does break it is a new protocol, not a major version, ie., XXXng (next generation)) Scott >>> Robert Herriot 11/10/97 05:52PM >>> I have two concerns a) about an operation being rejected if it contains an unsupported operation-attribute, and b) the incrementing of the major version when an operation attribute is added. I think that the major version should be incremented only when a Printer is likely to make a major mistake, e.g. the syntax has changed. A new operation attribute might fall into this category, but wouldn't normally if a Printer is allowed to ignore unrecognized ones, as I suggest below. The current model document says that a Printer MUST support all operation-attributes and by implication that a Printer rejects an operation if the operation contains an unsupported operation attribute (though I cannot find such language and the algorithm in section 15.3 does not loop through operation attributes (a bug?)). But Scott and Tom believe this to be the case. This issue is much like the fidelity notion for Job-Template attributes and probably calls for two changes in the future: a) an operation attribute "ipp-operation-fidelity" which if false allows the Printer to ignore operation-attributes, and b) an unsupported-operation-attributes group in a response to hold those operation attributes that the Printer ignored. The current behavior of rejecting an operation with unsupported operation attributes is simple, but will lead to problems in the future when different versions are trying to interoperate and users prefer something to nothing. But if an operation ignores attributes without telling the client, that can create problems too. I think that we have painted ourselves into a corner here. a) If we keep the current behavior of rejecting operations that have unsupported operation attributes, we have to rev the major version with each new operation attribute which will create a lot of needless versions to deal with. b) If we allow operations with unsupported operation attributes, then all operations responses need to be able to contain a list of ignored operation attributes (yet another change); otherwise clients won't know how to interpret a response. c) If we believe that a client should be able to choose between a strict and forgiving operation, then we also need to add the operation attribute "ipp-operation-fidelity". Bob Herriot From ipp-owner@pwg.org Tue Nov 25 20:11:38 1997 Delivery-Date: Tue, 25 Nov 1997 20:11:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA02600 for ; Tue, 25 Nov 1997 20:11:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA09707 for ; Tue, 25 Nov 1997 20:14:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA09458 for ; Tue, 25 Nov 1997 20:11:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 20:06:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08899 for ipp-outgoing; Tue, 25 Nov 1997 19:53:54 -0500 (EST) Message-Id: <3.0.1.32.19971103084508.00c25900@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 3 Nov 1997 08:45:08 PST To: ipp@pwg.org From: Marcia Beaulieu (by way of Carl-Uno Manros ) Subject: IPP> Re: IPP conflict with TLS in DC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I just got the following message from the IETF, confirming that our IPP meeting has ben moved to Wednesday afternoon. If you plan to be in Washington, DC, please take note. Carl-Uno ---- This is to confirm that IPP has been moved to Wednesday at 1300-1500 opposite ldapext, dhc, roamops, ospf, smime, avt Marcia ********************************************************************** Marcia Beaulieu IETF Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-758-5913 From ipp-owner@pwg.org Tue Nov 25 22:12:43 1997 Delivery-Date: Tue, 25 Nov 1997 22:12:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA03338 for ; Tue, 25 Nov 1997 22:12:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA09898 for ; Tue, 25 Nov 1997 22:15:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA11283 for ; Tue, 25 Nov 1997 22:12:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 22:08:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA10704 for ipp-outgoing; Tue, 25 Nov 1997 21:55:44 -0500 (EST) Date: Tue, 25 Nov 1997 18:54:45 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199711260254.SAA28805@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP>MOD add another issue [encoding of CompoundValue] X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I will try to explain the issue by giving more detail. The compoundValue has an integer value which specifies the number of following values that compose the compound value. There are two obvious ways to implement compoundValue in a general way: 1) recurse looking for additional values until the correct number is found or until a non-null attribute name is found or a delimiter tag is found. The latter two conditions are errors. This method works, but is tricky the "nested" values are really at the same level as other values in the protocol. 2) continue picking up values, but make a note that a compoundValue is being built. In this case, there must be a check when a non-null name is encountered, and when a delimiter tag is found for the error of a compoundValue is still being built. At first glance, this seems simpler, but it is easy to forget the checks mentioned above. Although compoundValue can be made to work, its complexity will lead to bugs. Also its type is determined by looking at all of the tags of values that it contains. This suggests that we should look for a simpler-to-implement option. The most obvious solution is to add two new types text-language and name-language which are the langauge constrained versions of text and name. Attributes with text and name values could also have a value of type text-language or name-language. Tom and others have suggested that language and text/name be separated by a single-quote character. It would work, but is not in the spirit of the current protocol which uses lengths instead of delimiting characters. So I suggest the value be . The length of the text/name string is length of the value minus ( language-length + 2). This solution is easier to parse because the components are contained with a single value. If we believe that tags are in short supply and that we don't want to allocate two values for such obscure types, we could create a tag type of "typed-octets" where the first byte of the value contains the sub-tag value which in our case would be either text-language or name-language. We could also have 2 bytes for the sub-tag rather than 1. > From hastings@cp10.es.xerox.com Mon Nov 24 10:46:48 1997 > > As long as you've re-opened this issue, I'd like to add several > other alternatives into the mix. (A committee is better able to > pick between alternatives, than to design one on the fly). > > On the other hand, it may be better to live with the current scheme > than to try to pick a new one. > > At 19:48 11/21/1997 PST, Robert Herriot wrote: > > > >As I am implementing the CompoundValue, I am finding problems that make > >me think it should be changed. It requires too much special-casing and > >in its current form it will introduce bugs where the value of the > >CompoundValue exceeds the number of remaining attributes for the > >attribute name or attribute group. To avoid those bugs, checks have to > >be made in several places. > > Please explain this problem more. > > > > >I suggest we reexamine the other possible solutions, one simple with > >no room for extension, the other with room for extension. > > > > a) add two new value types: text-language and name-language each of which > > is a single value in the protocol but which consists of 4 subfields: > > a text/name length field, a text/name field, a language length field, > > and a language field, . > > > > b) add a single new type: compound-value which consists of a single value > > in the protocol but which consists of a value-tag field followed by > > any number of groups-of-three subfields. Each group-of-three > > consists of a value tag, a value length and a value. The text-language > > solution of a) is represented by a text-language tag, a text tag, a > > text length, a text value, a natural-language-tag, a natural-language > > length and a natural-language value. > > > >I prefer b) because it offers room for extension and an implementation can > >determine if it supports the compound value by examining the initial > >tag in the compoundValue. > > Here are my additional alternatives: > > > c) Amplify the 'text' and 'name' attribute syntaxes to allow a second > natural language override value to precede the actual value which indicates > the language of the immediately following value. The attribute syntax of > the first value, when present, is: 'naturalLanguage' as defined in the > current spec. > > Advantages: simple > > Disadvantages: a single-valued attribute sometimes has two values, making > the validation of single-valued attributes more adhoc. Also counting > attribute values is more adhoc. > > > d) have two data types for each of 'text' and 'name': > 'text' (same as current) and 'taggedText' > 'name' (same as current) and 'taggedName' > > The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging > in the beginning of the data (but for language only, not charset) > to indicate natural language override: > > en'... > en-us'... > > to indicate English and U.S. English > > Those attributes which currently have 'text' and 'name' would > be changed to require support of both 'text' and 'taggedText' > and 'name' and 'taggedName' > > For example: > > job-name (name | taggedName) > > Advantages: most request/response instances would not need to use the > taggedText and taggedName in most interchanges. > > Disadvantages: clients and IPP objects would still have to support both > forms. > > > e) Change the spec for 'text' and 'name' to always require the RFC 2184 > natural language prefix (but not charset). > > Advantages: simple, natural language tag is always stored with the data. > Only one protocol value for each attribute value. > > Disadvantages: tag has to be skipped over when processing or displaying > the data. > > > f) Same as e) except include the charset tag as well, so in full compliance > with RFC 2184 (same as we had in the Model document after the Atlanta > meeting). Example: > > us-ascii'en'... > utf-8'en-us'... > > Advantages: simple, charset and natural language tag is always stored > with the data. Only one protocol value for each attribute value. > IPP object doesn't need to charset convert data to a single charset. > > Disadvantage: tags have to be skipped over when processing or displaying > the data. > > > g) Add the dictionary attribute syntax that we postponed. > > Advantages: It is even more general than your alternative b) and is > something we have agreed is something we want. I'd hate to see us > put in something that is half a dictionary. I think that the dictionary > also fixes the length checking problem that the current CompoundValue > has, correct? > > Disadvantages: None. > > Tom > > > > From ipp-owner@pwg.org Tue Nov 25 22:36:42 1997 Delivery-Date: Tue, 25 Nov 1997 22:36:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA05018 for ; Tue, 25 Nov 1997 22:36:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA09947 for ; Tue, 25 Nov 1997 22:39:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA11953 for ; Tue, 25 Nov 1997 22:36:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 25 Nov 1997 22:32:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA11379 for ipp-outgoing; Tue, 25 Nov 1997 22:20:18 -0500 (EST) Message-Id: <1.5.4.32.19971126021905.006766cc@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, 25 Nov 1997 18:19:05 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>IPP Last Call - need advance list of issues Sender: ipp-owner@pwg.org Yes, This is our main agenda point for the phone conference tomorrow. Carl-Uno At 09:28 AM 11/25/97 -0500, you wrote: >Carl-Uno, > >It would be extremely helpful if we all could have a list of the last call >issues we intend to discuss in Los Angeles >a day or two prior to the meeting so that we have a chance to think about them >a bit prior to the meeting. Even >if this came out on monday afternoon this would make the discussion at >Wednesday's IPP meeting a lot more >productive. Given where we are in the process, we need to make our meeting as >effective as possible. > >Thanks ... > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > From ipp-owner@pwg.org Wed Nov 26 02:42:59 1997 Delivery-Date: Wed, 26 Nov 1997 02:43:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA11438 for ; Wed, 26 Nov 1997 02:42:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA10372 for ; Wed, 26 Nov 1997 02:45:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA13068 for ; Wed, 26 Nov 1997 02:43:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 02:38:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA12509 for ipp-outgoing; Wed, 26 Nov 1997 02:26:23 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Additional comments on PRO + MOD docs... Date: Tue, 25 Nov 1997 23:24:08 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org NOTE: These comments are in addition to my security text proposals for both protocol and model documents. IPP Protocol Document Comments - Section 3 - "Network Byte Order" description I'm not sure I understand the use of the term "network byte order" when applied to 'character string' data types. I thought the term "network byte order" applied to only data types that have a least significant bit/byte and most significant bit/byte. Is our current wording correct? Section 3.10 Mapping of Attrribute Values In the description of the term "resolution", the word "ints is misspelled as "unts".....(FYI) Section 4 Has the port number 516 been allocated for IPP yet? Section 4.1 General Headers I think we can go ahead and remove the ISSUE statement about "HTTP experts". This document will hopefully be removed by those experts during IESG last call. Also, in section 4.1, the "Date" field should not reference RFC 1123, since all headers are implicitly defined by RFC 2068. RFC 2068 may indeed reference 1123, but we should keep HTTP 1.1 as the primary reference document for HTTP 1.1 headers. ------------------------------------------------------------------------ --------------------------------------------------- IPP Model Document Comments We've been careful about not replicating information in the protocol document that is defined by the model document. I think this philosophy should go both ways....hence most of my comments pertain to this idea... Section 3.1.2 Operation Targets I think the "Note:" section about HTTP 1.1 should be removed and covered by the protocol document. Section 3.2 Printer Operations Remove HTTP note... Section 3.3 Job Operations Move the HTTP rules to the protocol document (if they're not already there...) Section 4.3.1 job-uri The statement "This MUST be an HTTP schemed URI" should be removed. Section 4.4.1 printer-uri The statement "This MUST be an HTTP schemed URI" should be removed. Randy From ipp-owner@pwg.org Wed Nov 26 03:07:15 1997 Delivery-Date: Wed, 26 Nov 1997 03:07:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA11487 for ; Wed, 26 Nov 1997 03:07:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA10397 for ; Wed, 26 Nov 1997 03:10:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA13747 for ; Wed, 26 Nov 1997 03:07:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 03:02:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA13155 for ipp-outgoing; Wed, 26 Nov 1997 02:50:06 -0500 (EST) Message-Id: <3.0.1.32.19971125210931.010b57a0@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Nov 1997 21:09:31 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - My Last Call Model Comments Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id DAA11487 Subj: Last Call Model Comments from T. Hastings From: Tom Hastings Date: 11/25/97 File: ipp-model-last-call-comments-th.doc Editorial comments marked as [Editorial]. 1. [Editorial] Section 2.4, Object Identity, first line Change "object be identified" to "object are identified". 2. Section 3.2.1.1, Print-Job Request and Section 3.3.1.1 Send-Document Request The conformance requirement for "document-natural-language" was deleted. Re-instate the sentence: "A Printer object SHOULD support this attribute if it supports a document format that requires a natural language to be supplied in order to unambiguously image the document, such as 'text/plain' with Chinese and Japanese characters." 3. [Editorial] Section 3.1.4, Operation Status Codes and Messages Need to specify what the keyword name of the status message attribute is. The Protocol document says it is "status- message", so lets use that name here to keep the alignment. 4. Section 3.1.5.2, The "requesting-user-name" Operation Attribute ISSUE: The last two sentences say: "If the Printer object has access to a more authenticated representation of the user's id, the Printer object SHALL store that value instead of the value supplied by the client in the "requesting-user- name" operation attribute. Otherwise, the Printer object SHALL store the value supplied by the client in the "requesting-user-name" operation attribute." What if the client did not supply a "requesting-user-name" operation attribute? Suggest adding the following sentence: "In this case, if the client did not supply a "requesting-user-name" Operation attribute, the Printer SHALL make up a unique name, such as 'user150'." 5. Section 3.2.6.1 Get-Jobs Request Add "(1:MAX)" to "limit" (integer). 6. [Editorial] Section 3.2.6.1 Get-Jobs Request Drop the "not just my jobs" from the end of: "If the client does not supply this attribute, the Printer object SHALL respond as if the client had supplied the attribute with a value of 'false', i.e., all jobs not just my jobs." 7. Section 4.1.9 'mimeMediaType' In the sentence: "If the client supplies a document format value, the Printer SHOULD rely on the supplied attribute, rather than trust its auto-sensing algorithm." Change the "SHOULD" to "SHALL" to agree with the other changes in this paragraph. The Printer object MUST always obey the "document-format" attribute in a create operation. 8. [Editorial] Section 4.1.14 'dateTime' Change the sentence: "When accepting 'dateTime' values from users and displaying 'dateTime' values to users, clients SHOULD localize the values to the charset and natural language of the user." to be more like the 'enum': "DateTime values are for use in the protocol. A user interface will provide a mapping between protocol dateTime values and displayable user-friendly words and phrases which are localized to the natural language and date format of the user." 9. [Editorial] Section 4.1.15 'resolution' Add the sentence to the end: "The value '4' indicates dots per cm." 10. Section 4.2.4 multiple-document-handling ISSUE: How does the user that wants multiple documents to be stapled together, but wants the first impression of each document to start on a new sheet? Currently, the 'single- document' value requires impressions to come one side after the other, even on document boundaries. Possible solutions: Add a 'multiple-documents-finished- together' value or maybe call it 'single-job-finished-as- one' or … 11. Section 4.2.11, media (type4 keyword | name) ISSUE: The conformance of "media-ready" in not specified. Suggested solution: Specify that when supporting the "media" (and hence the "media-default" and "media-supported) attributes that the "media-ready" attribute is still OPTIONAL for a Printer object to support. 12. [Editorial] Section 4.4, Printer Description attributes Add "reference-uri-schemes-supported" to the table to agree with Section 4.4.23. 13. Section 4.4.19, printer-is-accepting-jobs and Section 13.1.5 Problem: What status code is returned when the value of the Printer's "printer-is-accepting-jobs" is 'false'? Solution: Suggest adding: 'server-error-not-accepting- jobs' status code, as a server error, not a client error, to this section. So add the phrase: "and returning the status code: 'server-error-not-accepting-jobs'. Add to Section 13.1.5: 3.1.5.7 server-error-not-accepting-jobs A temporary error indicating that the Printer is not currently accepting jobs, because the administrator has set the value of the Printer's "printer-is-not-accepting-jobs" attribute to 'false' (by means outside of IPP/1.0). 14. Section 4.4, Printer Description Attributes Do we need to add a "version-supported" or "major-version- supported" multi-valued attribute? Or does the version number that comes back in the version number field in the error response suffice (see last comment below)? 15. [Editorial] Section 11, Author's names Add Xavier Riley - Xerox Corp. to the list of participants. He has contributed to the security in particular. 16. [Editorial] Section 12.2.3, Supports Last paragraph, change "an system administrator" to "a system administrator". 17. Section 13.1.5.4, server-error-version-not-supported The sentence "The response SHOULD contain a Message describing why that version is not supported and what other versions are supported by that IPP object" has a problem. While it helps the user understand why the request was refused, the client has no idea which versions are supported. However, if the IPP object returned in the version field of the response the version that it does support, then the client would have a clue as to what to try next. So add the sentence to the end of the first paragraph: "The response SHALL identify the protocol version number in the version number field of the version that the IPP object does support, since the response is following the conformance requirements for that version of the protocol." From ipp-owner@pwg.org Wed Nov 26 04:59:21 1997 Delivery-Date: Wed, 26 Nov 1997 04:59:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA12118 for ; Wed, 26 Nov 1997 04:59:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA10504 for ; Wed, 26 Nov 1997 05:02:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA14463 for ; Wed, 26 Nov 1997 04:59:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 04:53:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA13910 for ipp-outgoing; Wed, 26 Nov 1997 04:41:04 -0500 (EST) Message-Id: <3.0.1.32.19971125230021.010c9e00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Nov 1997 23:00:21 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Processing algorithm - from Bob, Scott, Roger, and Tom Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org This work in progress on Section 15.3 and the new 15.4 sections. The specific comments to the rest of the document as a result are included first. I've put the ipp-section-15-3-rev.pdf and ipp-section-15-3.pdf and ipp-section-15-3.txt (same as embedded here) in ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3.pdf We'll have a final version next Monday or Tuesday. Tom Subj: Comments on the document that relate to the processing algorithm From: Roger deBry, Tom Hastings, Bob Herriot, Scott Isaacson, Date: 12/25/97 File: ipp-section-15-3.doc Revisions made after telecon, Monday, 11/24/97 with Roger and Scott. The new revision marks are in one color, and the older ones are in another. Here are some comments on the current draft of the Model document: 1. Section 3, Operations The validation of all Operation attributes is independent of the "ipp- attribute-fidelity" attribute. The "ipp-attribute-fidelity" only applies to Job Template attributes in create and Validate-Job requests. 2. Section 3, Operations The Model document should indicate for each request and response group whether the Operation attributes are MANDATORY for the IPP object to support and whether they are required for the client to supply and/or the IPP object to return or not, just as for attributes. 3. Section 3.1.6, Version Should be able to add OPTIONAL (for an IPP object to support) Operation attributes as a minor version change, not a major version change. Adding MANDATORY Operation attributes requires a major version change. 4. Section 3.2.1.2, Print-Job response Third to last paragraph: only return the attributes in conflict that are ignored or substituted, not the ones that are ok. For example, if the Printer object resolves the conflict: "media" = 'transparencies' and "finishings" = staple by ignoring "finishings", then only "finishing"='staple' should be returned in the Unsupported Attributes Group. 5. Section 3.2.5, Get Attributes (for Printer objects) As agreed on the 11/19 IPP telecon, the name space for Operation attributes and Job Template attributes is the same, so we can't use the same name for both an Operation attribute and a Job Template attribute, though we can use the same name for an Operation attribute whose purpose is to initialize a Job Description attribute, such as "job-name", "attributes-charset", or "attribute-natural-language". Therefore, we suggest that the "document-format" Operation attribute in the Get-Attributes (for Printer object) be changed to "which- document-format" to give a different name, and to align with the "which-jobs" Operation attribute. 6. Section 3.2.5.1, Get-Attributes Request Change the "which-document-format" to MANDATORY (for a Printer object to support and change to reject the operation and return the 'client- error-document-format-not-supported' status code if the document format is not supported, but change the definition of support so that it aligns with the validation that the Printer does for create operations. See separate e-mail on 11/14/97. 7. Section 3.2.6.1 Get-Jobs Request Make "which-jobs" and "my-jobs" MANDATORY for an IPP object to support and require support of both values for each. Clarify that support of 'completed' for a system that doesn't keep jobs after they complete, is to always return no jobs. 8. Section 3.3.1.2, Send-Document Response Writing the table on attribute groups, we found that the Send-Document (and Send-URI) operation needs to return the Unsupported Attributes group as group 3 if the client supplies unsupported attributes. Section 3.3.4, Get-Attributes Operation (for Job objects) Needs to return the Job Object Attributes, not the Printer Object Attributes group in the response. So add a phrase to the last sentence indicating this difference from the Get-Attributes Operation (for Printer objects): "and the returned attribute group is Job Object Attributes, instead of Printer Object Attributes." 9. Section 4.2, Job Template Attributes The following four Job Template attributes should move to become create Operation attributes and Job Description attributes: "compression", "job-k-octets", "job-impressions", and "job-media- sheets". These attributes are describing the job, not requesting some type of processing. The corresponding "compression-supported", "job-k- octets-supported", "job-impressions-supported", and "job-media-sheets- supported" become Printer Description attributes. Also none of these four attributes had "xxx-default" attributes, further indicating that they are different from Job Template attributes. These four Operation attributes are OPTIONAL for Printers to support, so some Operation attributes are OPTIONAL for a Printer to support and some are MANDATORY. Clients NEED NOT supply these Operation attributes, just as when they were Job Template attributes. 10. Section 4.2 Job Template Attributes table Change the attribute syntax of "copies-supported" and "copies-collated- supported" to rangeOfInteger, so like all other integer attributes which simplifies validation and so an administrator can specify a lower bound. 11. Section 4.2, Job Template Attributes table and Section 4.2.5 copies Do we need "copies-collated-supported" and "copies-collated-default? It make the Job Template validation more ad hoc for "copies". Also, the limit on uncollated copies is not for uncollated sheets in a copy, but uncollated documents in a multi-document job, so that neither are addressing a multi-output-bin collator which might have a different (lower) maximum copies supported than when the device makes multiple passes over the PDL (or interpreted bit maps) and uses a single output bin. 12. Section 4.4, Printer Description attributes table and Sections 4.4.17 document-format and 4.4.18 document-format-supported The "document-format" and "document-format-supported" Printer attributes need to be MANDATORY. A client has to be able to query them. 13. Section 13.1.4.12, client-error-attribute-not-supported (0x040B) and Section 13.2 Change the name to include values and make plural: client-error- attributes-or-values-not-supported (0x040B), since there is a distinction between an attribute not supported and an attribute value not supported, but both are returned on this error. 14. Section 15.3, Suggested Operation Processing Algorithm for Create and Validate-Job operations Make this section apply to all operations. Add a subsequent section that has the additional processing steps for create and Validate-Job operations. 15. Section 15.3, Suggested Operation Processing Algorithm for Create and Validate-Job operations Add the semantics for all of the Operation attributes. The following revised version of Section 15.3 is offered to meet the above comments. 15.3 Suggested Operation Processing Algorithm for all operations When an IPP object receives a request, the IPP object either accepts or rejects the request. In order to determine whether or not to accept or reject the request, the IPP object SHOULD use the following algorithm or an equivalent one that produces the same results. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request. Therefore, the error status codes returned may differ between implementations when there is more than one error in a request. The next section contains the additional steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send- Document, and Send-URI operations that create jobs, adds documents, and validates jobs. The table below contains abbreviations for operations used in the other tables in this section: Abbr Operation Abb Operation Abbr Operation r pj Print-Job sd Send-Document gap Get-Attribute (Printer) cj Create- su Send-URI gaj Get-Attribute Job (Job) vj Validate- caj Cancel-Job gj Get-Jobs Job pu Print-URI In the following algorithm, processing continues step by step until a "RETURNS the xxx status code ..." statement is encountered. Error returns are indicated by the verb: "REJECTS". Each error return to the client SHOULD be made before the entire Document Content data stream is accepted, so that the client need not send all of the data for a request that is being rejected. It is assumed that security authentication and authorization has already taken place at a lower layer. 15.3.1 Validate version number The Printer object checks to see if the requested major and minor version number is supported. If not, the Printer object REJECTS the request and RETURNS the 'server-error-version-not-supported' status code in the response. The checking of the minor version number is implementation dependent. Some implementations MAY accept all minor version numbers, while others MAY only accept ones that are equal to or lower than the highest one that they support. ISSUE: Do we need a "version-supported" attribute? If yes, it should be multi-valued. How indicate support of future minor versions? Or just make it "major-version-supported" (but multi-valued). 15.3.2 Validate operation code The Printer object checks to see if the operation is supported as indicated in the Printer object's "printer-operations-supported" attribute. If not, the Printer REJECTS the request and returns the 'server-error-operation-not-supported' status code in the response. 15.3.3 Validate attribute group presence and order Client requests and IPP object responses contain attribute groups in the order in Section 4. An IPP object verifies that the attribute groups are present and in the correct order. If an IPP object receives a request with required attribute groups missing or the attributes groups are out of order, the IPP object REJECTS the request and returns the 'client-error-bad-request' status code. For example, it is an error for the Job Template Attributes group to occur before the Operation Attributes group, for the Operation Attributes group to be omitted, or for an attribute group to occur more than once, except the Get-Jobs request. The numbers indicate the required order for the groups in a request or a response. Note: The Document Content group is supplied and is empty for the Create-Job, Validate-Job, Print-URI, and Send-URI requests. Operation Attribute Group Client: IPP object: Printer operations: Print-Job 1. Operation SHALL SHALL Create-Job Attributes supply support Print-URI request: 2. Job Template MAY supply SHALL Attributes support 3. future groups SHALL ignore 4. Document SHALL SHALL Content supply support response: 1. Operation SHALL supply Attributes 2. Job Object SHALL supply Attributes 3. Unsupported SHALL supply Attributes if the client supplied unsupported Operation or Job Template attributes Validate-Job 1. Operation SHALL SHALL Attributes supply support 2. Job Template MAY supply SHALL Attributes support 3. future groups SHALL ignore response: 1. Operation SHALL supply Attributes 2. Job Object SHALL supply Attributes 3. Unsupported SHALL supply Attributes if the client supplied unsupported Operation or Job Template attributes Get- 1. Operation SHALL SHALL Attributes Attributes supply support request (for a Printer object): 2. future groups SHALL ignore response: 1. Operation SHALL supply Attributes 2. Requested SHALL Printer Object supply, if Attributes there are any Printer attributes to return 3. future SHALL ignore additional groups Get-Jobs 1. Operation SHALL SHALL request: Attributes supply support response: 1. Operation SHALL supply Attributes 2. future SHALL ignore additional groups 3 to n. Requested SHALL supply Job Object 0 to n Attributes groups Job operations: Send- 1. Operation SHALL SHALL Document, Attributes supply support Send-URI 2. future groups SHALL ignore 3. Document SHALL SHALL Content supply support response: 1. Operation SHALL supply Attributes 2. Job Object SHALL supply Attributes 3. Unsupported SHALL supply Attributes if the client supplied any unsupported attributes Cancel-Job 1. Operation SHALL SHALL request: Attributes supply support response: 1. Operation SHALL supply Attributes Get- 1. Operation SHALL SHALL Attributes Attributes supply support request (for a Job object): 2. future groups SHALL ignore response: 1. Operation SHALL supply Attributes 2. Requested Job SHALL Object Attributes supply, if there are any Job attributes to return All unknown group in SHALL ignore operations indicated position requests: Unknown group in SHALL REJECT another position response: unknown group SHALL ignore Since this kind of error is most likely to be an error detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute group was out of order in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute group errors before returning this error. 15.3.4 Validate presence of required Operation attributes If the client fails to supply an Operation attribute that clients MUST supply, the IPP object returns the 'client-error-bad-request' status code. Operation Attribute Operations attributes-charset all attributes-natural- all language document-uri pu, su job-id (when to sd, su, caj, Printer URI) gaj last-document sd, su Since this kind of error is most likely to be an error detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attributes are missing in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all missing Operation attributes before returning this error. 15.3.5 Ignore unsupported Operation attributes An IPP object ignores all unsupported Operation attributes in all operations. For the create operation, this rule is independent of the value of the "ipp-attribute-fidelity" attribute. In order to inform the client of an unsupported Operation attribute, an IPP object copies such an Operation attribute to the Unsupported Attributes group in the response [renamed 'unsupported-attributes' delimiter tag in the Protocol document and change the value to the out-of-band 'unsupported' value]. When the operation is otherwise successful, the IPP object returns the 'successful-ok-ignored-or-substituted-attributes' status code. This treatment of unsupported Operation attributes in all operations is analogous to the handling of unsupported Job Template attributes in the create and Validate-Job operations when the client supplies the "ipp-attribute-fidelity" Operation attribute with the 'false' value. Rationale: This rule is so that we can add OPTIONAL Operation attributes to future versions of IPP so that older clients can inter- work with new IPP objects and newer clients can inter-work with older IPP objects. 15.3.6 Validate the values of the MANDATORY Operation attributes An IPP object validates the values of the MANDATORY Operation attribute supplied by the client that the IPP object MUST support. The next section specifies the validation of the values of the OPTIONAL Operation attributes that IPP objects MAY support. The IPP object performs the validation action indicated in the following table Each xxx attribute is checked against the following: a) that the length of each value is correct for the attribute syntax tag supplied by the client according to Section 4.1. b) that the attribute syntax tag is correct for the attribute in Sections 4.2 to 4.6, c) that the value is in the range specified for that attribute in Sections 4.2 to 4.6, d) the multiple values are not supplied for attributes that are single-valued, i.e., that are not 1setOf X) as specified in Sections 4.2 to 4.6 If any of these checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request'. Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. In addition, the IPP object checks the value against some Printer attribute or some hard-coded value if there is no "xxx-supported" Printer attribute defined. The check fails if its value is not among those supported and the IPP object RETURNS in error status code indicated in the table. Operation Operation Validation check Attributes s xxx attributes- all Any single non-empty 'charset' value charset less than 63 octets AND in the (charset) Printer's "charset-supported" attribute; else REJECT with "client-error-charset- not-supported" attributes- all Any single non-empty 'naturalLanguage' natural- value less than 63 octets, even if not language a member of the set in the Printer's (naturalLangu "natural-language-supported" attribute. age) "requesting- all Any single non-empty 'name' value less user-name" than 255, but if the IPP object can obtain a better authenticated name, use it instead. job-name pj, vj, Any single non-empty 'name' value less (name) pu, cj than 255. document-name pj, vj, Any single non-empty 'name' value less (name) pu, sd, than 255. su ipp-attribute- pj, vj, Either a single 'true' or 'false' fidelity pu, cj, 'boolean' value. (boolean) sd, su document- pj, vj, Any single non-empty 'mimeMediaType' format pu, cj, value less than 63 octets AND in the (mimeMediaTyp sd, su Printer's "document-format-supported" e) attribute else REJECT with 'client-error-document- format-not-supported' document-uri pu, su Any single non-empty 'uri' value less (uri) than 1023 octets AND whose scheme is in the Printer object's "reference-uri- schemes-supported" attribute else REJECT with 'client-error'-uri- scheme-not-supported' last-document sd, su Either a single 'true' or 'false' (boolean) 'boolean' value. job-id sd, su, Any single integer value in the range 1 (integer(1:MA caj, gaj to MAX AND a job-id of an existing Job X)) object else REJECT with the 'client-error-not- found' or 'client-error-gone' status code, if keep track or recently deleted jobs which- gap Any single non-empty 'mimeMediaType' document- value less than 63 octets format else REJECT with "client-error-document- (type2 format-not-supported" mimeMediaType ) If not supplied by the client, the Printer assumes the value of the Printer's "document-format" attribute. requested- gap, gaj, Any number of 'keyword' values less attributes gj than 255 octets (1setOf Ignore unsupported values which are the keyword) keyword names of unsupported attributes. Don't bother to copy such requested (unsupported) attributes to the Unsupported Attribute response group. which-jobs gj Either a single 'not-completed' or (type2 'completed' keyword value keyword) Note: a Printer still supports the 'completed' value even if it keeps no completed/canceled/aborted jobs: by returning no jobs when so queried. my-jobs gj Either a single 'true' or 'false' (boolean) 'boolean' value. limit gj Any single integer value in the range 1 (integer(1:MA to MAX X)) ISSUE: We propose to make "which-jobs" and "my-jobs" MANDATORY for an IPP object to support. 15.3.7 Validate the values of OPTIONAL Operation attributes supported OPTIONAL Operation attributes are those that an IPP object MAY or MAY NOT support. An IPP object validates the OPTIONAL attribute supplied by the client that IPP object supports. The IPP object performs the validation action indicated in the following table. Each xxx attribute that the Printer recognizes is validated as in Section 15.3.6. If the Printer object doesn't recognize/support an attribute (whether it is in this table or not), the Printer treats the attribute as an unknown attribute (see the unknown row in the table below). For example, if a printer doesn't support "job-k-octets" (because of the implementation or because of some administrator's choice), the Printer treats "job-k-octets" as an unknown attribute. Operation Operatio Validation check Attributes ns xxx document- pj, pu, Any single non-empty 'naturalLanguage' natural- sd, su value less than 63 octets that the language Printer supports, (no standard Printer (naturalLangu "xxx-supported" attribute) age) else REJECT with 'client-error-natural- language-not-supported' compression pj, vj, Any single 'keyword' values less than (type3 cj, pu 255 octets AND in the Printer's keyword) "compression-supported" else REJECT with 'client-error-attribute- or-value-not-supported'. job-k-octets pj, vj, Any single integer value in the range 0 (integer(0:MA pu , cj to MAX AND in the range of the Printer's X)) "job-k-octets-supported" else REJECT with the 'client-error- attribute-or-value-not-supported' job- pj, vj, Any single integer value in the range 0 impressions pu , cj to MAX AND in the range of the Printer's (integer(0:MA "job-impressions-supported" X)) else REJECT with the 'client-error- attribute-or-value-not-supported' job-media- pj, vj, Any single integer value in the range 0 sheets pu , cj to MAX AND in the range of the Printer's (integer(0:MA "job-media-supported" X)) else REJECT with the 'client-error- attribute-or-value-not-supported' message caj Any single non-empty 'text' value less (text) than 1023 octets. unknown all not applicable attribute ISSUE: the "document-format" Operation attribute is proposed to be changed to "which-document-format" in the Get Attributes (from Printer) operation, so that it isn't confused with the "document- format" Operation attribute that is used in pj, cj, vj, pu, sd, and su to identify the document format of the document being submitted. 15.4 Suggested Additional Processing for Operations that create jobs This section is combination with the previous section recommends the processing algorithm, or equivalent, for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations that create jobs the IPP objects SHOULD use. 15.4.1 Default "ipp-attribute-fidelity" if not supplied The Printer object checks to see if the client supplied an "ipp- attribute-fidelity" Operation attribute. If the attribute is missing (not supplied by the client), the Printer assumes that the value is 'false'. 15.4.2 Validation of Job Template attributes and values All Job Template attributes are OPTIONAL for a Printer object to support. An IPP object validates all Job Template attribute supplied by the client that IPP object supports. The IPP object performs the action indicated in the following table when the value is not a supported value (bad syntax has already been checked above). The Printer object loops through all the client-supplied Job Template attributes, checking to see if the supplied attribute and values are supported, e.g., the value of the "xxx" attribute in the request is one of the values in the Printer's "xxx-supported" attribute. If an attribute is not supported, i.e., there is no corresponding Printer object "xxx-supported" attribute, the Printer object copies the attribute to the Unsupported Attribute response group and sets its value to the out-of-band 'unsupported' value.. If an attribute value is not supported, i.e., there is no corresponding value in the Printer object's "xxx-supported" attribute, the Printer object copies the attribute to the Unsupported Attributes response group with its value. If the attribute contains more than one value, each value is checked and each unsupported value is separately copied, while supported values are not. If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation. The table below lists the Job Template attributes and shows what the Printer does if a value is unsupported. All are OPTIONAL for a Printer to support. Each "xxx" attribute that the Printer recognizes is checked against a printer attribute with the name "xxx-supported" (after "copies-collated-supported" gets removed) to determine if the value is supported. If the Printer doesn't recognize/support an attribute, the Printer treats the attribute as an unknown attribute (see the unknown rows in the table below). Note: whether the request is accepted or rejected is determined by the value of the "ipp-attributes-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined. Job Template Attribute IPP object action when the attribute is xxx supported, but the value is not job-priority Map the value, which has already been (integer(1:100)) checked to be between 1 and 100 to the nearest supported value in the range 1:100 as specified by the Printer's "job- priority-supported" attribute. job-hold-until Copy the attribute and value to the (type4 keyword | name) Unsupported Attribute response group, if not a member of the set in Printer's "job- hold-until-supported" attribute. job-sheets Copy the attribute and value to the (type4 keyword | name) Unsupported Attribute response group, if not a member of the set in Printer's "job- sheets-supported" attribute. multiple-document- Copy the attribute and value to the handling Unsupported Attribute response group, if (type2 keyword) not a member of the set in Printer's "multiple-document-handling-supported" attribute. copies Copy the attribute and value to the (integer(1:MAX)) Unsupported Attribute response group, if not a member of the rangeOfInteger in Printer's "copies-supported" attribute or "copies-collated-supported" attribute, depending on the value of the "multiple- document-handling" attribute. finishings Copy the attribute and value to the (1setOf type2 enum) Unsupported Attribute response group, if not a member of the set in Printer's "finishings-supported" attribute. page-ranges Copy the attribute and value to the (1setOf Unsupported Attribute response group, if rangeOfInteger(1:MAX)) the Printer's "page-ranges-supported" attribute is 'false'. sides Copy the attribute and value to the (type2 keyword) Unsupported Attribute response group, if not a member of the set in Printer's "sides-supported" attribute. number-up Copy the attribute and value to the (integer(0:MAX)) Unsupported Attribute response group, if not a member of the set of integer or rangeOfInteger in Printer's "number-up- supported" attribute. orientation Copy the attribute and value to the (type2 enum) Unsupported Attribute response group, if not a member of the set in Printer's "orientation-supported" attribute. media Copy the attribute and value to the (type4 keyword | name) Unsupported Attribute response group, if not a member of the set in Printer's "media-supported" attribute. printer-resolution Copy the attribute and value to the (resolution) Unsupported Attribute response group, if not a member of the set in Printer's "printer-resolution-supported" attribute. print-quality Copy the attribute and value to the (type2 enum) Unsupported Attribute response group, if not a member of the set in Printer's "print-quality-supported" attribute. unknown attribute Copy the attribute to the Unsupported Attribute response group and set the value to the out-of-band 'unsupported' value. ISSUE: We propose to change "copies-supported" a rangeOfInteger, so like all the others and so can have a lower bound. 15.4.3 Check for conflicting Job Template attributes Once all the Operation and Job Template attributes have been checked individually, the Printer object SHOULD check for any conflicting values among all the supported values supplied by the client. For example, a Printer object might be able to staple and to print on transparencies, however due to physical stapling constraints, the Printer object might not be able to staple transparencies. The IPP object copies the supported attributes and their conflicting attribute values to the Unsupported Attributes response group. The Printer object only copies over those attributes that the Printer object either ignores or substitutes in order to resolve the conflict, and it returns the original values which were supplied by the client. For example suppose the client supplies "finishings" equals 'staple' and "media" equals 'transparency', but the Printer object does not support stapling transparencies. If the Printer chooses to ignore the stapling request in order to resolve the conflict, the Printer objects returns "finishings" equal to 'staple' in the Unsupported Attributes response group. If any attributes are multi-valued, only the conflicting values of the attributes are copied. 15.4.4 Decide whether to REJECT the request If there were any unsupported attributes or unsupported/conflicting attribute values and the client supplied the "ipp-attribute-fidelity" attribute with the 'true' value, the Printer object REJECTS the request and return the status code: (1) 'client-error-conflicting-attributes' status code, if there were any conflicts (2) 'client-error-attribute-not-supported' status code, otherwise. 15.4.5 Return one of the success status codes, if the Validate-Job operation If the requested operation is the Validate-Job operation, the Printer object returns: (1) the "successful-ok" status code, if there are no unsupported or conflicting attributes or values. (2) the "successful-ok-conflicting-attributes, if there are any conflicting attribute or values. (3) the "successful-ok-ignored-or-substituted-attributes, if there are only unsupported attributes or values. 15.4.6 Create Job object with attributes to support If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by the client), the Printer object: (1) removes all unsupported attributes from the Job object. (2) for each unsupported value, removes either the unsupported value or substitutes the unsupported attribute value with some supported value. If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute). (3) for each conflicting value, removes either the conflicting value or substitutes the conflicting attribute value with some other supported value. If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute). If there were no attributes or values flagged as unsupported, or the value of 'ipp-attribute-fidelity" was 'false', the Printer object is able to accept the create request and create a new Job object. If the "ipp-attribute-fidelity" attribute is set to 'true', the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request. If the "ipp- attribute-fidelity" attribute is set to 'false', the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes may not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get- Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object. Note: All Job Template attributes that are persistently stored with the Job object are intended to be "override values"; that is, they that take precedence over whatever other embedded instructions might be in the document data itself. However, it is not possible for all Printer objects to realize the semantics of "override". End users may query the Printer's "pdl-override" attribute to determine if the Printer either attempts or does not attempt to override document data instructions with IPP attributes. There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object; only Job Template attributes actually in the create request are used to populate the Job object. The Printer's default values are only used at Job processing time if no other IPP attribute or instruction embedded in the document data is present. Note: If the default values associated with Job Template attributes that the client did not supply were to be used to populate the Job object, then these values would become "override values" rather than defaults. If the Printer supports the 'attempted' value of the "pdl- override" attribute, then these override values could replace values specified within the document data. This is not the intent of the default value mechanism. A default value for an attribute is used only if the create request did not specify that attribute (or it was ignored when allowed by "ipp-attribute-fidelity" being 'false') and no value was provided within the content of the document data. If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined. 15.4.7 Return one of the success status codes Once the Job object has been created, the Printer object accepts the request and returns to the client: (1) the 'successful-ok' status code, if there are no unsupported or conflicting attributes or values. (2) the 'successful-ok-conflicting-attributes' status code, if there are any conflicting attribute or values. (3) the 'successful-ok-ignored-or-substituted-attributes' status code, if there are only unsupported attributes or values. The Printer object also returns Job status attributes that indicate the initial state of the Job ('pending', 'pending-held', 'processing', etc.), etc. See Print-Job Response, section Error! Reference source not found.. 15.4.8 Accept appended Document Content The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing. 15.4.9 Scheduling and Starting to Process the Job The Printer object uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer object begins processing the Job, the Printer changes the Job's state to 'processing'. If the Printer object supports PDL override (the "pdl-override" attribute set to 'attempted'), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the document data. 15.4.10 Completing the Job The Printer object continues to process the Job until it can move the Job into the 'completed' state. If an Cancel-Job operation is received, the implementation eventually moves the Job into the 'canceled' state. If the system encounters errors during processing that do not allow it to progress the Job into a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state. 15.4.11 Destroying the Job after completion Once the Job moves to the 'completed', 'aborted', or 'canceled' state, it is an implementation decision as to when to destroy the Job object and release all associated resources. Once the Job has been destroyed, the Printer would return either the "client-error-not- found" or "client-error-gone" status codes for operations directed at that Job. 15.4.12 Interaction with "ipp-attribute-fidelity" Some Printer object implementations may support "ipp-attribute- fidelity" set to 'true' and "pdl-override" set to 'attempted' and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the document data and external job instructions that accompany the document data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, "ipp-attribute-fidelity" and "pdl-override", apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for "number-up". From ipp-owner@pwg.org Wed Nov 26 14:01:15 1997 Delivery-Date: Wed, 26 Nov 1997 14:01:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA19843 for ; Wed, 26 Nov 1997 14:01:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA12197 for ; Wed, 26 Nov 1997 14:04:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15523 for ; Wed, 26 Nov 1997 14:01:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 13:47:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14910 for ipp-outgoing; Wed, 26 Nov 1997 13:35:37 -0500 (EST) Message-Id: <3.0.1.32.19971104012233.00c5fe90@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 01:22:33 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Phone Conference into PWG IPP Meeting on December 3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, Several people have suggested that we organize a short phone conference into the PWG IPP Meeting in LA next week. I have therefore set up one as follows: Starting time: 2 pm PST on December 3, 1997 Duration: 1 hour Subject: Quick walktrough of issues and resolutions for Model and Protocol Phone Number: 1-800-857 5607 Passcode: cmanros Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Nov 26 14:10:40 1997 Delivery-Date: Wed, 26 Nov 1997 14:10:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA19970 for ; Wed, 26 Nov 1997 14:10:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA12249 for ; Wed, 26 Nov 1997 14:13:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16158 for ; Wed, 26 Nov 1997 14:10:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 14:06:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15184 for ipp-outgoing; Wed, 26 Nov 1997 13:51:52 -0500 (EST) Message-Id: <3.0.1.32.19971104014551.00988100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 01:45:51 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Last Call for Model and Protocol documents now closed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, The Last Call period for the Model & Semantics and the Protocol Specification documents is now closed. Thanks to Tom, Bob, Randy, Roger, Keith and others for taking the time to go through the texts and spot remaining things that were not clear enough or were inconsistent. Although we got quite a few comments, I cannot see that any of them are controversial or showstoppers. In most cases we have got proposed new texts for replacements or additions. We will spend the time in next week's face-to-face meeting and on the DL to try to reach consensus on resolutions for the points brought up as Last Call comments, so that we can present them during the IETF IPP WG meeting in Washington DC on December 10. We will make our final editing round after the IETF meeting and should then be ready to send the batch of IPP documents to the IESG before the Christmas Holidays. We are still waiting for the Rationale document to come out from the IETF secretariat. As soon as that is available I will initiate the WG Last Call on that too. I cannot imagine that we will get a lot of comments on that document. Again, thank you all for your efforts - the IPP group is a great team! Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From pwg-owner@pwg.org Wed Nov 26 20:34:21 1997 Delivery-Date: Wed, 26 Nov 1997 20:34:21 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25232 for ; Wed, 26 Nov 1997 20:34:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13209 for ; Wed, 26 Nov 1997 20:37:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA16910 for ; Wed, 26 Nov 1997 20:34:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 20:27:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16560 for pwg-outgoing; Wed, 26 Nov 1997 20:20:26 -0500 (EST) Message-Id: <3.0.1.32.19971104050502.00ade8b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 05:05:02 PST To: ipp@pwg.org, pwg@pwg.org, P1394@cp10.es.xerox.com From: Carl-Uno Manros Subject: PWG> ADM - Last minute information for PWG LA meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Hi, Here are few pieces of additional information that can be of use to you if you come to the LA meeting: 1) You will find the Crowne Plaza shuttles under the green signs when you come out from the baggage area. They are supposed to come by every 15-20 minutes, you can also use the free phones in the baggage area to phone the hotel directly. 2) They are just doing some repairs to the hotel entrance, use the smaller door round the corner for entry. 3) The PWG meeting will be held in the Bordeaux room (wine not included :-). We have the same room all week. 4) Do not believe that it is not raining in Southern California! This morning we had a real bad rainstorm, but the sun is now up again. You might need a raincoat or an umbrella. Temperatures are in the 70th. Looking forward to see many of you next week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Nov 26 20:41:07 1997 Delivery-Date: Wed, 26 Nov 1997 20:41:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25292 for ; Wed, 26 Nov 1997 20:41:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13219 for ; Wed, 26 Nov 1997 20:44:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17522 for ; Wed, 26 Nov 1997 20:41:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 26 Nov 1997 20:36:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16546 for ipp-outgoing; Wed, 26 Nov 1997 20:20:19 -0500 (EST) Message-Id: <3.0.1.32.19971104050502.00ade8b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 4 Nov 1997 05:05:02 PST To: ipp@pwg.org, pwg@pwg.org, P1394@cp10.es.xerox.com From: Carl-Uno Manros Subject: IPP> ADM - Last minute information for PWG LA meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, Here are few pieces of additional information that can be of use to you if you come to the LA meeting: 1) You will find the Crowne Plaza shuttles under the green signs when you come out from the baggage area. They are supposed to come by every 15-20 minutes, you can also use the free phones in the baggage area to phone the hotel directly. 2) They are just doing some repairs to the hotel entrance, use the smaller door round the corner for entry. 3) The PWG meeting will be held in the Bordeaux room (wine not included :-). We have the same room all week. 4) Do not believe that it is not raining in Southern California! This morning we had a real bad rainstorm, but the sun is now up again. You might need a raincoat or an umbrella. Temperatures are in the 70th. Looking forward to see many of you next week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From daemon Mon Dec 1 10:47:45 1997 Delivery-Date: Mon, 01 Dec 1997 10:54:00 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA16181 for ietf-123-outbound.10@ietf.org; Mon, 1 Dec 1997 10:47:33 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16147; Mon, 1 Dec 1997 10:47:29 -0500 (EST) Message-Id: <199712011547.KAA16147@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-02.txt Date: Mon, 01 Dec 1997 10:47:28 -0500 Sender: cclark@cnri.reston.va.us --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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-02.txt Pages : 9 Date : 26-Nov-97 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126115640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126115640.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Mon Dec 1 10:58:49 1997 Delivery-Date: Mon, 01 Dec 1997 11:04:51 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA16486 for ietf-123-outbound.10@ietf.org; Mon, 1 Dec 1997 10:58:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16317; Mon, 1 Dec 1997 10:52:28 -0500 (EST) Message-Id: <199712011552.KAA16317@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-03.txt Date: Mon, 01 Dec 1997 10:52:28 -0500 Sender: cclark@cnri.reston.va.us --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, R. Monsour, R. Pereira, M. Thomas Filename : draft-ietf-ippcp-protocol-03.txt Pages : 8 Date : 26-Nov-97 This document describes a protocol intended to provide lossless compression for Internet Protocol 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971126142603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126142603.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Dec 1 11:10:35 1997 Delivery-Date: Mon, 01 Dec 1997 11:10:35 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16916 for ; Mon, 1 Dec 1997 11:10:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02880 for ; Mon, 1 Dec 1997 11:13:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24178 for ; Mon, 1 Dec 1997 11:10:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Dec 1997 10:59:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23600 for ipp-outgoing; Mon, 1 Dec 1997 10:47:35 -0500 (EST) Message-Id: <199712011547.KAA16147@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-rat-02.txt Date: Mon, 01 Dec 1997 10:47:28 -0500 Sender: ipp-owner@pwg.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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-02.txt Pages : 9 Date : 26-Nov-97 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126115640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126115640.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Dec 1 16:36:32 1997 Delivery-Date: Mon, 01 Dec 1997 16:36:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA14961 for ; Mon, 1 Dec 1997 16:36:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04773 for ; Mon, 1 Dec 1997 16:39:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25612 for ; Mon, 1 Dec 1997 16:36:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Dec 1997 16:31:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25007 for ipp-outgoing; Mon, 1 Dec 1997 16:18:34 -0500 (EST) Message-Id: <3.0.1.32.19971201095323.00cb3e30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 1 Dec 1997 09:53:23 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Last Call for the IPP Rationale document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Folks, This is a formal request for final comments within the IETF IPP working group, prior to submitting the specification on to the IESG for consideration as an Informational RFC. The document has undergone considerable and repeated review and revision and we believe that we now have working group consensus on their adequacy. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Last Call is for 2 weeks. Hence, the period for working group comments will close on Monday, 15 December, 1997 (US pacific time reference). The relevant document is: Title : Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-02.txt Pages : 9 Date : 26-Nov-97 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt -- Carl-Uno Manros Co-chair IETF WG IPP Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Dec 1 17:13:16 1997 Delivery-Date: Mon, 01 Dec 1997 17:13:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23848 for ; Mon, 1 Dec 1997 17:13:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04941 for ; Mon, 1 Dec 1997 17:16:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26593 for ; Mon, 1 Dec 1997 17:13:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Dec 1997 17:08:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25803 for ipp-outgoing; Mon, 1 Dec 1997 16:55:29 -0500 (EST) Message-Id: <3.0.1.32.19971201104158.00b7d8e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 1 Dec 1997 10:41:58 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for IETF IPP WG Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Here is the final version of the IETF IPP WG Meeting Agenda: Internet Printing Protocol WG (ipp) Wednesday, December 10 1300-1500 ================================ Chairs: Steve Zilles Carl-Uno Manros AGENDA: discuss any remaining issues associated with the IPP WG I-Ds: - Requirements for an Internet Printing Protocol This document has been out for WG Last Call, with no comments. - Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol This document is currently out for WG Last Call, closing on December 15. - Mapping between LPD and IPP Protocols or later This document has been out for WG Last Call. A few editorial comments have been included in this updated draft. - Internet Printing Protocol/1.0: Model and Semantics This document has been out for WG Last Call. Resolutions to the comments are currently being worked on. - Internet Printing Protocol/1.0: Protocol Specification This document has been out for WG Last Call. Resolutions to the comments are currently being worked on. The emphasis of the IPP WG meeting will be on the last two documents. ---- The latest version of the overall IETF Meeting Agenda (dated November 26) can be found at: ftp://ftp.ietf.org/ietf/0mtg-agenda.txt ---- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Dec 1 22:05:45 1997 Delivery-Date: Mon, 01 Dec 1997 22:05:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18057 for ; Mon, 1 Dec 1997 22:05:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05811 for ; Mon, 1 Dec 1997 22:08:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA28458 for ; Mon, 1 Dec 1997 22:05:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Dec 1997 21:59:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27888 for ipp-outgoing; Mon, 1 Dec 1997 21:47:20 -0500 (EST) From: don@lexmark.com Message-Id: <199712020247.AA12732@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 1 Dec 1997 21:35:22 -0500 Subject: IPP> Is that it?/ A tome from home Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Well, they got me as IPP chair and I have no idea where they got the first two quotes but a little international publicity (Malaysia) is OK by me. I am sure this story is the result of the Paris IPP presentation I made early in November.... ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 12/01/97 09:31 PM --------------------------- November 28, 1997 ------------+-----------------------------+----------------------------- Is that it?/ A tome from home COMPUTIMES via Individual Inc. : page 30 WRITERS will be able to send their manuscripts over the Internet and have them published instantly if a standard being agreed by major printer manufacturers catches on. The Internet printing protocol (IPP) will make it possible to print out documents by locating its Web address and simply pressing the "print" button. Internet-enabled printers will be connected to a Web server and have their own unique address. When someone accesses the site, the computer and the printer will negotiate to establish whether the printer has the capability to do the job required. If it has, the document is downloaded as a word-processor document and printed exactly as it would be by a printer connected directly to the computer. "IPP will kill fax by offering high-quality printing, low telephone charges and multiple copies. "It will also eliminate couriers, because documents printed over the Internet will be regarded as originals," said Don Wright of Lexmark, who is also chairman of the IPP committee. "Internet printing could also make things easier for authors and students who need small numbers of large volumes such as theses printed out." Technology. Copyright 1997 The New Straits Times Press (Malaysia) Berhad <> [11-27-97 at 18:48 EDT, Copyright 1997, COMPUTIMES, File: c1127130.2wn] Entire contents (C) 1997 by INDIVIDUAL, Inc., 8 New England Executive Park West, Burlington, MA 01803. From ipp-owner@pwg.org Mon Dec 1 22:42:37 1997 Delivery-Date: Mon, 01 Dec 1997 22:42:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA19967 for ; Mon, 1 Dec 1997 22:42:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05878 for ; Mon, 1 Dec 1997 22:45:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29199 for ; Mon, 1 Dec 1997 22:42:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Dec 1997 22:38:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA28591 for ipp-outgoing; Mon, 1 Dec 1997 22:25:52 -0500 (EST) Message-ID: <34837FA9.DF3B6970@parc.xerox.com> Date: Mon, 1 Dec 1997 19:25:29 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: don@lexmark.com CC: ipp@pwg.org Subject: Re: IPP> Is that it?/ A tome from home References: <199712020247.AA12732@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > "IPP will kill fax by offering > high-quality printing, low telephone charges and multiple copies. I've been working on 'Requirements for Internet Fax' (draft-ietf-fax-requirements-XX.txt in the Internet Drafts directory, and a newer version at ftp://ftp.parc.xerox.com/pub/masinter/draft-ietf-fax-requirements-04bis.txt). The requirements do not designate the protocol used -- it *could* be IPP. However, it isn't clear how all of the requirements for Internet Fax can be met by IPP. I'd like to understand better how IPP can be used for the fax application, if it's really a serious option. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Dec 2 00:39:44 1997 Delivery-Date: Tue, 02 Dec 1997 00:39:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA25828 for ; Tue, 2 Dec 1997 00:39:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA06158 for ; Tue, 2 Dec 1997 00:42:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA00228 for ; Tue, 2 Dec 1997 00:39:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 00:35:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29632 for ipp-outgoing; Tue, 2 Dec 1997 00:22:43 -0500 (EST) From: don@lexmark.com Message-Id: <199712020522.AA16489@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: masinter@parc.xerox.com Cc: Ipp@pwg.org Date: Tue, 2 Dec 1997 00:19:36 -0500 Subject: Re: IPP> Is that it?/ A tome from home Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Larry: As I said in the forwarded message -- I don't know where they came up with the first two quotes -- one being the fax one. In any case, my presentation only mentioned telephony fax and not internet fax. The bottom line of the fax comment was directed at the many cases where the document exists electronically and is set via the telephony fax method rather than simply being printed remotely via IPP. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** masinter%parc.xerox.com@interlock.lexmark.com 12/01/97 10:25 PM To: Don Wright@Lexmark cc: ipp%pwg.org@interlock.lexmark.com bcc: Subject: Re: IPP> Is that it?/ A tome from home > "IPP will kill fax by offering > high-quality printing, low telephone charges and multiple copies. I've been working on 'Requirements for Internet Fax' (draft-ietf-fax-requirements-XX.txt in the Internet Drafts directory, and a newer version at ftp://ftp.parc.xerox.com/pub/masinter/draft-ietf-fax-requirements-04bis.txt ). The requirements do not designate the protocol used -- it *could* be IPP. However, it isn't clear how all of the requirements for Internet Fax can be met by IPP. I'd like to understand better how IPP can be used for the fax application, if it's really a serious option. Larry -- http://www.parc.xerox.com/masinter From pmp-owner@pwg.org Tue Dec 2 03:14:37 1997 Delivery-Date: Tue, 02 Dec 1997 03:14:37 -0500 Return-Path: pmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA26361 for ; Tue, 2 Dec 1997 03:14:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA06405 for ; Tue, 2 Dec 1997 03:17:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA01228 for ; Tue, 2 Dec 1997 03:14:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 03:09:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA00987 for pmp-outgoing; Tue, 2 Dec 1997 03:05:09 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pmp@pwg.org'" Subject: PMP> FW: I-D ACTION:draft-iesg-iana-considerations-01.txt Date: Tue, 2 Dec 1997 00:02:30 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCFEB5.96DF3F00" Sender: pmp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BCFEB5.96DF3F00 Content-Type: text/plain FYI, The draft referenced below is a very good document for us to consider in our definition of protocols that include not only predefined enumerations, but also allow for "type-2" or other ways for enumerations to be extended (and managed) later. Its a good summary of a topic (protocol enum extensions) that we seem to keep tackling on each protocol effort we work on... Randy > -----Original Message----- > From: Internet-Drafts@ns.ietf.org [SMTP:Internet-Drafts@ns.ietf.org] > Sent: Monday, December 01, 1997 9:51 AM > To: IETF-Announce@ns.ietf.org > Cc: iesg@ns.ietf.org > Subject: I-D ACTION:draft-iesg-iana-considerations-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IETF Steering Group of the IETF. > > Title : Guidelines for Writing an IANA Considerations > Section in RFCs > Author(s) : H. Alvestrand, T. Narten > Filename : draft-iesg-iana-considerations-01.txt > Pages : 9 > Date : 26-Nov-97 > > Many protocols make use of identifiers consisting of constants and > other well-known values. Even after a protocol has been defined and > deployment has begun, new values may need to be assigned (e.g., a > new > option type in DHCP). To insure that such quantities have unique > values, their assignment must be administered by a central > authority. > In the Internet, that role is provided by the Internet Assigned > Numbers Authority (IANA). > > In order for the IANA to manage a given numbering space prudently, > it > needs guidelines describing the conditions under which new values > can > be assigned. If the IANA is expected to play a role in the > management > of a numbering space, the IANA must be given clear and concise > instructions describing that role. This document discusses issues > that should be considered in formulating an identifier assignment > policy and provides guidelines to document authors on the specific > text that must be included in documents that place demands on the > IANA. > > 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-iesg-iana-considerations-01.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-0 > 1.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-iesg-iana-considerations-01.txt". > > NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------ =_NextPart_000_01BCFEB5.96DF3F00 Content-Type: message/rfc822 Subject: Date: Tue, 2 Dec 1997 00:02:33 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BCFEB5.96DF3F00" ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: text/plain ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: application/octet-stream; name="ATT00199.txt" Content-Disposition: attachment; filename="ATT00199.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126163600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iesg-iana-considerations-01.txt ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: message/external-body; site="internet-drafts"; dir="draft-iesg-iana-considerations-01.txt"; mode="ds.internic.net"; access-type="anon-ftp" ------ =_NextPart_002_01BCFEB5.96DF3F00-- ------ =_NextPart_000_01BCFEB5.96DF3F00-- From ipp-owner@pwg.org Tue Dec 2 03:35:57 1997 Delivery-Date: Tue, 02 Dec 1997 03:36:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA26404 for ; Tue, 2 Dec 1997 03:35:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA06434 for ; Tue, 2 Dec 1997 03:38:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA02212 for ; Tue, 2 Dec 1997 03:35:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 03:27:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA00965 for ipp-outgoing; Tue, 2 Dec 1997 03:01:42 -0500 (EST) Message-Id: <3.0.1.32.19971201235727.01026620@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) X-Priority: 2 (High) Date: Mon, 1 Dec 1997 23:57:27 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Tom Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've posted the updated version of the algorithmic processing of all operations, Section 15.3, and the additional steps for create in a new Section 15.4. Part of the proposed changes resulted from simplifications that we discovered when writing actual code. The Section 15.3 (and 15.4) is written more like pseudo code: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3-norev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3-norev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3-rev-red.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3-rev-black.pdf The rev versions are revisions from the 11/07/97 Model document. The .doc files are WORD 6. The beginning of the document contains comments on the body of the Model document that resulted from the re-written algorithm. I've added explicit text for the suggestions that cover the body of the Model in the beginning comments. I'll bring copies of the noref.pdf to the IPP meeting Wednesday for all attendees, in case you don't get to make your own copy before. Tom From ipp-owner@pwg.org Tue Dec 2 03:38:02 1997 Delivery-Date: Tue, 02 Dec 1997 03:38:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA26418 for ; Tue, 2 Dec 1997 03:38:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA06437 for ; Tue, 2 Dec 1997 03:40:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA02501 for ; Tue, 2 Dec 1997 03:37:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 03:30:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA00977 for ipp-outgoing; Tue, 2 Dec 1997 03:04:54 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pmp@pwg.org'" Subject: IPP> FW: I-D ACTION:draft-iesg-iana-considerations-01.txt Date: Tue, 2 Dec 1997 00:02:30 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCFEB5.96DF3F00" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BCFEB5.96DF3F00 Content-Type: text/plain FYI, The draft referenced below is a very good document for us to consider in our definition of protocols that include not only predefined enumerations, but also allow for "type-2" or other ways for enumerations to be extended (and managed) later. Its a good summary of a topic (protocol enum extensions) that we seem to keep tackling on each protocol effort we work on... Randy > -----Original Message----- > From: Internet-Drafts@ns.ietf.org [SMTP:Internet-Drafts@ns.ietf.org] > Sent: Monday, December 01, 1997 9:51 AM > To: IETF-Announce@ns.ietf.org > Cc: iesg@ns.ietf.org > Subject: I-D ACTION:draft-iesg-iana-considerations-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IETF Steering Group of the IETF. > > Title : Guidelines for Writing an IANA Considerations > Section in RFCs > Author(s) : H. Alvestrand, T. Narten > Filename : draft-iesg-iana-considerations-01.txt > Pages : 9 > Date : 26-Nov-97 > > Many protocols make use of identifiers consisting of constants and > other well-known values. Even after a protocol has been defined and > deployment has begun, new values may need to be assigned (e.g., a > new > option type in DHCP). To insure that such quantities have unique > values, their assignment must be administered by a central > authority. > In the Internet, that role is provided by the Internet Assigned > Numbers Authority (IANA). > > In order for the IANA to manage a given numbering space prudently, > it > needs guidelines describing the conditions under which new values > can > be assigned. If the IANA is expected to play a role in the > management > of a numbering space, the IANA must be given clear and concise > instructions describing that role. This document discusses issues > that should be considered in formulating an identifier assignment > policy and provides guidelines to document authors on the specific > text that must be included in documents that place demands on the > IANA. > > 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-iesg-iana-considerations-01.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-0 > 1.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-iesg-iana-considerations-01.txt". > > NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------ =_NextPart_000_01BCFEB5.96DF3F00 Content-Type: message/rfc822 Subject: Date: Tue, 2 Dec 1997 00:02:33 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BCFEB5.96DF3F00" ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: text/plain ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: application/octet-stream; name="ATT00199.txt" Content-Disposition: attachment; filename="ATT00199.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971126163600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iesg-iana-considerations-01.txt ------ =_NextPart_002_01BCFEB5.96DF3F00 Content-Type: message/external-body; site="internet-drafts"; dir="draft-iesg-iana-considerations-01.txt"; mode="ds.internic.net"; access-type="anon-ftp" ------ =_NextPart_002_01BCFEB5.96DF3F00-- ------ =_NextPart_000_01BCFEB5.96DF3F00-- From ipp-owner@pwg.org Tue Dec 2 10:38:50 1997 Delivery-Date: Tue, 02 Dec 1997 10:38:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA00251 for ; Tue, 2 Dec 1997 10:38:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07558 for ; Tue, 2 Dec 1997 10:41:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04112 for ; Tue, 2 Dec 1997 10:38:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 10:29:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03535 for ipp-outgoing; Tue, 2 Dec 1997 10:16:50 -0500 (EST) Message-ID: <3484260D.45207618@underscore.com> Date: Tue, 02 Dec 1997 10:15:25 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: don@lexmark.com CC: ipp@pwg.org Subject: Re: IPP> Is that it?/ A tome from home References: <199712020247.AA12732@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Don, Some say that any press is better than no press, right? ;-) This statement, however, needs to be publicly debunked by the IPP group so that public expectations don't blow up in our faces: > The Internet printing protocol (IPP) will make > it possible to print out documents by locating its Web address > and simply pressing the "print" button. There will be some implementations that might allow for this level of simplicity, but doesn't it seem a bit dangerous for us to let people think this will be the defacto norm? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 2 11:12:25 1997 Delivery-Date: Tue, 02 Dec 1997 11:12:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA01108 for ; Tue, 2 Dec 1997 11:12:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07818 for ; Tue, 2 Dec 1997 11:15:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA04819 for ; Tue, 2 Dec 1997 11:12:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 11:07:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04210 for ipp-outgoing; Tue, 2 Dec 1997 10:54:50 -0500 (EST) From: don@lexmark.com Message-Id: <199712021554.AA12649@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: jkm@underscore.com, ipp@pwg.org Date: Tue, 2 Dec 1997 10:51:28 -0500 Subject: Re: IPP> Is that it?/ A tome from home Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Jay: I think this is exactly the goal we had in mind for IPP. If the user has to do something really different to print to an IPP printer then we have failed. For the Windows user, finding the printer and its URL (read: WEB address), installing it and then printing to it should simply pressing the PRINT button or icon. The solutions in the non-Windows space may be different but for the readers of this article in a general circulation newspaper, computer equals Windows/Intel. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 12/02/97 10:47 AM --------------------------- To: Don Wright@Lexmark cc: ipp%pwg.org@interlock.lexmark.com bcc: Subject: Re: IPP> Is that it?/ A tome from home Don, Some say that any press is better than no press, right? ;-) This statement, however, needs to be publicly debunked by the IPP group so that public expectations don't blow up in our faces: > The Internet printing protocol (IPP) will make > it possible to print out documents by locating its Web address > and simply pressing the "print" button. There will be some implementations that might allow for this level of simplicity, but doesn't it seem a bit dangerous for us to let people think this will be the defacto norm? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 2 13:11:19 1997 Delivery-Date: Tue, 02 Dec 1997 13:11:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA03019 for ; Tue, 2 Dec 1997 13:11:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08857 for ; Tue, 2 Dec 1997 13:14:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA05733 for ; Tue, 2 Dec 1997 13:11:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 12:59:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05062 for ipp-outgoing; Tue, 2 Dec 1997 12:36:10 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 02 Dec 1997 10:35:12 -0700 From: Scott Isaacson To: don@lexmark.com, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP> Is that it?/ A tome from home Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Jay, >>> Jay Martin 12/02 8:15 AM >>> >> The Internet printing protocol (IPP) will make >> it possible to print out documents by locating its Web address >> and simply pressing the "print" button. > >There will be some implementations that might allow for this level >of simplicity, but doesn't it seem a bit dangerous for us to >let people think this will be the defacto norm? I agree with "management of expectations", but I, for one, had hoped that such a feature might soon be a common practice for Internet users. I know that you (and I) have spent much time and effort at enterprise printing solutions, but last week when I was at Comdex, there were so many people that I talked to who are just dying for such easy printing functionality from their Internet clients (weather they be fat, thin, or set-top Web TV clients). Why do we want to debunk what we have been trying to get to. Will it ALL happen the day the IESG says that we have proposed standard RFCs? No. Will it happen some day? I sure hope so. Scott From ipp-owner@pwg.org Tue Dec 2 13:25:11 1997 Delivery-Date: Tue, 02 Dec 1997 13:25:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA03309 for ; Tue, 2 Dec 1997 13:25:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08913 for ; Tue, 2 Dec 1997 13:28:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06822 for ; Tue, 2 Dec 1997 13:25:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 13:17:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05097 for ipp-outgoing; Tue, 2 Dec 1997 12:44:07 -0500 (EST) Message-Id: <3.0.1.32.19971202094438.00c6eca0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Dec 1997 09:44:38 PST To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> FW: I-D ACTION:draft-iesg-iana-considerations-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, Good try, but the reference given comes up with a "no such file" error message. Carl-Uno At 12:02 AM 12/2/97 PST, Turner, Randy wrote: > >FYI, > >The draft referenced below is a very good document for >us to consider in our definition of protocols that >include not only predefined enumerations, but also >allow for "type-2" or other ways for enumerations to >be extended (and managed) later. > >Its a good summary of a topic (protocol enum >extensions) that we seem to keep tackling on >each protocol effort we work on... > >Randy > > >> -----Original Message----- >> From: Internet-Drafts@ns.ietf.org [SMTP:Internet-Drafts@ns.ietf.org] >> Sent: Monday, December 01, 1997 9:51 AM >> To: IETF-Announce@ns.ietf.org >> Cc: iesg@ns.ietf.org >> Subject: I-D ACTION:draft-iesg-iana-considerations-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IETF Steering Group of the IETF. >> >> Title : Guidelines for Writing an IANA Considerations >> Section in RFCs >> Author(s) : H. Alvestrand, T. Narten >> Filename : draft-iesg-iana-considerations-01.txt >> Pages : 9 >> Date : 26-Nov-97 >> >> Many protocols make use of identifiers consisting of constants and >> other well-known values. Even after a protocol has been defined and >> deployment has begun, new values may need to be assigned (e.g., a >> new >> option type in DHCP). To insure that such quantities have unique >> values, their assignment must be administered by a central >> authority. >> In the Internet, that role is provided by the Internet Assigned >> Numbers Authority (IANA). >> >> In order for the IANA to manage a given numbering space prudently, >> it >> needs guidelines describing the conditions under which new values >> can >> be assigned. If the IANA is expected to play a role in the >> management >> of a numbering space, the IANA must be given clear and concise >> instructions describing that role. This document discusses issues >> that should be considered in formulating an identifier assignment >> policy and provides guidelines to document authors on the specific >> text that must be included in documents that place demands on the >> IANA. >> >> 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-iesg-iana-considerations-01.txt". >> A URL for the Internet-Draft is: >> ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-0 >> 1.txt >> >> Internet-Drafts directories are located at: >> >> Africa: ftp.is.co.za >> >> Europe: ftp.nordu.net >> ftp.nis.garr.it >> >> Pacific Rim: munnari.oz.au >> >> US East Coast: ds.internic.net >> >> 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-iesg-iana-considerations-01.txt". >> >> NOTE: The mail server at ds.internic.net can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >Subject: >Date: Tue, 2 Dec 1997 00:02:33 -0800 >X-Priority: 3 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.0.1458.49) >Content-Type: multipart/mixed; > boundary="---- =_NextPart_002_01BCFEB5.96DF3F00" > > >Attachment Converted: "C:\WINNT\profiles\cmanros\personal\Attach\ATT00199.txt" > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Dec 2 13:26:24 1997 Delivery-Date: Tue, 02 Dec 1997 13:26:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA03325 for ; Tue, 2 Dec 1997 13:26:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08924 for ; Tue, 2 Dec 1997 13:29:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06969 for ; Tue, 2 Dec 1997 13:26:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 13:18:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05116 for ipp-outgoing; Tue, 2 Dec 1997 12:47:03 -0500 (EST) Message-ID: <34844969.944AF289@underscore.com> Date: Tue, 02 Dec 1997 12:46:18 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Scott Isaacson CC: ipp@pwg.org Subject: Re: IPP> Is that it?/ A tome from home References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Scott, After reading Don's reply, I guess I didn't do a very good job of describing my fears around the single sentence statement in that news clipping. I, too, imagine a day when printing is far easier than it is within hetergeneous network environments. I was just pointing out that this statement--made in late 1997--might tend to deceive people about what IPP can (or can't) do, or at least how easy it really will be: > The Internet printing protocol (IPP) will make > it possible to print out documents by locating its Web address > and simply pressing the "print" button. For example, "locating its Web address" hides the fact that it isn't just point-n-shoot printing...the user will first have to locate the printer's web address. (Sure, directory service support can be simple, but it's another step in the actions required by the user.) I really don't wish to get into any kind of debate here. ;-) Rather, I was just commenting on how easy it will be for the usual marketing machines to make the public believe IPP is the obvious panacea for network printing, that's all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 2 13:58:46 1997 Delivery-Date: Tue, 02 Dec 1997 13:58:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA03823 for ; Tue, 2 Dec 1997 13:58:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09058 for ; Tue, 2 Dec 1997 14:01:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA07742 for ; Tue, 2 Dec 1997 13:58:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 13:54:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA07136 for ipp-outgoing; Tue, 2 Dec 1997 13:41:39 -0500 (EST) Message-ID: <3484556B.FDB338D0@underscore.com> Date: Tue, 02 Dec 1997 13:37:31 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: "Turner, Randy" , "'ipp@pwg.org'" Subject: Re: IPP> FW: I-D ACTION:draft-iesg-iana-considerations-01.txt References: <3.0.1.32.19971202094438.00c6eca0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno Manros wrote: > > Randy, > > Good try, but the reference given comes up with a "no such file" error > message. If you're like me, then you use an email agent that allows you to point-n-click at a URL to immediately fetch the document. Unfortunately, Randy's outbound email agent wrapped the original URL near the end. The full URL is: ftp://ds.internic.net/internet-drafts/draft-iesg-iana-considerations-01.txt Hopefully the above line didn't get wrapped by *my* agent... ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 2 20:14:20 1997 Delivery-Date: Tue, 02 Dec 1997 20:14:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA07844 for ; Tue, 2 Dec 1997 20:14:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA10589 for ; Tue, 2 Dec 1997 20:17:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA12311 for ; Tue, 2 Dec 1997 20:14:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 20:09:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11725 for ipp-outgoing; Tue, 2 Dec 1997 19:56:33 -0500 (EST) Message-ID: <3484AE01.85A6ED64@parc.xerox.com> Date: Tue, 2 Dec 1997 16:55:29 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Jay Martin , ipp@pwg.org Subject: Re: IPP> Is that it?/ A tome from home References: <34844969.944AF289@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org nobody believes those magazines anyway, they're like National Enquirer. "Space Aliens Invaded My Printer!". -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Dec 2 21:58:42 1997 Delivery-Date: Tue, 02 Dec 1997 21:58:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA08488 for ; Tue, 2 Dec 1997 21:58:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10813 for ; Tue, 2 Dec 1997 22:01:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA13075 for ; Tue, 2 Dec 1997 21:58:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Dec 1997 21:54:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA12516 for ipp-outgoing; Tue, 2 Dec 1997 21:41:43 -0500 (EST) Message-Id: <3.0.1.32.19971202183744.00eb1480@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 2 Dec 1997 18:37:44 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Complete Issues List for Wed meeting - from Carl-Uno and Scott Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've posted the issues list summary on: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-issues.ppt .pdf Carl-Uno is bringing 35 hard copies and transparencies. Tom From ipp-owner@pwg.org Wed Dec 3 10:19:44 1997 Delivery-Date: Wed, 03 Dec 1997 10:19:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20494 for ; Wed, 3 Dec 1997 10:19:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA12297 for ; Wed, 3 Dec 1997 10:22:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15042 for ; Wed, 3 Dec 1997 10:19:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Dec 1997 10:09:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14408 for ipp-outgoing; Wed, 3 Dec 1997 09:56:20 -0500 (EST) Message-Id: <1.5.4.32.19971203135409.006dceac@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: Wed, 03 Dec 1997 05:54:09 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Phone Conference into the PWG IPP Meeting - REMINDER Sender: ipp-owner@pwg.org Several people have suggested that we organize a short phone conference into the PWG IPP Meeting in LA today, December 3. I have therefore set up one as follows: Starting time: 2 pm PST on December 3, 1997 Duration: 1 hour Subject: Quick walktrough of issues and resolutions for Model and Protocol Phone Number: 1-800-857 5607 Passcode: cmanros Regards, Carl-Uno From ipp-owner@pwg.org Thu Dec 4 22:42:21 1997 Delivery-Date: Thu, 04 Dec 1997 22:42:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA02977 for ; Thu, 4 Dec 1997 22:42:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA20346 for ; Thu, 4 Dec 1997 22:45:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA18070 for ; Thu, 4 Dec 1997 22:42:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Dec 1997 22:30:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17504 for ipp-outgoing; Thu, 4 Dec 1997 22:18:14 -0500 (EST) From: don@lexmark.com Message-Id: <199712050318.AA14510@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 4 Dec 1997 22:15:16 -0500 Subject: IPP> December Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the meeting minutes from the December Meeting in LA. I have also posted these to the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-01297.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-01297.pdf ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ----------------------------------------------------------------- Internet Printing Project Meeting Minutes December 3, 1997 Los Angeles, CA The meeting started on December 3, 1997 at 8:30 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: - Randy Turner - Sharp - Ron Bergman - DataProducts - Peter Zehler - Xerox - Lee Farrell - Canon - Philip Thambidurai - Okidata - Bob Pentecost - HP - Don Wright - Lexmark - Keith Carter - IBM - Steve Zilles - Adobe - Roger deBry - IBM - Tom Hastings - Xerox - Scott Isaacson - Novell - Carl-Uno Manros - Xerox - Dave Kellerman - NorthLake - Stuart Rowley - Kyocera - Bill Wagner - DPI/Osicom - Bob Herriot - Sun - Chuck Adams - Tektronix - Henrik Holst - I-Data - Frank Zhao - Panasonic - Yuji Susalai - Japan Computer Industry - Atsushi Uchino - Seiko-Epson - Rick Yardumian - Xerox - Xavier Riley - Xerox - Gary Roberts - Ricoh - Dale Wick - TrueSpectra - Mike Moldovan - Genoa Technology - Gary James - Genoa Technology - Jun Fujisawa - Canon - Harry Lewis - IBM - Kevin Osborn - Sun (JavaSoft) Carl-Uno Manros reviewed the agenda for the day and dealt with the administrivia of the meeting. ISSUES ------ Scott Isaacson started off the meeting by going through the issues list which is posted on the server as ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-issues.pdf M01) Versioning rules for major/minor revisions - resolved per the suggested changes in "ipp-section-15-3-norev.doc" (posted on the server.) Private extensions do not cause the major/minor versions to change. Only changes to the documents (protocol and model) cause a change to the versions. Implementations shall accept all request with the same major version and any minor version. Fidelity will control the behavior should unknown attribute or operations be encountered from a different minor version. -- Add statements in the versioning section * Not reassign objects between versions * Each major version will state what prior versions are to be supported M02) Issues concerning groups in operations: - What should a printer do if an operation contains an unexpected group? ** see proposed new 15.3.3.1 - What should a printer do if the correct groups are present but in the wrong order? ** see proposed new 15.3.3.1 - If Get-Attributes is returning no job/printer attributes, what does it return? ** Clients should send the group tag even if there are no attributes. The general philosophy should be to be conservative in what is sent and liberal in what is accepted. Overall for groups and attributes, group tags may be included with no attributes or the group tags can be omitted. Therefore receivers of data shall accept both. M03) Return not supported operation attributes in Get-Attributes operation. ** Not an issue because all the operation attributes are mandatory but allow for the group to show no support for extensions M04) Moving job-k-octets, job-impressions, compression and job-media-sheets to become optional operations attributes? ** These operation attributes get mapped into job description attributes. Now all job-template attributes are affected by fidelity. Section 3.1.1 of the model document needs to be updated to reflect these changes. M05) Keep document-format as operation attribute ** Yes M06) See issues M04 M07) Upper bounds ** See "ipp-min-max" on the server. Generally, attributes will be sized by type but on an attribute by attribute basis, special cases will be dealt with. M08) Granularity of error messages? This has been addressed in the latest version. M09) Semantics of unsupported and supported. This has been addressed in the latest version. M10) Statement that validation is attribute specific. This has been generally fixed in the latest version. M11) Add semantics to section 3.1.5.2 about requesting-user-name operation attribute. ** Bob Herriot will write up some clarifying language for this section. Remove the requirement for creating a unique name if one is not provided. The name does not have to be unique. M12) Add (1:MAX) to limit in section 3.2.6.1 of the model. ** OK M13) We will remove "copies-collated-*" M14) Change SHOULD to SHALL in section 4.1.9 ** Both SHOULDs need to be changed to SHALLs in this section. M15) Why is "attributes-natural-languages" special? ** When a client submits something and specifies the language it is used as a "post-it". We will change the following: natural-language -> generated-natural-language-default natural-language-supported -> generated-natural-language-supported We will add the -default to "charset" and "document-format" M16) Semantics of multiple-document-handling (section 4.2.4) ** Not resolved for Version 1. M17) Semantics of Page-ranges attribute (section 4.2.7) Change to specify non- overlapping ranges provided in ascending order. M18) Fixed in "ipp-section-15-3-norev.doc" M19) No M20) Conformance Language for natural-language ** Optional for object to support M21) Conformance Language for media-ready ** Optional M22) What status code is returned when printer is "accepting jobs" is false? ** Add an error code "server error - not accepting jobs" will be added/ M23) Semantics of server-error-version-not-supported need clarification ** See changes suggested in "ipp-model-last-call-comments-th.doc" M24) Semantic changes needed in 15.3 ** See "ipp-section-15-3-norev.doc" The series of checks provided in this new section are semantic examples and not conformance requirements. Some implementations may be softer and allow some non-conforming operations/attribute. Some of the semantics and interactions contained in the section are important but are not found elsewhere. M25) Occurrences of HTTP in Model document ** The references to HTTP will be removed from the MODEL document. M26) Internationalization clarifications ** Section 7: add classification of various text attributes and their source and interaction of language and charset with them. ** Revisited M15 and change to natural-language-configured. Scott will take a work item to clarify this. M27) Align our syntax descriptions with ** Carl-Uno Manros and Steve Zilles will explore this with our area directors. P01) Do we want to define and mandate a client-specified transaction ID. ** Yes, it will follow the version number in the protocol, it will be mandatory and will be 4 bytes and the range 0 -> (2^31)-1 P02) Does text on the Network Byte Order (protocol, sect 3) need improvement? ** Bob Herriot will fix. P03) We need a better description of how HTTP chunking is done by IPP. ** Bob Herriot will add some text about this and reference the HTTP/1.1 document as a reference for people implementing both IPP and HTTP. ** Some additional areas needing clarification were identified and will be written up by several people and added to the protocol document as "hints" or "implications of IPP over HTTP" P04) Do we need to refine CompoundValue? ** We have removed CV and replaced it with two new tags called "localized-text" and "localized-name" This will be written up in the next version of the document. I02) Revise definition of Application/IPP so it can be run over other transports. **This will be fixed in the documents. P05) OK P06) A long discussion ensued over the idea of using a special marker to indicate the end of the header and also indicating that there is or isn't more data. ** Resolution: Rename the "data" tag to be called the "end-of-header", "end-of-attributes" or "end-of-parsing" tag that indicates the end of the IPP header. GENOA ----- A presentation was made by Gary James from Genoa Technology about what Genoa is doing testing protocols. A discussion followed about how Genoa would do an IPP test suite. Genoa has looked at the IPP protocol and they are in the process of making a business decision to prioritize the various other projects they are investigating. They currently plan to do an IPP test suite and are trying to decide when to do it. They expect a decision by early '98. ADOBE ----- Steve Zilles made a presentation on some work on Job Tickets that is being done by Adobe. Version 1.0 of the Job Ticket specification was completed on October 6th. The document is available on the Adobe Web site in the developer's area in the tech notes area as tech note #5620. ISSUES ------ P07) Wording has been changed. P08) Remove the issue statement from the section. P09) Bob Herriot will add some additional examples in this section. P10) When does the IPP server rejects an operation? ** Randy has an action item to write up. The suggested tests listed in the new 15.3 section says not to quite checking early, i.e. when the first error is found. P11) OK, Bob will incorporate new wording into the protocol document based upon wording from Carl-Uno. P12) Port numbers for IPP? ** Carl-Uno will request an IPP and an IPP/TLS port. S01) Accept Randy Turner's text S02) Accept Randy Turner's text S03) Make "digest authentication" optional ** Yes, IPP will defer to the HTTP/1.1 security requirements. S04) Security terminology ** Leave the wording as is. S05) Move security to earlier in the document. ** According to the IETF, Section 8 is suppose to be the security section. We will add a forward reference earlier in the document pointing to sect. 8. D01) Alignment of IPP with Service Location Protocol Printer Scheme. ** Scott Isaacson will coordinate with the SRVLOC people. I01) Parameters for application/octet-stream MIME type. ** Application/octet-stream does not support CHARSET, OK -- no action. I03) Register document formats as MIME media types ** Action item for Tom Hastings to post a list of what will be registered and what will not to the mailing list. He will provided a deadline for comments back to him. I04) Register application/ipp with IANA ** Action item for Carl-Uno to do this after Ira MacDonald posts the text to the mailing list. Scott Isaacson reviewed the changes made at the Boulder meeting that were reflected into the "last call" document. The following caused additional discussion and/or decisions: 1) We will remove the "0" value of number-up and be silent on the embellishment issue relating to number up. 2) A discussion was held about issue of time. We decided to leave the time attributes as currently defined. DOCUMENTS --------- After the IETF meeting in Washington DC, we will send the resultant documents to the mailing list first and everyone should do a quick review before sending we send them to the IESG as the last call document. We expect to do this before the end of the year. The Rationale and Mapping documents may need some updates based upon today's work before going out to the IESG for last call. The Requirements document will go as is to the IESG for last call. The meeting was adjourned at 5:30 PM PST. From ipp-owner@pwg.org Fri Dec 5 11:03:38 1997 Delivery-Date: Fri, 05 Dec 1997 11:03:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15325 for ; Fri, 5 Dec 1997 11:03:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21828 for ; Fri, 5 Dec 1997 11:06:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19769 for ; Fri, 5 Dec 1997 11:03:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Dec 1997 10:53:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19179 for ipp-outgoing; Fri, 5 Dec 1997 10:40:45 -0500 (EST) Message-ID: <3488206D.472A4975@underscore.com> Date: Fri, 05 Dec 1997 10:40:29 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Mailing List IPP Subject: IPP> A free IPP test suite to be available! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org This section of the just-posted IPP minutes caught my attention: > GENOA > ----- > > A presentation was made by Gary James from Genoa Technology about > what Genoa is doing testing protocols. A discussion followed about > how Genoa would do an IPP test suite. Genoa has looked at the IPP > protocol and they are in the process of making a business decision > to prioritize the various other projects they are investigating. > They currently plan to do an IPP test suite and are trying to decide > when to do it. They expect a decision by early '98. This is really good news, that Genoa is undertaking the effort to deliver a FREE test suite for IPP. It's not often that we find a vendor so willing to provide such tools to an otherwise highly competitive industry. Thanks to Genoa for standing up at the IPP meeting and making this important public announcement! We look forward to seeing this new FREE test suite. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From daemon Fri Dec 5 11:15:31 1997 Delivery-Date: Fri, 05 Dec 1997 11:29:28 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA15622 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 11:15:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15483; Fri, 5 Dec 1997 11:09:15 -0500 (EST) Message-Id: <199712051609.LAA15483@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-lzs-02.txt Date: Fri, 05 Dec 1997 11:09:14 -0500 Sender: cclark@cnri.reston.va.us --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 Using LZS Author(s) : R. Friend, R. Monsour Filename : draft-ietf-ippcp-lzs-02.txt Pages : 7 Date : 31-Jul-07 This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. 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-lzs-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-lzs-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-lzs-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971204153112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-lzs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-lzs-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204153112.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Dec 5 11:44:27 1997 Delivery-Date: Fri, 05 Dec 1997 11:44:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16603 for ; Fri, 5 Dec 1997 11:44:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22107 for ; Fri, 5 Dec 1997 11:47:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20494 for ; Fri, 5 Dec 1997 11:44:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Dec 1997 11:39:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19910 for ipp-outgoing; Fri, 5 Dec 1997 11:26:57 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Message-ID: <5030100014690410000002L002*@MHS> Date: Fri, 5 Dec 1997 11:26:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA16603 I have a comment about this section: 15.3 Suggested Operation Processing Algorithm for all operations ... In the following algorithm, processing continues step by step until a "RETURNS the xxx status code *(" statement is encountered. Error returns are indicated by the verb: "REJECTS". Since clients have difficulty getting the status code, before sending all of the document data in a Print-Job request, clients SHOULD use the Validate-Job operation before sending large documents to be printed, in order to validate whether the IPP Printer will accept the job or not. I think that this use of the Validate-Job operation might be redundant, since HTTP/1.1 already provides a mechanism for this kind of thing: o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty footer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection. ... o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 (Continue) status followed by a regular response. ... 100 Continue The client may continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. So, the IPP object SHOULD process and validate the request up to step 15.4.8, then send either a "100 Continue" or an error response to the client, before waiting to receive the document data. The client should SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting document data. Since we should do all this anyway for HTTP/1.1, maybe we don't need the separate Validate-Job step? Side question: does an IPP error response have an HTTP status code of Successful "200 OK"? Carl Kugler From ipp-owner@pwg.org Sat Dec 6 08:58:45 1997 Delivery-Date: Sat, 06 Dec 1997 08:58:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA03054 for ; Sat, 6 Dec 1997 08:58:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA25253 for ; Sat, 6 Dec 1997 09:01:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA22787 for ; Sat, 6 Dec 1997 08:58:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 6 Dec 1997 08:49:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA22196 for ipp-outgoing; Sat, 6 Dec 1997 08:37:20 -0500 (EST) Message-ID: <34895479.6118FA0@ibm.net> Date: Sat, 06 Dec 1997 08:34:49 -0500 From: Philip Thambidurai Reply-To: pthambi@ibm.net X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: Jay Martin CC: Mailing List IPP Subject: Re: IPP> A free IPP test suite to be available! X-Priority: 3 (Normal) References: <3488206D.472A4975@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I don't recall Genoa or anyone else saying this was FREE. Jay Martin wrote: > This section of the just-posted IPP minutes caught my attention: > > > GENOA > > ----- > > > > A presentation was made by Gary James from Genoa Technology about > > what Genoa is doing testing protocols. A discussion followed about > > how Genoa would do an IPP test suite. Genoa has looked at the IPP > > protocol and they are in the process of making a business decision > > to prioritize the various other projects they are investigating. > > They currently plan to do an IPP test suite and are trying to decide > > > when to do it. They expect a decision by early '98. > > This is really good news, that Genoa is undertaking the effort to > deliver a FREE test suite for IPP. It's not often that we find a > vendor so willing to provide such tools to an otherwise highly > competitive industry. > > Thanks to Genoa for standing up at the IPP meeting and making this > important public announcement! We look forward to seeing this new > FREE test suite. > > ...jay > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Sun Dec 7 17:16:19 1997 Delivery-Date: Sun, 07 Dec 1997 17:16:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23567 for ; Sun, 7 Dec 1997 17:16:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01191 for ; Sun, 7 Dec 1997 17:19:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27523 for ; Sun, 7 Dec 1997 17:16:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 17:08:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26950 for ipp-outgoing; Sun, 7 Dec 1997 16:55:45 -0500 (EST) Message-ID: <348B1B4A.63E627DC@underscore.com> Date: Sun, 07 Dec 1997 16:55:22 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Mailing List IPP Subject: Re: IPP> A free IPP test suite to be available! References: <3488206D.472A4975@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Thanks to the folks who replied (both publicly and privately) to my original note on this topic. For the record, I have included essential parts of those responses to this message for all to read. Yeah, I didn't actually think the Genoa test suite would be FREE. What bothers me is that the IPP group--a fully functioning working group of the IETF--actually allowed a SINGLE vendor to stand up in a face-to-face IPP meeting and talk business. Not generic business, mind you, but business FOR THAT VENDOR ONLY. If the PWG desires to send out the equivalent of a "Request For Quotation" or whatever, then fine. Do that. (And, btw, I think that's a *great* idea for getting an IPP test suite going.) However, to give very precious meeting time to a SINGLE VENDOR is wholely and totally UNACCEPTABLE. The fact that Genoa is virtually ABSENT from ongoing PWG activities (of any kind) makes the situation even more distasteful. Even worse was having Genoa get up and pitch their (*potential*) product, yet the topic was not on the agenda posted for the meeting. I'll bet Chris Wellens of IWL would have liked to have had the chance to make a similar pitch. As a fellow host-based software vendor, even I would have liked to have been involved in such an exploratory meeting to better understand potential future business opportunities, even if test suites are not our specific bread-and-butter business. This kind of preferential treatment of a single vendor is NOT something the PWG should be doing, particularly when that vendor has never taken the time to involve itself with one or more of the many ongoing PWG projects on the table (past or present). ...jay PS: For those unable to attend the IPP meeting, Bob Herriot provided some very useful information. At least this will serve to level the playing field a bit. ---------------------------------------------------------------------- -- 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 wrote: > > Jay, > > Do not believe that the test suite is FREE. You can either have your tests > done by Geneo in which case they will charge you for testing. If you want > to buy the test suite you can count on forking out some $20,000. don@lexmark.com wrote: > > Jay: > > You forgot to put a winking emoticon after the word "FREE" in your e-mail. Robert Herriot wrote: > > The financial details were omitted from the minutes. Gary said that it > typically costs Genoa about $200,000 to develop a test suite. He never > volunteered what he would charge pwg members, so I asked that question > at the end. He said that he didn't know but it would depend on their > estimate of market size. He gave examples of a cost of $7,500 for a > test suite which had a large market versus $27,000 for another test > suite they developed for a small market. > > So, it won't be FREE to any of us, but I expect it will cost less that > if we were each to develop our own test suites. Genoa has to cover > its $200,000 cost somehow. Philip Thambidurai wrote: > > I don't recall Genoa or anyone else saying this was FREE. Jay Martin wrote: > > This section of the just-posted IPP minutes caught my attention: > > > GENOA > > ----- > > > > A presentation was made by Gary James from Genoa Technology about > > what Genoa is doing testing protocols. A discussion followed about > > how Genoa would do an IPP test suite. Genoa has looked at the IPP > > protocol and they are in the process of making a business decision > > to prioritize the various other projects they are investigating. > > They currently plan to do an IPP test suite and are trying to decide > > when to do it. They expect a decision by early '98. > > This is really good news, that Genoa is undertaking the effort to > deliver a FREE test suite for IPP. It's not often that we find a > vendor so willing to provide such tools to an otherwise highly > competitive industry. > > Thanks to Genoa for standing up at the IPP meeting and making this > important public announcement! We look forward to seeing this new > FREE test suite. > > ...jay From ipp-owner@pwg.org Sun Dec 7 18:59:24 1997 Delivery-Date: Sun, 07 Dec 1997 18:59:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA26362 for ; Sun, 7 Dec 1997 18:59:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01375 for ; Sun, 7 Dec 1997 19:02:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA28258 for ; Sun, 7 Dec 1997 18:59:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 18:54:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27681 for ipp-outgoing; Sun, 7 Dec 1997 18:41:36 -0500 (EST) Date: Sun, 7 Dec 1997 15:46:09 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9712072346.AA12628@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> MOD - Updated 'application/ipp' MIME type - 7 Dec 1997 Sender: ipp-owner@pwg.org Copies To: masinter@parc.xerox.com imcdonal@eso.mc.xerox.com ipp@pwg.org Hi folks, Sunday (7 December 1997) At our IPP Telecon on Wednesday (3 December), I got the action item to REVISE the text for registration of MIME media type "application/ipp". I used revision bars ('|') in the first column, to flag all changes. The following template came from the IETF MIME Part Four: Registration Procedures (RFC 2048, November 1996). We can apply for registration of this media-type when the IESG accepts our IPP/1.0 specs for entry onto the Internet 'standards track'. The application is normally made by mail (see below) and does NOT need to be supported by a separate Informational RFC. The 'Intended usage' of 'COMMON' (rather than the former 'LIMITED USE') is based on two of our decisions on Wednesday (3 December): a) All IPP Model attributes conveyed (eg, in the IPP/1.0 over HTTP/1.1 mapping) in header fields of the underlying transport protocol, MAY be specified in the body of the 'application/ipp' message; b) All 'application/ipp' messages MUST contain a 'transaction ID' (positive 32-bit integer), supplied by the operation requestor for later operation response correlations (and possibly notification correlations in a future version of IPP). Therefore, use of 'application/ipp' as a MIME type in email is now straightforward. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc 716-425-6141 (office at Xerox until April 1998) 716-442-0609 (home in Rochester, NY until April 1998) ------------------------------------------------------------------------ To: ietf-types@iana.org Subject: Registration of MIME media type "application/ipp" MIME type name: application MIME subtype name: ipp A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.0, described in [IPP-MOD] and [IPP-PRO]. Required parameters: none Optional parameters: none Encoding considerations: IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths). Security considerations: IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. | Protocol mixed-version interworking rules in [IPP-MOD] as well as | protocol encoding rules in [IPP-PRO] are complete and unambiguous. Interoperability considerations: IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed | by the normative specifications [IPP-MOD] and [IPP-PRO]. Protocol | encoding rules specified in [IPP-PRO] are comprehensive, so that | interoperability between conforming implementations is guaranteed (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.0 attribute values of syntax "text" or "name" are explicit within IPP protocol requests/responses (without recourse to any external information | in HTTP, SMTP, or other message transport headers). Published specification: [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", | work in progress , December 1997. [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner, "Internet Printing Protocol/1.0: Protocol Specification", | work in progress , December 1997. Applications which use this media type: Internet Printing Protocol (IPP) print clients and print servers, | communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or | other transport protocol. Messages of type "application/ipp" are | self-contained and transport-independent, including "charset" and | "natural-language" context for any "text" or "name" attributes. Person & email address to contact for further information: Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 Email: scott_isaacson@novell.com or Robert Herriot Sun Microsystems Inc. 901 San Antonio Road, MPK-17 Palo Alto, CA 94303 Phone: 650-786-8995 Fax: 650-786-7077 Email: robert.herriot@eng.sun.com Intended usage: | COMMON ------------------------------------------------------------------------ From ipp-owner@pwg.org Sun Dec 7 21:17:17 1997 Delivery-Date: Sun, 07 Dec 1997 21:17:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA29852 for ; Sun, 7 Dec 1997 21:17:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA01601 for ; Sun, 7 Dec 1997 21:20:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29041 for ; Sun, 7 Dec 1997 21:17:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 21:11:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28480 for ipp-outgoing; Sun, 7 Dec 1997 20:59:16 -0500 (EST) Message-Id: <3.0.1.32.19971207175937.00982920@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 7 Dec 1997 17:59:37 PST To: Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: IPP> Re: Agenda for the WG-Chairs/Directorate meeting Cc: ipp@pwg.org In-Reply-To: <344.881417188@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harald, A couple of comments from an IPP perspective below. Carl-Uno At 06:06 AM 12/6/97 PST, you wrote: >The agenda will be, roughly: > >- Reports from WGs, with our usual distraction frequency - 45 min > (that's approximately 1-2 min per slot; take care!) >- Charset policy - how is it received & applied? - 15 min We have mandated support for UTF-8, but are allowing additional encodings >- Security in applications: Strategy, directions, progress? - 1 hour We are happy about TLS eventually coming out as RFC so that we can reference it, but are unhappy with the removal of of the "no-security" case which was possible in earlier drafts. This forced us to redesign the solution in IPP. Did the Application Area had any say in this? After all, we believe that the applications are the main IETF "customers" of the security specs. >- AOB - 1/2 hour > > Harald A > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sun Dec 7 21:45:43 1997 Delivery-Date: Sun, 07 Dec 1997 21:45:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00802 for ; Sun, 7 Dec 1997 21:45:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA01653 for ; Sun, 7 Dec 1997 21:48:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29746 for ; Sun, 7 Dec 1997 21:45:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 21:41:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29172 for ipp-outgoing; Sun, 7 Dec 1997 21:28:58 -0500 (EST) Message-Id: <3.0.1.32.19971207182918.00984a40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 7 Dec 1997 18:29:18 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Area Directors' comments on IPP Cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, I had a short chat with Harald and Keith this evening (Sunday) about a couple of IPP subjects: 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure that our specs say that we MUST support the mandatory features that are minimum requirements for TLS, such as the cypher suite. They seemed a bit uncertain whether it was wise to also require mandatory support for SSL3 (due to the RSA licencing). Maybe we should change that to a strong recommendation rather than the conditional SHALL that we now have? I think that as the TLS minimum alone really doesn't do the job, so we need to keep at least that recommendation in the IPP spec. I expect this to come up during the IPP meeting on Wednesday, so stay tuned. 2) Alignment with Harald's I-D on IANA registration procedures . We should be in reasonable shape here already, as Harald said that he had actually used our IPP Model document as partial input for his I-D on the subject. There is no formal requirement to adhere to Harald's I-D at this stage. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sun Dec 7 22:47:16 1997 Delivery-Date: Sun, 07 Dec 1997 22:47:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA03675 for ; Sun, 7 Dec 1997 22:47:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA01784 for ; Sun, 7 Dec 1997 22:50:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA00527 for ; Sun, 7 Dec 1997 22:47:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 22:40:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29895 for ipp-outgoing; Sun, 7 Dec 1997 22:27:48 -0500 (EST) Message-Id: <3.0.1.32.19971207192809.009084e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 7 Dec 1997 19:28:09 PST To: Jay Martin , Mailing List IPP From: Carl-Uno Manros Subject: Re: IPP> A free IPP test suite to be available! In-Reply-To: <348B1B4A.63E627DC@underscore.com> References: <3488206D.472A4975@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Jay, This was all my fault, I have to take the responsibility for what happened. During my IPP presentation at the MFPA conference in San Diego, I ran into people from Genoa who explained that they were seriously considering the development of a "public" test suite for IPP. Apart from Rajesh Chawla, who has already advertised his intentions on the IPP DL, this was the first time I heard anybody express a serious interest in the subject, including from you. As the Genoa people are located close to LA, it was convenient for them to join the meeting and give us a very short presentation and following short discussion about the subject. As testing is going to be the next task for IPP to tackle, I personally thought that we should take this opportunity to hear their ideas. The Genoa folks showed up as normal participants in the IPP meeting and contributed to the conference costs like everybody else, which helped to compensate for other people who had PINGed, but changed their plans last minute. FYI, the Genoa folks has actually made an appearance in an earlier testing event on the Printer MIB. We can expect them to now become regular participants in the IPP effort, and probably make more appearances than people from some other companies with heavy influence but scarse participation. It might have been inappropriate to have this kind of discussion in a formal IETF meeting (I have seen exception there too), but I expected that the PWG was more flexibel. Nobody in the meeting expressed any objections to this agenda point, which admittedly was advertised very late. It seemed to me that everybody present in the IPP actually found the subject quite interesting. As testing is going to be very important for IPP in the coming year, I suggest that we might want to get further people and organizations that do testing involved in our work. You might be horrified to learn that Steve Zilles also handed out documentation and said a few words about Adobe's Job Ticket's, which is now public information on their web site. Jay, my impression is that we are talking about sour grapes here, you are just kicking yourself that you decided not to come to the meeting, in which case I am sure that the discussion of this subject would have taken much more time from the rest of our agenda. Carl-Uno At 01:55 PM 12/7/97 PST, Jay Martin wrote: >Thanks to the folks who replied (both publicly and privately) >to my original note on this topic. For the record, I have >included essential parts of those responses to this message >for all to read. > >Yeah, I didn't actually think the Genoa test suite would be FREE. > >What bothers me is that the IPP group--a fully functioning working >group of the IETF--actually allowed a SINGLE vendor to stand up in >a face-to-face IPP meeting and talk business. Not generic business, >mind you, but business FOR THAT VENDOR ONLY. > >If the PWG desires to send out the equivalent of a "Request For >Quotation" or whatever, then fine. Do that. (And, btw, I think >that's a *great* idea for getting an IPP test suite going.) > >However, to give very precious meeting time to a SINGLE VENDOR >is wholely and totally UNACCEPTABLE. The fact that Genoa is >virtually ABSENT from ongoing PWG activities (of any kind) makes >the situation even more distasteful. > >Even worse was having Genoa get up and pitch their (*potential*) >product, yet the topic was not on the agenda posted for the meeting. >I'll bet Chris Wellens of IWL would have liked to have had the chance >to make a similar pitch. As a fellow host-based software vendor, >even I would have liked to have been involved in such an exploratory >meeting to better understand potential future business opportunities, >even if test suites are not our specific bread-and-butter business. > >This kind of preferential treatment of a single vendor is NOT >something the PWG should be doing, particularly when that vendor >has never taken the time to involve itself with one or more of >the many ongoing PWG projects on the table (past or present). > > ...jay > >PS: For those unable to attend the IPP meeting, Bob Herriot provided > some very useful information. At least this will serve to level > the playing field a bit. > >---------------------------------------------------------------------- >-- 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 wrote: >> >> Jay, >> >> Do not believe that the test suite is FREE. You can either have your tests >> done by Geneo in which case they will charge you for testing. If you want >> to buy the test suite you can count on forking out some $20,000. > > >don@lexmark.com wrote: >> >> Jay: >> >> You forgot to put a winking emoticon after the word "FREE" in your e-mail. > > >Robert Herriot wrote: >> >> The financial details were omitted from the minutes. Gary said that it >> typically costs Genoa about $200,000 to develop a test suite. He never >> volunteered what he would charge pwg members, so I asked that question >> at the end. He said that he didn't know but it would depend on their >> estimate of market size. He gave examples of a cost of $7,500 for a >> test suite which had a large market versus $27,000 for another test >> suite they developed for a small market. >> >> So, it won't be FREE to any of us, but I expect it will cost less that >> if we were each to develop our own test suites. Genoa has to cover >> its $200,000 cost somehow. > > >Philip Thambidurai wrote: >> >> I don't recall Genoa or anyone else saying this was FREE. > > >Jay Martin wrote: >> >> This section of the just-posted IPP minutes caught my attention: >> >> > GENOA >> > ----- >> > >> > A presentation was made by Gary James from Genoa Technology about >> > what Genoa is doing testing protocols. A discussion followed about >> > how Genoa would do an IPP test suite. Genoa has looked at the IPP >> > protocol and they are in the process of making a business decision >> > to prioritize the various other projects they are investigating. >> > They currently plan to do an IPP test suite and are trying to decide >> > when to do it. They expect a decision by early '98. >> >> This is really good news, that Genoa is undertaking the effort to >> deliver a FREE test suite for IPP. It's not often that we find a >> vendor so willing to provide such tools to an otherwise highly >> competitive industry. >> >> Thanks to Genoa for standing up at the IPP meeting and making this >> important public announcement! We look forward to seeing this new >> FREE test suite. >> >> ...jay > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sun Dec 7 23:02:09 1997 Delivery-Date: Sun, 07 Dec 1997 23:02:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA06760 for ; Sun, 7 Dec 1997 23:02:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA01802 for ; Sun, 7 Dec 1997 23:05:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA01187 for ; Sun, 7 Dec 1997 23:02:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 7 Dec 1997 22:57:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA00169 for ipp-outgoing; Sun, 7 Dec 1997 22:42:29 -0500 (EST) Message-Id: <3.0.1.32.19971207194246.00a5da30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 7 Dec 1997 19:42:46 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD - Updated 'application/ipp' MIME type - 7 Dec 1997 In-Reply-To: <9712072346.AA12628@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Ira, Thanks for taking care of your homework assignment so rapidly and reliably. Just so we do not confuse people, it should be noted that your text anticipates a new set of I-Ds, which are still in progress by the editors. Carl-Uno At 03:46 PM 12/7/97 PST, you wrote: >Copies To: masinter@parc.xerox.com > imcdonal@eso.mc.xerox.com > ipp@pwg.org > >Hi folks, Sunday (7 December 1997) > >At our IPP Telecon on Wednesday (3 December), I got the action item to >REVISE the text for registration of MIME media type "application/ipp". >I used revision bars ('|') in the first column, to flag all changes. > >The following template came from the IETF MIME Part Four: Registration >Procedures (RFC 2048, November 1996). > >We can apply for registration of this media-type when the IESG accepts >our IPP/1.0 specs for entry onto the Internet 'standards track'. The >application is normally made by mail (see below) and does NOT need to be >supported by a separate Informational RFC. > >The 'Intended usage' of 'COMMON' (rather than the former 'LIMITED USE') >is based on two of our decisions on Wednesday (3 December): > >a) All IPP Model attributes conveyed (eg, in the IPP/1.0 over HTTP/1.1 > mapping) in header fields of the underlying transport protocol, MAY > be specified in the body of the 'application/ipp' message; >b) All 'application/ipp' messages MUST contain a 'transaction ID' > (positive 32-bit integer), supplied by the operation requestor for > later operation response correlations (and possibly notification > correlations in a future version of IPP). > >Therefore, use of 'application/ipp' as a MIME type in email is now >straightforward. > >Cheers, >- Ira McDonald (outside consultant at Xerox) > High North Inc > 716-425-6141 (office at Xerox until April 1998) > 716-442-0609 (home in Rochester, NY until April 1998) > >------------------------------------------------------------------------ > > To: ietf-types@iana.org > Subject: Registration of MIME media type "application/ipp" > > MIME type name: application > > MIME subtype name: ipp > > A Content-Type of "application/ipp" indicates an Internet Printing > Protocol message body (request or response). Currently there is > one version: IPP/1.0, described in [IPP-MOD] and [IPP-PRO]. > > Required parameters: none > > Optional parameters: none > > Encoding considerations: > > IPP/1.0 protocol requests/responses MAY contain long lines and > ALWAYS contain binary data (for example attribute value lengths). > > Security considerations: > > IPP/1.0 protocol requests/responses do not introduce any security > risks not already inherent in the underlying transport protocols. >| Protocol mixed-version interworking rules in [IPP-MOD] as well as >| protocol encoding rules in [IPP-PRO] are complete and unambiguous. > > Interoperability considerations: > > IPP/1.0 requests (generated by clients) and responses (generated > by servers) MUST comply with all conformance requirements imposed >| by the normative specifications [IPP-MOD] and [IPP-PRO]. Protocol >| encoding rules specified in [IPP-PRO] are comprehensive, so that >| interoperability between conforming implementations is guaranteed > (although support for specific optional features is not ensured). > Both the "charset" and "natural-language" of all IPP/1.0 attribute > values of syntax "text" or "name" are explicit within IPP protocol > requests/responses (without recourse to any external information >| in HTTP, SMTP, or other message transport headers). > > Published specification: > > [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, > P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", >| work in progress , December 1997. > > [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner, > "Internet Printing Protocol/1.0: Protocol Specification", >| work in progress , December 1997. > > Applications which use this media type: > > Internet Printing Protocol (IPP) print clients and print servers, >| communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or >| other transport protocol. Messages of type "application/ipp" are >| self-contained and transport-independent, including "charset" and >| "natural-language" context for any "text" or "name" attributes. > > Person & email address to contact for further information: > > Scott A. Isaacson > Novell, Inc. > 122 E 1700 S > Provo, UT 84606 > > Phone: 801-861-7366 > Fax: 801-861-4025 > Email: scott_isaacson@novell.com > > or > > Robert Herriot > Sun Microsystems Inc. > 901 San Antonio Road, MPK-17 > Palo Alto, CA 94303 > > Phone: 650-786-8995 > Fax: 650-786-7077 > Email: robert.herriot@eng.sun.com > > Intended usage: > >| COMMON > >------------------------------------------------------------------------ > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Dec 8 14:15:18 1997 Delivery-Date: Mon, 08 Dec 1997 14:15:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA15156 for ; Mon, 8 Dec 1997 14:15:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04121 for ; Mon, 8 Dec 1997 14:18:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA04652 for ; Mon, 8 Dec 1997 14:15:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 14:05:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04070 for ipp-outgoing; Mon, 8 Dec 1997 13:53:10 -0500 (EST) Message-Id: <199712081822.NAA00364@lust.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: ipp@pwg.org, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu Subject: IPP> Re: Area Directors' comments on IPP In-reply-to: Your message of "Sun, 07 Dec 1997 18:29:18 PST." <3.0.1.32.19971207182918.00984a40@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 13:22:48 -0500 Sender: ipp-owner@pwg.org > 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure that our > specs say that we MUST support the mandatory features that are minimum > requirements for TLS, such as the cypher suite. 1. IESG has not allowed other groups to reference SSL, and it unlikely that an exception would be made for IPP. If IPP uses SSL-like technology, the reference should be to the TLS RFC. 2. If IPP specifies TLS authentication, IPP must either implicitly use the mandatory ciphersuite from the TLS spec, or specify at least one mandatory TLS ciphersuite. 3. It will be very difficult for IPP to convince IESG to accept any mandatory TLS ciphersuite that uses encumbered algorithms, especially given that adequate unencumbered algorithms seem to be available. Suggestion: specify MUST implement ciphersuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one or more of the ciphersuites commonly used with SSL3. Keith From ipp-owner@pwg.org Mon Dec 8 15:57:32 1997 Delivery-Date: Mon, 08 Dec 1997 15:57:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA15835 for ; Mon, 8 Dec 1997 15:57:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04576 for ; Mon, 8 Dec 1997 16:00:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05356 for ; Mon, 8 Dec 1997 15:57:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 15:51:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04798 for ipp-outgoing; Mon, 8 Dec 1997 15:39:00 -0500 (EST) From: Steve Gebert To: Message-ID: <5030100014790501000002L012*@MHS> Date: Mon, 8 Dec 1997 15:39:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA15835 For interoperability testing, we were wondering if people were interested in exchanging binary files corresponding to IPP Requests and Responses. The parties using these files would simply need to construct a simple program to feed the file data into their server or client and read data from their server or client into a file. These files could be sent as email attachments and for the near term help with interoperability testing prior to people setting up machines outside filewalls. Perhaps we could even catalog the files and make them available for download so that there would be a common test baseline for early testing. We could make some example files available if there is any interest. What do you think Peter? Steve Gebert From ipp-owner@pwg.org Mon Dec 8 21:38:57 1997 Delivery-Date: Mon, 08 Dec 1997 21:38:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA17525 for ; Mon, 8 Dec 1997 21:38:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05513 for ; Mon, 8 Dec 1997 21:41:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06443 for ; Mon, 8 Dec 1997 21:38:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 21:32:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05853 for ipp-outgoing; Mon, 8 Dec 1997 21:20:15 -0500 (EST) Message-Id: <3.0.1.32.19971208173324.0091e810@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 8 Dec 1997 17:33:24 PST To: Steve Gebert , From: Tom Hastings Subject: IPP> Re: In-Reply-To: <5030100014790501000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Sounds like a great idea to me. It would also help those of us trying to make the spec unambiguous to look at as well, if we could look at sample requests and response binary files. Tom At 12:39 12/08/1997 PST, Steve Gebert wrote: >For interoperability testing, we were wondering if people were interested in >exchanging binary files > corresponding to IPP Requests and Responses. The parties using these files >would simply need to > construct a simple program to feed the file data into their server or client >and read data from their > server or client into a file. > > These files could be sent as email attachments and for the near term help >with interoperability testing > prior to people setting up machines outside filewalls. Perhaps we could even >catalog the files and > make them available for download so that there would be a common test >baseline for early testing. > > We could make some example files available if there is any interest. What do >you think Peter? > > >Steve Gebert > > From ipp-owner@pwg.org Mon Dec 8 22:26:43 1997 Delivery-Date: Mon, 08 Dec 1997 22:26:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18592 for ; Mon, 8 Dec 1997 22:26:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05614 for ; Mon, 8 Dec 1997 22:29:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07175 for ; Mon, 8 Dec 1997 22:26:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 22:18:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06570 for ipp-outgoing; Mon, 8 Dec 1997 22:02:49 -0500 (EST) Date: Mon, 8 Dec 1997 19:01:52 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712090301.TAA11613@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol doc X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the latest protocol documents to ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The documents are: ipp-pro-971208.doc MS Word Version 6 with no revisions ipp-pro-971208.txt Text with no revisions ipp-pro-971208-rev.doc MS Word Version 6 with revisions This has changes we agreed on in Los Angeles From ipp-owner@pwg.org Mon Dec 8 22:35:45 1997 Delivery-Date: Mon, 08 Dec 1997 22:36:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA19370 for ; Mon, 8 Dec 1997 22:35:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05629 for ; Mon, 8 Dec 1997 22:38:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07789 for ; Mon, 8 Dec 1997 22:35:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 22:31:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06616 for ipp-outgoing; Mon, 8 Dec 1997 22:12:48 -0500 (EST) From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: ipp@pwg.org Subject: IPP> Re: Agenda for the WG-Chairs/Directorate meeting In-reply-to: Your message of "Sun, 07 Dec 1997 17:59:37 PST." <3.0.1.32.19971207175937.00982920@garfield> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4446.881609905.1@dale.uninett.no> Date: Mon, 08 Dec 1997 14:38:25 -0500 Message-ID: <4448.881609905@dale.uninett.no> Sender: ipp-owner@pwg.org No, the Apps people did not know about the removal of "negotiate to NULL" from the TLS spec. Harald A From ipp-owner@pwg.org Mon Dec 8 23:54:58 1997 Delivery-Date: Mon, 08 Dec 1997 23:54:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA24942 for ; Mon, 8 Dec 1997 23:54:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA05948 for ; Mon, 8 Dec 1997 23:57:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08672 for ; Mon, 8 Dec 1997 23:54:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Dec 1997 23:49:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08048 for ipp-outgoing; Mon, 8 Dec 1997 23:36:14 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Keith Moore'" , Carl-Uno Manros Cc: ipp@pwg.org, Harald.T.Alvestrand@uninett.no Subject: RE: IPP> Re: Area Directors' comments on IPP Date: Mon, 8 Dec 1997 20:33:45 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org The problem with not mentioning SSL3 as allowable in our specification is that, until TLS becomes available, there will be no interoperable implementations of IPP for IPP servers implemented as CGI behind generic HTTP servers. And thats assuming that all the server installed base upgrade when these TLS servers become available (which is unlikely). I'm open to other wording in the spec, but we need to document that SSL3 servers CAN interoperate with clients that implement TLS, and vice versa. And I totally agree that we need to try to meet our security requirements without mandating encumbered security mechanisms. To this end, some combination MD5, Diffie-Hellman, and Triple-DES should give us a reasonable level of security. I don't feel that these technologies place an undue burden on simple IPP services since we have agreed that "secure" IPP clients and servers are optional. Randy > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Monday, December 08, 1997 10:23 AM > To: Carl-Uno Manros > Cc: ipp@pwg.org; Harald.T.Alvestrand@uninett.no; moore@cs.utk.edu > Subject: IPP> Re: Area Directors' comments on IPP > > > 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure > that our > > specs say that we MUST support the mandatory features that are > minimum > > requirements for TLS, such as the cypher suite. > > 1. IESG has not allowed other groups to reference SSL, and it unlikely > that an exception would be made for IPP. If IPP uses SSL-like > technology, the reference should be to the TLS RFC. > > 2. If IPP specifies TLS authentication, IPP must either implicitly use > the mandatory ciphersuite from the TLS spec, or specify at least one > mandatory TLS ciphersuite. > > 3. It will be very difficult for IPP to convince IESG to accept any > mandatory TLS ciphersuite that uses encumbered algorithms, especially > given that adequate unencumbered algorithms seem to be available. > > Suggestion: specify MUST implement ciphersuite > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one > or more of the ciphersuites commonly used with SSL3. > > Keith > From ipp-owner@pwg.org Tue Dec 9 02:07:29 1997 Delivery-Date: Tue, 09 Dec 1997 02:07:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA25486 for ; Tue, 9 Dec 1997 02:07:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06369 for ; Tue, 9 Dec 1997 02:10:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA09711 for ; Tue, 9 Dec 1997 02:07:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 02:02:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA09163 for ipp-outgoing; Tue, 9 Dec 1997 01:49:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 08 Dec 1997 23:45:56 -0700 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, moore@cs.utk.edu, rturner@sharplabs.com Cc: ipp@pwg.org, Harald.T.Alvestrand@uninett.no Subject: RE: IPP> Re: Area Directors' comments on IPP Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Randy and all, To be perfectly clear, let's review some of the language that has been written down (both in the last call I-D and in emails since then). >>> "Turner, Randy" 12/08 9:33 PM >>> > The problem with not mentioning SSL3 as allowable in our > specification is that, until TLS becomes available, there will > be no interoperable implementations of IPP for IPP servers > implemented as CGI behind generic HTTP servers. The security text that Randy wrote during the WG final comment period does not metion SSL3 at all. Does it need to? I beleive that the I-D used to say that SSL3 might be used by implementers however such an product would NOT be compliant. It was just as statement about the realities of deploying IPP over existing (now, today) infrastructure. > And thats assuming that all the server installed base upgrade > when these TLS servers become available (which is unlikely). > I'm open to other wording in the spec, but we need to > document that SSL3 servers CAN interoperate with clients > that implement TLS, and vice versa. The text that Randy proposes is: "Within the context of this document, a "secure" implementation is one that utilizes a transport layer that supports Transport Layer Security (TLS) Version 1.0." > And I totally agree that we need to try to meet our security > requirements without mandating encumbered security > mechanisms. To this end, some combination MD5, > Diffie-Hellman, and Triple-DES should give us a reasonable > level of security. > I don't feel that these technologies place an undue > burden on simple IPP services since we have agreed that > "secure" IPP clients and servers are optional. Randy has written the following proposed text to support the idea of "if security is implemented, it MUST be TSL": "Since the security levels or the specific threats that any given IPP system administrator may be concerned with cannot be anticipated, IPP MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required. TLS Version 1.0 supports the type of negotiated levels of security required by most, if not all, potential IPP environments. IPP environments that require no security can elect to deploy IPP implementations that do not utilize the optional TLS security mechanisms." Keith and Harald, is this acceptable? From ipp-owner@pwg.org Tue Dec 9 08:59:37 1997 Delivery-Date: Tue, 09 Dec 1997 08:59:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA26836 for ; Tue, 9 Dec 1997 08:59:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA06974 for ; Tue, 9 Dec 1997 09:02:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA10786 for ; Tue, 9 Dec 1997 08:59:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 08:44:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA10164 for ipp-outgoing; Tue, 9 Dec 1997 08:32:08 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Scott Isaacson'" , cmanros@cp10.es.xerox.com, moore@cs.utk.edu, rturner@sharplabs.com Cc: ipp@pwg.org, Harald.T.Alvestrand@uninett.no Subject: RE: IPP> Re: Area Directors' comments on IPP Date: Tue, 9 Dec 1997 05:29:29 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I wrote the TLS requirement based on the availability of TLS as a proposed standard. And like Scott has pointed out, I did not mention SSL3 because of comments I received on the DL and from others about referencing something like SSL3 that is not somehow on the standards track. I guess what I'm proposing is that we include an informative appendix (non-normative) that talks about how to interoperate in "legacy" SSL3 environments. This is exactly how its done in the TLS 1.0 document as well. Randy > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Monday, December 08, 1997 10:46 PM > To: cmanros@cp10.es.xerox.com; moore@cs.utk.edu; > rturner@sharplabs.com > Cc: ipp@pwg.org; Harald.T.Alvestrand@uninett.no > Subject: RE: IPP> Re: Area Directors' comments on IPP > > Randy and all, > > To be perfectly clear, let's review some of the language that has been > written down (both in the last call I-D and in emails since then). > > >>> "Turner, Randy" 12/08 9:33 PM >>> > > > > The problem with not mentioning SSL3 as allowable in our > > specification is that, until TLS becomes available, there will > > be no interoperable implementations of IPP for IPP servers > > implemented as CGI behind generic HTTP servers. > > The security text that Randy wrote during the WG final comment period > does > not metion SSL3 at all. Does it need to? I beleive that the I-D used > to > say that SSL3 might be used by implementers however such an product > would > NOT be compliant. It was just as statement about the realities of > deploying > IPP over existing (now, today) infrastructure. > > > And thats assuming that all the server installed base upgrade > > when these TLS servers become available (which is unlikely). > > I'm open to other wording in the spec, but we need to > > document that SSL3 servers CAN interoperate with clients > > that implement TLS, and vice versa. > > The text that Randy proposes is: > > "Within the context of this document, a "secure" implementation is one > that > utilizes a transport layer that supports Transport Layer Security > (TLS) > Version 1.0." > > > And I totally agree that we need to try to meet our security > > requirements without mandating encumbered security > > mechanisms. To this end, some combination MD5, > > Diffie-Hellman, and Triple-DES should give us a reasonable > > level of security. > > I don't feel that these technologies place an undue > > burden on simple IPP services since we have agreed that > > "secure" IPP clients and servers are optional. > > Randy has written the following proposed text to support the idea of > "if > security is implemented, it MUST be TSL": > > "Since the security levels or the specific threats that any given IPP > system > administrator may be concerned with cannot be anticipated, IPP MUST be > capable of operating with different security mechanisms and security > policies as required by the individual installation. Security policies > might > vary from very strong, to very weak, to none at all, and corresponding > security mechanisms will be required. TLS Version 1.0 supports the > type of > negotiated levels of security required by most, if not all, potential > IPP > environments. IPP environments that require no security can elect to > deploy > IPP implementations that do not utilize the optional TLS security > mechanisms." > > Keith and Harald, is this acceptable? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Tue Dec 9 09:22:04 1997 Delivery-Date: Tue, 09 Dec 1997 09:22:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA27012 for ; Tue, 9 Dec 1997 09:22:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07304 for ; Tue, 9 Dec 1997 09:24:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA11817 for ; Tue, 9 Dec 1997 09:22:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 09:14:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA10272 for ipp-outgoing; Tue, 9 Dec 1997 08:46:14 -0500 (EST) Message-Id: <3.0.1.32.19971209054623.00ba7100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Dec 1997 05:46:23 PST To: Keith Moore , Harald.T.Alvestrand@uninett.no From: Carl-Uno Manros Subject: IPP> Re: Area Directors' comments on IPP Cc: ipp@pwg.org, wg-chairs@apps.ietf.org, directorate@apps.ietf.ort In-Reply-To: <199712081822.NAA00364@lust.cs.utk.edu> 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 Keith and Harold, I think that the Application Area in general has a serious process problem. We have spent considerable time and effort in the IPP project studying and evaluating security services and security options. In parallell, the Security Area seems to contuinually change the rules of the game. As I have stated before, I think that we, the Application Area standards developers are the main customers of the Security Area and they seem to ignore us totally. We are getting tired of trying to predict what may or may not fly in the IESG, when it comes to security options. If the security people are going to dictate in every detail what we can or cannot do, then I think it is their responsibility to make sure that they participate in our WGs to give advice us advice in the context of our needs and discussions, rather than come down and criticize what we have done every time we think we have found an acceptable solution. Keith and Harald, with all due respect, your advice in th area of security has not been very reliable either; we need the advice directly from the people who is going to review this aspect of our work in the IESG. Yesterday's Application Area WG meetings in the IETF showed very clearly to me that several other Application Area WGs are in the same boat as we are here. I pointed out these problems in the Application Area WG Chair meetings during the previous two IETF meetings, but the situation has not improved. Action, please! My 2 cents, Carl-Uno Manros In my role as co-chair if the IPP WG At 10:22 AM 12/8/97 PST, Keith Moore wrote: >> 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure that our >> specs say that we MUST support the mandatory features that are minimum >> requirements for TLS, such as the cypher suite. > >1. IESG has not allowed other groups to reference SSL, and it unlikely >that an exception would be made for IPP. If IPP uses SSL-like >technology, the reference should be to the TLS RFC. > >2. If IPP specifies TLS authentication, IPP must either implicitly use >the mandatory ciphersuite from the TLS spec, or specify at least one >mandatory TLS ciphersuite. > >3. It will be very difficult for IPP to convince IESG to accept any >mandatory TLS ciphersuite that uses encumbered algorithms, especially >given that adequate unencumbered algorithms seem to be available. > >Suggestion: specify MUST implement ciphersuite >TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one >or more of the ciphersuites commonly used with SSL3. > >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 From ipp-owner@pwg.org Tue Dec 9 09:23:44 1997 Delivery-Date: Tue, 09 Dec 1997 09:23:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA27018 for ; Tue, 9 Dec 1997 09:23:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07310 for ; Tue, 9 Dec 1997 09:26:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA12001 for ; Tue, 9 Dec 1997 09:23:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 09:16:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA10456 for ipp-outgoing; Tue, 9 Dec 1997 08:49:45 -0500 (EST) Message-Id: <3.0.1.32.19971209054958.009856a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Dec 1997 05:49:58 PST To: "Turner, Randy" , "'Scott Isaacson'" , cmanros@cp10.es.xerox.com, moore@cs.utk.edu, rturner@sharplabs.com From: Carl-Uno Manros Subject: RE: IPP> Re: Area Directors' comments on IPP Cc: ipp@pwg.org, Harald.T.Alvestrand@uninett.no In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, We already have that as an Appendix in the Protocol Specification draft. We should just check if we need to do any further edits to the Appendix. Check Bob's latest draft. Carl-Uno At 05:29 AM 12/9/97 PST, Turner, Randy wrote: > > >I wrote the TLS requirement based on the availability of >TLS as a proposed standard. And like Scott has pointed >out, I did not mention SSL3 because of comments I >received on the DL and from others about referencing >something like SSL3 that is not somehow on the >standards track. > >I guess what I'm proposing is that we include an >informative appendix (non-normative) that talks about >how to interoperate in "legacy" SSL3 environments. This >is exactly how its done in the TLS 1.0 document as well. > >Randy > >> -----Original Message----- >> From: Scott Isaacson [SMTP:SISAACSON@novell.com] >> Sent: Monday, December 08, 1997 10:46 PM >> To: cmanros@cp10.es.xerox.com; moore@cs.utk.edu; >> rturner@sharplabs.com >> Cc: ipp@pwg.org; Harald.T.Alvestrand@uninett.no >> Subject: RE: IPP> Re: Area Directors' comments on IPP >> >> Randy and all, >> >> To be perfectly clear, let's review some of the language that has been >> written down (both in the last call I-D and in emails since then). >> >> >>> "Turner, Randy" 12/08 9:33 PM >>> >> >> >> > The problem with not mentioning SSL3 as allowable in our >> > specification is that, until TLS becomes available, there will >> > be no interoperable implementations of IPP for IPP servers >> > implemented as CGI behind generic HTTP servers. >> >> The security text that Randy wrote during the WG final comment period >> does >> not metion SSL3 at all. Does it need to? I beleive that the I-D used >> to >> say that SSL3 might be used by implementers however such an product >> would >> NOT be compliant. It was just as statement about the realities of >> deploying >> IPP over existing (now, today) infrastructure. >> >> > And thats assuming that all the server installed base upgrade >> > when these TLS servers become available (which is unlikely). >> > I'm open to other wording in the spec, but we need to >> > document that SSL3 servers CAN interoperate with clients >> > that implement TLS, and vice versa. >> >> The text that Randy proposes is: >> >> "Within the context of this document, a "secure" implementation is one >> that >> utilizes a transport layer that supports Transport Layer Security >> (TLS) >> Version 1.0." >> >> > And I totally agree that we need to try to meet our security >> > requirements without mandating encumbered security >> > mechanisms. To this end, some combination MD5, >> > Diffie-Hellman, and Triple-DES should give us a reasonable >> > level of security. >> > I don't feel that these technologies place an undue >> > burden on simple IPP services since we have agreed that >> > "secure" IPP clients and servers are optional. >> >> Randy has written the following proposed text to support the idea of >> "if >> security is implemented, it MUST be TSL": >> >> "Since the security levels or the specific threats that any given IPP >> system >> administrator may be concerned with cannot be anticipated, IPP MUST be >> capable of operating with different security mechanisms and security >> policies as required by the individual installation. Security policies >> might >> vary from very strong, to very weak, to none at all, and corresponding >> security mechanisms will be required. TLS Version 1.0 supports the >> type of >> negotiated levels of security required by most, if not all, potential >> IPP >> environments. IPP environments that require no security can elect to >> deploy >> IPP implementations that do not utilize the optional TLS security >> mechanisms." >> >> Keith and Harald, is this acceptable? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Dec 9 09:49:02 1997 Delivery-Date: Tue, 09 Dec 1997 09:49:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA27139 for ; Tue, 9 Dec 1997 09:49:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07435 for ; Tue, 9 Dec 1997 09:51:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA12704 for ; Tue, 9 Dec 1997 09:49:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 09:44:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA12121 for ipp-outgoing; Tue, 9 Dec 1997 09:31:58 -0500 (EST) From: "Zehler,Peter" To: Steve Gebert , ipp@pwg.org Subject: IPP> RE: TES:binary files Date: Tue, 9 Dec 1997 06:35:41 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Dec9.063143pst."61011(1)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Steve, Even when we test across the internet we will still need to capture the results. I am all for anything that will help us move along. I have created a directory called "Traces" under the new_TES directory for the time being. We can decide on a directory structure at a later time. I assume that we will capture traces in more than one form. We need to decide on a naming convention. For this purpose I assume that we will limit each trace file to a single request or response. The naming convention should provide for the pairing of the request to its response. The naming convention should facilitate the capturing of an extended IPP conversation. A conversation is a sequence of IPP operations on an IPP printer. We need to designate the session, operation, request|response, and sequence in the conversation. A suggestion would be "SSSSOR##.trc" where SSSS: an arbitrary unique sequence identifier. The identifier would be unique within the "Traces" directory. O: The operation of the request/response. This is the hexadecimal value of the IPP operation enum. R: Designates request or response. A=request B=response. ##: sequence number of the operation in the IPP conversation. We will also need to catalogue the contents of the directory. This can be accomplished by a pdf file containing a table with relevant information. I can keep this up to date if contributors send me the information. I think some concise description of the objective/purpose of the IPP conversation would be appropriate. I found that putting up an IPP emulator through an ISV is trivial. The emulator is the front end of my IPP printer. I have this anyway since small printers do not have very rich debug environments. I think we need to know if there is any interest in pursuing binary trace files. Do any other individuals have any feelings on this? What do you think? 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 __________________________________ > -----Original Message----- > From: Steve Gebert [SMTP:stevegeb@us.ibm.com] > Sent: Monday, December 08, 1997 3:39 PM > To: ipp@pwg.org > Subject: > > For interoperability testing, we were wondering if people were > interested in > exchanging binary files > corresponding to IPP Requests and Responses. The parties using these > files > would simply need to > construct a simple program to feed the file data into their server > or client > and read data from their > server or client into a file. > > These files could be sent as email attachments and for the near term > help > with interoperability testing > prior to people setting up machines outside filewalls. Perhaps we > could even > catalog the files and > make them available for download so that there would be a common > test > baseline for early testing. > > We could make some example files available if there is any > interest. What do > you think Peter? > > > Steve Gebert From ipp-owner@pwg.org Tue Dec 9 13:45:00 1997 Delivery-Date: Tue, 09 Dec 1997 13:45:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA28866 for ; Tue, 9 Dec 1997 13:45:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09147 for ; Tue, 9 Dec 1997 13:47:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA14210 for ; Tue, 9 Dec 1997 13:44:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 13:40:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13575 for ipp-outgoing; Tue, 9 Dec 1997 13:27:16 -0500 (EST) Message-ID: <348D8C8B.643755FA@underscore.com> Date: Tue, 09 Dec 1997 13:23:07 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: Mailing List IPP Subject: Re: IPP> A free IPP test suite to be available! References: <3488206D.472A4975@underscore.com> <3.0.1.32.19971207192809.009084e0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Just a few final words on this subject. Carl-Uno Manros wrote: > You might be horrified to learn that Steve Zilles also handed out > documentation and said a few words about Adobe's Job Ticket's, which is now > public information on their web site. Adobe (via Steve Zilles) was not explicitly trying to sell anyone anything. (At least not directly... ;-) Btw, it would have been great if the actual URL on this topic was listed in the minutes. > Jay, my impression is that we are talking about sour grapes here, you are > just kicking yourself that you decided not to come to the meeting, in which > case I am sure that the discussion of this subject would have taken much > more time from the rest of our agenda. Well, you're just plain wrong on this one, Carl-Uno. It's too bad you feel this way. Look, my point is this. An IPP test suite is important to ALL of us, whether we are a customer or a vendor of such a suite. If the PWG desired to entertain discussion of this topic, then it should have been formally listed in the agendas of one or more PWG projects. That way people like Chris Wellens and other host-based software vendors could have had the chance to be at the discussion to witness all the comments first-hand, rather than get a real-view-mirror statement as documented in the minutes. As most everyone knows by now, I'm all in favor of business-based discussion in the PWG (as long as we don't step on the IETF's toes in the process). However, any and all such discussion should be done on a level playing field, and not to the sole benefit of a single vendor. That's all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 9 14:09:35 1997 Delivery-Date: Tue, 09 Dec 1997 14:09:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28992 for ; Tue, 9 Dec 1997 14:09:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09246 for ; Tue, 9 Dec 1997 14:12:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14957 for ; Tue, 9 Dec 1997 14:09:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 14:05:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14321 for ipp-outgoing; Tue, 9 Dec 1997 13:52:30 -0500 (EST) From: don@lexmark.com Message-Id: <199712091850.AA23144@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: jkm@underscore.com Cc: Cmanros@Cp10.Es.Xerox.Com, Ipp@pwg.org Date: Tue, 9 Dec 1997 13:50:11 -0500 Subject: Re: IPP> A free IPP test suite to be available! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Jay Martin said: >Adobe (via Steve Zilles) was not explicitly trying to sell anyone >anything. (At least not directly... ;-) Btw, it would have been >great if the actual URL on this topic was listed in the minutes. The minutes would have listed the URL had it been provided. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Dec 9 15:19:01 1997 Delivery-Date: Tue, 09 Dec 1997 15:19:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29371 for ; Tue, 9 Dec 1997 15:19:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09560 for ; Tue, 9 Dec 1997 15:21:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16079 for ; Tue, 9 Dec 1997 15:18:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 15:12:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA15395 for ipp-outgoing; Tue, 9 Dec 1997 14:59:18 -0500 (EST) From: Steve Gebert To: Subject: IPP> TES: IBM Client Prototye Message-ID: <5030100014851699000002L092*@MHS> Date: Tue, 9 Dec 1997 14:59:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA29371 The IBM client prototype has been updated and is now available at the same location (www.printers.ibm.com/ download.html). I believe we have fixed the problems that people have mentioned. This is version 1.1 of the prototype and since it is 2-3 days old probably down-level, but I guess that is the way it goes. Please see the README.FIRST file for changes. Steve Gebert From ipp-owner@pwg.org Tue Dec 9 15:34:02 1997 Delivery-Date: Tue, 09 Dec 1997 15:34:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29466 for ; Tue, 9 Dec 1997 15:34:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09629 for ; Tue, 9 Dec 1997 15:36:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16768 for ; Tue, 9 Dec 1997 15:33:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 15:29:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15768 for ipp-outgoing; Tue, 9 Dec 1997 15:14:34 -0500 (EST) Message-Id: <348DA68A.9A92D389@pogo.wv.tek.com> Date: Tue, 09 Dec 1997 12:14:02 -0800 From: Chuck Adams Organization: Tektronix, Inc. X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: Ipp@pwg.org Subject: IPP> Adobe Job Ticket URL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Folks, Here is what I found: http://www.adobe.com/supportservice/devrelations/technotes.html see: Portable Job Ticket Format Chuck Adams Tektronix, Inc. From ipp-owner@pwg.org Tue Dec 9 16:11:25 1997 Delivery-Date: Tue, 09 Dec 1997 16:11:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29691 for ; Tue, 9 Dec 1997 16:11:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09795 for ; Tue, 9 Dec 1997 16:14:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA17583 for ; Tue, 9 Dec 1997 16:11:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 16:07:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16944 for ipp-outgoing; Tue, 9 Dec 1997 15:54:07 -0500 (EST) Message-ID: <348DAFAF.371D63DC@underscore.com> Date: Tue, 09 Dec 1997 15:53:03 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Adobe Job Ticket URL References: <348DA68A.9A92D389@pogo.wv.tek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Chuck Adams wrote: > > Folks, > > Here is what I found: > > http://www.adobe.com/supportservice/devrelations/technotes.html > > see: > > Portable Job Ticket Format > > Chuck Adams > Tektronix, Inc. Here's the complete URL for those who don't want to spend a lot of time browsing a long (and excellent) list of technical topics on the Adobe web: http://www.adobe.com/supportservice/devrelations/PDFS/TN/5620.pjtf.pdf ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Dec 9 16:48:50 1997 Delivery-Date: Tue, 09 Dec 1997 16:48:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29882 for ; Tue, 9 Dec 1997 16:48:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09943 for ; Tue, 9 Dec 1997 16:51:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18403 for ; Tue, 9 Dec 1997 16:48:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 16:43:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA17759 for ipp-outgoing; Tue, 9 Dec 1997 16:30:40 -0500 (EST) From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: Keith Moore , ipp@pwg.org, wg-chairs@apps.ietf.org, directorate@apps.ietf.org, jis@mit.edu Subject: IPP> IPP and the security area (Re: Area Directors' comments on IPP) In-reply-to: Your message of "Tue, 09 Dec 1997 05:46:23 PST." <3.0.1.32.19971209054623.00ba7100@garfield> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8009.881702392.1@dale.uninett.no> Date: Tue, 09 Dec 1997 16:19:52 -0500 Message-ID: <8011.881702392@dale.uninett.no> Sender: ipp-owner@pwg.org Carl-Uno, you say: > If the security people are going to dictate in every detail what we > can or cannot do, then I think it is their responsibility to make sure > that they participate in our WGs to give advice us advice in the > context of our needs and discussions, rather than come down and > criticize what we have done every time we think we have found an > acceptable solution. I would say that the foot is definitely in the other shoe: If you see that protocol development is being done which will impact your product, it is definitely in your interest to make sure that the people doing that development know your requirements. It is 100% obvious to you that when you consider using TLS, the TLS group is an interesting forum for you. It is not at all obvious to the TLS group that there is anything going on in Internet printing that impacts requirements for TLS. That group too is an open forum; the reason you are not a member is because you have chosen not to be. Most of the people working on TLS are there because they need TLS in *other* projects; their own requirements are obvious to them, yours are not. And remember: this is not something they do for a hobby; anything we ask them to do above what they already do usually comes straight out of their spare time. The security requirements are really, really simple: - THINK about what security your application needs, and provide that - No plaintext passwords The requirements that apply to ALL protocols, in ALL aspects are: - Enough requirements to ensure interoperability - Avoid use of IPR-tainted technology whenever reasonable. The last two are NOT security requirements, it's just that the security area, thanks to RSA, has one of the nastiest examples of this being a problem. BTW, I consulted with the security AD about ciphersuites in TLS; he was quite surprised that anyone would consider using TLS without security, since this adds quite a bit of overhead over raw TCP. Ciphersuites are "numbered items", but the intent of the TLS group is that it should be simple to add new ones; the reason for using suites rather than feature combinations is that some combinations of features have non-obvious but serious security flaws. If you want a ciphersuite with different properties than the existing set, take this up with the TLS group. ietf-tls@consensus.com; use the -request convention to subscribe. Harald A From ipp-owner@pwg.org Tue Dec 9 23:44:40 1997 Delivery-Date: Tue, 09 Dec 1997 23:44:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08430 for ; Tue, 9 Dec 1997 23:44:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA11105 for ; Tue, 9 Dec 1997 23:47:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA21033 for ; Tue, 9 Dec 1997 23:44:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Dec 1997 23:39:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA20404 for ipp-outgoing; Tue, 9 Dec 1997 23:26:17 -0500 (EST) Message-Id: <3.0.1.32.19971209190557.00bd39f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Dec 1997 19:05:57 PST To: Harald.T.Alvestrand@uninett.no, Carl-Uno Manros From: Carl-Uno Manros Subject: IPP> Re: IPP and the security area (Re: Area Directors' comments on IPP) Cc: Keith Moore , ipp@pwg.org, wg-chairs@apps.ietf.org, directorate@apps.ietf.org, jis@mit.edu, ietf-tls@consensus.com In-Reply-To: <8011.881702392@dale.uninett.no> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harald, We have been following the TLS activities for some time and have also held discussions with individual members of the WG. We were happy to use the TLS functionality as documented up to their last draft but one, but in the final version that was passed by the IESG they suddenly introduced some new mandatory stuff, for which we have so far seen little or no rationale or explanation. Just now I am only interested to get a recommendation, from whoever consider themselves qualified, about a "politically correct" combination of TLS security features that provides the same functionality as SSL3. Is this concrete enough? Carl-Uno At 01:19 PM 12/9/97 PST, Harald.T.Alvestrand@uninett.no wrote: >Carl-Uno, > >you say: >> If the security people are going to dictate in every detail what we >> can or cannot do, then I think it is their responsibility to make sure >> that they participate in our WGs to give advice us advice in the >> context of our needs and discussions, rather than come down and >> criticize what we have done every time we think we have found an >> acceptable solution. > >I would say that the foot is definitely in the other shoe: >If you see that protocol development is being done which will >impact your product, it is definitely in your interest to make >sure that the people doing that development know your requirements. > >It is 100% obvious to you that when you consider using TLS, the >TLS group is an interesting forum for you. >It is not at all obvious to the TLS group that there is anything >going on in Internet printing that impacts requirements for TLS. >That group too is an open forum; the reason you are not a member is >because you have chosen not to be. >Most of the people working on TLS are there because they need TLS in >*other* projects; their own requirements are obvious to them, yours >are not. >And remember: this is not something they do for a hobby; anything >we ask them to do above what they already do usually comes straight >out of their spare time. > >The security requirements are really, really simple: >- THINK about what security your application needs, and provide that >- No plaintext passwords >The requirements that apply to ALL protocols, in ALL aspects are: >- Enough requirements to ensure interoperability >- Avoid use of IPR-tainted technology whenever reasonable. >The last two are NOT security requirements, it's just that the >security area, thanks to RSA, has one of the nastiest examples of this >being a problem. > >BTW, I consulted with the security AD about ciphersuites in TLS; he >was quite surprised that anyone would consider using TLS without >security, since this adds quite a bit of overhead over raw TCP. >Ciphersuites are "numbered items", but the intent of the TLS group >is that it should be simple to add new ones; the reason for using >suites rather than feature combinations is that some combinations >of features have non-obvious but serious security flaws. >If you want a ciphersuite with different properties than the existing >set, take this up with the TLS group. ietf-tls@consensus.com; use the >-request convention to subscribe. > > Harald A > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Dec 10 00:46:10 1997 Delivery-Date: Wed, 10 Dec 1997 00:46:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA08665 for ; Wed, 10 Dec 1997 00:46:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA11204 for ; Wed, 10 Dec 1997 00:49:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA21958 for ; Wed, 10 Dec 1997 00:46:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 00:40:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA21346 for ipp-outgoing; Wed, 10 Dec 1997 00:27:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 09 Dec 1997 22:24:09 -0700 From: Scott Isaacson To: ipp@pwg.org, kugler@us.ibm.com Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Carl has suggested that there might not be a need Validate-Job. I haven't seen any public responses? Does silence mean AGREE or DISAGREE? Or is everyone like me - don't know yet. Carl also asks: >>> Carl Kugler 12/05 9:26 AM >>> > Side question: does an IPP error response have an HTTP status code of > Successful "200 OK"? The answer to this is YES. The HTTP POST worked fine. The "application/ipp" body within the POST had the error. From ipp-owner@pwg.org Wed Dec 10 04:13:32 1997 Delivery-Date: Wed, 10 Dec 1997 04:13:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA09270 for ; Wed, 10 Dec 1997 04:12:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11570 for ; Wed, 10 Dec 1997 04:15:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA23796 for ; Wed, 10 Dec 1997 04:12:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 04:06:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA23144 for ipp-outgoing; Wed, 10 Dec 1997 03:53:45 -0500 (EST) Message-Id: <3.0.1.32.19971210005402.00b8a100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Dec 1997 00:54:02 PST To: Scott Isaacson , ipp@pwg.org, kugler@us.ibm.com From: Carl-Uno Manros Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 09:24 PM 12/9/97 PST, Scott Isaacson wrote: >Carl has suggested that there might not be a need Validate-Job. > >I haven't seen any public responses? Does silence mean AGREE or DISAGREE? >Or is >everyone like me - don't know yet. > As this was NOT raised as an issue during the Last Call period, my assumption is it stays as it is in the current draft. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Dec 10 08:17:35 1997 Delivery-Date: Wed, 10 Dec 1997 08:17:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA09862 for ; Wed, 10 Dec 1997 08:17:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA12039 for ; Wed, 10 Dec 1997 08:20:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA25588 for ; Wed, 10 Dec 1997 08:17:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 08:07:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA24928 for ipp-outgoing; Wed, 10 Dec 1997 07:54:44 -0500 (EST) From: "Zehler,Peter" To: Scott Isaacson , ipp@pwg.org, kugler@us.ibm.com Subject: RE: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Date: Wed, 10 Dec 1997 04:58:34 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Dec10.045437pst."52370(6)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Scott, Carl, I must have missed the original posting. If the question is "Do we need a Validate-Job operation?" I do have an opinion. I believe this would be very useful for large jobs across the Internet where fidelity is required. I also see this useful in intranets and long job printing. I was under the impression that Paul Moore wanted this operation to initiate security challenges. I would assume any operation could accomplish this. I hope we leave it in and let implementations of IPP print systems determine its viability. There is very little overhead for support of this operation. 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 __________________________________ > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Wednesday, December 10, 1997 12:24 AM > To: ipp@pwg.org; kugler@us.ibm.com > Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, > Roger, > > Carl has suggested that there might not be a need Validate-Job. > > I haven't seen any public responses? Does silence mean AGREE or > DISAGREE? > Or is > everyone like me - don't know yet. > > Carl also asks: > > >>> Carl Kugler 12/05 9:26 AM >>> > > Side question: does an IPP error response have an HTTP status code > of > > Successful "200 OK"? > > The answer to this is YES. The HTTP POST worked fine. The > "application/ipp" body within > the POST had the error. > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Wed Dec 10 08:51:36 1997 Delivery-Date: Wed, 10 Dec 1997 08:51:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA10032 for ; Wed, 10 Dec 1997 08:51:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA12149 for ; Wed, 10 Dec 1997 08:54:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA26369 for ; Wed, 10 Dec 1997 08:51:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 08:45:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA25733 for ipp-outgoing; Wed, 10 Dec 1997 08:32:44 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Message-ID: <5030100014885950000002L002*@MHS> Date: Wed, 10 Dec 1997 08:32:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA10032 I'd prefer to leave it in. Roger K deBry Senior Technical 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 12/10/97 06:32 AM --------------------------- ipp-owner@pwg.org 12/09/97 10:43 PM Please respond to ipp-owner@pwg.org @ internet To: Carl Kugler/Boulder/IBM@ibmus, ipp@pwg.org @ internet cc: Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Carl has suggested that there might not be a need Validate-Job. I haven't seen any public responses? Does silence mean AGREE or DISAGREE? Or is everyone like me - don't know yet. Carl also asks: >>> Carl Kugler 12/05 9:26 AM >>> > Side question: does an IPP error response have an HTTP status code of > Successful "200 OK"? The answer to this is YES. The HTTP POST worked fine. The "application/ipp" body within the POST had the error. From ipp-owner@pwg.org Wed Dec 10 11:10:08 1997 Delivery-Date: Wed, 10 Dec 1997 11:10:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11168 for ; Wed, 10 Dec 1997 11:10:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA12730 for ; Wed, 10 Dec 1997 11:12:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA27726 for ; Wed, 10 Dec 1997 11:09:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 10:59:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27030 for ipp-outgoing; Wed, 10 Dec 1997 10:45:43 -0500 (EST) Message-Id: <3.0.1.32.19971210073743.0115d100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Dec 1997 07:37:43 PST To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Cc: Larry Masinter In-Reply-To: <5030100014690410000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Carl, I disagree. We should NOT remove Validate-Job for the following reasons: 1. I had the same language that you propose about returning error status early and the clients should monitor such returned status, but the replies on the DL were that that didn't work with HTTP, so I removed the recommendation that the Printer return an error status as soon as it detects an error, rather than waiting until the entire document has been sent. So there is substantial disagreement with your suggestion about HTTP. Could some HTTP experts shed some light on this confusion that we in the IPP WG have about HTTP? 2. Validate-Job works with any transport protocol. While we are only envisioning HTTP as a transport, we are trying to keep the model independent of the transport. 3. Validate-Job is easy to implement, because its syntax and semantics are the same as Print-Job, except that no data is sent, no job is created, no job-id is returned, and no job status attributes are returned. 4. Validate-Job is a MANDATORY operation, so a client can count on it being implemented by all IPP Printers. An IPP client cannot count on the behavior you describe with all HTTP servers, so it is more likely to work for a client to use a Validate-Job before sending a big document with Print-Job. If the document is small, the client can skip the Validate-Job step if it wants to. Also if the client doesn't care about response, it can always skip the Validate-Job, no matter how big the document is. Tom At 08:26 12/05/1997 PST, Carl Kugler wrote: >I have a comment about this section: > >15.3 Suggested Operation Processing Algorithm for all operations >... >In the following algorithm, processing continues step by step until a "RETURNS >the xxx status code *(" statement is encountered. Error returns are indicated >by the verb: "REJECTS". Since clients have difficulty getting the status code, >before sending all of the document data in a Print-Job request, clients SHOULD >use the Validate-Job operation before sending large documents to be printed, in >order to validate whether the IPP Printer will accept the job or not. > >I think that this use of the Validate-Job operation might be redundant, since >HTTP/1.1 already provides a mechanism for this kind of thing: > >o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor > the network connection for an error status while it is transmitting > the request. If the client sees an error status, it SHOULD > immediately cease transmitting the body. If the body is being sent > using a "chunked" encoding (section 3.6), a zero length chunk and > empty footer MAY be used to prematurely mark the end of the > message. If the body was preceded by a Content-Length header, the > client MUST close the connection. >... >o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 > (Continue) status followed by a regular response. >... >100 Continue > The client may continue with its request. This interim response is > used to inform the client that the initial part of the request has > been received and has not yet been rejected by the server. The client > SHOULD continue by sending the remainder of the request or, if the > request has already been completed, ignore this response. The server > MUST send a final response after the request has been completed. > >So, the IPP object SHOULD process and validate the request up to step 15.4.8, >then send either a "100 Continue" or an error response to the client, before >waiting to receive the document data. The client should SHOULD monitor the >network connection for an error status while it is transmitting the request. If >the client sees an error status, it SHOULD immediately cease transmitting >document data. Since we should do all this anyway for HTTP/1.1, maybe we don't >need the separate Validate-Job step? > >Side question: does an IPP error response have an HTTP status code of >Successful "200 OK"? > >Carl Kugler > > From ipp-owner@pwg.org Wed Dec 10 11:22:24 1997 Delivery-Date: Wed, 10 Dec 1997 11:22:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11319 for ; Wed, 10 Dec 1997 11:22:13 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA12837 for ; Wed, 10 Dec 1997 11:25:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA28417 for ; Wed, 10 Dec 1997 11:22:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 11:16:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27107 for ipp-outgoing; Wed, 10 Dec 1997 10:58:38 -0500 (EST) Date: Wed, 10 Dec 1997 07:55:30 -0800 (Pacific Standard Time) From: Ron Bergman To: Jay Martin cc: ipp@pwg.org Subject: Re: IPP> A free IPP test suite to be available! In-Reply-To: <348D8C8B.643755FA@underscore.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Jay, Had you been at the meeting you may have been even more vocal on this subject. The Genoa presentation was primarily a sales presentation and a "Oh byte way, we are planning to do an IPP test suite. But we don't know when it will be available." It would have been much more appropriate had they presented actual plans for a test suite with, at least a mini-specification. Ron Bergman Dataproducts Corp. On Tue, 9 Dec 1997, Jay Martin wrote: > Just a few final words on this subject. > > Carl-Uno Manros wrote: > > > You might be horrified to learn that Steve Zilles also handed out > > documentation and said a few words about Adobe's Job Ticket's, which is now > > public information on their web site. > > Adobe (via Steve Zilles) was not explicitly trying to sell anyone > anything. (At least not directly... ;-) Btw, it would have been > great if the actual URL on this topic was listed in the minutes. > > > > Jay, my impression is that we are talking about sour grapes here, you are > > just kicking yourself that you decided not to come to the meeting, in which > > case I am sure that the discussion of this subject would have taken much > > more time from the rest of our agenda. > > Well, you're just plain wrong on this one, Carl-Uno. It's too bad > you feel this way. > > Look, my point is this. An IPP test suite is important to ALL > of us, whether we are a customer or a vendor of such a suite. > If the PWG desired to entertain discussion of this topic, then > it should have been formally listed in the agendas of one or > more PWG projects. That way people like Chris Wellens and other > host-based software vendors could have had the chance to be at > the discussion to witness all the comments first-hand, rather > than get a real-view-mirror statement as documented in the minutes. > > As most everyone knows by now, I'm all in favor of business-based > discussion in the PWG (as long as we don't step on the IETF's toes > in the process). However, any and all such discussion should be > done on a level playing field, and not to the sole benefit of a > single vendor. That's all. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From ipp-owner@pwg.org Wed Dec 10 11:57:05 1997 Delivery-Date: Wed, 10 Dec 1997 11:57:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11929 for ; Wed, 10 Dec 1997 11:57:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA13037 for ; Wed, 10 Dec 1997 11:59:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA29269 for ; Wed, 10 Dec 1997 11:57:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 11:52:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28592 for ipp-outgoing; Wed, 10 Dec 1997 11:39:01 -0500 (EST) Message-Id: <3.0.1.32.19971210080140.00ce9770@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Dec 1997 08:01:40 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO latest protocol doc [.pdf files uploaded] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've distilled the two .doc files and produced: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-971208-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-971208.pdf As an experiment, I checked the MS-WORD V6 compatibility feature to display color as black and white on a black and white printer. Those who have had trouble in the past printing rev.pdf files with red revision marks, please try this one and see if it works. It will save time and space not to have to produce both black and red versions of pdf files with revision marks. Thanks, Tom >Date: Mon, 8 Dec 1997 19:01:52 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO latest protocol doc >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I have just downloaded the latest protocol documents to > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > >The documents are: > > ipp-pro-971208.doc MS Word Version 6 with no revisions > ipp-pro-971208.txt Text with no revisions > ipp-pro-971208-rev.doc MS Word Version 6 with revisions > >This has changes we agreed on in Los Angeles > > From ipp-owner@pwg.org Wed Dec 10 12:38:29 1997 Delivery-Date: Wed, 10 Dec 1997 12:38:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA12210 for ; Wed, 10 Dec 1997 12:38:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13299 for ; Wed, 10 Dec 1997 12:41:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA00132 for ; Wed, 10 Dec 1997 12:38:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 12:31:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29475 for ipp-outgoing; Wed, 10 Dec 1997 12:18:39 -0500 (EST) X-Sender: szilles@elroy Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Dec 1997 09:05:38 -0800 To: Carl-Uno Manros , Scott Isaacson , ipp@pwg.org, kugler@us.ibm.com From: szilles@Adobe.COM (Steve Zilles) Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Cc: szilles@Adobe.COM Sender: ipp-owner@pwg.org At 12:54 AM 12/10/97, Carl-Uno Manros wrote: >At 09:24 PM 12/9/97 PST, Scott Isaacson wrote: >>Carl has suggested that there might not be a need Validate-Job. >> >>I haven't seen any public responses? Does silence mean AGREE or DISAGREE? >>Or is >>everyone like me - don't know yet. >> > >As this was NOT raised as an issue during the Last Call period, my >assumption is it stays as it is in the current draft. > >Carl-Uno I agree with Carl-Uno and, as I remember it, Validate-Job is needed because Create-Job is not mandatory so there is no other guaranteed way to check out a single document job. Steve Zilles -------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com | Adobe Systems Inc. | | Mailstop W14 | tel: (work) (408) 536-4766 | 345 Park Avenue | (Admin) (408) 536-4751 | San Jose, CA 95110-2704 | fax: (408) 537-4042 | -------------------------------------------------------------- From ipp-owner@pwg.org Wed Dec 10 13:02:30 1997 Delivery-Date: Wed, 10 Dec 1997 13:02:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12337 for ; Wed, 10 Dec 1997 13:02:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13489 for ; Wed, 10 Dec 1997 13:05:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00965 for ; Wed, 10 Dec 1997 13:02:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 12:56:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA00271 for ipp-outgoing; Wed, 10 Dec 1997 12:43:17 -0500 (EST) Message-Id: <3.0.1.32.19971210083245.0113ea90@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Dec 1997 08:32:45 PST To: "Zehler,Peter" , Steve Gebert , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> RE: TES:binary files In-Reply-To: <97Dec9.063143pst."61011(1)"@alpha.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Peter, I agree on your approach to putting up trace files. However, I have a couple of suggestions: 1. There should be both a printable form (.txt) and a binary form (.trc). Actually, if the printable form is in MS-WORD, it should have line numbers on it, so that it is easier to talk about. Then there should be .doc and .pdf forms of the printable form. 2. The printable form of the trace file should contain all the information about the request or response in English at the beginning of the file, including: a. the person posting the trace file b. contact information for that person c. the unique sequence number for the conversation (SSSS) d. the name of the operation (O) d. whether it is a request or a response (R) e. the file name of the file f. the date g. a comment about the intent of the operation request or response, such as "submitting a job with fidelity 'false'" or "intentional invalid request, expecting a client-error-bad-request rejection" or "rejection response of 'client-error-bad-request'". 3. The binary form would just be the raw binary of each request or response. Then a bunch of trace files can be printed and the printout will completely identify the content. A few questions, suggestions below. At 06:35 12/09/1997 PST, Zehler,Peter wrote: >Steve, > Even when we test across the internet we will still need to capture >the results. I am all for anything that will help us move along. > I have created a directory called "Traces" under the new_TES >directory for the time being. We can decide on a directory structure at >a later time. I assume that we will capture traces in more than one >form. > We need to decide on a naming convention. For this purpose I assume >that we will limit each trace file to a single request or response. The >naming convention should provide for the pairing of the request to its >response. The naming convention should facilitate the capturing of an >extended IPP conversation. A conversation is a sequence of IPP >operations on an IPP printer. > We need to designate the session, operation, request|response, and >sequence in the conversation. A suggestion would be "SSSSOR##.trc" >where >SSSS: an arbitrary unique sequence identifier. The identifier > would be unique within the "Traces" directory. Rather than this being numeric, how about the two letter initials of the person submitting the trace and a two digit sequence number that they keep track of? >O: The operation of the request/response. This is the > hexadecimal value of the IPP operation enum. >R: Designates request or response. A=request > B=response. >##: sequence number of the operation in the IPP conversation. Starting at 00? So if I posted a trace of Validate-Job, Print-Job, Get-Jobs, there would be six printable files: TH004A00.txt TH004B01.txt TH002A02.txt TH002B03.txt TH00AA04.txt TH00AB04.txt and six binary files: TH004A00.trc TH004B01.trc TH002A02.trc TH002B03.trc TH00AA04.trc TH00AB04.trc > We will also need to catalogue the contents of the directory. This >can be accomplished by a pdf file containing a table with relevant >information. I can keep this up to date if contributors send me the >information. I think some concise description of the objective/purpose >of the IPP conversation would be appropriate. > >I found that putting up an IPP emulator through an ISV is trivial. The >emulator is the front end of my IPP printer. I have this anyway since >small printers do not have very rich debug environments. > >I think we need to know if there is any interest in pursuing binary >trace files. Do any other individuals have any feelings on this? Good idea. But can we have printable ones too? Do we need a tool to dump a binary trace file into a printable one? > >What do you think? >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 >__________________________________ > >> -----Original Message----- >> From: Steve Gebert [SMTP:stevegeb@us.ibm.com] >> Sent: Monday, December 08, 1997 3:39 PM >> To: ipp@pwg.org >> Subject: >> >> For interoperability testing, we were wondering if people were >> interested in >> exchanging binary files >> corresponding to IPP Requests and Responses. The parties using these >> files >> would simply need to >> construct a simple program to feed the file data into their server >> or client >> and read data from their >> server or client into a file. >> >> These files could be sent as email attachments and for the near term >> help >> with interoperability testing >> prior to people setting up machines outside filewalls. Perhaps we >> could even >> catalog the files and >> make them available for download so that there would be a common >> test >> baseline for early testing. >> >> We could make some example files available if there is any >> interest. What do >> you think Peter? >> >> >> Steve Gebert > > From ipp-owner@pwg.org Wed Dec 10 16:31:29 1997 Delivery-Date: Wed, 10 Dec 1997 16:31:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA13445 for ; Wed, 10 Dec 1997 16:31:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14580 for ; Wed, 10 Dec 1997 16:34:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03199 for ; Wed, 10 Dec 1997 16:31:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 16:24:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02521 for ipp-outgoing; Wed, 10 Dec 1997 16:11:11 -0500 (EST) From: Harald.T.Alvestrand@uninett.no To: Carl-Uno Manros cc: Keith Moore , ipp@pwg.org, wg-chairs@apps.ietf.org, directorate@apps.ietf.org, jis@mit.edu, ietf-tls@consensus.com Subject: IPP> Re: IPP and the security area (Re: Area Directors' comments on IPP) In-reply-to: Your message of "Tue, 09 Dec 1997 19:05:57 PST." <3.0.1.32.19971209190557.00bd39f0@garfield> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9857.881764146.1@dale.uninett.no> Date: Wed, 10 Dec 1997 09:29:07 -0500 Message-ID: <9859.881764147@dale.uninett.no> Sender: ipp-owner@pwg.org Carl-Uno said: > We were happy to use the TLS functionality as documented up to their > last draft but one, but in the final version that was passed by the > IESG they suddenly introduced some new mandatory stuff, for which we > have so far seen little or no rationale or explanation. The mandatory stuff (section 9 of the TLS document) was added by the TLS WG after explicit instructions from the Security AD, with explicit backing from the plenary at the Munich IETF. It was added in order to satisfy the requirements for interoperability and avoidance of IPR issues that are common to all IETF protocols. I don't know of any other last-minute changes, but this particular section of the TLS spec should hardly come as a surprise to anyone; it was the subject of great debate over the last 6 months. Was this the only change you had problems with? Harald A From ipp-owner@pwg.org Wed Dec 10 18:38:35 1997 Delivery-Date: Wed, 10 Dec 1997 18:38:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA14088 for ; Wed, 10 Dec 1997 18:38:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15107 for ; Wed, 10 Dec 1997 18:41:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05590 for ; Wed, 10 Dec 1997 18:38:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 18:32:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04261 for ipp-outgoing; Wed, 10 Dec 1997 18:10:43 -0500 (EST) Message-ID: <348F20E7.3B27D0A2@bldvmb.boulder.ibm.com> Date: Wed, 10 Dec 1997 16:08:26 -0700 From: Carl Kugler X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I must admit I was "thinking out loud" about this, trying to understand it. Also, I'm relatively new to IPP and I missed the exchange you refer to in #1; could you point me to it in the archives so I can review it? I didn't mean to suggest removing the Validate-Job operation; just the words in the model document that say "clients SHOULD use the Validate-Job operation before sending large documents to be printed, in order to validate whether the IPP Printer will accept the job or not". I thought that IF servers returned error status without waiting to receive the document data, and IF clients monitored for error status while transmitting the request, it might be more efficient to just send the Print-Job and avoid the round trip for the Validate-Job. There's also a little window there between the Validate and the Print during which it's possible that conditions could change on the Printer. If the IPP operation and attributes were sent in a separate HTTP "chunk" before the document data, would that make it easier for the server to return a response before receiving the entire HTTP request? I guess that's really an HTTP question, or a web server implementation question. Finally, after peeking for the first time at Section 8.2, Message Transmission Requirements, in INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997, at http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-01.txt, I wish to withdraw my suggestion that IPP make use of the 100-Continue response to notify the client that a PrintJob has been validated, continue sending document data. -Carl |Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, > Tom Hastings (hastings@cp10.es.xerox.com) > Wed, 10 Dec 1997 07:37:43 PST > > Carl, > > I disagree. We should NOT remove Validate-Job for the following reasons: > > 1. I had the same language that you propose about returning error status > early and the clients should monitor such returned status, but the > replies on the DL were that that didn't work with HTTP, so I removed > the recommendation that the Printer return an error status as soon > as it detects an error, rather than waiting until the entire document > has been sent. So there is substantial disagreement with your suggestion > about HTTP. > > Could some HTTP experts shed some light on this confusion that we in the > IPP WG have about HTTP? > > 2. Validate-Job works with any transport protocol. While we are only > envisioning HTTP as a transport, we are trying to keep the model > independent of the transport. > > 3. Validate-Job is easy to implement, because its syntax and semantics > are the same as Print-Job, except that no data is sent, no job is created, > no job-id is returned, and no job status attributes are returned. > > 4. Validate-Job is a MANDATORY operation, so a client can count on it > being implemented by all IPP Printers. An IPP client cannot count on > the behavior you describe with all HTTP servers, so it is more likely to > work for a client to use a Validate-Job before sending a big document > with Print-Job. If the document is small, the client can skip the > Validate-Job step if it wants to. Also if the client doesn't care > about response, it can always skip the Validate-Job, no matter how big > the document is. > > Tom > > At 08:26 12/05/1997 PST, Carl Kugler wrote: > >I have a comment about this section: > > > >15.3 Suggested Operation Processing Algorithm for all operations > >... > >In the following algorithm, processing continues step by step until a > "RETURNS > >the xxx status code *(" statement is encountered. Error returns are > indicated > >by the verb: "REJECTS". Since clients have difficulty getting the status > code, > >before sending all of the document data in a Print-Job request, clients > SHOULD > >use the Validate-Job operation before sending large documents to be > printed, in > >order to validate whether the IPP Printer will accept the job or not. > > > >I think that this use of the Validate-Job operation might be redundant, since > >HTTP/1.1 already provides a mechanism for this kind of thing: > > > >o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor > > the network connection for an error status while it is transmitting > > the request. If the client sees an error status, it SHOULD > > immediately cease transmitting the body. If the body is being sent > > using a "chunked" encoding (section 3.6), a zero length chunk and > > empty footer MAY be used to prematurely mark the end of the > > message. If the body was preceded by a Content-Length header, the > > client MUST close the connection. > >... > >o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 > > (Continue) status followed by a regular response. > >... > >100 Continue > > The client may continue with its request. This interim response is > > used to inform the client that the initial part of the request has > > been received and has not yet been rejected by the server. The client > > SHOULD continue by sending the remainder of the request or, if the > > request has already been completed, ignore this response. The server > > MUST send a final response after the request has been completed. > > > >So, the IPP object SHOULD process and validate the request up to step 15.4.8, > >then send either a "100 Continue" or an error response to the client, before > >waiting to receive the document data. The client should SHOULD monitor the > >network connection for an error status while it is transmitting the > request. If > >the client sees an error status, it SHOULD immediately cease transmitting > >document data. Since we should do all this anyway for HTTP/1.1, maybe we > don't > >need the separate Validate-Job step? > > > >Side question: does an IPP error response have an HTTP status code of > >Successful "200 OK"? > > > >Carl Kugler > > > > > > * Next message: Ron Bergman: "Re: IPP> A free IPP test suite to be available!" > * Previous message: Roger K Debry: "Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger," http://www.pwg.org/hypermail/ipp/2889.html From ipp-owner@pwg.org Wed Dec 10 19:59:13 1997 Delivery-Date: Wed, 10 Dec 1997 19:59:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14336 for ; Wed, 10 Dec 1997 19:59:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15285 for ; Wed, 10 Dec 1997 20:02:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06523 for ; Wed, 10 Dec 1997 19:59:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 19:53:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05905 for ipp-outgoing; Wed, 10 Dec 1997 19:40:17 -0500 (EST) Message-Id: <199712110040.QAA22664@rbi.rbi.com> Subject: IPP> Fonts, Job Redirection, and Protocol Date: Wed, 10 Dec 97 16:40:11 -0800 x-sender: bhasting@rbi.rbi.com x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Bill Hastings To: "ipp" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org I'm fairly new to IPP so please excuse any "dumb" questions. 1) How can a client determine what fonts are available (built-in) in a PostScript Printer? 2) Is there an appropriate mechanism for redirecting a job after it has been sent to a printer? The only thing I can come up with is to save a copy of the job data on the client side, cancel the current job in progress, and resend the job to a new printer. 3) In the latest protocol document (dated 12/8/97), section 10.7 (example Get-Jobs Response) the last "localized-name" attribute is a compound attribute, but its format doesn't match the description given in section 3.1. Which is correct? Bill Hastings RBI Software Systems bhastings@rbi.com From ipp-owner@pwg.org Wed Dec 10 20:23:17 1997 Delivery-Date: Wed, 10 Dec 1997 20:23:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14447 for ; Wed, 10 Dec 1997 20:23:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15383 for ; Wed, 10 Dec 1997 20:26:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA07244 for ; Wed, 10 Dec 1997 20:23:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 20:17:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06626 for ipp-outgoing; Wed, 10 Dec 1997 20:04:12 -0500 (EST) From: Harry Lewis To: , Subject: IPP> Directory Schema attribute question Message-ID: <5030300015950649000002L092*@MHS> Date: Wed, 10 Dec 1997 20:09:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA14447 This is either a nit or a misunderstanding on my part. Appx E of the Model doc lists attributes to be included in a directory schema (great idea!) but does not always refer exactly to the same name. Example finishings-supported vs. finishings in section 4.2.6. Is this a lingering editorial, or am I completely missing the boat somewhere on attribute names? Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Dec 10 21:19:18 1997 Delivery-Date: Wed, 10 Dec 1997 21:19:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA14633 for ; Wed, 10 Dec 1997 21:19:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15495 for ; Wed, 10 Dec 1997 21:22:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08305 for ; Wed, 10 Dec 1997 21:19:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 21:09:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07427 for ipp-outgoing; Wed, 10 Dec 1997 20:47:22 -0500 (EST) Message-ID: <348F45BE.3721@sharplabs.com> Date: Wed, 10 Dec 1997 20:45:34 -0500 From: Randy Turner X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, References: <348F20E7.3B27D0A2@bldvmb.boulder.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org See my comments below... Randy Carl Kugler wrote: > > I must admit I was "thinking out loud" about this, trying to understand it. Also, I'm relatively new to > IPP and I missed the exchange you refer to in #1; could you point me to it in the archives so I can > review it? > > I didn't mean to suggest removing the Validate-Job operation; just the words in the model document > that say "clients SHOULD use the Validate-Job operation before sending large documents to be printed, > in order to validate whether the IPP Printer will accept the job or not". I agree with Carl that there is no reason to suggest the use of VALIDATE-JOB. The operation exists and is well described. We can include a scenario on how it could be used but there is no reason (IMHO) to suggest that it be used. I thought that IF servers > returned error status without waiting to receive the document data, and IF clients monitored for error > status while transmitting the request, it might be more efficient to just send the Print-Job and avoid > the round trip for the Validate-Job. There's also a little window there between the Validate and the > Print during which it's possible that conditions could change on the Printer. I believe there is wording that servers return errors as soon as they are detected, and not wait around to receive the entire request data. Clients should be designed to react on these statuses ASAP. > > If the IPP operation and attributes were sent in a separate HTTP "chunk" before the document data, > would that make it easier for the server to return a response before receiving the entire HTTP > request? I guess that's really an HTTP question, or a web server implementation question. > > Finally, after peeking for the first time at Section 8.2, Message Transmission Requirements, in > INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997, at > http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-01.txt, I wish to withdraw my > suggestion that IPP make use of the 100-Continue response to notify the client that a PrintJob has been > validated, continue sending document data. > > -Carl > > |Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger, > > > Tom Hastings (hastings@cp10.es.xerox.com) > > Wed, 10 Dec 1997 07:37:43 PST > > > > Carl, > > > > I disagree. We should NOT remove Validate-Job for the following reasons: > > > > 1. I had the same language that you propose about returning error status > > early and the clients should monitor such returned status, but the > > replies on the DL were that that didn't work with HTTP, so I removed > > the recommendation that the Printer return an error status as soon > > as it detects an error, rather than waiting until the entire document > > has been sent. So there is substantial disagreement with your suggestion > > about HTTP. > > > > Could some HTTP experts shed some light on this confusion that we in the > > IPP WG have about HTTP? > > > > 2. Validate-Job works with any transport protocol. While we are only > > envisioning HTTP as a transport, we are trying to keep the model > > independent of the transport. > > > > 3. Validate-Job is easy to implement, because its syntax and semantics > > are the same as Print-Job, except that no data is sent, no job is created, > > no job-id is returned, and no job status attributes are returned. > > > > 4. Validate-Job is a MANDATORY operation, so a client can count on it > > being implemented by all IPP Printers. An IPP client cannot count on > > the behavior you describe with all HTTP servers, so it is more likely to > > work for a client to use a Validate-Job before sending a big document > > with Print-Job. If the document is small, the client can skip the > > Validate-Job step if it wants to. Also if the client doesn't care > > about response, it can always skip the Validate-Job, no matter how big > > the document is. > > > > Tom > > > > At 08:26 12/05/1997 PST, Carl Kugler wrote: > > >I have a comment about this section: > > > > > >15.3 Suggested Operation Processing Algorithm for all operations > > >... > > >In the following algorithm, processing continues step by step until a > > "RETURNS > > >the xxx status code *(" statement is encountered. Error returns are > > indicated > > >by the verb: "REJECTS". Since clients have difficulty getting the status > > code, > > >before sending all of the document data in a Print-Job request, clients > > SHOULD > > >use the Validate-Job operation before sending large documents to be > > printed, in > > >order to validate whether the IPP Printer will accept the job or not. > > > > > >I think that this use of the Validate-Job operation might be redundant, since > > >HTTP/1.1 already provides a mechanism for this kind of thing: > > > > > >o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor > > > the network connection for an error status while it is transmitting > > > the request. If the client sees an error status, it SHOULD > > > immediately cease transmitting the body. If the body is being sent > > > using a "chunked" encoding (section 3.6), a zero length chunk and > > > empty footer MAY be used to prematurely mark the end of the > > > message. If the body was preceded by a Content-Length header, the > > > client MUST close the connection. > > >... > > >o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 > > > (Continue) status followed by a regular response. > > >... > > >100 Continue > > > The client may continue with its request. This interim response is > > > used to inform the client that the initial part of the request has > > > been received and has not yet been rejected by the server. The client > > > SHOULD continue by sending the remainder of the request or, if the > > > request has already been completed, ignore this response. The server > > > MUST send a final response after the request has been completed. > > > > > >So, the IPP object SHOULD process and validate the request up to step 15.4.8, > > >then send either a "100 Continue" or an error response to the client, before > > >waiting to receive the document data. The client should SHOULD monitor the > > >network connection for an error status while it is transmitting the > > request. If > > >the client sees an error status, it SHOULD immediately cease transmitting > > >document data. Since we should do all this anyway for HTTP/1.1, maybe we > > don't > > >need the separate Validate-Job step? > > > > > >Side question: does an IPP error response have an HTTP status code of > > >Successful "200 OK"? > > > > > >Carl Kugler > > > > > > > > > > * Next message: Ron Bergman: "Re: IPP> A free IPP test suite to be available!" > > * Previous message: Roger K Debry: "Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger," > > http://www.pwg.org/hypermail/ipp/2889.html From ipp-owner@pwg.org Wed Dec 10 21:24:44 1997 Delivery-Date: Wed, 10 Dec 1997 21:24:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA14653 for ; Wed, 10 Dec 1997 21:24:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15505 for ; Wed, 10 Dec 1997 21:27:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA09072 for ; Wed, 10 Dec 1997 21:24:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Dec 1997 21:15:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07455 for ipp-outgoing; Wed, 10 Dec 1997 20:52:23 -0500 (EST) Message-ID: <348F46E7.5F2F@sharplabs.com> Date: Wed, 10 Dec 1997 20:50:31 -0500 From: Randy Turner X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Fonts, Job Redirection, and Protocol References: <199712110040.QAA22664@rbi.rbi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bill Hastings wrote: > > I'm fairly new to IPP so please excuse any "dumb" questions. > > 1) How can a client determine what fonts are available (built-in) in a > PostScript Printer? Yeah! What ever happened to the GET-FONTS operation ;) > > 2) Is there an appropriate mechanism for redirecting a job after it has > been sent to a printer? The only thing I can come up with is to save a > copy of the job data on the client side, cancel the current job in > progress, and resend the job to a new printer Redirection of a job after it has been sent to the printer must be done "out-of-band" to IPP 1.0. It might be something to consider on a future rev. of the protocol. ..snip.. Randy > > Bill Hastings > RBI Software Systems > bhastings@rbi.com From ipp-owner@pwg.org Thu Dec 11 08:27:06 1997 Delivery-Date: Thu, 11 Dec 1997 08:27:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA23290 for ; Thu, 11 Dec 1997 08:27:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA16597 for ; Thu, 11 Dec 1997 08:29:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA12628 for ; Thu, 11 Dec 1997 08:27:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 08:17:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA11985 for ipp-outgoing; Thu, 11 Dec 1997 08:04:23 -0500 (EST) From: don@lexmark.com Message-Id: <199712111304.AA04520@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: bhasting@rbi.com Cc: Ipp@pwg.org Date: Thu, 11 Dec 1997 08:04:09 -0500 Subject: Re: IPP> Fonts, Job Redirection, and Protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Bill Hastings said: >1) How can a client determine what fonts are available (built-in) in a >PostScript Printer? Let's keep our language clean here. Four letter words starting with "F" are not allowed. Seriously, Fonts (oops, I said it too) were purposefully removed from the scope of IPP 1.0. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Thu Dec 11 11:09:25 1997 Delivery-Date: Thu, 11 Dec 1997 11:09:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24256 for ; Thu, 11 Dec 1997 11:09:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17225 for ; Thu, 11 Dec 1997 11:12:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA13611 for ; Thu, 11 Dec 1997 11:09:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 11:04:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13015 for ipp-outgoing; Thu, 11 Dec 1997 10:51:17 -0500 (EST) From: Harry Lewis To: , Subject: IPP> Directory Schema attribute question - resolved Message-ID: <5030300015974897000002L072*@MHS> Date: Thu, 11 Dec 1997 10:56:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA24256 Sorry for the traffic. I think I resolved my question by reading section 4.2 Job Template Attributes. It seems confusing, at first, but I guess not so much once you get used to it. Just for readability and understanding, I'd prefer if we not use phrases like "The "xxx-default" default value attribute describes...(the default)...". It's confusing whether copies, copies-default and copies-supported are 1 or 3 attributes... I'd say 3 but really just different names for the same attribute when it is either supplied, defaulted or queried. So, we could just say "The xxx-default" value describes... (the default)...". Anyway, I'm sure you've all been through these discussions and it's too late for this round. I think I'm getting it! I'll dig deeper before I ask another question. Harry Lewis - IBM Printing Systems ----- Forwarded by Harry Lewis/Boulder/IBM on 12/10/97 10:56 PM ----- ipp-owner@pwg.org on 12/10/97 06:24:16 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, SISAACSON@novell.com @ internet cc: Subject: IPP> Directory Schema attribute question This is either a nit or a misunderstanding on my part. Appx E of the Model doc lists attributes to be included in a directory schema (great idea!) but does not always refer exactly to the same name. Example finishings-supported vs. finishings in section 4.2.6. Is this a lingering editorial, or am I completely missing the boat somewhere on attribute names? Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Thu Dec 11 13:09:45 1997 Delivery-Date: Thu, 11 Dec 1997 13:09:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA25748 for ; Thu, 11 Dec 1997 13:09:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17721 for ; Thu, 11 Dec 1997 13:12:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15698 for ; Thu, 11 Dec 1997 13:09:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 13:05:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14505 for ipp-outgoing; Thu, 11 Dec 1997 12:47:34 -0500 (EST) Message-Id: <199712111747.JAA25625@rbi.rbi.com> Subject: IPP> PWG conference Date: Thu, 11 Dec 97 09:47:27 -0800 x-sender: bgalten@rbi.rbi.com x-mailer: Claris Emailer 2.0, March 15, 1997 From: Brendan Galten To: "IPP Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org I'm new to the mailing group and am looking for some more information about the January 26th-30th PWG conference. A number of people from my company may be interested in attending. Also has any kind of agenda been discussed. Sorry if I'm rehashing old news. I would appreciate any help that is offered. Brendan Brendan Galten RBI Software Systems 510-204-9980 bgalten@rbi.com From ipp-owner@pwg.org Thu Dec 11 14:14:02 1997 Delivery-Date: Thu, 11 Dec 1997 14:14:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA26439 for ; Thu, 11 Dec 1997 14:14:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA17860 for ; Thu, 11 Dec 1997 14:16:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16658 for ; Thu, 11 Dec 1997 14:14:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 14:08:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16087 for ipp-outgoing; Thu, 11 Dec 1997 13:55:52 -0500 (EST) From: don@lexmark.com Message-Id: <199712111855.AA23782@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: bgalten@rbi.com Cc: Ipp@pwg.org Date: Thu, 11 Dec 1997 13:55:38 -0500 Subject: Re: IPP> PWG conference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Check out the Chair's page off www.pwg,org for the details on the Jan meeting. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** bgalten%rbi.com@interlock.lexmark.com 12/11/97 12:47 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> PWG conference I'm new to the mailing group and am looking for some more information about the January 26th-30th PWG conference. A number of people from my company may be interested in attending. Also has any kind of agenda been discussed. Sorry if I'm rehashing old news. I would appreciate any help that is offered. Brendan Brendan Galten RBI Software Systems 510-204-9980 bgalten@rbi.com From ipp-owner@pwg.org Thu Dec 11 14:35:49 1997 Delivery-Date: Thu, 11 Dec 1997 14:36:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA26627 for ; Thu, 11 Dec 1997 14:35:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA17947 for ; Thu, 11 Dec 1997 14:38:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17366 for ; Thu, 11 Dec 1997 14:35:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 14:31:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16762 for ipp-outgoing; Thu, 11 Dec 1997 14:18:38 -0500 (EST) Message-Id: <3.0.1.32.19971211095824.00f9a2a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 11 Dec 1997 09:58:24 PST To: Bill Hastings , "ipp" From: Tom Hastings Subject: Re: IPP> Fonts, Job Redirection, and Protocol In-Reply-To: <199712110040.QAA22664@rbi.rbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 16:40 12/10/1997 PST, Bill Hastings wrote: >I'm fairly new to IPP so please excuse any "dumb" questions. > > >1) How can a client determine what fonts are available (built-in) in a >PostScript Printer? While we said that fonts were outside the scope of IPP V1.0, we could add it using the registration mechanism after V1.0 is approved. Now that we have the "document-format" as an input parameter to the Get-Attributes operation, it would be very useful to have a Printer Description attribute of "font-supported". Then the proper PostScript fonts could be returned when the "document-format" input parameter was 'application/postscript' and would be the PCL fonts when the input parameter was 'application/vnd.hp-PCL' would return the PCL fonts. Presumably the attribute syntax would be: font-supported (1setOf name) Such an attribute would be a good candidate to propose to the PWG as an attribute for registration as an extension following the procedures for registering extensions in the Model document. ISSUES: We could even make it a Job Template attribute, like the current "orientation" attribute which is only for document formats, like 'text/plain' that don't embed the font specification in the document data. Such an attribute may be more important for Asian countries where the document format is: 'text/plain; charset=utf-8' or 'text/plain; charset=ISO-10646-ucs-2' (i.e., Unicode) and they want to select a particular font. snip... > > From ipp-owner@pwg.org Thu Dec 11 19:35:06 1997 Delivery-Date: Thu, 11 Dec 1997 19:35:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA28169 for ; Thu, 11 Dec 1997 19:35:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA18994 for ; Thu, 11 Dec 1997 19:37:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18500 for ; Thu, 11 Dec 1997 19:35:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Dec 1997 19:30:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17922 for ipp-outgoing; Thu, 11 Dec 1997 19:17:32 -0500 (EST) Message-Id: <3.0.1.32.19971211144142.00bc23a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 11 Dec 1997 14:41:42 PST To: Brendan Galten , "IPP Group" From: Carl-Uno Manros Subject: Re: IPP> PWG conference In-Reply-To: <199712111747.JAA25625@rbi.rbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 09:47 AM 12/11/97 PST, Brendan Galten wrote: > I'm new to the mailing group and am looking for some more >information about the January 26th-30th PWG conference. A number of >people from my company may be interested in attending. Also has any kind >of agenda been discussed. Sorry if I'm rehashing old news. I would >appreciate any help that is offered. >Brendan > >Brendan Galten >RBI Software Systems >510-204-9980 >bgalten@rbi.com > > > Brendan, The IPP meeting is only one of several meetings organized by the PWG that week. Current plan is to meet a full day on January 28th for IPP. As we expect to have all our drafts out for review by the IESG by then, the main subject for the January meeting will be concentrated on testing and implementation of IPP. See: http://www.pwg.org/chair/maui.html for meeting logistics. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Dec 12 00:43:33 1997 Delivery-Date: Fri, 12 Dec 1997 00:43:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA07417 for ; Fri, 12 Dec 1997 00:43:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA19524 for ; Fri, 12 Dec 1997 00:46:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19778 for ; Fri, 12 Dec 1997 00:43:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 00:38:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA19206 for ipp-outgoing; Fri, 12 Dec 1997 00:25:37 -0500 (EST) Message-Id: <3.0.1.32.19971211212542.00b3ce00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 11 Dec 1997 21:25:42 PST To: ipp@pwg.org From: szilles@Adobe.COM (Steve Zilles by way of Carl-Uno Manros ) Subject: IPP> Summary of IPP WG Meeting at Washington DC IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org IPP Summary Paragraph The standards track documents on the IPP Model and Semantics and the IPP Protocol Specification and the informational documents on IPP Requirements, IPP Rationale and Mapping between IPP and LPD were discussed. WG final calls for these had either expired or were about to expire. Proposed solutions to all known problems were reviewed (and, where necessary, corrected) during the WG meeting. Unless some new issue arises, it is the intent that final documents that include the proposed solutions will be given to the IESG for final processing before the end of the year. With this action, we consider the WG's charter to be fullfilled and do not expect to meet at the next IETF meeting. Steve Zilles -------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com | Adobe Systems Inc. | | Mailstop W14 | tel: (work) (408) 536-4766 | 345 Park Avenue | (Admin) (408) 536-4751 | San Jose, CA 95110-2704 | fax: (408) 537-4042 | -------------------------------------------------------------- From ipp-owner@pwg.org Fri Dec 12 08:15:00 1997 Delivery-Date: Fri, 12 Dec 1997 08:15:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA09001 for ; Fri, 12 Dec 1997 08:14:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA20018 for ; Fri, 12 Dec 1997 08:17:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA21232 for ; Fri, 12 Dec 1997 08:14:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 08:05:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA20645 for ipp-outgoing; Fri, 12 Dec 1997 07:52:58 -0500 (EST) From: Roger K Debry To: Cc: Subject: IPP> ipp> Dictionary attribute syntax Message-ID: <5030100015007310000002L002*@MHS> Date: Fri, 12 Dec 1997 07:52:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA09001 Bob, we have the need to define a private IPP extension using the dictionary data type. We want to be sure that the tag vaue for dictionary remains in the protocol document as a reserved value. Thanks ... Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From jmp-owner@pwg.org Fri Dec 12 11:03:35 1997 Delivery-Date: Fri, 12 Dec 1997 11:03:36 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10609 for ; Fri, 12 Dec 1997 11:03:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20792 for ; Fri, 12 Dec 1997 11:06:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22775 for ; Fri, 12 Dec 1997 11:03:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 10:56:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21782 for jmp-outgoing; Fri, 12 Dec 1997 10:50:11 -0500 (EST) Message-Id: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Dec 1997 07:48:28 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: JMP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: jmp-owner@pwg.org Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pmp-owner@pwg.org Fri Dec 12 11:07:44 1997 Delivery-Date: Fri, 12 Dec 1997 11:07:44 -0500 Return-Path: pmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10641 for ; Fri, 12 Dec 1997 11:07:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20811 for ; Fri, 12 Dec 1997 11:10:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23206 for ; Fri, 12 Dec 1997 11:07:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 10:59:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21760 for pmp-outgoing; Fri, 12 Dec 1997 10:49:54 -0500 (EST) Message-Id: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Dec 1997 07:48:28 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: PMP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: pmp-owner@pwg.org Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pwg-owner@pwg.org Fri Dec 12 11:13:36 1997 Delivery-Date: Fri, 12 Dec 1997 11:13:36 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10709 for ; Fri, 12 Dec 1997 11:13:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20844 for ; Fri, 12 Dec 1997 11:16:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23678 for ; Fri, 12 Dec 1997 11:13:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 11:03:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21825 for pwg-outgoing; Fri, 12 Dec 1997 10:50:55 -0500 (EST) Message-Id: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Dec 1997 07:48:28 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: PWG> January Meeting Notice Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-pwg@pwg.org Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-owner@pwg.org Fri Dec 12 11:30:11 1997 Delivery-Date: Fri, 12 Dec 1997 11:30:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10974 for ; Fri, 12 Dec 1997 11:30:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20952 for ; Fri, 12 Dec 1997 11:33:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24624 for ; Fri, 12 Dec 1997 11:30:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 11:25:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21805 for ipp-outgoing; Fri, 12 Dec 1997 10:50:31 -0500 (EST) Message-Id: <3.0.32.19971212074811.00890ba0@pop3.fapo.com> X-Sender: lstein@pop3.fapo.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Dec 1997 07:48:28 -0800 To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org, pp1394@pure.cpdc.canon.co.jp From: Larry Stein Subject: IPP> January Meeting Notice Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Hello, This is a reminder for the January meeting of the Printer Working Group. (Sorry in advance for multiple posting). The deadline is coming up. Be sure to RSVP to me (lstein@fapo.com) after you make your reservations. Thanks, Larry ********************************************************* The particulars: Where: Maui Marriott on Kaanapali Beach When: January 26, 1998 to January 30, 1998 Rate: $179.00 double, $25 per additional Plus meeting charges Reservation #: 1-800-763-1333 1-808-667-1200 Group Name: Printer Working Group DEADLINE: DECEMBER 23, 1997 This was a difficult meeting to setup. I held rooms based upon the responses from the previous ping request. Space is limited so please make your reservations as soon as possible. You should be able to make reservations by Monday, November 24. Be sure to mention the group name. PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. EVEN IF YOU PINGED BEFORE. I need to know: check in date: Meetings attending: check out date: There will be a group function on Tuesday night. Please let me know if you would like to attend and how many people (spouse, kids,....) Agenda (subject to change): Monday 1/26 Joint 1394 Printer Working Group meeting Tuesday 1/17 Joint 1394 Printer Working Group meeting Wednesday 1/28 Printer Working Group -- IPP Thursday 1/29 Printer Working Group -- SENSE Friday 1/30 Printer Working Group -- FIN All meetings will run from 8:30 AM to 5:00 PM. There will be coffee and break included. Thanks, Larry Stein *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From jmp-owner@pwg.org Fri Dec 12 21:03:25 1997 Delivery-Date: Fri, 12 Dec 1997 21:03:25 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16429 for ; Fri, 12 Dec 1997 21:03:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA22845 for ; Fri, 12 Dec 1997 21:06:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28117 for ; Fri, 12 Dec 1997 21:03:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 21:00:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27928 for jmp-outgoing; Fri, 12 Dec 1997 20:58:29 -0500 (EST) From: Harry Lewis To: , Subject: JMP> Inconsistency with REQUESTED attributes Message-ID: <5030300016043924000002L042*@MHS> Date: Fri, 12 Dec 1997 21:02:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: jmp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id VAA16429 I think we have a consistency problem with attributes job-impressions and job-media-sheets. The inconsistency exists in both JMP and IPP. Most attributes that reflect a REQUESTED value are based on the "unit" of one copy of the job. For instance, job-impressions (requested) is specifically PER COPY. Sheets, however, for some reason, is defined to pertain to all the sheets in all the copies in the job. There seems to be no good reason for this and I request that we adjust sheets back to a unit base like other attributes. If an application wants to calculate load they can multiply sheets by copies... like with any other requested attribute. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri Dec 12 21:18:01 1997 Delivery-Date: Fri, 12 Dec 1997 21:18:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16491 for ; Fri, 12 Dec 1997 21:18:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA22868 for ; Fri, 12 Dec 1997 21:20:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28705 for ; Fri, 12 Dec 1997 21:17:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Dec 1997 21:13:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27920 for ipp-outgoing; Fri, 12 Dec 1997 20:58:23 -0500 (EST) From: Harry Lewis To: , Subject: IPP> Inconsistency with REQUESTED attributes Message-ID: <5030300016043924000002L042*@MHS> Date: Fri, 12 Dec 1997 21:02:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id VAA16491 I think we have a consistency problem with attributes job-impressions and job-media-sheets. The inconsistency exists in both JMP and IPP. Most attributes that reflect a REQUESTED value are based on the "unit" of one copy of the job. For instance, job-impressions (requested) is specifically PER COPY. Sheets, however, for some reason, is defined to pertain to all the sheets in all the copies in the job. There seems to be no good reason for this and I request that we adjust sheets back to a unit base like other attributes. If an application wants to calculate load they can multiply sheets by copies... like with any other requested attribute. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Dec 15 16:13:43 1997 Delivery-Date: Mon, 15 Dec 1997 16:13:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20692 for ; Mon, 15 Dec 1997 16:13:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA03918 for ; Mon, 15 Dec 1997 16:16:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06509 for ; Mon, 15 Dec 1997 16:13:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Dec 1997 15:59:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04988 for ipp-outgoing; Mon, 15 Dec 1997 15:36:13 -0500 (EST) From: "Carl Kugler" To: "IPP" Subject: IPP> TES: binary files Date: Mon, 15 Dec 1997 13:34:28 -0700 Message-ID: <01bd0998$ee6dbc90$259e6309@carlk.penn.boulder.ibm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BD095E.420EE490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BD095E.420EE490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steve Gebert and I have put up=20 ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012A00.trc and=20 ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012B00.trc with Peter's help. These are a Print-Job request and response. Here is a dump of 00012A00.trc: 50 4F 53 54 20 2F 73 65 72 76 6C 65 74 2F 49 50 POST /se rvlet/IP 50 53 65 72 76 6C 65 74 20 48 54 54 50 2F 31 2E PServlet HTTP/1. 31 0D 0A 48 6F 73 74 3A 20 6C 6F 63 61 6C 68 6F 1..Host: localho 73 74 0D 0A 41 63 63 65 70 74 3A 20 61 70 70 6C st..Acce pt: appl 69 63 61 74 69 6F 6E 2F 69 70 70 20 0D 0A 43 6F ication/ ipp ..Co 6E 74 65 6E 74 2D 74 79 70 65 3A 20 61 70 70 6C ntent-ty pe: appl 69 63 61 74 69 6F 6E 2F 69 70 70 0D 0A 43 6F 6E ication/ ipp..Con 74 65 6E 74 2D 6C 65 6E 67 74 68 3A 20 32 32 34 tent-len gth: 224 0D 0A 0D 0A 01 00 00 02 01 47 00 12 61 74 74 72 ....=E2=98=BA = =E2=98=BB =E2=98=BAG =E2=86=95attr 69 62 75 74 65 73 2D 63 68 61 72 73 65 74 00 08 ibutes-c harset . 55 53 2D 41 53 43 49 49 48 00 1B 61 74 74 72 69 US-ASCII H = =E2=86=90attri 62 75 74 65 73 2D 6E 61 74 75 72 61 6C 2D 6C 61 butes-na tural-la 6E 67 75 61 67 65 00 05 65 6E 2D 55 53 42 00 08 nguage =E2=99=A3 = en-USB . 6A 6F 62 2D 6E 61 6D 65 00 04 6A 6F 62 31 22 00 job-name = =E2=99=A6job1" 16 69 70 70 2D 61 74 74 72 69 62 75 74 65 2D 66 =E2=96=ACipp-att = ribute-f 69 64 65 6C 69 74 79 00 01 00 42 00 14 72 65 71 idelity = =E2=98=BA B =C2=B6req 75 65 73 74 69 6E 67 2D 75 73 65 72 2D 6E 61 6D uesting- user-nam 65 00 05 73 74 65 76 65 42 00 0D 64 6F 63 75 6D e =E2=99=A3steve = B .docum 65 6E 74 2D 6E 61 6D 65 00 09 64 6F 63 75 6D 65 ent-name .docume 6E 74 31 02 21 00 06 63 6F 70 69 65 73 00 01 01 nt1=E2=98=BB! = =E2=99=A0c opies =E2=98=BA=E2=98=BA 21 00 0C 6A 6F 62 2D 70 72 69 6F 72 69 74 79 00 ! =E2=99=80job-p = riority 01 01 42 00 08 4A 6F 62 2D 6E 61 6D 65 00 02 79 = =E2=98=BA=E2=98=BAB .Job -name =E2=98=BBy 6F 03 31 31 o=E2=99=A511 and here of 00012B00.trc 48 54 54 50 2F 31 2E 30 20 32 30 30 20 4F 4B 0D HTTP/1.0 200 OK. 0A 53 65 72 76 65 72 3A 20 53 65 72 76 6C 65 74 .Server: Servlet 53 65 72 76 65 72 2F 31 2E 30 0D 0A 43 6F 6E 74 Server/1 .0..Cont 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 ent-Type : applic 61 74 69 6F 6E 2F 69 70 70 0D 0A 44 61 74 65 3A ation/ip p..Date: 20 4D 6F 6E 2C 20 30 38 20 44 65 63 20 31 39 39 Mon, 08 Dec 199 37 20 31 37 3A 35 30 3A 32 38 20 47 4D 54 0D 0A 7 17:50: 28 GMT.. 0D 0A 01 00 00 00 02 42 00 08 6A 6F 62 2D 6E 61 ..=E2=98=BA = =E2=98=BBB .job-na 6D 65 00 04 4A 6F 62 31 42 00 09 6A 6F 62 2D 73 me =E2=99=A6Job1 = B .job-s 74 61 74 65 00 04 4A 6F 62 31 42 00 00 00 04 4A tate =E2=99=A6Jo = b1B =E2=99=A6J 6F 62 32 42 00 11 6A 6F 62 2D 73 74 61 74 65 2D ob2B =E2=97=84jo = b-state- 72 65 61 73 6F 6E 73 00 04 4A 6F 62 31 42 00 11 reasons = =E2=99=A6Job1B =E2=97=84 6A 6F 62 2D 73 74 61 74 65 2D 6D 65 73 73 61 67 job-stat e-messag 65 00 02 59 4F 05 41 00 05 73 69 64 65 73 00 0B e = =E2=98=BBYO=E2=99=A3A =E2=99=A3sides =E2=99=82 75 6E 73 75 70 70 6F 72 74 65 64 03 unsuppor = ted=E2=99=A5 IPP> RE: TES:binary files Zehler,Peter (pzehler@channels.mc.xerox.com) Tue, 9 Dec 1997 06:35:41 PST=20 a.. Messages sorted by: [ date ][ thread ][ subject ][ author ]=20 b.. Next message: Jay Martin: "Re: IPP> A free IPP test suite to be = available!"=20 c.. Previous message: Carl-Uno Manros: "RE: IPP> Re: Area Directors' = comments on IPP"=20 Steve, Even when we test across the internet we will still need to capture the results. I am all for anything that will help us move along.=20 I have created a directory called "Traces" under the new_TES directory for the time being. We can decide on a directory structure at a later time. I assume that we will capture traces in more than one form.=20 We need to decide on a naming convention. For this purpose I assume that we will limit each trace file to a single request or response. The naming convention should provide for the pairing of the request to its response. The naming convention should facilitate the capturing of an extended IPP conversation. A conversation is a sequence of IPP operations on an IPP printer.=20 We need to designate the session, operation, request|response, and sequence in the conversation. A suggestion would be "SSSSOR##.trc" where SSSS: an arbitrary unique sequence identifier. The identifier=20 would be unique within the "Traces" directory. O: The operation of the request/response. This is the=20 hexadecimal value of the IPP operation enum. R: Designates request or response. A=3Drequest B=3Dresponse. ##: sequence number of the operation in the IPP conversation. We will also need to catalogue the contents of the directory. This can be accomplished by a pdf file containing a table with relevant information. I can keep this up to date if contributors send me the information. I think some concise description of the objective/purpose of the IPP conversation would be appropriate.=20 I found that putting up an IPP emulator through an ISV is trivial. The emulator is the front end of my IPP printer. I have this anyway since small printers do not have very rich debug environments. I think we need to know if there is any interest in pursuing binary trace files. Do any other individuals have any feelings on this? What do you think? Pete __________________________________=20 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 __________________________________=20 "I always wanted to be somebody,=20 but I should have been more specific."=20 Lily Tomlin __________________________________=20 > -----Original Message----- > From: Steve Gebert [SMTP:stevegeb@us.ibm.com] > Sent: Monday, December 08, 1997 3:39 PM > To: ipp@pwg.org > Subject:=20 >=20 > For interoperability testing, we were wondering if people were > interested in > exchanging binary files > corresponding to IPP Requests and Responses. The parties using these > files > would simply need to > construct a simple program to feed the file data into their server > or client > and read data from their > server or client into a file. >=20 > These files could be sent as email attachments and for the near term > help > with interoperability testing > prior to people setting up machines outside filewalls. Perhaps we > could even > catalog the files and > make them available for download so that there would be a common > test > baseline for early testing. >=20 > We could make some example files available if there is any > interest. What do > you think Peter? >=20 >=20 > Steve Gebert a.. Next message: Jay Martin: "Re: IPP> A free IPP test suite to be = available!"=20 b.. Previous message: Carl-Uno Manros: "RE: IPP> Re: Area Directors' = comments on IPP"=20 ------=_NextPart_000_0007_01BD095E.420EE490 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable IPP Mail Archive: IPP> RE: TES:binary = files

Steve Gebert and I have put up =
 
    ftp://= ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012A00.trc
 
and
 
    ftp://= ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012B00.trc
 
with Peter's help.  These are a Print-Job = request and=20 response.
 
Here is a dump of = 00012A00.trc:
50 4F 53 = 54 20 2F 73=20 65   72 76 6C 65 74 2F 49 50      = POST /se=20 rvlet/IP
50 53 65 72 76 6C 65 74   20 48 54 54 50 2F 31=20 2E      PServlet  HTTP/1.
31 0D 0A 48 = 6F 73 74=20 3A   20 6C 6F 63 61 6C 68 6F     =20 1..Host:  localho
73 74 0D 0A 41 63 63 65   70 74 3A = 20 61 70=20 70 6C      st..Acce pt: appl
69 63 61 74 69 = 6F 6E=20 2F   69 70 70 20 0D 0A 43 6F      = ication/=20 ipp ..Co
6E 74 65 6E 74 2D 74 79   70 65 3A 20 61 70 70=20 6C      ntent-ty pe: appl
69 63 61 74 69 6F = 6E=20 2F   69 70 70 0D 0A 43 6F 6E      = ication/=20 ipp..Con
74 65 6E 74 2D 6C 65 6E   67 74 68 3A 20 32 32=20 34      tent-len gth: 224
0D 0A 0D 0A 01 00 = 00=20 02   01 47 00 12 61 74 74 72      = ....☺ =20 ☻ ☺G ↕attr
69 62 75 74 65 73 2D 63   68 = 61 72 73 65 74 00=20 08      ibutes-c harset .
55 53 2D 41 53 43 = 49=20 49   48 00 1B 61 74 74 72 69      = US-ASCII H=20 ←attri
62 75 74 65 73 2D 6E 61   74 75 72 61 6C 2D 6C=20 61      butes-na tural-la
6E 67 75 61 67 65 = 00=20 05   65 6E 2D 55 53 42 00 08      = nguage=20 ♣ en-USB .
6A 6F 62 2D 6E 61 6D 65   00 04 6A 6F 62 = 31 22=20 00      job-name  ♦job1"
16 = 69 70 70=20 2D 61 74 74   72 69 62 75 74 65 2D = 66     =20 ▬ipp-att ribute-f
69 64 65 6C 69 74 79 00   01 00 42 = 00 14 72 65=20 71      idelity  ☺ B ¶req
75 = 65 73 74 69=20 6E 67 2D   75 73 65 72 2D 6E 61 = 6D     =20 uesting- user-nam
65 00 05 73 74 65 76 65   42 00 0D 64 6F = 63 75=20 6D      e ♣steve B .docum
65 6E 74 2D = 6E 61 6D=20 65   00 09 64 6F 63 75 6D 65     =20 ent-name  .docume
6E 74 31 02 21 00 06 63   6F 70 69 = 65 73 00=20 01 01      nt1☻! ♠c opies = ☺☺
21 00 0C 6A 6F=20 62 2D 70   72 69 6F 72 69 74 79 = 00      !=20 ♀job-p riority
01 01 42 00 08 4A 6F 62   2D 6E 61 6D = 65 00 02=20 79      ☺☺B .Job -name = ☻y
6F 03 31=20 31            = ;            =             &= nbsp;       =20 o♥11 
 
and here of = 00012B00.trc
48 54 54 = 50 2F 31 2E=20 30   20 32 30 30 20 4F 4B 0D     =20 HTTP/1.0  200 OK.
0A 53 65 72 76 65 72 3A   20 53 65 = 72 76 6C=20 65 74      .Server:  Servlet
53 65 72 = 76 65 72=20 2F 31   2E 30 0D 0A 43 6F 6E 74      = Server/1=20 .0..Cont
65 6E 74 2D 54 79 70 65   3A 20 61 70 70 6C 69=20 63      ent-Type : applic
61 74 69 6F 6E 2F = 69=20 70   70 0D 0A 44 61 74 65 3A      = ation/ip=20 p..Date:
20 4D 6F 6E 2C 20 30 38   20 44 65 63 20 31 39=20 39       Mon, 08  Dec 199
37 20 31 = 37 3A=20 35 30 3A   32 38 20 47 4D 54 0D = 0A      7=20 17:50: 28 GMT..
0D 0A 01 00 00 00 02 42   00 08 6A 6F 62 2D = 6E=20 61      ..☺   ☻B  = .job-na
6D 65 00 04=20 4A 6F 62 31   42 00 09 6A 6F 62 2D = 73      me=20 ♦Job1 B .job-s
74 61 74 65 00 04 4A 6F   62 31 42 00 = 00 00 04=20 4A      tate ♦Jo b1B   = ♦J
6F=20 62 32 42 00 11 6A 6F   62 2D 73 74 61 74 65=20 2D      ob2B ◄jo b-state-
72 65 61 73 = 6F 6E 73=20 00   04 4A 6F 62 31 42 00 11     =20 reasons  ♦Job1B ◄
6A 6F 62 2D 73 74 61 = 74   65 2D 6D 65=20 73 73 61 67      job-stat e-messag
65 00 02 = 59 4F 05=20 41 00   05 73 69 64 65 73 00 0B      = e=20 ☻YO♣A  ♣sides ♂
75 6E 73 75 70 70 6F = 72   74 65 64=20 03            = ;     =20 unsuppor ted♥ 
 
 

IPP> RE: TES:binary files

Zehler,Peter (pzehler@channels.mc.xerox.c= om)
Tue,=20 9 Dec 1997 06:35:41 PST=20

Steve,
Even when we test across the = internet=20 we will still need to capture
the results. I am all for anything that = will=20 help us move along.
I have created a directory called = "Traces"=20 under the new_TES
directory for the time being. We can decide on a = directory=20 structure at
a later time. I assume that we will capture traces in = more than=20 one
form.
We need to decide on a naming convention. For this = purpose I=20 assume
that we will limit each trace file to a single request or = response.=20 The
naming convention should provide for the pairing of the request = to=20 its
response. The naming convention should facilitate the capturing = of=20 an
extended IPP conversation. A conversation is a sequence of=20 IPP
operations on an IPP printer.
We need to designate the = session,=20 operation, request|response, and
sequence in the conversation. A = suggestion=20 would be "SSSSOR##.trc"
where
SSSS: an arbitrary unique = sequence=20 identifier. The identifier
would be unique within the = "Traces"=20 directory.
O: The operation of the request/response. This is the=20
hexadecimal value of the IPP operation enum.
R: Designates = request or=20 response. A=3Drequest
B=3Dresponse.
##: sequence number of the = operation in=20 the IPP conversation.
We will also need to catalogue the contents of = the=20 directory. This
can be accomplished by a pdf file containing a table = with=20 relevant
information. I can keep this up to date if contributors send = me=20 the
information. I think some concise description of the=20 objective/purpose
of the IPP conversation would be appropriate.

I found that putting up an IPP emulator through an ISV is trivial.=20 The
emulator is the front end of my IPP printer. I have this anyway=20 since
small printers do not have very rich debug environments.

I think we need to know if there is any interest in pursuing = binary
trace=20 files. Do any other individuals have any feelings on this?

What do you think?
Pete
__________________________________ =
Email:=20 pzehler@channels.mc.xerox.com
US Mail: Peter Zehler
Xerox = Corp.
800=20 Phillips Rd.
Webster NY, 14580-9701
Voice: (716) 265-8755
FAX:=20 (716)265-8792
__________________________________
"I always = wanted to=20 be somebody,
but I should have been more specific."
Lily=20 Tomlin
__________________________________

> -----Original Message-----
> From: Steve Gebert=20 [SMTP:stevegeb@us.ibm.com]
> Sent: Monday, December 08, = 1997 3:39=20 PM
> To: ipp@pwg.org
> Subject: =
>=20
> For interoperability testing, we were wondering if = people=20 were
> interested in
> exchanging binary=20 files
> corresponding to IPP Requests and Responses. The = parties=20 using these
> files
> would simply need=20 to
> construct a simple program to feed the file data into = their=20 server
> or client
> and read data from=20 their
> server or client into a file.
>=20
> These files could be sent as email attachments and for = the near=20 term
> help
> with interoperability=20 testing
> prior to people setting up machines outside = filewalls.=20 Perhaps we
> could even
> catalog the files=20 and
> make them available for download so that there would = be a=20 common
> test
> baseline for early=20 testing.
>
> We could make some example files = available if there is any
> interest. What = do
> you=20 think Peter?
>
>
> Steve = Gebert

------=_NextPart_000_0007_01BD095E.420EE490-- From ipp-owner@pwg.org Mon Dec 15 16:14:25 1997 Delivery-Date: Mon, 15 Dec 1997 16:14:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20701 for ; Mon, 15 Dec 1997 16:14:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA03921 for ; Mon, 15 Dec 1997 16:17:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06605 for ; Mon, 15 Dec 1997 16:14:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Dec 1997 16:07:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05019 for ipp-outgoing; Mon, 15 Dec 1997 15:42:49 -0500 (EST) From: "Zehler,Peter" To: "IPP Discussion List (E-mail)" Subject: IPP> TES - sharing binary IPP trace files Date: Mon, 15 Dec 1997 12:35:56 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Dec15.123157pst."53340(2)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, For anyone wishing to share a trace of IPP requests and responses A directory for that purpose has been created on the PWG server under new_TES. the directory is called "traces". Catchy name eh? Each file contains a single IPP request or response. The filename will tie request to response and multiple request/responses into a "conversation". Carl Kugler has uploaded a couple of files there so you can see an example. When I get some time I will post an example of an extended "conversation". If you have any problems uploading the file send it to me and I will se it gets uploaded. A catalogue of the files will be maintained. To facilitate this some conventions: 1) The filename will be CCCCORSS.trc a) CCCC is a unique "conversation" number. This is a sequence of numbers and case insensitive characters. The conversation number does not change through the duration of your trace. That is if you are showing an IPP Get_Jobs based on some specific jobs, the request/responses for the multiple Print_Job and subsequent Get_Jobs would all share the same "conversation" number. The next three fields in the file name will differentiate the traces. b) O is the hexadecimal number for the operation. The value can be determined by examining the operation field in the IPP request. c) R is used to indicate a request or response. An 'A' indicates a request. A 'B' indicates a response. d) SS is the sequence number. Each IPP request/response in a conversation is uniquely sequenced by a monotonically increasing number. It does not matter if the number starts at 0 or 1. 2) The following information must be sent to me so I may update the catalogue: a. the person posting the trace file b. contact information for that person(email address) c. the unique sequence number for the conversation (CCCC) d. the filenames e. the name of the operation(s) (O) f. which are requests and responses (R) g. the date h. a comment about the intent of the operation request or response, such as "submitting a job with fidelity 'false'" or "intentional invalid request, expecting a client-error-bad-request rejection" or "rejection response of 'client-error-bad-request'". 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 __________________________________ From ipp-owner@pwg.org Mon Dec 15 20:39:13 1997 Delivery-Date: Mon, 15 Dec 1997 20:39:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA22332 for ; Mon, 15 Dec 1997 20:39:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA04788 for ; Mon, 15 Dec 1997 20:41:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA08231 for ; Mon, 15 Dec 1997 20:39:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Dec 1997 20:33:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07657 for ipp-outgoing; Mon, 15 Dec 1997 20:20:05 -0500 (EST) Message-Id: <3.0.1.32.19971215143550.00c779f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 15 Dec 1997 14:35:50 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Draft minutes from the IETF IPP WG Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Please read the following draft minutes taken by Steve Zilles during the meeting. If any of the meeting participants have copmments or if any of the non-attendents need further clarifications, give us those back on the DL ASAP. The only area that still seems somewhat uncertain is whether the IESG will like our security solutions, but we signalled in the meeting that we now want the IESG to hold the formal review and to give us their explicit feedback if they are not yet happy. Regards, Carl-Uno -- Minutes IETF IPP WG Meeting, 97/12/10, Washington DC 1-3PM, Executive Meeting Room Carl-Uno began the meeting with an overview of the documents and the agenda for the meeting: Review suggested resolution of existing issues on Model and Semantics document, Scott Isaacson Protocol Specification document, Bob Herriot In the recording below, issues and their suggested resolution are recorded as presented (sometimes with some expansion for clarity). In most cases there was no discussion and the proposed solution was accepted as presented. If there was a discussion, this is recorded after the presented solution and if a different decision was made, this is recorded after the discussion as a decision. Model Document Issues, Scott Isaacson 1. Major/Minor Versioning Rules Mandate common encoding across all versions All elements added in a new minor version can be ignored New major version indicates new support requirements 2. Allow empty attribute groups Be conservative in what is sent; send an empty group Be liberal in what is received; allow missing group on reception 3. ALL operations MAY return "Unsupported Attributes" 4. Define protocol value-size upper bounds for URIs, charsets, natural languages, identifiers, ... 5. MUST-implement requirements for text and name strings; each string has a maximum length specification: some 63 octets, others 127 or 1023 octets Clarified validation checks for operation processing Non-secure implementation client supplies "requesting-user-name" If client does not supply a name, the printer will generate one (which need not be unique) Discussion: Is an authenticated mode required of all Printers Keith Moore would like to have this be true; without it the protocol will not be interoperable; that is, two implementations of the spec may not be able to find a common (authenticated) communication path Keith asserts that the current rules require this, because use of an Internet accessible printer will require authentication; Keith believes that submitting it as documented will cause kick back from the IESG. But, for interoperability, it is not the case that both client and server must do all the mechanisms as long on one or the other must do all; that means that requiring all clients to do the secure solution is enough to meet Keith's understanding of the rules Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving a single site; It appears that Digest Authentication (with a few tweaks based on an idea of Paul Leach) may meet this need.(and that Microsoft and Netscape may be likely to implement Digest) Details on this discussion will play-out on the HTTP mailing list over the next few weeks. Keith Moore: Whether Digest Authentication is enough is not an issue of whether it is secure enough, but whether this solution is sufficiently scalable (Jim G asserts that Paul Leach's solution may solve the scalability issue) Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for key exchange and should be relatively easy to implement. It is noted that there are two different classes of interoperation over the Internet: (1) remote access to a private resource (such as the printer on my desk) versus (2) providing a service to all comers (such as a Kinko's service) over the Internet. Scalability is not an issue in the first case. It was suggested that we identify the basic mode as "authenticated" mode (because Digest Authentication is already mandated for all HTTP/1.1 clients) and the full TLS based mode as secure mode. Decision: Digest authentication is already mandated for all HTTP/1.1 clients IPP will mandate TLS for all clients 8. Removed "copies-collated" attribute 9. Identified sources for all text and name valued attributes: end user device vendor, operator administrator allow any natural language for non-generated strings name change to "generated-natural-languages-supported" 10. Keep "charset-supported" 11. Clarified semantics of "page-range" attribute 12. Support for Media attributes If supporting "media-default", then MANDATORY If supporting "media-supported", then MANDATORY If supporting "media-ready", then OPTIONAL 13. Added missing status codes "server-error-not-accepting-jobs" "server-error-version-not-supported" 14. Asserted that IPP is already aligned with 15. Made "application/ipp" a "common usage" media type added "request ID" to allow matching of responses to corresponding request for protocols other than HTTP (e.g. SMTP) included all parameters, including the target object URI, within the application/ipp body 16. Security Allow for "non-secure", really "authenticated" servers If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows Decision: rename "non-secure" to "authenticated" rename "secure" to "private and authenticated" (or something similar Discussion: WEBDAV has been asked to not allow basic authentication. 17. Provide input to the SVRLOC Printer Scheme I-D 18. Register all the SNMP printer languages as a (MIME) media types with cross references to the SNMP enums 19. Register "application/ipp" as a media type Keith said the preferred method for handling the MIME type registration is to put the registration text (as per RFC2048) into the standards track RFC that uses/defines it. IANA should then automatically add it to the registry within a few days of the publication of the RFC. New Issues: 20. Should we register new ports for IPP use Keith Moore: a reason for a separate port number is to allow firewalls to be configured to allow or block the printing port. But, Keith observes that firewall usage is typically to block all access except to particular servers and if HTTP is not allowed, then it is likely that printing would also not be allowed so this is not a big issue. Hence, Keith is neutral on registering a port for IPP IESG has made TLS remove creation of new ports for other protocols than HTTP. Ones that are already deployed were kept, but no new ones. Therefore, we should not have a separate new port for IPP over TLS Other than the port discussion, no new issues were raise Protocol Document Issues since August 1997, Bob Herriot 1. Attribute Group Tags Sender (of request or response) SHOULD send attribute group tag with no following attributes with the exception of the unsupported-attributes-tag which SHOULD be omitted Recipient (of request or response) MUST accept as equivalent representations of an empty attribute group: - attribute group tag with no following attributes - expected but missing attribute tag 2. Identified a subset of the tag types (0-0xf) as being attribute group tags (some of which have not yet be assigned); these should be handled like attribute tags by any application/ipp recipient. The subset of tag types (0x10-oxff) are "value tags". 3. A recipient of a request or response MAY skip all attributes in an unknown group 4. Printer-uri and job-uri MUST be on HTTP request line MUST also be in operation attributes 5. Job operations MUST be supported with both job-uri target printer-uri target with job-id attribute 6. Create-job operation returns job-uri and job-id 7. Handling of localized text and names Added two new data types: localized text localized name both of there are represented as an octet string with four fields: length of natural language identification natural language identification (per RFC length of text/name content of text/name 8. Request ID added to all requests and responses server returns received request-id in the response to the request that had the request-id client may match response with requests using the request-id; client is responsible for management of request id numbering space; in HTTP, the client can always use 0 as the request-id because HTTP guarantees responses in the order requests are made. 9. Renamed 'data-tag' to 'end-of-attributes' tag 10. Added new out-of-band values for no-value unknown 11. Definition of status codes and operations moved to model document No new issues were raised at the meeting Mapping between LPD to IPP, Bob Herriot, the document was updated as follows: 1. added statement that this is informational and its intent is to help implements of gateways between IPP and LPD 2. job-id now both job-id and job-uri are available allows job-id to be same as LPD job-id in relevant cases 3. job-originating-host was removed from IPP model; IPP-to-LPD must use some other means to supply the 'H'(host) parameter. 4. job-k-octets was clarified to count octets in one copy, not all copies; file size in lpq response does contain copies 5. Notification was removed from the IPP model; therefore support for LPD email notification is not possible 6. For document format, SNMP Printer MIB enums were replace by (MIME) media types 7. Authentication job-originating-user replaced by job-originating-user-name value is (explicitly) a human readable name value comes from underlying authentication mechanism and the attribute: requesting-user-name No other issues were raised Since all issues presented had a proposed solution that was acceptable to the meeting; final copies of the documents, containing the proposed resolutions, will be prepared and circulated to the mailing list by the end of the week. Assuming there are no significant comments received by Dec 18, the revised documents will be transmitted to the IESG for processing before the end of the year. IPP Summary Paragraph The standards track documents on the IPP Model and Semantics and the IPP Protocol Specification and the informational documents on IPP Requirements, IPP Rationale and Mapping between IPP and LPD were discussed. WG final calls for these had either expired or were about to expire. Proposed solutions to all known problems were reviewed (and, where necessary, corrected) during the WG meeting. Unless some new issue arises, it is the intent that final documents that include the proposed solutions will be given to the IESG for final processing before the end of the year. With this action, we consider the WG's charter to be fullfilled and do not expect to meet at the next IETF meeting. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Dec 16 12:16:20 1997 Delivery-Date: Tue, 16 Dec 1997 12:16:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA05193 for ; Tue, 16 Dec 1997 12:16:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07231 for ; Tue, 16 Dec 1997 12:19:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA09837 for ; Tue, 16 Dec 1997 12:16:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 12:07:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09249 for ipp-outgoing; Tue, 16 Dec 1997 11:54:23 -0500 (EST) Message-Id: <199712161654.LAA09244@lists.underscore.com> Date: Tue, 16 Dec 97 09:47:20 MST From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" To: ipp@pwg.org Subject: IPP> Attributes Sender: ipp-owner@pwg.org Perhaps someone can clear up a confusion I have here. In the model document I find "Status-Code" under section 3.2.1.2 Print-Job Response given as being in Group 1, an Operation Attribute. However, in the protocol document "Status-Code" is treated as a distinct entity. It is not treated as an Operation Attribute, as it is transmitted before an operation-attribute tag (this tag signifying the beginning of all operation attributes). There seems to be a contradiction here. Can someone explain this to me. Thanks, Steve Gebert From jmp-owner@pwg.org Tue Dec 16 12:31:39 1997 Delivery-Date: Tue, 16 Dec 1997 12:31:39 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA05330 for ; Tue, 16 Dec 1997 12:31:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07293 for ; Tue, 16 Dec 1997 12:34:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10119 for ; Tue, 16 Dec 1997 12:31:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 12:29:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09930 for jmp-outgoing; Tue, 16 Dec 1997 12:26:59 -0500 (EST) Message-Id: <3.0.1.32.19971216092211.00cc5c70@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Dec 1997 09:22:11 PST To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> Re: Inconsistency with REQUESTED attributes [I don't think its a problem] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Harry, I thought of a why this inconsistency is a useful feature for IPP. (The inconsistency is that k octets and impressions requested don't take account of the number of copies while media requested does. See Harry's attached mail). In IPP the job-k-octets, job-impressions, and job-media-sheets have corresponding Printer attributes: job-k-octets-supported, job-impressions-supported, and job-media-sheets-supported. These three xxx-supported attributes have an integer range value which is a lower bound and an upper bound on the allowed values for the job-k-octets, job-impressions, and job-media-sheets job attributes. This allows the system administrator some control over preventing too small or two large jobs from being accepted. By making job-media-sheets, include copies, but job-k-octets and job-impressions, not include copies, the system administrator is able to limit the size of documents and the size of jobs. So he/she can say, no more that 100 sheets (whether one- or two-sided and no matter how many copies) will be accepted. Thus controlling cost of media. Also not less than n, for a high volume printer. Then he/she can limit the size of the document(s), independent of the number of copies, by picking the value for job-k-octets-supported and job-impressions-supported (which correspond to the Job MIB jmJobKOctetsPerCopyRequested and jmJobImpressionsPerCopyRequested objects). So I think we have a good reason to be different between K octets/impressions requested versus media requested. And happily, both IPP and Job Mon have this same difference, so lets keep IPP and Job Mon as they are and in agreement with each other (since we are trying to forward both documents as I-Ds to the IESG this week to become standard track and informational RFC, respectively). Ok? Tom >From: Harry Lewis >To: , >Subject: IPP> Inconsistency with REQUESTED attributes >Date: Fri, 12 Dec 1997 18:02:21 PST >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id SAA23815 > >I think we have a consistency problem with attributes job-impressions and >job-media-sheets. The inconsistency exists in both JMP and IPP. Most attributes >that reflect a REQUESTED value are based on the "unit" of one copy of the job. >For instance, job-impressions (requested) is specifically PER COPY. Sheets, >however, for some reason, is defined to pertain to all the sheets in all the >copies in the job. There seems to be no good reason for this and I request that >we adjust sheets back to a unit base like other attributes. If an application >wants to calculate load they can multiply sheets by copies... like with any >other requested attribute. > >Harry Lewis - IBM Printing Systems > > From ipp-owner@pwg.org Tue Dec 16 12:46:23 1997 Delivery-Date: Tue, 16 Dec 1997 12:46:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA05490 for ; Tue, 16 Dec 1997 12:46:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07374 for ; Tue, 16 Dec 1997 12:49:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10752 for ; Tue, 16 Dec 1997 12:46:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 12:42:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09922 for ipp-outgoing; Tue, 16 Dec 1997 12:26:52 -0500 (EST) Message-Id: <3.0.1.32.19971216092211.00cc5c70@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Dec 1997 09:22:11 PST To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Re: Inconsistency with REQUESTED attributes [I don't think its a problem] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harry, I thought of a why this inconsistency is a useful feature for IPP. (The inconsistency is that k octets and impressions requested don't take account of the number of copies while media requested does. See Harry's attached mail). In IPP the job-k-octets, job-impressions, and job-media-sheets have corresponding Printer attributes: job-k-octets-supported, job-impressions-supported, and job-media-sheets-supported. These three xxx-supported attributes have an integer range value which is a lower bound and an upper bound on the allowed values for the job-k-octets, job-impressions, and job-media-sheets job attributes. This allows the system administrator some control over preventing too small or two large jobs from being accepted. By making job-media-sheets, include copies, but job-k-octets and job-impressions, not include copies, the system administrator is able to limit the size of documents and the size of jobs. So he/she can say, no more that 100 sheets (whether one- or two-sided and no matter how many copies) will be accepted. Thus controlling cost of media. Also not less than n, for a high volume printer. Then he/she can limit the size of the document(s), independent of the number of copies, by picking the value for job-k-octets-supported and job-impressions-supported (which correspond to the Job MIB jmJobKOctetsPerCopyRequested and jmJobImpressionsPerCopyRequested objects). So I think we have a good reason to be different between K octets/impressions requested versus media requested. And happily, both IPP and Job Mon have this same difference, so lets keep IPP and Job Mon as they are and in agreement with each other (since we are trying to forward both documents as I-Ds to the IESG this week to become standard track and informational RFC, respectively). Ok? Tom >From: Harry Lewis >To: , >Subject: IPP> Inconsistency with REQUESTED attributes >Date: Fri, 12 Dec 1997 18:02:21 PST >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id SAA23815 > >I think we have a consistency problem with attributes job-impressions and >job-media-sheets. The inconsistency exists in both JMP and IPP. Most attributes >that reflect a REQUESTED value are based on the "unit" of one copy of the job. >For instance, job-impressions (requested) is specifically PER COPY. Sheets, >however, for some reason, is defined to pertain to all the sheets in all the >copies in the job. There seems to be no good reason for this and I request that >we adjust sheets back to a unit base like other attributes. If an application >wants to calculate load they can multiply sheets by copies... like with any >other requested attribute. > >Harry Lewis - IBM Printing Systems > > From ipp-owner@pwg.org Tue Dec 16 15:12:52 1997 Delivery-Date: Tue, 16 Dec 1997 15:12:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA07153 for ; Tue, 16 Dec 1997 15:12:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08057 for ; Tue, 16 Dec 1997 15:15:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11657 for ; Tue, 16 Dec 1997 15:12:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 14:56:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11024 for ipp-outgoing; Tue, 16 Dec 1997 14:43:47 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 16 Dec 1997 12:42:00 -0700 From: Scott Isaacson To: ipp@pwg.org, smg1@vnet.IBM.COM Subject: Re: IPP> Attributes Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org As I went back and re-read this it did sound a little confusing. I'll see if I can fix it up a bit. Let's see if I can summarize here: 1. The status code is sent back in a special place in the header of the response. It is not an operation attribute. 2. The OPTIONAL (for an IPP object to return in the response) status message is an operation attribute ("status-message" (text)) that is returned in the operation attributes group. 3. In each of the Response sections where I say "Status Code and Message" I will change that to just Status Message (and still point back to 3.1.4) to describe the semantics of a status code vs a status message and their relationship. Each of the individual operations will not talk about where or how the status code is returned (that is a protocol spec issue). 4. The newly added 15.3.3.3 shows that "status-message" is an operation attribute but the status code is not. That section will stay the same. Scott >>> "steve gebert Dept:ecg SN:579517 Div:ISM Ext" 12/16 9:47 AM >>> Perhaps someone can clear up a confusion I have here. In the model document I find "Status-Code" under section 3.2.1.2 Print-Job Response given as being in Group 1, an Operation Attribute. However, in the protocol document "Status-Code" is treated as a distinct entity. It is not treated as an Operation Attribute, as it is transmitted before an operation-attribute tag (this tag signifying the beginning of all operation attributes). There seems to be a contradiction here. Can someone explain this to me. Thanks, Steve Gebert From ipp-owner@pwg.org Tue Dec 16 15:41:45 1997 Delivery-Date: Tue, 16 Dec 1997 15:41:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA07476 for ; Tue, 16 Dec 1997 15:41:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08199 for ; Tue, 16 Dec 1997 15:44:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA12574 for ; Tue, 16 Dec 1997 15:41:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 15:29:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA11309 for ipp-outgoing; Tue, 16 Dec 1997 15:01:48 -0500 (EST) Date: Tue, 16 Dec 1997 12:00:40 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712162000.MAA18062@woden.eng.sun.com> To: ipp@pwg.org, smg1@vnet.IBM.COM Subject: Re: IPP> Attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Section 3.9 lists the operation attributes that are treated specially in the protocol. Status-code is one of them. I have added some language in section 3.5 of the protocol document which notes this exception. Thanks for pointing it out. Bob Herriot > From smg1@vnet.IBM.COM Tue Dec 16 09:09:58 1997 > Date: Tue, 16 Dec 97 09:47:20 MST > From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" > To: ipp@pwg.org > Subject: IPP> Attributes > Sender: ipp-owner@pwg.org > Content-Length: 528 > X-Lines: 8 > > Perhaps someone can clear up a confusion I have here. In the model > document I find "Status-Code" under section 3.2.1.2 Print-Job Response > given as being in Group 1, an Operation Attribute. However, in the > protocol document "Status-Code" is treated as a distinct entity. It > is not treated as an Operation Attribute, as it is transmitted before > an operation-attribute tag (this tag signifying the beginning of all > operation attributes). There seems to be a contradiction here. > Can someone explain this to me. Thanks, Steve Gebert > From ipp-owner@pwg.org Tue Dec 16 15:47:18 1997 Delivery-Date: Tue, 16 Dec 1997 15:47:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA07559 for ; Tue, 16 Dec 1997 15:47:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08234 for ; Tue, 16 Dec 1997 15:50:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA12994 for ; Tue, 16 Dec 1997 15:47:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 15:37:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA11459 for ipp-outgoing; Tue, 16 Dec 1997 15:06:46 -0500 (EST) Message-Id: <199712162006.PAA11445@lists.underscore.com> Date: Tue, 16 Dec 97 13:06:09 MST From: "steve gebert Dept:ecg SN: Div:ISM Ext" To: ipp@pwg.org Subject: IPP> IPP Attributes Sender: ipp-owner@pwg.org Bob/Scott, Thanks, I think it is much clearer now. Steve From ipp-owner@pwg.org Tue Dec 16 15:55:50 1997 Delivery-Date: Tue, 16 Dec 1997 15:55:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA07624 for ; Tue, 16 Dec 1997 15:55:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08275 for ; Tue, 16 Dec 1997 15:58:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13618 for ; Tue, 16 Dec 1997 15:55:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 15:51:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA11755 for ipp-outgoing; Tue, 16 Dec 1997 15:24:48 -0500 (EST) Message-Id: <3.0.1.32.19971216103117.00fd0a80@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Dec 1997 10:31:17 PST To: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Attributes In-Reply-To: <199712161654.LAA09244@lists.underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org It is a little confusing, since the status code is indicated as being in group 1 in the Model, along with the OPTIONAL "status-message", and MANDATORY "attributes-charset" and "attributes-natural-language", but the status code is always returned as a two octet value in the protocol, so it really isn't really an operation attribute returned in group 1. One way to think of it is that the status code is a operation attribute that is mapped in the protocol document to the fixed place in the protocol (and there is no "status-code" keyword returned, only the two-octet value). We probably need to clarify this in both the Model and Protocol documents. Tom At 08:47 12/16/1997 PST, steve gebert Dept:ecg SN:579517 Div:ISM Ext wrote: >Perhaps someone can clear up a confusion I have here. In the model >document I find "Status-Code" under section 3.2.1.2 Print-Job Response >given as being in Group 1, an Operation Attribute. However, in the >protocol document "Status-Code" is treated as a distinct entity. It >is not treated as an Operation Attribute, as it is transmitted before >an operation-attribute tag (this tag signifying the beginning of all >operation attributes). There seems to be a contradiction here. >Can someone explain this to me. Thanks, Steve Gebert > > From owner-nat@livingston.com Tue Dec 16 20:32:19 1997 Delivery-Date: Tue, 16 Dec 1997 20:32:19 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA10355 for ; Tue, 16 Dec 1997 20:32:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA26649; Tue, 16 Dec 1997 17:26:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA08490 for nat-outgoing; Tue, 16 Dec 1997 17:30:38 -0800 (PST) Message-Id: <3.0.5.32.19971216171751.00880600@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Dec 1997 17:17:51 -0800 To: Philippe OECHSLIN From: Matt Holdrege Subject: Re: (NAT) tcp options and non-routable names Cc: nat@livingston.com In-Reply-To: <23912.882294624@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 05:50 PM 12/16/97 +0000, Philippe OECHSLIN wrote: >- DNS > > When using a NAPT to hide a network behind a single address, the > machines in the hidden network use non-routable IP addresses. > In order to be able to connect with each others, these machines > must be able to look up each others name, conveniently in the DNS. > Since these addresses can be used in multiple locations, they will > not be registered in the global DNS. I assume that the nat box > could run a DNS server which would register the names of the machines > it is hiding. > > Wouldn't it be convenient if the global DNS would carry a set of > dummy names for addresses in the non-routable networks? Say > > pc1.nat.net, pc2.nat.net ... printer1.nat.net ... server1.nat.net > www.nat.net for a given subnet of non-routable addresses > > In that way, users behind a NAPT could simply use any of these names > without having to administer the DNS for them. Also, if one of these > names leaked out into the Internet (eg. as a url in a document) it > could be recognized as a non-routable IP hostname, which might be > more interesting than an unknown hostname. I don't think that would fly. For starters, folks in non-english speaking countries might object. Secondly, no two networks are alike. You can't assume pc1, printer1, server1, etc. Better that the NAT device or some other local device runs a local DNS server. Or the hidden hosts use a local hosts file. Matt Holdrege http://www.ascend.com matt@ascend.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From ipp-owner@pwg.org Wed Dec 17 09:05:40 1997 Delivery-Date: Wed, 17 Dec 1997 09:05:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA22195 for ; Wed, 17 Dec 1997 09:05:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA10239 for ; Wed, 17 Dec 1997 08:21:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA17975 for ; Wed, 17 Dec 1997 08:18:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 08:09:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA17392 for ipp-outgoing; Wed, 17 Dec 1997 07:56:00 -0500 (EST) From: "Zehler,Peter" To: "IPP Discussion List (E-mail)" Subject: IPP> TES - January meeting Date: Wed, 17 Dec 1997 04:59:54 PST X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Dec17.045553pst."52860(2)"@alpha.xerox.com> Sender: ipp-owner@pwg.org All, There has been a request to hold an implementers/testing meeting on Thursday during the January PWG meeting. I would like to gauge the interest in such a meeting. There are a few alternatives. 1) implementers/testing meeting on Thursday 2) informal implementers/testing dinner Wednesday night 3) TES item on IPP agenda to discuss how to get TES moving I am looking for input from the IPP group on which alternative(s) should be pursued. Any other ideas are also welcome. 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 __________________________________ From ipp-owner@pwg.org Wed Dec 17 09:06:10 1997 Delivery-Date: Wed, 17 Dec 1997 09:06:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA22224 for ; Wed, 17 Dec 1997 09:06:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA09891 for ; Wed, 17 Dec 1997 04:03:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA16727 for ; Wed, 17 Dec 1997 04:00:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 03:56:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA16171 for ipp-outgoing; Wed, 17 Dec 1997 03:43:00 -0500 (EST) Message-ID: <34978E74.CC45B1C4@sharplabs.com> Date: Wed, 17 Dec 1997 00:33:56 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Herriot CC: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP>MOD Action Item from LA: fix requesting-user-name explanation References: <199712170430.UAA23694@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org See my comments on the new proposed text below... Randy Robert Herriot wrote: ..snip.. > > Proposed wording: > > Each operation SHALL specify the user who is performing the operation > in two ways: > > 1) via the the MANDATORY "requesting-user-name" operation attribute > that a client SHOULD supply in all operations. The client SHALL obtain > the value for this attribute from an environmental or network login > name for the user, rather than allowing the user to supply any value. > > 2) via an authentication mechanism of the underlying transport which > may be configured to give no authentication information. I think implementers would like to know if the relationship between the above 2 ways is: "either-or","and",or just "or". > > There are six cases to consider: > > a) the authentication mechanism gives no information, and the client > doesnt specify requesting- user-name. > > b) the authentication mechanism gives no information, but the client > specifies requesting-user- name. > > c) the authentication mechanism specifies a user which has no human > readable representation, and the client doesnt specify > requesting-user-name. I'm not sure that it is entirely unreasonable to require credentials to always map to a human readable string representation. I know this info is available on x.509 certificates. > > d) the authentication mechanism specifies a user which has no human > readable representation, but the client specifies > requesting-user-name. > > e) the authentication mechanism specifies a user which has a human > readable representation. The Printer object ignores the > ?requesting-user-name?. > > f) the authentication mechanism specifies a user which is special and > means that the value of the requesting-user-name, which must be > present, is treated as the authenticated name. I do not think scenario (f) should be included in this list. It sounds like a real niche case that might take alot of text to explain why this is needed. > > The user-name has two forms: > > one that is human readable: it is held in the MANDATORY > "job-originating-user-name" Job Description attribute which is set > during the job creation operations. It is used for presentation only, > such as returning in queries or printing on start sheets In the original existing case, we stated that the originating-user-name should come from the client's notion of an OS login name, or some equivalent, locally (on the client host) authenticated mechanism. If this is still the case, then I do not think we should preclude an IPP server from performing some type of lightweight authentication and access control using the originating-user-name. However, as always, when using a secure IPP connection, the TLS authentication would ALWAYS take precedence. Randy > > one for authorization: it is held in an undefined (by IPP) Job object > attribute which is set by the job creation operation. It is used to > authorize other operations, such as Send-Document, Send-URI, > Cancel-Job, to determine the user when the my-jobs attribute is > specified with Get-Jobs, and to limit what attributes to return with > Get-Attributes and Get-Jobs. > > The human readable name: > > is the value of the requesting-user-name for cases b, d and f. > > comes from the authentication mechanism for case e > > is some anonymous name, such as guest for cases a and c. > > The name used for authorization: > > is the value of the requesting-user-name for cases b and f. > > comes from the authentication mechanism for cases c, d and e > > is some anonymous name, such as guest for case a. From ipp-owner@pwg.org Wed Dec 17 09:06:17 1997 Delivery-Date: Wed, 17 Dec 1997 09:06:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA22256 for ; Wed, 17 Dec 1997 09:06:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA09554 for ; Tue, 16 Dec 1997 23:56:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA15603 for ; Tue, 16 Dec 1997 23:53:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Dec 1997 23:48:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA14992 for ipp-outgoing; Tue, 16 Dec 1997 23:35:30 -0500 (EST) Date: Tue, 16 Dec 1997 20:30:36 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712170430.UAA23694@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: IPP>MOD Action Item from LA: fix requesting-user-name explanation X-Sun-Charset: ISO-8859-1 Sender: ipp-owner@pwg.org I have enclosed the existing wording and my proposed wording below. I have added the language about the gateway that I was asked to add and I have tightened the language to make things (hopefully) clearer. I have addressed cases that are not addressed with the current language. ------------------------------------------------------------------------- 3.1.5.2 The "requesting-user-name" Operation Attribute Existing Wording: A Printer object SHALL support the MANDATORY "requesting-user-name" operation attribute that a client SHOULD supply in all operations. This operation attribute is provided in case (1) there is no security service being used, (2) the client and Printer object negotiate to no authorization, or (3) the authentication service does not make available to the Printer object an authenticated printable representation of the user's name that is making the request. The client SHALL obtain the value for this attribute from an environmental or network login name for the user, rather than allowing the user to supply any value. For create requests the Printer object, upon creating a new Job object, SHALL store the originating user's name in the MANDATORY "job-originating-user-name" Job Description attribute. The "job-originating- user-name" attribute is used for presentation only, such as returning in queries or printing on start sheets, and is not used for matching the authenticated principal of subsequent operations. If the Printer object has access to a more authenticated printable representation of the user's name, the Printer object SHALL store that value instead of the value supplied by the client in the "requesting-user-name" operation attribute. The Printer object, upon creating a new Job object, SHALL store the originating user's principal credential in an internal implementation-dependent Job Description attribute. This attribute is not specified as part of IPP, since it is not of any interest to clients. However, the Printer object uses this internal attribute for matching the authenticated principal id of subsequent operations. If the Printer object has access to a more authenticated representation of the user's id, the Printer object SHALL store that value instead of the value supplied by the client in the "requesting-user-name" operation attribute. Otherwise, the Printer object SHALL store the value supplied by the client in the "requesting-user-name" operation attribute. ------------------------------------------------------------------------- Proposed wording: Each operation SHALL specify the user who is performing the operation in two ways: 1) via the the MANDATORY "requesting-user-name" operation attribute that a client SHOULD supply in all operations. The client SHALL obtain the value for this attribute from an environmental or network login name for the user, rather than allowing the user to supply any value. 2) via an authentication mechanism of the underlying transport which may be configured to give no authentication information. There are six cases to consider: a) the authentication mechanism gives no information, and the client doesnt specify requesting- user-name. b) the authentication mechanism gives no information, but the client specifies requesting-user- name. c) the authentication mechanism specifies a user which has no human readable representation, and the client doesnt specify requesting-user-name. d) the authentication mechanism specifies a user which has no human readable representation, but the client specifies requesting-user-name. e) the authentication mechanism specifies a user which has a human readable representation. The Printer object ignores the “requesting-user-name”. f) the authentication mechanism specifies a user which is special and means that the value of the requesting-user-name, which must be present, is treated as the authenticated name. The user-name has two forms: one that is human readable: it is held in the MANDATORY "job-originating-user-name" Job Description attribute which is set during the job creation operations. It is used for presentation only, such as returning in queries or printing on start sheets one for authorization: it is held in an undefined (by IPP) Job object attribute which is set by the job creation operation. It is used to authorize other operations, such as Send-Document, Send-URI, Cancel-Job, to determine the user when the my-jobs attribute is specified with Get-Jobs, and to limit what attributes to return with Get-Attributes and Get-Jobs. The human readable name: is the value of the requesting-user-name for cases b, d and f. comes from the authentication mechanism for case e is some anonymous name, such as guest for cases a and c. The name used for authorization: is the value of the requesting-user-name for cases b and f. comes from the authentication mechanism for cases c, d and e is some anonymous name, such as guest for case a. From ipp-owner@pwg.org Wed Dec 17 12:37:45 1997 Delivery-Date: Wed, 17 Dec 1997 12:37:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA24505 for ; Wed, 17 Dec 1997 12:37:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11254 for ; Wed, 17 Dec 1997 12:40:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA19846 for ; Wed, 17 Dec 1997 12:37:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 12:32:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19242 for ipp-outgoing; Wed, 17 Dec 1997 12:19:28 -0500 (EST) Message-Id: <3.0.1.32.19971217091500.00cf0dd0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 17 Dec 1997 09:15:00 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? Cc: (Scott Isaacson), szilles@Adobe.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org In Washington and before, there has been discussion that calling the second uri, "printer-secure-uri" makes it sound like the first "printer-uri" is not secure. So we've been searching for a better term. Scott and Steve came up with the term (drum roll): "Mutual Authentication and Privacy (MAP). So ok to call the second uri Printer attribute: "printer-map-uri"? It will be put right after the first uri: "printer-uri" secion 4.4.2 in the Model document. SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK TO THE IESG. Thanks, Tom From ipp-owner@pwg.org Wed Dec 17 13:22:20 1997 Delivery-Date: Wed, 17 Dec 1997 13:22:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA24926 for ; Wed, 17 Dec 1997 13:22:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11387 for ; Wed, 17 Dec 1997 13:25:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20570 for ; Wed, 17 Dec 1997 13:22:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 13:14:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19961 for ipp-outgoing; Wed, 17 Dec 1997 12:56:01 -0500 (EST) From: don@lexmark.com Message-Id: <199712171755.AA21978@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.com Cc: Ipp@pwg.org Date: Wed, 17 Dec 1997 12:55:37 -0500 Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map -uri"? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org If I were to see "printer-map-uri" I would assume I could point my browser at thar uri and see were the printer is located on a MAP!! What about being real straight-forward and calling it one of the following: TLS-Printer-uri Printer-TLS-uri Actually, secure-printer-uri is exactly what is says it is and printer-uri says nothing about security. I'm not opposed to calling it what it is and living with the implications of that. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ----------------------------------------------- To: ipp%pwg.org@interlock.lexmark.com cc: SISAACSON%novell.com@interlock.lexmark.com, szilles%Adobe.COM@interlock.lexmark.com (bcc: Don Wright) bcc: Don Wright Subject: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? In Washington and before, there has been discussion that calling the second uri, "printer-secure-uri" makes it sound like the first "printer-uri" is not secure. So we've been searching for a better term. Scott and Steve came up with the term (drum roll): "Mutual Authentication and Privacy (MAP). So ok to call the second uri Printer attribute: "printer-map-uri"? It will be put right after the first uri: "printer-uri" secion 4.4.2 in the Model document. SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK TO THE IESG. Thanks, Tom From ipp-owner@pwg.org Wed Dec 17 13:30:19 1997 Delivery-Date: Wed, 17 Dec 1997 13:30:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA25076 for ; Wed, 17 Dec 1997 13:30:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11415 for ; Wed, 17 Dec 1997 13:33:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA21174 for ; Wed, 17 Dec 1997 13:30:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 13:26:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19982 for ipp-outgoing; Wed, 17 Dec 1997 13:04:55 -0500 (EST) Message-Id: <199712171804.NAA19977@lists.underscore.com> Date: Wed, 17 Dec 97 09:33:33 MST From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" To: ipp@pwg.org Subject: IPP> Get Attributes Sender: ipp-owner@pwg.org I know this has probably been mentioned before, but as I am getting more into implementation I am finding the use of Get-Attributes on both the Printer and Job object to be ackward with regard to implementation. It is the only case of a method being dependent on the object and introduces some special case processing that could be avoided by having 2 distinct methods. It seems that with regard to consistency it would be better to have 2 methods that are similar and consistent with the other methods (Get-Printer-Attributes and Get-Job-Attributes). In addition, I think, at least based on my limited experience, that perhaps the implementations could be a little simpler. Since part of the reason for prototyping is to provide feedback to the spec developers I thought I would mention this. Steve From ipp-owner@pwg.org Wed Dec 17 14:31:04 1997 Delivery-Date: Wed, 17 Dec 1997 14:31:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA25849 for ; Wed, 17 Dec 1997 14:30:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11713 for ; Wed, 17 Dec 1997 14:33:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22230 for ; Wed, 17 Dec 1997 14:30:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 14:19:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21310 for ipp-outgoing; Wed, 17 Dec 1997 13:46:57 -0500 (EST) Message-ID: <34981D40.298CB91F@underscore.com> Date: Wed, 17 Dec 1997 13:43:12 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: hastings@cp10.es.xerox.com CC: don@lexmark.com, Ipp@pwg.org Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map -uri"? References: <199712171755.AA21978@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I agree with Don wholeheartedly. ...jay don@lexmark.com wrote: > > If I were to see "printer-map-uri" I would assume I could point my browser > at thar uri and see were the printer is located on a MAP!! > > What about being real straight-forward and calling it one of the following: > > TLS-Printer-uri > Printer-TLS-uri > > Actually, secure-printer-uri is exactly what is says it is and printer-uri > says > nothing about security. I'm not opposed to calling it what it is and > living with > the implications of that. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > ----------------------------------------------- > > To: ipp%pwg.org@interlock.lexmark.com > cc: SISAACSON%novell.com@interlock.lexmark.com, > szilles%Adobe.COM@interlock.lexmark.com (bcc: Don Wright) > bcc: Don Wright > Subject: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? > > In Washington and before, there has been discussion that calling > the second uri, "printer-secure-uri" makes it sound like the first > "printer-uri" is not secure. So we've been searching for a better > term. > Scott and Steve came up with the term (drum roll): > "Mutual Authentication and Privacy (MAP). > So ok to call the second uri Printer attribute: "printer-map-uri"? > It will be put right after the first uri: "printer-uri" secion > 4.4.2 in the Model document. > SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK > TO THE IESG. > Thanks, > Tom From ipp-owner@pwg.org Wed Dec 17 14:36:28 1997 Delivery-Date: Wed, 17 Dec 1997 14:36:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA25895 for ; Wed, 17 Dec 1997 14:36:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11758 for ; Wed, 17 Dec 1997 14:39:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22996 for ; Wed, 17 Dec 1997 14:36:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 14:26:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21325 for ipp-outgoing; Wed, 17 Dec 1997 13:50:54 -0500 (EST) Message-Id: <1.5.4.32.19971217175135.006eec40@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: Wed, 17 Dec 1997 09:51:35 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> TES - January meeting Sender: ipp-owner@pwg.org Peter, As we expect to have handed over all our texts to the IETF by that time, my plan is that the Wednesday IPP meeting will primarily focus on any problems that the testers have found, as well as any other activities relating to testing. Will this be enough or do think that more time is required? Carl-Uno At 04:59 AM 12/17/97 PST, you wrote: >All, > There has been a request to hold an implementers/testing meeting on >Thursday during the January PWG meeting. I would like to gauge the >interest in such a meeting. There are a few alternatives. > 1) implementers/testing meeting on Thursday > 2) informal implementers/testing dinner Wednesday night > 3) TES item on IPP agenda to discuss how to get TES moving >I am looking for input from the IPP group on which alternative(s) should >be pursued. Any other ideas are also welcome. > >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 >__________________________________ > > > From ipp-owner@pwg.org Wed Dec 17 14:40:01 1997 Delivery-Date: Wed, 17 Dec 1997 14:40:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA25928 for ; Wed, 17 Dec 1997 14:40:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11771 for ; Wed, 17 Dec 1997 14:42:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA23301 for ; Wed, 17 Dec 1997 14:39:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 14:31:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21391 for ipp-outgoing; Wed, 17 Dec 1997 13:57:13 -0500 (EST) Message-Id: <1.5.4.32.19971217175756.006f896c@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: Wed, 17 Dec 1997 09:57:56 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Get Attributes Sender: ipp-owner@pwg.org At 09:33 AM 12/17/97 MST, you wrote: >I know this has probably been mentioned before, but as I am getting >more into implementation I am finding the use of Get-Attributes on >both the Printer and Job object to be ackward with regard to >implementation. It is the only case of a method being dependent >on the object and introduces some special case processing that could >be avoided by having 2 distinct methods. It seems that with regard >to consistency it would be better to have 2 methods that are >similar and consistent with the other methods (Get-Printer-Attributes and >Get-Job-Attributes). In addition, I think, at least based on my limited >experience, that perhaps the implementations could be a little simpler. > >Since part of the reason for prototyping is to provide feedback to the >spec developers I thought I would mention this. Steve Steve, I have made the suggestion repeatedly that we should have two operations, but I was apparently never able to deliver strong enough arguments to get it changed. I still think it is a good idea, but have to leave it to the editors to determine if they want to do this last minute change. Carl-Uno > > From ipp-owner@pwg.org Wed Dec 17 14:56:41 1997 Delivery-Date: Wed, 17 Dec 1997 14:56:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA26153 for ; Wed, 17 Dec 1997 14:56:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11818 for ; Wed, 17 Dec 1997 14:59:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA24007 for ; Wed, 17 Dec 1997 14:56:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 14:52:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23156 for ipp-outgoing; Wed, 17 Dec 1997 14:37:39 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'steve gebert Dept:ecg SN:579517 Div:ISM Ext'" , ipp@pwg.org Subject: RE: IPP> Get Attributes Date: Wed, 17 Dec 1997 11:34:59 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org The awkwardness of having get-attributes for both printer and job objects depends on how you implement the server. If you always have one server handling all requests, then you have to check the URL on the get-attributes request to determine if the URL points to a job or printer object. If however, the server is multithreaded, and spawns multiple threads (one per job), then the job-handler threads each have their own URL and any get-attributes request sent to a job-URL goes to the job object "thread" and no check has to be done. Randy > -----Original Message----- > From: steve gebert Dept:ecg SN:579517 Div:ISM Ext > [SMTP:smg1@vnet.IBM.COM] > Sent: Wednesday, December 17, 1997 8:34 AM > To: ipp@pwg.org > Subject: IPP> Get Attributes > > I know this has probably been mentioned before, but as I am getting > more into implementation I am finding the use of Get-Attributes on > both the Printer and Job object to be ackward with regard to > implementation. It is the only case of a method being dependent > on the object and introduces some special case processing that could > be avoided by having 2 distinct methods. It seems that with regard > to consistency it would be better to have 2 methods that are > similar and consistent with the other methods (Get-Printer-Attributes > and > Get-Job-Attributes). In addition, I think, at least based on my > limited > experience, that perhaps the implementations could be a little > simpler. > > Since part of the reason for prototyping is to provide feedback to the > spec developers I thought I would mention this. Steve From owner-nat@livingston.com Wed Dec 17 15:39:38 1997 Delivery-Date: Wed, 17 Dec 1997 15:39:39 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26580 for ; Wed, 17 Dec 1997 15:39:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA23106; Wed, 17 Dec 1997 12:34:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA09579 for nat-outgoing; Wed, 17 Dec 1997 12:37:46 -0800 (PST) Message-Id: <3.0.5.32.19971217123625.008b4100@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Dec 1997 12:36:25 -0800 To: Philippe OECHSLIN From: Matt Holdrege Subject: Re: (NAT) tcp options and non-routable names Cc: nat@livingston.com In-Reply-To: <1155.882367906@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 02:11 PM 12/17/97 +0000, Philippe OECHSLIN wrote: >This is applicable for most of the typical SOHO users of NAPT. Larger private >networks are assumed to have their own DNS server anyway. > >The key point is that, I think, it doesn't harm people who don't want to use >these names and it is helpful for those who want. I guess my point is that this isn't something that needs to be standardized. This is something that in most cases is site specific. The idea to create a useful template for SOHO's is good. Perhaps you could write it as an informational RFC. But I question it's applicability as a standards track document. Matt Holdrege http://www.ascend.com matt@ascend.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From ipp-owner@pwg.org Wed Dec 17 16:03:05 1997 Delivery-Date: Wed, 17 Dec 1997 16:03:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA26950 for ; Wed, 17 Dec 1997 16:03:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12131 for ; Wed, 17 Dec 1997 16:05:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24832 for ; Wed, 17 Dec 1997 16:03:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 15:50:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24147 for ipp-outgoing; Wed, 17 Dec 1997 15:35:00 -0500 (EST) Date: Wed, 17 Dec 1997 12:33:40 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712172033.MAA24335@woden.eng.sun.com> To: smg1@vnet.IBM.COM, ipp@pwg.org, rturner@sharplabs.com Subject: RE: IPP> Get Attributes X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have noticed the same problem during my implementation. With printer operations except Get-Attributes, the presence of a job-id is an error. With job operations whose target is a printer-uri except Get-Attributes, the absence of a job-id is an error. Because Get-Attributes is both a job and printer operation, neither the presence nor absence of job-id is an error. Rather it determines whether the operation is a printer or job operation. I am leaning towards Steve's idea to have two operations Get-Job-Attributes and Get-Printer-Attributes. > From rturner@sharplabs.com Wed Dec 17 11:53:33 1997 > > > The awkwardness of having get-attributes for both > printer and job objects depends on how you implement > the server. If you always have one server handling > all requests, then you have to check the URL > on the get-attributes request to determine if the URL > points to a job or printer object. If however, the > server is multithreaded, and spawns multiple threads > (one per job), then the job-handler threads each have > their own URL and any get-attributes request sent > to a job-URL goes to the job object "thread" and no > check has to be done. > > Randy > > > > -----Original Message----- > > From: steve gebert Dept:ecg SN:579517 Div:ISM Ext > > [SMTP:smg1@vnet.IBM.COM] > > Sent: Wednesday, December 17, 1997 8:34 AM > > To: ipp@pwg.org > > Subject: IPP> Get Attributes > > > > I know this has probably been mentioned before, but as I am getting > > more into implementation I am finding the use of Get-Attributes on > > both the Printer and Job object to be ackward with regard to > > implementation. It is the only case of a method being dependent > > on the object and introduces some special case processing that could > > be avoided by having 2 distinct methods. It seems that with regard > > to consistency it would be better to have 2 methods that are > > similar and consistent with the other methods (Get-Printer-Attributes > > and > > Get-Job-Attributes). In addition, I think, at least based on my > > limited > > experience, that perhaps the implementations could be a little > > simpler. > > > > Since part of the reason for prototyping is to provide feedback to the > > spec developers I thought I would mention this. Steve > From ipp-owner@pwg.org Wed Dec 17 16:53:18 1997 Delivery-Date: Wed, 17 Dec 1997 16:53:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27594 for ; Wed, 17 Dec 1997 16:53:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12515 for ; Wed, 17 Dec 1997 16:56:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25576 for ; Wed, 17 Dec 1997 16:53:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 16:33:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24171 for ipp-outgoing; Wed, 17 Dec 1997 15:46:11 -0500 (EST) Message-Id: <3.0.1.32.19971217103536.0094d460@mail2.cp10.es.xerox.com> X-Sender: xriley@mail2.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 17 Dec 1997 10:35:36 PST To: ipp@pwg.org From: "Xavier D. Riley" Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? Cc: xriley@cp10.es.xerox.com In-Reply-To: <3.0.1.32.19971217091500.00cf0dd0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Tom, Any name is OK with me. Are you aware that mutual authentication and privacy are not mandatory in TLS. It is optional based on the cipher suite used. Will the user see this name? I prefer "printer-tls-uri" or "printer-secure-uri". --Xavier At 09:15 AM 12/17/97 PST, Tom Hastings wrote: >In Washington and before, there has been discussion that calling >the second uri, "printer-secure-uri" makes it sound like the first >"printer-uri" is not secure. So we've been searching for a better >term. > >Scott and Steve came up with the term (drum roll): > > "Mutual Authentication and Privacy (MAP). > >So ok to call the second uri Printer attribute: "printer-map-uri"? > >It will be put right after the first uri: "printer-uri" secion >4.4.2 in the Model document. > >SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK >TO THE IESG. > >Thanks, >Tom > > > ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Wed Dec 17 17:25:26 1997 Delivery-Date: Wed, 17 Dec 1997 17:25:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27877 for ; Wed, 17 Dec 1997 17:25:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12607 for ; Wed, 17 Dec 1997 17:28:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26655 for ; Wed, 17 Dec 1997 17:25:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:04:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24635 for ipp-outgoing; Wed, 17 Dec 1997 15:58:01 -0500 (EST) Date: Wed, 17 Dec 1997 12:52:26 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712172052.MAA24362@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, rturner@sharplabs.com Subject: Re: IPP>MOD Action Item from LA: fix requesting-user-name explanation Cc: hastings@cp10.es.xerox.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From rturner@sharplabs.com Wed Dec 17 00:38:33 1997 > > See my comments on the new proposed > text below... > > Randy > > > Robert Herriot wrote: > > ..snip.. > > > > > Proposed wording: > > > > Each operation SHALL specify the user who is performing the operation > > in two ways: Change above two lines to: Each operation SHALL specify the user who is performing the operation in both of the following two ways: > > > > 1) via the the MANDATORY "requesting-user-name" operation attribute > > that a client SHOULD supply in all operations. The client SHALL obtain > > the value for this attribute from an environmental or network login > > name for the user, rather than allowing the user to supply any value. Add the following sentence at the end of 1) If the client does not supply a value for "requesting-user-name", the printer SHALL assume that the client is supplying some anonymous name, such as "guest". > > > > 2) via an authentication mechanism of the underlying transport which > > may be configured to give no authentication information. > > I think implementers would like to know if the relationship > between the above 2 ways is: "either-or","and",or just "or". > > > > > There are six cases to consider: > > > > a) the authentication mechanism gives no information, and the client > > doesnt specify requesting- user-name. > > > > b) the authentication mechanism gives no information, but the client > > specifies requesting-user- name. > > > > c) the authentication mechanism specifies a user which has no human > > readable representation, and the client doesnt specify > > requesting-user-name. > > I'm not sure that it is entirely unreasonable to > require credentials to always map to a human > readable string representation. I know this > info is available on x.509 certificates. I think that you are correct. Cases c and d are probably unnecessary. I have included them in case I am wrong. > > > > > d) the authentication mechanism specifies a user which has no human > > readable representation, but the client specifies > > requesting-user-name. > > > > e) the authentication mechanism specifies a user which has a human > > readable representation. The Printer object ignores the > > ?requesting-user-name?. > > > > f) the authentication mechanism specifies a user which is special and > > means that the value of the requesting-user-name, which must be > > present, is treated as the authenticated name. > > I do not think scenario (f) should be included > in this list. It sounds like a real niche > case that might take alot of text to explain > why this is needed. Case f) is intended for a tightly coupled gateway and server to work together so that the "user" name is that of the gateway's client and not that of the gateway. Because most if not all system vendors will initially implement IPP via a gateway into their existing print system, this mechansism is necessary unless the authentication mechanism allows a gateway (client) to act on behalf of some other client. > > > > > The user-name has two forms: > > > > one that is human readable: it is held in the MANDATORY > > "job-originating-user-name" Job Description attribute which is set > > during the job creation operations. It is used for presentation only, > > such as returning in queries or printing on start sheets > > In the original existing case, we stated that > the originating-user-name should come from the > client's notion of an OS login name, or some > equivalent, locally (on the client host) > authenticated mechanism. If this is still the > case, then I do not think we should preclude > an IPP server from performing some type of > lightweight authentication and access control > using the originating-user-name. However, as > always, when using a secure IPP connection, the > TLS authentication would ALWAYS take precedence. I differ with you on the gateway case where I think that it should be possible for a printer to be configured to treat the requesting-user-name as the authenticated name. This could happen for both TLS and for digest and basic authentication. > > > Randy > > > > > one for authorization: it is held in an undefined (by IPP) Job object > > attribute which is set by the job creation operation. It is used to > > authorize other operations, such as Send-Document, Send-URI, > > Cancel-Job, to determine the user when the my-jobs attribute is > > specified with Get-Jobs, and to limit what attributes to return with > > Get-Attributes and Get-Jobs. > > > > The human readable name: > > > > is the value of the requesting-user-name for cases b, d and f. > > > > comes from the authentication mechanism for case e > > > > is some anonymous name, such as guest for cases a and c. > > > > The name used for authorization: > > > > is the value of the requesting-user-name for cases b and f. > > > > comes from the authentication mechanism for cases c, d and e > > > > is some anonymous name, such as guest for case a. > You didn't comment on any of the above three lines. These differ from the current model document by allowing the requesting-user-name or a default guest name to be used for authorization. From ipp-owner@pwg.org Wed Dec 17 17:32:29 1997 Delivery-Date: Wed, 17 Dec 1997 17:32:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27935 for ; Wed, 17 Dec 1997 17:32:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12642 for ; Wed, 17 Dec 1997 17:35:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27166 for ; Wed, 17 Dec 1997 17:32:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:13:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24437 for ipp-outgoing; Wed, 17 Dec 1997 15:54:23 -0500 (EST) From: Carl Kugler To: Subject: RE: IPP> Get Attributes Message-ID: <5030100015195352000002L022*@MHS> Date: Wed, 17 Dec 1997 15:54:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA27935 >The awkwardness of having get-attributes for both >printer and job objects depends on how you implement >the server. Then why not make 2 separate methods and avoid constraining the implementation? Keep in mind that implementers don't always get to start from a clean slate. One might be reusing legacy code, or extending an existing product, or using a platform that makes multi-threading difficult. -Carl ipp-owner@pwg.org 12/17/97 07:59 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, smg1@vnet.IBM.COM @ internet cc: Subject: RE: IPP> Get Attributes The awkwardness of having get-attributes for both printer and job objects depends on how you implement the server. If you always have one server handling all requests, then you have to check the URL on the get-attributes request to determine if the URL points to a job or printer object. If however, the server is multithreaded, and spawns multiple threads (one per job), then the job-handler threads each have their own URL and any get-attributes request sent to a job-URL goes to the job object "thread" and no check has to be done. Randy > -----Original Message----- > From: steve gebert Dept:ecg SN:579517 Div:ISM Ext > [SMTP:smg1@vnet.IBM.COM] > Sent: Wednesday, December 17, 1997 8:34 AM > To: ipp@pwg.org > Subject: IPP> Get Attributes > > I know this has probably been mentioned before, but as I am getting > more into implementation I am finding the use of Get-Attributes on > both the Printer and Job object to be ackward with regard to > implementation. It is the only case of a method being dependent > on the object and introduces some special case processing that could > be avoided by having 2 distinct methods. It seems that with regard > to consistency it would be better to have 2 methods that are > similar and consistent with the other methods (Get-Printer-Attributes > and > Get-Job-Attributes). In addition, I think, at least based on my > limited > experience, that perhaps the implementations could be a little > simpler. > > Since part of the reason for prototyping is to provide feedback to the > spec developers I thought I would mention this. Steve From ipp-owner@pwg.org Wed Dec 17 17:41:50 1997 Delivery-Date: Wed, 17 Dec 1997 17:41:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27980 for ; Wed, 17 Dec 1997 17:41:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12673 for ; Wed, 17 Dec 1997 17:44:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27812 for ; Wed, 17 Dec 1997 17:41:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:23:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24907 for ipp-outgoing; Wed, 17 Dec 1997 16:08:16 -0500 (EST) Date: Wed, 17 Dec 1997 13:03:23 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712172103.NAA24387@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, don@lexmark.com Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map -uri"? Cc: Ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I had a concern when "printer-map-uri" was considered that most people would think of the English word "map" rather than see it as an acronym for "mutual authentication and privacy". But the reason for moving away from "secure-printer-uri" is that the printer-uri is not totally insecure. It can have authentication. Perhaps "printer-tls-uri" is the least bad, but we have had other reasons for avoiding it. It also the case, that if we went to name another port (other than 80 and 443) in the protocol, the IESG would want a single port for TLS and non-tls, so there might be a single printer-uri. Though I expect that depPerhaps > From don@lexmark.com Wed Dec 17 10:18:16 1997 > > > If I were to see "printer-map-uri" I would assume I could point my browser > at thar uri and see were the printer is located on a MAP!! > > What about being real straight-forward and calling it one of the following: > > TLS-Printer-uri > Printer-TLS-uri > > Actually, secure-printer-uri is exactly what is says it is and printer-uri > says > nothing about security. I'm not opposed to calling it what it is and > living with > the implications of that. > > Don > > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > ----------------------------------------------- > > > > To: ipp%pwg.org@interlock.lexmark.com > cc: SISAACSON%novell.com@interlock.lexmark.com, > szilles%Adobe.COM@interlock.lexmark.com (bcc: Don Wright) > bcc: Don Wright > Subject: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? > > > > > In Washington and before, there has been discussion that calling > the second uri, "printer-secure-uri" makes it sound like the first > "printer-uri" is not secure. So we've been searching for a better > term. > Scott and Steve came up with the term (drum roll): > "Mutual Authentication and Privacy (MAP). > So ok to call the second uri Printer attribute: "printer-map-uri"? > It will be put right after the first uri: "printer-uri" secion > 4.4.2 in the Model document. > SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK > TO THE IESG. > Thanks, > Tom > > > > > > From ipp-owner@pwg.org Wed Dec 17 17:50:33 1997 Delivery-Date: Wed, 17 Dec 1997 17:50:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28033 for ; Wed, 17 Dec 1997 17:50:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12693 for ; Wed, 17 Dec 1997 17:53:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA28173 for ; Wed, 17 Dec 1997 17:50:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:33:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24940 for ipp-outgoing; Wed, 17 Dec 1997 16:17:27 -0500 (EST) Date: Wed, 17 Dec 1997 13:12:07 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712172112.NAA24395@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, don@lexmark.com Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map -uri"? Cc: Ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The previous email was sent accidentally before it was complete. The important issue is that "printer-map-uri" probably isn't right, but I'm not sure what is. We could switch around the acronym to "pma" ("privacy and mutual authentication") to give us "printer-pma-uri". But the issue I started to raise in the previous email is what a single dedicated port would look like. Would we still have the "http" and "https" schemes on a single port, or would we go to an "ipp" scheme with some other mechanism to determine whether the TLS is being used. This has implications for when the alternative printer-uri is used. Perhaps another name is "printer-alt-uri" or "printer-alternate-uri". Bob > From don@lexmark.com Wed Dec 17 10:18:16 1997 > From: don@lexmark.com > X-Lotus-Fromdomain: LEXMARK@LEXMTA > To: hastings@cp10.es.xerox.com > Cc: Ipp@pwg.org > Date: Wed, 17 Dec 1997 12:55:37 -0500 > Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map > -uri"? > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 58 > > > If I were to see "printer-map-uri" I would assume I could point my browser > at thar uri and see were the printer is located on a MAP!! > > What about being real straight-forward and calling it one of the following: > > TLS-Printer-uri > Printer-TLS-uri > > Actually, secure-printer-uri is exactly what is says it is and printer-uri > says > nothing about security. I'm not opposed to calling it what it is and > living with > the implications of that. > > Don > > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > ----------------------------------------------- > > > > To: ipp%pwg.org@interlock.lexmark.com > cc: SISAACSON%novell.com@interlock.lexmark.com, > szilles%Adobe.COM@interlock.lexmark.com (bcc: Don Wright) > bcc: Don Wright > Subject: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? > > > > > In Washington and before, there has been discussion that calling > the second uri, "printer-secure-uri" makes it sound like the first > "printer-uri" is not secure. So we've been searching for a better > term. > Scott and Steve came up with the term (drum roll): > "Mutual Authentication and Privacy (MAP). > So ok to call the second uri Printer attribute: "printer-map-uri"? > It will be put right after the first uri: "printer-uri" secion > 4.4.2 in the Model document. > SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK > TO THE IESG. > Thanks, > Tom > > > > > > From ipp-owner@pwg.org Wed Dec 17 18:09:34 1997 Delivery-Date: Wed, 17 Dec 1997 18:09:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28132 for ; Wed, 17 Dec 1997 18:09:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12794 for ; Wed, 17 Dec 1997 18:12:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA29413 for ; Wed, 17 Dec 1997 18:09:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:55:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25441 for ipp-outgoing; Wed, 17 Dec 1997 16:48:11 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Xavier D. Riley'" , ipp@pwg.org Subject: RE: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-u ri"? Date: Wed, 17 Dec 1997 13:45:05 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I also prefer printer-secure-uri.... Randy > -----Original Message----- > From: Xavier D. Riley [SMTP:xriley@cp10.es.xerox.com] > Sent: Wednesday, December 17, 1997 10:36 AM > To: ipp@pwg.org > Cc: xriley@cp10.es.xerox.com > Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: > "printer-map-uri"? > > Tom, > Any name is OK with me. Are you aware that mutual > authentication and privacy are not mandatory in TLS. > It is optional based on the cipher suite used. > > Will the user see this name? > > I prefer "printer-tls-uri" or "printer-secure-uri". > > --Xavier > > At 09:15 AM 12/17/97 PST, Tom Hastings wrote: > >In Washington and before, there has been discussion that calling > >the second uri, "printer-secure-uri" makes it sound like the first > >"printer-uri" is not secure. So we've been searching for a better > >term. > > > >Scott and Steve came up with the term (drum roll): > > > > "Mutual Authentication and Privacy (MAP). > > > >So ok to call the second uri Printer attribute: "printer-map-uri"? > > > >It will be put right after the first uri: "printer-uri" secion > >4.4.2 in the Model document. > > > >SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK > >TO THE IESG. > > > >Thanks, > >Tom > > > > > > > > ______________________________________________________________________ > Xavier Riley > Xerox Corp. > Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 > 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 > El Segundo, California 90245 Email: xriley@cp10.es.xerox.com > ______________________________________________________________________ From ipp-owner@pwg.org Wed Dec 17 18:10:02 1997 Delivery-Date: Wed, 17 Dec 1997 18:10:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28141 for ; Wed, 17 Dec 1997 18:10:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12800 for ; Wed, 17 Dec 1997 18:12:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA29446 for ; Wed, 17 Dec 1997 18:10:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 17:56:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25381 for ipp-outgoing; Wed, 17 Dec 1997 16:46:18 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Robert.Herriot@Eng.Sun.COM'" , rturner@sharplabs.com Cc: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: RE: IPP>MOD Action Item from LA: fix requesting-user-name explana tion Date: Wed, 17 Dec 1997 13:43:20 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I agree that it is possible to construct a scenario whereby case f) below is necessary. But isn't this a special case?, and if it is a gateway issue, I don't think this kind of text should be in the normative specification. We shouldn't preclude the construction of gateways, but we shouldn't necessarily sway the architecture or normative text directly towards supporting gateways. Perhaps, mechanisms that enable gateways should be an appendix... Also FYI, regarding cases (c) and (d) below, the latest TLS draft only provides authentication via certificates, and only certificates. These certificates contain (among other things) human readable identification strings. Randy > -----Original Message----- > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > Sent: Wednesday, December 17, 1997 12:52 PM > To: Robert.Herriot@Eng.Sun.COM; rturner@sharplabs.com > Cc: hastings@cp10.es.xerox.com; ipp@pwg.org > Subject: Re: IPP>MOD Action Item from LA: fix > requesting-user-name explanation > > > > From rturner@sharplabs.com Wed Dec 17 00:38:33 1997 > > > > See my comments on the new proposed > > text below... > > > > Randy > > > > > > Robert Herriot wrote: > > > > ..snip.. > > > > > > > > Proposed wording: > > > > > > Each operation SHALL specify the user who is performing the > operation > > > in two ways: > Change above two lines to: > > Each operation SHALL specify the user who is performing the operation > in both of the following two ways: > > > > > > > > 1) via the the MANDATORY "requesting-user-name" operation > attribute > > > that a client SHOULD supply in all operations. The client > SHALL obtain > > > the value for this attribute from an environmental or > network login > > > name for the user, rather than allowing the user to supply > any value. > Add the following sentence at the end of 1) > > If the client does not supply a value for "requesting-user-name", the > printer > SHALL assume that the client is supplying some anonymous name, such as > "guest". > > > > > > 2) via an authentication mechanism of the underlying > transport which > > > may be configured to give no authentication information. > > > > I think implementers would like to know if the relationship > > between the above 2 ways is: "either-or","and",or just "or". > > > > > > > > There are six cases to consider: > > > > > > a) the authentication mechanism gives no information, and > the client > > > doesnt specify requesting- user-name. > > > > > > b) the authentication mechanism gives no information, but > the client > > > specifies requesting-user- name. > > > > > > c) the authentication mechanism specifies a user which > has no human > > > readable representation, and the client doesnt specify > > > requesting-user-name. > > > > I'm not sure that it is entirely unreasonable to > > require credentials to always map to a human > > readable string representation. I know this > > info is available on x.509 certificates. > > I think that you are correct. Cases c and d are probably unnecessary. > I > have included them in case I am wrong. > > > > > > > > d) the authentication mechanism specifies a user which > has no human > > > readable representation, but the client specifies > > > requesting-user-name. > > > > > > e) the authentication mechanism specifies a user which > has a human > > > readable representation. The Printer object ignores the > > > ?requesting-user-name?. > > > > > > f) the authentication mechanism specifies a user which is > special and > > > means that the value of the requesting-user-name, which > must be > > > present, is treated as the authenticated name. > > > > I do not think scenario (f) should be included > > in this list. It sounds like a real niche > > case that might take alot of text to explain > > why this is needed. > > Case f) is intended for a tightly coupled gateway and server to work > together so that the "user" name is that of the gateway's client and > not that of the gateway. Because most if not all system vendors will > initially implement IPP via a gateway into their existing print > system, > this mechansism is necessary unless the authentication mechanism > allows > a gateway (client) to act on behalf of some other client. > > > > > > > > > The user-name has two forms: > > > > > > one that is human readable: it is held in the MANDATORY > > > "job-originating-user-name" Job Description attribute > which is set > > > during the job creation operations. It is used for > presentation only, > > > such as returning in queries or printing on start sheets > > > > In the original existing case, we stated that > > the originating-user-name should come from the > > client's notion of an OS login name, or some > > equivalent, locally (on the client host) > > authenticated mechanism. If this is still the > > case, then I do not think we should preclude > > an IPP server from performing some type of > > lightweight authentication and access control > > using the originating-user-name. However, as > > always, when using a secure IPP connection, the > > TLS authentication would ALWAYS take precedence. > > I differ with you on the gateway case where I think that it > should be possible for a printer to be configured to treat > the requesting-user-name as the authenticated name. This > could happen for both TLS and for digest and basic > authentication. > > > > > > > Randy > > > > > > > > one for authorization: it is held in an undefined (by IPP) > Job object > > > attribute which is set by the job creation operation. It > is used to > > > authorize other operations, such as Send-Document, > Send-URI, > > > Cancel-Job, to determine the user when the my-jobs > attribute is > > > specified with Get-Jobs, and to limit what attributes to > return with > > > Get-Attributes and Get-Jobs. > > > > > > The human readable name: > > > > > > is the value of the requesting-user-name for cases b, d > and f. > > > > > > comes from the authentication mechanism for case e > > > > > > is some anonymous name, such as guest for cases a and c. > > > > > > The name used for authorization: > > > > > > is the value of the requesting-user-name for cases b and > f. > > > > > > comes from the authentication mechanism for cases c, d and > e > > > > > > is some anonymous name, such as guest for case a. > > > You didn't comment on any of the above three lines. These differ from > the current model document by allowing the requesting-user-name or a > default guest name to be used for authorization. From ipp-owner@pwg.org Wed Dec 17 18:31:42 1997 Delivery-Date: Wed, 17 Dec 1997 18:31:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28266 for ; Wed, 17 Dec 1997 18:31:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12933 for ; Wed, 17 Dec 1997 18:34:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00198 for ; Wed, 17 Dec 1997 18:31:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 18:19:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27391 for ipp-outgoing; Wed, 17 Dec 1997 17:35:35 -0500 (EST) Message-Id: <1.5.4.32.19971217213658.006e9ba8@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: Wed, 17 Dec 1997 13:36:58 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Printer URI names Cc: masinter@parc.xerox.com Sender: ipp-owner@pwg.org My apologies for having been a bit too slow to communicate this to the people who were not present in the IETF meeting. Here are a couple of explanations to what we need to do in the way of security in order to meet the agreements in our IPP meeting. 1) The meaning of "all clients have to support both kinds of URIs and their associated security" means that ALL clients have to support the HTTP security, including RC 2069, as well as a suitable subset of TLS. 2) The TLS specs require that every application specifies a profile on how they use TLS. Such a documrent has obviously not yet been produced for IPP. A couple of guys from the TLS group promissed to quickly produce a document for HTTP over TLS. It might be possible for us to just use that, but if we are not happy with what that document states, we will have to create our own. It is unlikely that the IPP documents will be accepted as Proposed Standards before we can reference a TLS profile document. I have asked my local security guys to get involved in the HTTT/TLS profile draft and urge others from the IPP group to also join in, as this is now on our critical path. Carl-Uno From ipp-owner@pwg.org Wed Dec 17 18:46:27 1997 Delivery-Date: Wed, 17 Dec 1997 18:46:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28584 for ; Wed, 17 Dec 1997 18:46:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12987 for ; Wed, 17 Dec 1997 18:49:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00856 for ; Wed, 17 Dec 1997 18:46:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 18:37:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28860 for ipp-outgoing; Wed, 17 Dec 1997 18:02:17 -0500 (EST) Date: Wed, 17 Dec 1997 14:56:52 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712172256.OAA24502@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, rturner@sharplabs.com Subject: RE: IPP>MOD Action Item from LA: fix requesting-user-name explana tion Cc: hastings@cp10.es.xerox.com, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The real issue here is that the protocol provides two channels for authentication information: a) in application/ipp layer as requesting-user-name attribute b) in the transport layer via some unspecified authentication mechanism I think we agree that if b) above provides no authentication information, then the user name comes from a). If neither channel provides a user name, then the user is "guest" or something similar. The issue we are disagreeing on is where both channels provide authentication information. In that case, MUST the server always use b) and ignore a) or can an implementation be configured to use a)? If an implementation can be configured to use a), then it can either 1) do it for all values it obtains from b) or 2) only for certain values it obtains from b). I was suggesting 2) because it is more likely to be useful. Furthermore, 2) is a superset of 1). Bob Herriot > From rturner@sharplabs.com Wed Dec 17 13:50:15 1997 > From: "Turner, Randy" > To: "'Robert.Herriot@Eng.Sun.COM'" , rturner@sharplabs.com > Cc: hastings@cp10.es.xerox.com, ipp@pwg.org > Subject: RE: IPP>MOD Action Item from LA: fix requesting-user-name explana > tion > Date: Wed, 17 Dec 1997 13:43:20 -0800 > X-Priority: 3 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.0.1458.49) > X-Lines: 202 > > > I agree that it is possible to construct a scenario whereby > case f) below is necessary. But isn't this a special case?, > and if it is a gateway issue, I don't think this kind of text > should be in the normative specification. We shouldn't > preclude the construction of gateways, but we shouldn't > necessarily sway the architecture or normative text > directly towards supporting gateways. > > Perhaps, mechanisms that enable gateways should > be an appendix... > > > Also FYI, > regarding cases (c) and (d) below, the latest > TLS draft only provides authentication via certificates, > and only certificates. These certificates contain > (among other things) human readable identification strings. > > > Randy > > > -----Original Message----- > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > > Sent: Wednesday, December 17, 1997 12:52 PM > > To: Robert.Herriot@Eng.Sun.COM; rturner@sharplabs.com > > Cc: hastings@cp10.es.xerox.com; ipp@pwg.org > > Subject: Re: IPP>MOD Action Item from LA: fix > > requesting-user-name explanation > > > > > > > From rturner@sharplabs.com Wed Dec 17 00:38:33 1997 > > > > > > See my comments on the new proposed > > > text below... > > > > > > Randy > > > > > > > > > Robert Herriot wrote: > > > > > > ..snip.. > > > > > > > > > > > Proposed wording: > > > > > > > > Each operation SHALL specify the user who is performing the > > operation > > > > in two ways: > > Change above two lines to: > > > > Each operation SHALL specify the user who is performing the operation > > in both of the following two ways: > > > > > > > > > > > > 1) via the the MANDATORY "requesting-user-name" operation > > attribute > > > > that a client SHOULD supply in all operations. The client > > SHALL obtain > > > > the value for this attribute from an environmental or > > network login > > > > name for the user, rather than allowing the user to supply > > any value. > > Add the following sentence at the end of 1) > > > > If the client does not supply a value for "requesting-user-name", the > > printer > > SHALL assume that the client is supplying some anonymous name, such as > > "guest". > > > > > > > > 2) via an authentication mechanism of the underlying > > transport which > > > > may be configured to give no authentication information. > > > > > > I think implementers would like to know if the relationship > > > between the above 2 ways is: "either-or","and",or just "or". > > > > > > > > > > > There are six cases to consider: > > > > > > > > a) the authentication mechanism gives no information, and > > the client > > > > doesnt specify requesting- user-name. > > > > > > > > b) the authentication mechanism gives no information, but > > the client > > > > specifies requesting-user- name. > > > > > > > > c) the authentication mechanism specifies a user which > > has no human > > > > readable representation, and the client doesnt specify > > > > requesting-user-name. > > > > > > I'm not sure that it is entirely unreasonable to > > > require credentials to always map to a human > > > readable string representation. I know this > > > info is available on x.509 certificates. > > > > I think that you are correct. Cases c and d are probably unnecessary. > > I > > have included them in case I am wrong. > > > > > > > > > > > d) the authentication mechanism specifies a user which > > has no human > > > > readable representation, but the client specifies > > > > requesting-user-name. > > > > > > > > e) the authentication mechanism specifies a user which > > has a human > > > > readable representation. The Printer object ignores the > > > > ?requesting-user-name?. > > > > > > > > f) the authentication mechanism specifies a user which is > > special and > > > > means that the value of the requesting-user-name, which > > must be > > > > present, is treated as the authenticated name. > > > > > > I do not think scenario (f) should be included > > > in this list. It sounds like a real niche > > > case that might take alot of text to explain > > > why this is needed. > > > > Case f) is intended for a tightly coupled gateway and server to work > > together so that the "user" name is that of the gateway's client and > > not that of the gateway. Because most if not all system vendors will > > initially implement IPP via a gateway into their existing print > > system, > > this mechansism is necessary unless the authentication mechanism > > allows > > a gateway (client) to act on behalf of some other client. > > > > > > > > > > > > > The user-name has two forms: > > > > > > > > one that is human readable: it is held in the MANDATORY > > > > "job-originating-user-name" Job Description attribute > > which is set > > > > during the job creation operations. It is used for > > presentation only, > > > > such as returning in queries or printing on start sheets > > > > > > In the original existing case, we stated that > > > the originating-user-name should come from the > > > client's notion of an OS login name, or some > > > equivalent, locally (on the client host) > > > authenticated mechanism. If this is still the > > > case, then I do not think we should preclude > > > an IPP server from performing some type of > > > lightweight authentication and access control > > > using the originating-user-name. However, as > > > always, when using a secure IPP connection, the > > > TLS authentication would ALWAYS take precedence. > > > > I differ with you on the gateway case where I think that it > > should be possible for a printer to be configured to treat > > the requesting-user-name as the authenticated name. This > > could happen for both TLS and for digest and basic > > authentication. > > > > > > > > > > > Randy > > > > > > > > > > > one for authorization: it is held in an undefined (by IPP) > > Job object > > > > attribute which is set by the job creation operation. It > > is used to > > > > authorize other operations, such as Send-Document, > > Send-URI, > > > > Cancel-Job, to determine the user when the my-jobs > > attribute is > > > > specified with Get-Jobs, and to limit what attributes to > > return with > > > > Get-Attributes and Get-Jobs. > > > > > > > > The human readable name: > > > > > > > > is the value of the requesting-user-name for cases b, d > > and f. > > > > > > > > comes from the authentication mechanism for case e > > > > > > > > is some anonymous name, such as guest for cases a and c. > > > > > > > > The name used for authorization: > > > > > > > > is the value of the requesting-user-name for cases b and > > f. > > > > > > > > comes from the authentication mechanism for cases c, d and > > e > > > > > > > > is some anonymous name, such as guest for case a. > > > > > You didn't comment on any of the above three lines. These differ from > > the current model document by allowing the requesting-user-name or a > > default guest name to be used for authorization. > From jmp-owner@pwg.org Wed Dec 17 18:56:38 1997 Delivery-Date: Wed, 17 Dec 1997 18:56:38 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28708 for ; Wed, 17 Dec 1997 18:56:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA13027 for ; Wed, 17 Dec 1997 18:59:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01549 for ; Wed, 17 Dec 1997 18:56:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 18:51:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00993 for jmp-outgoing; Wed, 17 Dec 1997 18:47:30 -0500 (EST) Message-Id: <3.0.1.32.19971217130348.00fd26d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 17 Dec 1997 13:03:48 PST To: jmp@pwg.org From: Tom Hastings Subject: JMP> URGENT: Should impressions include blank last page back sides or not? Cc: ipp@pwg.org, szilles@Adobe.COM In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org At the JMP meeting on 12/5, we agreed that the definitions of impressions would count the number of times a media side goes past the marker, even if there are no marks made. I think we agreed to that, becasue impressions is supposed to count after the sheet is stacked, so that the sheet counter doesn't know whether the back side of the last page (documents with an odd number of pages), was marked or not, so we said that it SHALL count. Howver, for an accounting application, the customers may get pretty unhappy with having to pay for the final side they didn't use, as Angelo points out, when their document has an odd number of pages. URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: So how about RECOMMENDING (but not requiring) that the number of impressions for two-sided printing not include counting both sides of sheets marked on only one side. It may be that the interpreter has to be involved in counting impressions, rather than the sheet counter in the stacker or maybe the implementation only worries about the last sheet and so there is just an internal status bit that says whether a document has an odd number or an even number of sides in order to know whether to count the last sheet as 1 or 2 impressions. I suggest changing the sentence in the definition of impression: If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. to: If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. BTW, the current definition of "impression" in the IPP Model is: 12.2.15 impressions An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. So it seems that the IPP Job Model is in agreement with the following recommendation for the Job Mon MIB: The full definition of the term impressions (as sent yesterday) is for the Job Monitoring MIB: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". I propose to soften that definition to: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY OBJECTIONS, I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. Thanks, Tom At 07:18 12/17/1997 PST, Caruso, Angelo wrote: >Tom, > snip... >Your proposed definition of impressions is great except for the sentence >"If a two-sided document has an odd number of pages, the last sheet >still counts as two impressions, if that sheet makes two passes through >the marker or the marker marks on both sides of a sheet in a single >pass." I disagree with this. Why should the odd side count as an >impression if it is not marked? And which impressions counters would you >increment for the unmarked odd side? Some engine architectures require >that the sheet pass through the marker twice even though the sheet only >gets marked on one side. This seems like a rather arbitrary and unfair >policy, especially from the customer's point of view. With this policy, >if I printed 100 copies of a 5 page duplex document, I would pay for 600 >impressions even though I only made 500 impressions. > >Thanks, >Angelo > > > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Tuesday, December 16, 1997 5:37 PM > To: jmp@pwg.org; Caruso, Angelo > Cc: XCMI Editors only > Subject: URGENT: Ambiguity in >impressions|fullColor|highlighColorComppleteddefns > > Angelo, > > You've come up with a third interpretation of the >impressionsCompleted, > fullColorImpressionsCompleted and >highlightColorImpressionsCompleted! > > > I'm proposing the interpretation based on our discussion at the > Dec 5 JMP meeting (which you did not have the benefit of >attending). > > > PEOPLE, > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU >OBJECT TO > MY CLARIFICATIONS. > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS >AGREEMENT. > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK >AS WE > AGREED AT THE JMP MEETING. > > First, here is the definition of the term "impression" that we > came up with at the meeting (please review the text too, since >it was only > the ideas that we agreed to at the meeting): > > Impression: For a print job, an impression is the passage of >the entire > side of a sheet by the marker, whether or not any marks are made >and > independent of the number of passes that the side makes past the >marker. > Thus a four pass color process counts as a single impression. >One-sided > processing involves one impression per sheet. Two-sided >processing > involves two impressions per sheet. If a two-sided document has >an odd > number of pages, the last sheet still counts as two impressions, >if that > sheet makes two passes through the marker or the marker marks on >both sides > of a sheet in a single pass. Two-up printing is the placement >of two > logical pages on one side of a sheet and so is still a single >impression. > See "page" and "sheet". > > The three interpretations of these three attributes are: > > 1. Does impressionsCompleted increment or not when a highlight >or full color > impression is made? The current above definition of impressions >suggests > that it does, since an impressions is the passing of one side of >the > media past the marker whether color or not. > > 2. Does the fullColorImpressionsCompleted count once for each >side of > a full color impression or once for each color pass past the >side of > a medium? > > For example, if I had a 16-page document that had 10 black and >white pages, > 5 highlight color pages, and 1 full 4-color page, (number-up=1, >sides=1), > would the counts at the end of my job be: > > highlightColor fullColor > impressionsCompleted ImpressionsCompleted >ImpressionsCompleted > > 1. 16 5 1 > 2. 16 5 20 > 3. 10 5 1 > 4. 10 5 20 > > I suggest that it is interpretation 1 that we are agreeing to >and I'll clarify > the fullColorImpressionsCompleted, by adding the phrase, >"independent > of the number of colors or color passes" to the end of the first > sentence, yielding: > > The number of full color impressions completed by the device for >this job > so far independent of the number of colors or color passes. > > I'll also add the parenthetical remake to the >impressionsCompleted > "(monochome, highlight color, and full color)" to the first >sentence, > since it is clear from the definition of impression that it >includes > all, yielding: > > The total number of impressions (monochome, highlight color, and >full > color) completed for this job so far. > > Ok? > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE >CLARIFICATION. > > Thanks, > Tom > > The current definitions of impressionsCompleted, > highlightColorImpressionsCompleted, and >fullColorImpressionsCompleted are: > > OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of impressions completed for this job so far. >For > printing devices, the impressions completed includes >interpreting, marking, > and stacking the output. For other types of job services, the >number of > impressions completed includes the number of impressions >processed. > > NOTE - See the impressionsCompletedCurrentCopy and > pagesCompletedCurrentCopy attributes for attributes that are >reset on each > document copy. > > NOTE - The jmJobImpressionsCompleted object can be used with the > jmJobImpressionsPerCopyRequested object to provide an indication >of the > relative progress of the job, provided that the multiplicative >factor is > taken into account for some implementations of multiple copies." > REFERENCE > "See the definition of the term "impression" in Section 2 and >the counting > example in Section 3.4 entitled 'Monitoring Job Progress'." > DEFVAL { 0 } -- default is no octets > ::= { jmJobEntry 8 } > > fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > INTEGER: The number of full color impressions completed by the >device for > this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Full color impressions are typically >defined as > those requiring 3 or more colorants, but this MAY vary by >implementation. > > highlightColorImpressionsCompleted(115), >Integer32(-2..2147483647) > INTEGER: The number of highlight color impressions completed by >the device > for this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Highlight color impressions are >typically defined > as those requiring black plus one other colorant, but this MAY >vary by > implementation. > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > >Tom, > > > >There's no ambiguity in my mind. You increment exactly one of >the three > >counters ([monochrome]impressionsCompleted, > >fullColorImpressionsCompleted, or >highlightColorImpressionsCompleted) > >for each SIDE completed. If the side requires 3 or more >colorants to > >produce the impression then it's Full Color, black plus one >other > >colorant would be Highlight color, and a side that uses only >black would > >cause the monochrome counter to increment. To display job >progress to a > >user you need to sum all three of these counters. > > The advantage to saying that impressionsCompleted, counts >black/white, > highlight color, and full color, is that an application only >need to > look at one attribute if it doesn't care about the distinction >of b/w, > highlight and full color. Also the device might not implement > the other two, so it is easier for an application to just look >at the > one attribute if that is all it is interested in. Ok? > > > > >For example, if you produce a duplex sheet with full process >color > >graphics on the front side and black text on the back side, >then you > >would increment fullColorImpressionsCompleted when the front >side was > >completed and [monochrome]impressionsCompleted when the back >was > >complete. Since the descriptions of these attributes were >changed to say > >"For printing, the impressions completed includes interpreting, >marking, > >and stacking the output", then this implies to me that both >counters > >would be incremented simultaneously when this completed duplex >sheet was > >delivered to the output. > > So with my suggested resolution, the >fullColorImpressionsCompleted > would count by 1 and the impressionsCompleted would count by 2 >in > your example. > > > > >Is there something else I'm missing here? > > > >Obviously these objects do not provide detailed colorant use >information > >for each page. To do so would require objects to count the >actual amount > >of each colorant transferred to each side. So as a compromise, >we > >proposed these two new objects (which complement the previously >existing > >[monochrome]impressionsCompleted counter) to provide enough >information > >for an accounting application to bill at different rates for >monochrome, > >highlight color, and full color impressions within a job. > > I think that the accounting program can still bill correctly >with > impressionsCompleted counting highlight and fullColor as well as >monochrome. > It can substract out the monochrome, if it wants to, or build in >the > charge for color to be less that the correct charge for coloer >by the amount > charged for monochrome and avoid subtracting. > > > > >Thanks, > >Angelo > > > >> -----Original Message----- > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > >> Sent: Friday, December 12, 1997 11:26 AM > >> To: Angelo_Caruso@wb.xerox.com > >> Cc: XCMI Editors only > >> Subject: Ambiguity in XCMI & PWG Job Mon: > >> fullColorImpressionsCompleted(1 > >> > >> URGENT: > >> > >> The current definition of fullColorImpressionsCompleted(114) >and > >> highlightColorImpressionsCompleted(115) is: > >> > >> fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > >> INTEGER: The number of full color impressions completed by >the device > >> for > >> this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Full color impressions are typically >defined as > >> those requiring 3 or more colorants, but this MAY vary by > >> implementation. > >> > >> highlightColorImpressionsCompleted(115), > >> Integer32(-2..2147483647) > >> INTEGER: The number of highlight color impressions completed >by the > >> device > >> for this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Highlight color impressions are >typically > >> defined > >> as those requiring black plus one other colorant, but this >MAY vary by > >> implementation. > >> > >> > >> Suppose you have a 4 color process that makes four passes >through the > >> marker > >> for each side, does this attribute count by 1 for each pass >or does > >> it still > >> count just the number of sides? > >> > >> The advantage of counting the number of color passes is that >something > >> > >> counts for each pass which can be shown to a user. Also >accounting > >> may > >> want to charge for each color pass. Conceivably, there might >be a > >> variable > >> number of passes, depending on the colors demanded by each >image? > >> > >> The advantage of only counting once per side, is that you can >then > >> compare > >> the number of impressions for the job with the number of > >> fullColorImpressionsCompleted and determine the percentage of >color > >> impressions in the job. Also this definition seems to be >more in > >> keeping > >> with the > >> concept of "stacking" the media mentioned in the definition. > >> > >> Since Xerox proposed this attribute, what did we have in >mind? > >> > >> Thanks, > >> Tom > > > > > > From ipp-owner@pwg.org Wed Dec 17 18:59:27 1997 Delivery-Date: Wed, 17 Dec 1997 18:59:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28732 for ; Wed, 17 Dec 1997 18:59:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA13042 for ; Wed, 17 Dec 1997 19:02:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01684 for ; Wed, 17 Dec 1997 18:59:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 18:46:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29596 for ipp-outgoing; Wed, 17 Dec 1997 18:17:26 -0500 (EST) Message-Id: <1.5.4.32.19971217221457.006e81e0@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: Wed, 17 Dec 1997 14:14:57 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? Sender: ipp-owner@pwg.org Bob, At 01:12 PM 12/17/97 -0800, you wrote: >But the issue I started to raise in the previous email is what >a single dedicated port would look like. Would we still have >the "http" and "https" schemes on a single port, or would we >go to an "ipp" scheme with some other mechanism to determine whether >the TLS is being used. This has implications for when the >alternative printer-uri is used. > Although there is an effort to use a single port, I have heard nothing about changing the "https" to anything else, so this is still the distinguishing difference when IPP uses TLS or not. Carl-Uno From ipp-owner@pwg.org Wed Dec 17 19:27:29 1997 Delivery-Date: Wed, 17 Dec 1997 19:27:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA28897 for ; Wed, 17 Dec 1997 19:27:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA13118 for ; Wed, 17 Dec 1997 19:30:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02956 for ; Wed, 17 Dec 1997 19:27:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 19:18:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01017 for ipp-outgoing; Wed, 17 Dec 1997 18:47:47 -0500 (EST) Message-Id: <3.0.1.32.19971217130348.00fd26d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 17 Dec 1997 13:03:48 PST To: jmp@pwg.org From: Tom Hastings Subject: IPP> URGENT: Should impressions include blank last page back sides or not? Cc: ipp@pwg.org, szilles@Adobe.COM In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At the JMP meeting on 12/5, we agreed that the definitions of impressions would count the number of times a media side goes past the marker, even if there are no marks made. I think we agreed to that, becasue impressions is supposed to count after the sheet is stacked, so that the sheet counter doesn't know whether the back side of the last page (documents with an odd number of pages), was marked or not, so we said that it SHALL count. Howver, for an accounting application, the customers may get pretty unhappy with having to pay for the final side they didn't use, as Angelo points out, when their document has an odd number of pages. URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: So how about RECOMMENDING (but not requiring) that the number of impressions for two-sided printing not include counting both sides of sheets marked on only one side. It may be that the interpreter has to be involved in counting impressions, rather than the sheet counter in the stacker or maybe the implementation only worries about the last sheet and so there is just an internal status bit that says whether a document has an odd number or an even number of sides in order to know whether to count the last sheet as 1 or 2 impressions. I suggest changing the sentence in the definition of impression: If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. to: If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. BTW, the current definition of "impression" in the IPP Model is: 12.2.15 impressions An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. So it seems that the IPP Job Model is in agreement with the following recommendation for the Job Mon MIB: The full definition of the term impressions (as sent yesterday) is for the Job Monitoring MIB: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". I propose to soften that definition to: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has some sheets that only have marks on one side (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of two, even if that sheet makes two passes through the marker. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY OBJECTIONS, I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. Thanks, Tom At 07:18 12/17/1997 PST, Caruso, Angelo wrote: >Tom, > snip... >Your proposed definition of impressions is great except for the sentence >"If a two-sided document has an odd number of pages, the last sheet >still counts as two impressions, if that sheet makes two passes through >the marker or the marker marks on both sides of a sheet in a single >pass." I disagree with this. Why should the odd side count as an >impression if it is not marked? And which impressions counters would you >increment for the unmarked odd side? Some engine architectures require >that the sheet pass through the marker twice even though the sheet only >gets marked on one side. This seems like a rather arbitrary and unfair >policy, especially from the customer's point of view. With this policy, >if I printed 100 copies of a 5 page duplex document, I would pay for 600 >impressions even though I only made 500 impressions. > >Thanks, >Angelo > > > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Tuesday, December 16, 1997 5:37 PM > To: jmp@pwg.org; Caruso, Angelo > Cc: XCMI Editors only > Subject: URGENT: Ambiguity in >impressions|fullColor|highlighColorComppleteddefns > > Angelo, > > You've come up with a third interpretation of the >impressionsCompleted, > fullColorImpressionsCompleted and >highlightColorImpressionsCompleted! > > > I'm proposing the interpretation based on our discussion at the > Dec 5 JMP meeting (which you did not have the benefit of >attending). > > > PEOPLE, > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU >OBJECT TO > MY CLARIFICATIONS. > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS >AGREEMENT. > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK >AS WE > AGREED AT THE JMP MEETING. > > First, here is the definition of the term "impression" that we > came up with at the meeting (please review the text too, since >it was only > the ideas that we agreed to at the meeting): > > Impression: For a print job, an impression is the passage of >the entire > side of a sheet by the marker, whether or not any marks are made >and > independent of the number of passes that the side makes past the >marker. > Thus a four pass color process counts as a single impression. >One-sided > processing involves one impression per sheet. Two-sided >processing > involves two impressions per sheet. If a two-sided document has >an odd > number of pages, the last sheet still counts as two impressions, >if that > sheet makes two passes through the marker or the marker marks on >both sides > of a sheet in a single pass. Two-up printing is the placement >of two > logical pages on one side of a sheet and so is still a single >impression. > See "page" and "sheet". > > The three interpretations of these three attributes are: > > 1. Does impressionsCompleted increment or not when a highlight >or full color > impression is made? The current above definition of impressions >suggests > that it does, since an impressions is the passing of one side of >the > media past the marker whether color or not. > > 2. Does the fullColorImpressionsCompleted count once for each >side of > a full color impression or once for each color pass past the >side of > a medium? > > For example, if I had a 16-page document that had 10 black and >white pages, > 5 highlight color pages, and 1 full 4-color page, (number-up=1, >sides=1), > would the counts at the end of my job be: > > highlightColor fullColor > impressionsCompleted ImpressionsCompleted >ImpressionsCompleted > > 1. 16 5 1 > 2. 16 5 20 > 3. 10 5 1 > 4. 10 5 20 > > I suggest that it is interpretation 1 that we are agreeing to >and I'll clarify > the fullColorImpressionsCompleted, by adding the phrase, >"independent > of the number of colors or color passes" to the end of the first > sentence, yielding: > > The number of full color impressions completed by the device for >this job > so far independent of the number of colors or color passes. > > I'll also add the parenthetical remake to the >impressionsCompleted > "(monochome, highlight color, and full color)" to the first >sentence, > since it is clear from the definition of impression that it >includes > all, yielding: > > The total number of impressions (monochome, highlight color, and >full > color) completed for this job so far. > > Ok? > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE >CLARIFICATION. > > Thanks, > Tom > > The current definitions of impressionsCompleted, > highlightColorImpressionsCompleted, and >fullColorImpressionsCompleted are: > > OBJECT-TYPE > SYNTAX Integer32(-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of impressions completed for this job so far. >For > printing devices, the impressions completed includes >interpreting, marking, > and stacking the output. For other types of job services, the >number of > impressions completed includes the number of impressions >processed. > > NOTE - See the impressionsCompletedCurrentCopy and > pagesCompletedCurrentCopy attributes for attributes that are >reset on each > document copy. > > NOTE - The jmJobImpressionsCompleted object can be used with the > jmJobImpressionsPerCopyRequested object to provide an indication >of the > relative progress of the job, provided that the multiplicative >factor is > taken into account for some implementations of multiple copies." > REFERENCE > "See the definition of the term "impression" in Section 2 and >the counting > example in Section 3.4 entitled 'Monitoring Job Progress'." > DEFVAL { 0 } -- default is no octets > ::= { jmJobEntry 8 } > > fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > INTEGER: The number of full color impressions completed by the >device for > this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Full color impressions are typically >defined as > those requiring 3 or more colorants, but this MAY vary by >implementation. > > highlightColorImpressionsCompleted(115), >Integer32(-2..2147483647) > INTEGER: The number of highlight color impressions completed by >the device > for this job so far. For printing, the impressions completed >includes > interpreting, marking, and stacking the output. For other types >of job > services, the number of impressions completed includes the >number of > impressions processed. Highlight color impressions are >typically defined > as those requiring black plus one other colorant, but this MAY >vary by > implementation. > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > >Tom, > > > >There's no ambiguity in my mind. You increment exactly one of >the three > >counters ([monochrome]impressionsCompleted, > >fullColorImpressionsCompleted, or >highlightColorImpressionsCompleted) > >for each SIDE completed. If the side requires 3 or more >colorants to > >produce the impression then it's Full Color, black plus one >other > >colorant would be Highlight color, and a side that uses only >black would > >cause the monochrome counter to increment. To display job >progress to a > >user you need to sum all three of these counters. > > The advantage to saying that impressionsCompleted, counts >black/white, > highlight color, and full color, is that an application only >need to > look at one attribute if it doesn't care about the distinction >of b/w, > highlight and full color. Also the device might not implement > the other two, so it is easier for an application to just look >at the > one attribute if that is all it is interested in. Ok? > > > > >For example, if you produce a duplex sheet with full process >color > >graphics on the front side and black text on the back side, >then you > >would increment fullColorImpressionsCompleted when the front >side was > >completed and [monochrome]impressionsCompleted when the back >was > >complete. Since the descriptions of these attributes were >changed to say > >"For printing, the impressions completed includes interpreting, >marking, > >and stacking the output", then this implies to me that both >counters > >would be incremented simultaneously when this completed duplex >sheet was > >delivered to the output. > > So with my suggested resolution, the >fullColorImpressionsCompleted > would count by 1 and the impressionsCompleted would count by 2 >in > your example. > > > > >Is there something else I'm missing here? > > > >Obviously these objects do not provide detailed colorant use >information > >for each page. To do so would require objects to count the >actual amount > >of each colorant transferred to each side. So as a compromise, >we > >proposed these two new objects (which complement the previously >existing > >[monochrome]impressionsCompleted counter) to provide enough >information > >for an accounting application to bill at different rates for >monochrome, > >highlight color, and full color impressions within a job. > > I think that the accounting program can still bill correctly >with > impressionsCompleted counting highlight and fullColor as well as >monochrome. > It can substract out the monochrome, if it wants to, or build in >the > charge for color to be less that the correct charge for coloer >by the amount > charged for monochrome and avoid subtracting. > > > > >Thanks, > >Angelo > > > >> -----Original Message----- > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > >> Sent: Friday, December 12, 1997 11:26 AM > >> To: Angelo_Caruso@wb.xerox.com > >> Cc: XCMI Editors only > >> Subject: Ambiguity in XCMI & PWG Job Mon: > >> fullColorImpressionsCompleted(1 > >> > >> URGENT: > >> > >> The current definition of fullColorImpressionsCompleted(114) >and > >> highlightColorImpressionsCompleted(115) is: > >> > >> fullColorImpressionsCompleted(114), >Integer32(-2..2147483647) > >> INTEGER: The number of full color impressions completed by >the device > >> for > >> this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Full color impressions are typically >defined as > >> those requiring 3 or more colorants, but this MAY vary by > >> implementation. > >> > >> highlightColorImpressionsCompleted(115), > >> Integer32(-2..2147483647) > >> INTEGER: The number of highlight color impressions completed >by the > >> device > >> for this job so far. For printing, the impressions completed >includes > >> interpreting, marking, and stacking the output. For other >types of > >> job > >> services, the number of impressions completed includes the >number of > >> impressions processed. Highlight color impressions are >typically > >> defined > >> as those requiring black plus one other colorant, but this >MAY vary by > >> implementation. > >> > >> > >> Suppose you have a 4 color process that makes four passes >through the > >> marker > >> for each side, does this attribute count by 1 for each pass >or does > >> it still > >> count just the number of sides? > >> > >> The advantage of counting the number of color passes is that >something > >> > >> counts for each pass which can be shown to a user. Also >accounting > >> may > >> want to charge for each color pass. Conceivably, there might >be a > >> variable > >> number of passes, depending on the colors demanded by each >image? > >> > >> The advantage of only counting once per side, is that you can >then > >> compare > >> the number of impressions for the job with the number of > >> fullColorImpressionsCompleted and determine the percentage of >color > >> impressions in the job. Also this definition seems to be >more in > >> keeping > >> with the > >> concept of "stacking" the media mentioned in the definition. > >> > >> Since Xerox proposed this attribute, what did we have in >mind? > >> > >> Thanks, > >> Tom > > > > > > From ipp-owner@pwg.org Wed Dec 17 19:28:03 1997 Delivery-Date: Wed, 17 Dec 1997 19:28:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA28902 for ; Wed, 17 Dec 1997 19:28:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA13121 for ; Wed, 17 Dec 1997 19:30:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA03032 for ; Wed, 17 Dec 1997 19:28:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 19:20:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00992 for ipp-outgoing; Wed, 17 Dec 1997 18:47:30 -0500 (EST) Date: Wed, 17 Dec 1997 15:10:34 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9712172310.AA15579@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> Re: ADM - Draft minutes [client security issues] Sender: ipp-owner@pwg.org Hi folks, Wednesday (17 December 1997) My comments on security issues are imbedded below. Cheers, - Ira McDonald (outside consultant at Xerox) >----------------------------------------------------------------------< >Date: Mon, 15 Dec 1997 14:35:50 PST >To: ipp@pwg.org >From: Carl-Uno Manros >Subject: IPP> ADM - Draft minutes from the IETF IPP WG Meeting > >Please read the following draft minutes taken by Steve Zilles during the >meeting. If any of the meeting participants have copmments or if any of the >non-attendents need further clarifications, give us those back on the DL ASAP. >snip... > >Minutes IETF IPP WG Meeting, 97/12/10, Washington DC >1-3PM, Executive Meeting Room >snip... > >5. MUST-implement requirements for text and name strings; each string has >a maximum length specification: >some 63 octets, others 127 or 1023 octets > >snip... > >Decision: >Digest authentication is already mandated for all HTTP/1.1 clients >IPP will mandate TLS for all clients > My client s/w colleagues here at Xerox object STRONGLY to being told that the "interoperability" problem belongs to clients, so that they cannot build a simple client (without TLS) for intranet IPP printers and claim conformance. The IETF ADs are just plain WRONG about this one! Security should be a customer purchasing choice, not a "cost of doing business using Internet 'standards track' protocols"! If IPP actually does supplant LPR in the enterprise network (as we all hope) MOST of the printers and clients will be configured WITHOUT security. >snip... > >16. Security >Allow for "non-secure", really "authenticated" servers >If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS >For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows > >Decision: >rename "non-secure" to "authenticated" >rename "secure" to "private and authenticated" (or something similar > Both ISO and IETF security standards have consistently mandated that "data confidentiality" (often shortened to "privacy") may ONLY be supported when BOTH "data integrity" (eg, hash matching) and "data authentication" (eg, certficate exchange) are used concurrently. Therefore, I suggest that we rename "secure" to "private" and clarify that, in any IPP protocol mapping, the IPP term "private" SHALL mean "mutual authentication, data integrity, and data confidentiality". >----------------------------------------------------------------------< From ipp-owner@pwg.org Wed Dec 17 21:33:40 1997 Delivery-Date: Wed, 17 Dec 1997 21:33:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA29475 for ; Wed, 17 Dec 1997 21:33:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA13310 for ; Wed, 17 Dec 1997 21:36:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05116 for ; Wed, 17 Dec 1997 21:33:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 21:25:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03999 for ipp-outgoing; Wed, 17 Dec 1997 21:02:05 -0500 (EST) Date: Wed, 17 Dec 1997 17:59:03 -0800 (Pacific Standard Time) From: Ron Bergman To: scott_isaacson@novell.com cc: ipp@pwg.org Subject: IPP> Editorial corrections for the model doc. Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Scott, I found the following items in version 7. 1. section 4.4.17 - The attribute name "document-format" should be "document-format-default" as is the convention for the other default attributes. 2. also in section 4.4.17, in the second line of the text, "...to assume of..." should be "...to assume if..." 3. section 4.4.18 - "document format-supported" should be "document-format-supported" Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Wed Dec 17 21:33:46 1997 Delivery-Date: Wed, 17 Dec 1997 21:33:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA29480 for ; Wed, 17 Dec 1997 21:33:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA13313 for ; Wed, 17 Dec 1997 21:36:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05132 for ; Wed, 17 Dec 1997 21:33:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 21:24:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03980 for ipp-outgoing; Wed, 17 Dec 1997 20:59:04 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Re: ADM - Draft minutes [client security issues] Date: Wed, 17 Dec 1997 17:55:57 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Originally, Keith Moore had problems with our standard saying that implementing secure and non-secure IPP was developing TWO protocols and would be pushed back from the IESG. We discussed this and agreed that there would be far more differing platforms and implementations for servers than clients; and that realistically, OS vendors will include IPP clients in their operating systems (if IPP is successful). So if a vendor ships a fully functional and secure client, then it would always have an interoperability solution no matter which type of server implementation was contacted. (Realizing that we should also write a "TLS profile for IPP" section in our document). It is my opinion that this is the vast majority of real world cases. If IPP is successful, OS vendors will implement the clients, and code,RAM, and CPU resources will not be that much of an issue on host machines. It is server implementations of IPP that will experience the widest possible deployment scenarios (dedicated, CGI-based, ISAPI-based, on the host, on the printer, split-functionality, etc.). All of the arguments about mandating TLS for ALL IPP implementations came from vendors that would have this code burden for embedded (in the printer firmware) implementations of IPP servers. It is also my opinion that if we attempt to diverge from the consensus we had at the meeting in Washington D.C., we will definitely have a problem getting our spec through the IESG. Randy (Also, Scott Isaacson contacted Paul Moore about this and Paul did not indicate any pushback with this new client requirement). > -----Original Message----- > From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] > Sent: Wednesday, December 17, 1997 3:11 PM > To: ipp@pwg.org > Subject: IPP> Re: ADM - Draft minutes [client security issues] > > Hi folks, Wednesday (17 December > 1997) > > My comments on security issues are imbedded below. > > Cheers, > - Ira McDonald (outside consultant at Xerox) > >--------------------------------------------------------------------- > -< > >Date: Mon, 15 Dec 1997 14:35:50 PST > >To: ipp@pwg.org > >From: Carl-Uno Manros > >Subject: IPP> ADM - Draft minutes from the IETF IPP WG Meeting > > > >Please read the following draft minutes taken by Steve Zilles during > the > >meeting. If any of the meeting participants have copmments or if any > of the > >non-attendents need further clarifications, give us those back on the > DL ASAP. > >snip... > > > >Minutes IETF IPP WG Meeting, 97/12/10, Washington DC > >1-3PM, Executive Meeting Room > >snip... > > > >5. MUST-implement requirements for text and name strings; each > string has > >a maximum length specification: > >some 63 octets, others 127 or 1023 octets > > > >snip... > > > >Decision: > >Digest authentication is already mandated for all HTTP/1.1 clients > >IPP will mandate TLS for all clients > > > > My client s/w colleagues here at Xerox object STRONGLY to being told > that the "interoperability" problem belongs to clients, so that they > cannot build a simple client (without TLS) for intranet IPP printers > and claim conformance. The IETF ADs are just plain WRONG about this > one! Security should be a customer purchasing choice, not a "cost of > doing business using Internet 'standards track' protocols"! If IPP > actually does supplant LPR in the enterprise network (as we all hope) > MOST of the printers and clients will be configured WITHOUT security. > > >snip... > > > >16. Security > >Allow for "non-secure", really "authenticated" servers > >If Privacy and/or Mutual Authentication is implemented, then it Shall > be TLS > >For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows > > > >Decision: > >rename "non-secure" to "authenticated" > >rename "secure" to "private and authenticated" (or something similar > > > > Both ISO and IETF security standards have consistently mandated that > "data confidentiality" (often shortened to "privacy") may ONLY be > supported when BOTH "data integrity" (eg, hash matching) and "data > authentication" (eg, certficate exchange) are used concurrently. > > Therefore, I suggest that we rename "secure" to "private" and clarify > that, in any IPP protocol mapping, the IPP term "private" SHALL mean > "mutual authentication, data integrity, and data confidentiality". > >--------------------------------------------------------------------- > -< From jmp-owner@pwg.org Thu Dec 18 00:02:53 1997 Delivery-Date: Thu, 18 Dec 1997 00:02:53 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA06899 for ; Thu, 18 Dec 1997 00:02:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA13529 for ; Thu, 18 Dec 1997 00:05:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA05681 for ; Thu, 18 Dec 1997 00:02:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Dec 1997 23:57:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05474 for jmp-outgoing; Wed, 17 Dec 1997 23:53:47 -0500 (EST) Message-ID: <3498AB7D.AB3E721C@underscore.com> Date: Wed, 17 Dec 1997 23:50:05 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: jmp@pwg.org, ipp@pwg.org Subject: Re: JMP> URGENT: Should impressions include blank last page back sides or not? References: <3.0.1.32.19971217130348.00fd26d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Sorry, but I must agree with Angelo Caruso with the position that most folks are going to be pretty upset if they are charged for blanks sides of sheets. Can't say that I like that idea at all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Dec 18 00:22:09 1997 Delivery-Date: Thu, 18 Dec 1997 00:22:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA06995 for ; Thu, 18 Dec 1997 00:22:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA13575 for ; Thu, 18 Dec 1997 00:24:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA06585 for ; Thu, 18 Dec 1997 00:22:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 00:10:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05386 for ipp-outgoing; Wed, 17 Dec 1997 23:37:59 -0500 (EST) Message-ID: <3498A8A3.7C567275@underscore.com> Date: Wed, 17 Dec 1997 23:37:55 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Ira Mcdonald x10962 Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] References: <9712172310.AA15579@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I've gotta say that I agree with Ira on the topic of mandatory support for security. Seems a bit extreme to require both ends of a comm session to perform a relatively heavy security dance when the customer does not wish to get involved with the attendant administration. ...jay Ira Mcdonald x10962 wrote: > My client s/w colleagues here at Xerox object STRONGLY to being told > that the "interoperability" problem belongs to clients, so that they > cannot build a simple client (without TLS) for intranet IPP printers > and claim conformance. The IETF ADs are just plain WRONG about this > one! Security should be a customer purchasing choice, not a "cost of > doing business using Internet 'standards track' protocols"! If IPP > actually does supplant LPR in the enterprise network (as we all hope) > MOST of the printers and clients will be configured WITHOUT security. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Dec 18 00:26:20 1997 Delivery-Date: Thu, 18 Dec 1997 00:26:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA07030 for ; Thu, 18 Dec 1997 00:26:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA13588 for ; Thu, 18 Dec 1997 00:29:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA06912 for ; Thu, 18 Dec 1997 00:26:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 00:16:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05405 for ipp-outgoing; Wed, 17 Dec 1997 23:41:33 -0500 (EST) Message-Id: <1.5.4.32.19971218034250.006eb24c@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: Wed, 17 Dec 1997 19:42:50 -0800 To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) (by way of Carl-Uno Manros ) Subject: IPP> Re: ADM - Draft minutes [client security issues] Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Keith and Harald, This is one strong reaction I got back on the DL as result of our attemps to satisfy your security requirements in Washington. Do you have any comments? Carl-Uno ---- Hi folks, Wednesday (17 December 1997) My comments on security issues are imbedded below. Cheers, - Ira McDonald (outside consultant at Xerox) >----------------------------------------------------------------------< >Date: Mon, 15 Dec 1997 14:35:50 PST >To: ipp@pwg.org >From: Carl-Uno Manros >Subject: IPP> ADM - Draft minutes from the IETF IPP WG Meeting > >Please read the following draft minutes taken by Steve Zilles during the >meeting. If any of the meeting participants have copmments or if any of the >non-attendents need further clarifications, give us those back on the DL ASAP. >snip... > >Minutes IETF IPP WG Meeting, 97/12/10, Washington DC >1-3PM, Executive Meeting Room >snip... > >5. MUST-implement requirements for text and name strings; each string has >a maximum length specification: >some 63 octets, others 127 or 1023 octets > >snip... > >Decision: >Digest authentication is already mandated for all HTTP/1.1 clients >IPP will mandate TLS for all clients > My client s/w colleagues here at Xerox object STRONGLY to being told that the "interoperability" problem belongs to clients, so that they cannot build a simple client (without TLS) for intranet IPP printers and claim conformance. The IETF ADs are just plain WRONG about this one! Security should be a customer purchasing choice, not a "cost of doing business using Internet 'standards track' protocols"! If IPP actually does supplant LPR in the enterprise network (as we all hope) MOST of the printers and clients will be configured WITHOUT security. >snip... > >16. Security >Allow for "non-secure", really "authenticated" servers >If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS >For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows > >Decision: >rename "non-secure" to "authenticated" >rename "secure" to "private and authenticated" (or something similar > Both ISO and IETF security standards have consistently mandated that "data confidentiality" (often shortened to "privacy") may ONLY be supported when BOTH "data integrity" (eg, hash matching) and "data authentication" (eg, certficate exchange) are used concurrently. Therefore, I suggest that we rename "secure" to "private" and clarify that, in any IPP protocol mapping, the IPP term "private" SHALL mean "mutual authentication, data integrity, and data confidentiality". >----------------------------------------------------------------------< From ipp-owner@pwg.org Thu Dec 18 00:32:16 1997 Delivery-Date: Thu, 18 Dec 1997 00:32:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA07053 for ; Thu, 18 Dec 1997 00:32:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA13612 for ; Thu, 18 Dec 1997 00:35:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA07534 for ; Thu, 18 Dec 1997 00:32:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 00:28:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05482 for ipp-outgoing; Wed, 17 Dec 1997 23:54:04 -0500 (EST) Message-ID: <3498AB7D.AB3E721C@underscore.com> Date: Wed, 17 Dec 1997 23:50:05 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: jmp@pwg.org, ipp@pwg.org Subject: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? References: <3.0.1.32.19971217130348.00fd26d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Sorry, but I must agree with Angelo Caruso with the position that most folks are going to be pretty upset if they are charged for blanks sides of sheets. Can't say that I like that idea at all. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Dec 18 01:28:16 1997 Delivery-Date: Thu, 18 Dec 1997 01:28:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA07300 for ; Thu, 18 Dec 1997 01:28:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA13663 for ; Thu, 18 Dec 1997 01:31:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA08474 for ; Thu, 18 Dec 1997 01:28:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 01:23:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA07771 for ipp-outgoing; Thu, 18 Dec 1997 01:09:17 -0500 (EST) Message-ID: <3498BBC8.4EFC54AC@sharplabs.com> Date: Wed, 17 Dec 1997 21:59:36 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Herriot CC: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP>MOD Action Item from LA: fix requesting-user-name explana tion References: <199712172256.OAA24502@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org See my comments below... Randy Robert Herriot wrote: > > The real issue here is that the protocol provides two channels for > authentication information: > a) in application/ipp layer as requesting-user-name attribute > b) in the transport layer via some unspecified authentication mechanism There is actually a (c) scenario: c) where the authentication information comes from TLS. > > I think we agree that if b) above provides no authentication information, then > the user name comes from a). If neither channel provides a user name, then > the user is "guest" or something similar. Yes, I think we agree on this point, except I would extend it to say that, if (b) or (c) is not available for authentication, and no requesting-user-name is specified, then this is a request for "anonymous" access to the resource. if (b) or (c) is not available for authentication, but a requesting-user-name is specified, then the server is free to use the requesting-user-name for authentication. if (c) is not available, but (b) provides authentication info, then use the transport-specific auth info provided by (b). The tricky part comes when both (b) and (c) provide authentication information. In this case, which authentication information takes precedence? In order to avoid a potential rathole with regards to multiple layers of security, I would like to state in the model document that if TLS is used for the session, and the TLS handshake provided auth info, that the TLS auth info always take precedence. At least with text like this we can guarantee (in the model document) interoperability between two implementations that wish to use authentication. Randy ..snip.. From ipp-owner@pwg.org Thu Dec 18 02:07:53 1997 Delivery-Date: Thu, 18 Dec 1997 02:08:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA07474 for ; Thu, 18 Dec 1997 02:07:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA13710 for ; Thu, 18 Dec 1997 02:10:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA09172 for ; Thu, 18 Dec 1997 02:07:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 02:02:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA08576 for ipp-outgoing; Thu, 18 Dec 1997 01:48:12 -0500 (EST) Message-Id: <3.0.1.32.19971217224354.00b913e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 17 Dec 1997 22:43:54 PST To: "Zehler,Peter" , "IPP Discussion List (E-mail)" From: Tom Hastings Subject: Re: IPP> TES - January meeting In-Reply-To: <97Dec17.045553pst."52860(2)"@alpha.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 04:59 12/17/1997 PST, Zehler,Peter wrote: >All, > There has been a request to hold an implementers/testing meeting on >Thursday during the January PWG meeting. I would like to gauge the >interest in such a meeting. There are a few alternatives. > 1) implementers/testing meeting on Thursday > 2) informal implementers/testing dinner Wednesday night > 3) TES item on IPP agenda to discuss how to get TES moving I suggest 1 and 3. Only do 2, if not do 1. Tom >I am looking for input from the IPP group on which alternative(s) should >be pursued. Any other ideas are also welcome. > >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 >__________________________________ > > > From ipp-owner@pwg.org Thu Dec 18 07:26:01 1997 Delivery-Date: Thu, 18 Dec 1997 07:26:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA08654 for ; Thu, 18 Dec 1997 07:26:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA14109 for ; Thu, 18 Dec 1997 07:28:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA10622 for ; Thu, 18 Dec 1997 07:25:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 07:14:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA09489 for ipp-outgoing; Thu, 18 Dec 1997 06:50:12 -0500 (EST) Message-Id: <1.5.4.32.19971218104841.006ee460@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, 18 Dec 1997 02:48:41 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Sender: ipp-owner@pwg.org At 11:37 PM 12/17/97 -0500, you wrote: >I've gotta say that I agree with Ira on the topic of mandatory >support for security. Seems a bit extreme to require both ends >of a comm session to perform a relatively heavy security dance >when the customer does not wish to get involved with the >attendant administration. > > ...jay > >Ira Mcdonald x10962 wrote: > >> My client s/w colleagues here at Xerox object STRONGLY to being told >> that the "interoperability" problem belongs to clients, so that they >> cannot build a simple client (without TLS) for intranet IPP printers >> and claim conformance. The IETF ADs are just plain WRONG about this >> one! Security should be a customer purchasing choice, not a "cost of >> doing business using Internet 'standards track' protocols"! If IPP >> actually does supplant LPR in the enterprise network (as we all hope) >> MOST of the printers and clients will be configured WITHOUT security. I will do my best to respond as we have not yet heard from any of the Area Directors: Jay's assumption that both clients and servers have to support everything is false, only the clients have to support both servers that use "HTTP security" and "TLS security". This was the compromise from Washington DC. The reason why the IETF is so stringent about security features is that they are designing solutions for the INTERNET, they do not care about INTRANETS. Part of the problem is that the press takes every opportunity to criticize the "Internet" for its lack of security, which is threatening the overall reputation of the whole Internet concept and has forced the IETF to take somewhat extreme measures in response. If, like Ira states, implementors react against some of the security language in an IETF document, then they will implement an "almost conforming" version without the security features they do not like. In the end, the market decides what products you can sell at what price. My assumption though is that customers will buy the "secure" versions, even if they cost a bit more, as soon as the recently standardized IETF security features become more generally available as products (which might take a couple of years). So I think that we are debating a timing problem rather than a technical problem. Carl-Uno From ipp-owner@pwg.org Thu Dec 18 07:26:03 1997 Delivery-Date: Thu, 18 Dec 1997 07:26:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA08659 for ; Thu, 18 Dec 1997 07:26:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA14113 for ; Thu, 18 Dec 1997 07:28:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA10625 for ; Thu, 18 Dec 1997 07:25:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 07:17:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA09504 for ipp-outgoing; Thu, 18 Dec 1997 06:54:05 -0500 (EST) From: Harald.T.Alvestrand@uninett.no To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) (by way of Carl-Uno Manros ) cc: moore@cs.utk.edu, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Wed, 17 Dec 1997 19:42:50 PST." <1.5.4.32.19971218034250.006eb24c@pop3.holonet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19671.882440695.1@dale.uninett.no> Date: Thu, 18 Dec 1997 11:24:55 +0100 Message-ID: <19673.882440695@dale.uninett.no> Sender: ipp-owner@pwg.org Thanks - will go back to WG list and reply. Harald A From ipp-owner@pwg.org Thu Dec 18 10:04:58 1997 Delivery-Date: Thu, 18 Dec 1997 10:04:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA10351 for ; Thu, 18 Dec 1997 10:04:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA14629 for ; Thu, 18 Dec 1997 10:07:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA11509 for ; Thu, 18 Dec 1997 10:04:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 09:59:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA10949 for ipp-outgoing; Thu, 18 Dec 1997 09:46:27 -0500 (EST) Message-Id: <199712181444.JAA13721@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) (by way of Carl-Uno Manros ) cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Wed, 17 Dec 1997 19:42:50 PST." <1.5.4.32.19971218034250.006eb24c@pop3.holonet.net> Date: Thu, 18 Dec 1997 09:44:22 -0500 Sender: ipp-owner@pwg.org > The IETF ADs are just plain WRONG about this > one! Security should be a customer purchasing choice, not a "cost of > doing business using Internet 'standards track' protocols"! If IPP > actually does supplant LPR in the enterprise network (as we all hope) > MOST of the printers and clients will be configured WITHOUT security. We respectfully disagree. Internet standards specify requirements for interoperability over the entire Internet, not just in an enterprise network. Many enterprise networks also need security. Be assured that the requirement for strong, mandatory, interoperable authentication will not be changed. > Both ISO and IETF security standards have consistently mandated that > "data confidentiality" (often shortened to "privacy") may ONLY be > supported when BOTH "data integrity" (eg, hash matching) and "data > authentication" (eg, certficate exchange) are used concurrently. > > Therefore, I suggest that we rename "secure" to "private" and clarify > that, in any IPP protocol mapping, the IPP term "private" SHALL mean > "mutual authentication, data integrity, and data confidentiality". this is fine w/me. Keith From jmp-owner@pwg.org Thu Dec 18 11:52:22 1997 Delivery-Date: Thu, 18 Dec 1997 11:52:23 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11543 for ; Thu, 18 Dec 1997 11:52:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15212 for ; Thu, 18 Dec 1997 11:55:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA11936 for ; Thu, 18 Dec 1997 11:52:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 11:48:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11741 for jmp-outgoing; Thu, 18 Dec 1997 11:46:49 -0500 (EST) Message-ID: From: "Wagner, William" Cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p age back sides or not? Date: Thu, 18 Dec 1997 11:44:14 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: jmp-owner@pwg.org This was discussed in great detail at the LA meeting. If one agrees that the MIB is to provide information on what the printer does, which may not necessarily agree with what the rate structures may or may not be at a particular place at a particular time, then I think the contention that sending a sheet side through transfer and fixing steps constitutes making an impression. The question of how much colorant is put on that page is a separate one. If it is a single period, a fully colored page or a blank page, colorant use is a different characteristic from impression, and one which could be instrumented. In most page printers, the information that a page has no marking is not readily available. The page goes though the same processes, takes pretty much the same time and the same wear and tear on the mechanism. I suggest that, unless the printer has a way of separately ejecting such sheet sides, from a printer point of view, treating a blank side differently is an artificial distinction. The point may be moot. I am told that commercial duplication houses charge by the sheet, with perhaps a different sheet rate for duplex (but no distinction for blank sides). A large in-house reports person told me that there are no blank pages; there is a header or footer, a page number, or a "This page intentionally left blank" message. I suggest that a measure of importance from those actually concerned with the accounting be obtained before the MIB imposes the derivation of another parameter on the printer. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Wednesday, December 17, 1997 11:50 PM > To: Tom Hastings > Cc: jmp@pwg.org; ipp@pwg.org > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > last page back sides or not? > > Sorry, but I must agree with Angelo Caruso with the position > that most folks are going to be pretty upset if they are > charged for blanks sides of sheets. Can't say that I like > that idea at all. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From jmp-owner@pwg.org Thu Dec 18 12:00:23 1997 Delivery-Date: Thu, 18 Dec 1997 12:00:23 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA11670 for ; Thu, 18 Dec 1997 12:00:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15246 for ; Thu, 18 Dec 1997 12:03:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA12150 for ; Thu, 18 Dec 1997 12:00:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 11:56:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11961 for jmp-outgoing; Thu, 18 Dec 1997 11:53:22 -0500 (EST) Message-ID: From: "Wagner, William" To: jmp@pwg.org Cc: ipp@pwg.org Subject: JMP> RE: IPP> URGENT: Should impressions include blank last page back sides or not? Date: Thu, 18 Dec 1997 11:50:43 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org Tom, I suggest that making it optional (should) is undesirable since it merely adds to the confusion. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Wednesday, December 17, 1997 4:04 PM > To: jmp@pwg.org > Cc: ipp@pwg.org; szilles@Adobe.COM > Subject: IPP> URGENT: Should impressions include blank last page > back sides or not? > > At the JMP meeting on 12/5, we agreed that the definitions of > impressions would count the number of times a media side goes past > the marker, even if there are no marks made. > > I think we agreed to that, becasue impressions is supposed to count > after the sheet is stacked, so that the sheet counter doesn't know > whether > the back side of the last page (documents with an odd number of > pages), > was marked or not, so we said that it SHALL count. > > Howver, for an accounting application, the customers may get pretty > unhappy with having to pay for the final side they didn't use, as > Angelo points out, when their document has an odd number of pages. > > URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. > HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: > > So how about RECOMMENDING (but not requiring) that the number of > impressions > for two-sided printing not include counting both sides of sheets > marked on > only one side. It may be that the interpreter has to be involved in > counting impressions, rather than the sheet counter in the stacker or > maybe > the implementation only worries about the last sheet and so there is > just > an internal status bit that says whether a document has an odd number > or an > even number of sides in order to know whether to count the last sheet > as 1 > or 2 impressions. > > I suggest changing the sentence in the definition of impression: > > If a two-sided document has an odd number of pages, the last sheet > still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > > > to: > > If a two-sided document has some sheets that only have marks on one > side > (such as on the last sheet of a document with an odd-number of > impressions), those sheets SHOULD count as one impression, instead of > two, > even if that sheet makes two passes through the marker. > > BTW, the current definition of "impression" in the IPP Model is: > > 12.2.15 impressions > > An "impression" is the image (possibly many print-stream pages in > different > configurations) imposed onto a single media page. > > So it seems that the IPP Job Model is in agreement with the following > recommendation for the Job Mon MIB: > > > The full definition of the term impressions (as sent yesterday) is > for the Job Monitoring MIB: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an > odd > number of pages, the last sheet still counts as two impressions, if > that > sheet makes two passes through the marker or the marker marks on both > sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single > impression. > See "page" and "sheet". > > > I propose to soften that definition to: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has some > sheets that only have marks on one side (such as on the last sheet of > a > document with an odd-number of impressions), those sheets SHOULD count > as > one impression, instead of two, even if that sheet makes two passes > through > the marker. Two-up printing is the placement of two logical pages on > one > side of a sheet and so is still a single impression. See "page" and > "sheet". > > > PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY > OBJECTIONS, > I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. > > Thanks, > Tom > > > > At 07:18 12/17/1997 PST, Caruso, Angelo wrote: > >Tom, > > > snip... > > >Your proposed definition of impressions is great except for the > sentence > >"If a two-sided document has an odd number of pages, the last sheet > >still counts as two impressions, if that sheet makes two passes > through > >the marker or the marker marks on both sides of a sheet in a single > >pass." I disagree with this. Why should the odd side count as an > >impression if it is not marked? And which impressions counters would > you > >increment for the unmarked odd side? Some engine architectures > require > >that the sheet pass through the marker twice even though the sheet > only > >gets marked on one side. This seems like a rather arbitrary and > unfair > >policy, especially from the customer's point of view. With this > policy, > >if I printed 100 copies of a 5 page duplex document, I would pay for > 600 > >impressions even though I only made 500 impressions. > > > >Thanks, > >Angelo > > > > > > > > -----Original Message----- > > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > Sent: Tuesday, December 16, 1997 5:37 PM > > To: jmp@pwg.org; Caruso, Angelo > > Cc: XCMI Editors only > > Subject: URGENT: Ambiguity in > >impressions|fullColor|highlighColorComppleteddefns > > > > Angelo, > > > > You've come up with a third interpretation of the > >impressionsCompleted, > > fullColorImpressionsCompleted and > >highlightColorImpressionsCompleted! > > > > > > I'm proposing the interpretation based on our discussion at the > > Dec 5 JMP meeting (which you did not have the benefit of > >attending). > > > > > > PEOPLE, > > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU > >OBJECT TO > > MY CLARIFICATIONS. > > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS > >AGREEMENT. > > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK > >AS WE > > AGREED AT THE JMP MEETING. > > > > First, here is the definition of the term "impression" that we > > came up with at the meeting (please review the text too, since > >it was only > > the ideas that we agreed to at the meeting): > > > > Impression: For a print job, an impression is the passage of > >the entire > > side of a sheet by the marker, whether or not any marks are made > >and > > independent of the number of passes that the side makes past the > >marker. > > Thus a four pass color process counts as a single impression. > >One-sided > > processing involves one impression per sheet. Two-sided > >processing > > involves two impressions per sheet. If a two-sided document has > >an odd > > number of pages, the last sheet still counts as two impressions, > >if that > > sheet makes two passes through the marker or the marker marks on > >both sides > > of a sheet in a single pass. Two-up printing is the placement > >of two > > logical pages on one side of a sheet and so is still a single > >impression. > > See "page" and "sheet". > > > > The three interpretations of these three attributes are: > > > > 1. Does impressionsCompleted increment or not when a highlight > >or full color > > impression is made? The current above definition of impressions > >suggests > > that it does, since an impressions is the passing of one side of > >the > > media past the marker whether color or not. > > > > 2. Does the fullColorImpressionsCompleted count once for each > >side of > > a full color impression or once for each color pass past the > >side of > > a medium? > > > > For example, if I had a 16-page document that had 10 black and > >white pages, > > 5 highlight color pages, and 1 full 4-color page, (number-up=1, > >sides=1), > > would the counts at the end of my job be: > > > > highlightColor fullColor > > impressionsCompleted ImpressionsCompleted > >ImpressionsCompleted > > > > 1. 16 5 1 > > 2. 16 5 20 > > 3. 10 5 1 > > 4. 10 5 20 > > > > I suggest that it is interpretation 1 that we are agreeing to > >and I'll clarify > > the fullColorImpressionsCompleted, by adding the phrase, > >"independent > > of the number of colors or color passes" to the end of the first > > sentence, yielding: > > > > The number of full color impressions completed by the device for > >this job > > so far independent of the number of colors or color passes. > > > > I'll also add the parenthetical remake to the > >impressionsCompleted > > "(monochome, highlight color, and full color)" to the first > >sentence, > > since it is clear from the definition of impression that it > >includes > > all, yielding: > > > > The total number of impressions (monochome, highlight color, and > >full > > color) completed for this job so far. > > > > Ok? > > > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE > >CLARIFICATION. > > > > Thanks, > > Tom > > > > The current definitions of impressionsCompleted, > > highlightColorImpressionsCompleted, and > >fullColorImpressionsCompleted are: > > > > OBJECT-TYPE > > SYNTAX Integer32(-2..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The total number of impressions completed for this job so far. > >For > > printing devices, the impressions completed includes > >interpreting, marking, > > and stacking the output. For other types of job services, the > >number of > > impressions completed includes the number of impressions > >processed. > > > > NOTE - See the impressionsCompletedCurrentCopy and > > pagesCompletedCurrentCopy attributes for attributes that are > >reset on each > > document copy. > > > > NOTE - The jmJobImpressionsCompleted object can be used with the > > jmJobImpressionsPerCopyRequested object to provide an indication > >of the > > relative progress of the job, provided that the multiplicative > >factor is > > taken into account for some implementations of multiple copies." > > REFERENCE > > "See the definition of the term "impression" in Section 2 and > >the counting > > example in Section 3.4 entitled 'Monitoring Job Progress'." > > DEFVAL { 0 } -- default is no octets > > ::= { jmJobEntry 8 } > > > > fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > INTEGER: The number of full color impressions completed by the > >device for > > this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Full color impressions are typically > >defined as > > those requiring 3 or more colorants, but this MAY vary by > >implementation. > > > > highlightColorImpressionsCompleted(115), > >Integer32(-2..2147483647) > > INTEGER: The number of highlight color impressions completed by > >the device > > for this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Highlight color impressions are > >typically defined > > as those requiring black plus one other colorant, but this MAY > >vary by > > implementation. > > > > > > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > > >Tom, > > > > > >There's no ambiguity in my mind. You increment exactly one of > >the three > > >counters ([monochrome]impressionsCompleted, > > >fullColorImpressionsCompleted, or > >highlightColorImpressionsCompleted) > > >for each SIDE completed. If the side requires 3 or more > >colorants to > > >produce the impression then it's Full Color, black plus one > >other > > >colorant would be Highlight color, and a side that uses only > >black would > > >cause the monochrome counter to increment. To display job > >progress to a > > >user you need to sum all three of these counters. > > > > The advantage to saying that impressionsCompleted, counts > >black/white, > > highlight color, and full color, is that an application only > >need to > > look at one attribute if it doesn't care about the distinction > >of b/w, > > highlight and full color. Also the device might not implement > > the other two, so it is easier for an application to just look > >at the > > one attribute if that is all it is interested in. Ok? > > > > > > > >For example, if you produce a duplex sheet with full process > >color > > >graphics on the front side and black text on the back side, > >then you > > >would increment fullColorImpressionsCompleted when the front > >side was > > >completed and [monochrome]impressionsCompleted when the back > >was > > >complete. Since the descriptions of these attributes were > >changed to say > > >"For printing, the impressions completed includes interpreting, > >marking, > > >and stacking the output", then this implies to me that both > >counters > > >would be incremented simultaneously when this completed duplex > >sheet was > > >delivered to the output. > > > > So with my suggested resolution, the > >fullColorImpressionsCompleted > > would count by 1 and the impressionsCompleted would count by 2 > >in > > your example. > > > > > > > >Is there something else I'm missing here? > > > > > >Obviously these objects do not provide detailed colorant use > >information > > >for each page. To do so would require objects to count the > >actual amount > > >of each colorant transferred to each side. So as a compromise, > >we > > >proposed these two new objects (which complement the previously > >existing > > >[monochrome]impressionsCompleted counter) to provide enough > >information > > >for an accounting application to bill at different rates for > >monochrome, > > >highlight color, and full color impressions within a job. > > > > I think that the accounting program can still bill correctly > >with > > impressionsCompleted counting highlight and fullColor as well as > >monochrome. > > It can substract out the monochrome, if it wants to, or build in > >the > > charge for color to be less that the correct charge for coloer > >by the amount > > charged for monochrome and avoid subtracting. > > > > > > > >Thanks, > > >Angelo > > > > > >> -----Original Message----- > > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > >> Sent: Friday, December 12, 1997 11:26 AM > > >> To: Angelo_Caruso@wb.xerox.com > > >> Cc: XCMI Editors only > > >> Subject: Ambiguity in XCMI & PWG Job Mon: > > >> fullColorImpressionsCompleted(1 > > >> > > >> URGENT: > > >> > > >> The current definition of fullColorImpressionsCompleted(114) > >and > > >> highlightColorImpressionsCompleted(115) is: > > >> > > >> fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > >> INTEGER: The number of full color impressions completed by > >the device > > >> for > > >> this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Full color impressions are typically > >defined as > > >> those requiring 3 or more colorants, but this MAY vary by > > >> implementation. > > >> > > >> highlightColorImpressionsCompleted(115), > > >> Integer32(-2..2147483647) > > >> INTEGER: The number of highlight color impressions completed > >by the > > >> device > > >> for this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Highlight color impressions are > >typically > > >> defined > > >> as those requiring black plus one other colorant, but this > >MAY vary by > > >> implementation. > > >> > > >> > > >> Suppose you have a 4 color process that makes four passes > >through the > > >> marker > > >> for each side, does this attribute count by 1 for each pass > >or does > > >> it still > > >> count just the number of sides? > > >> > > >> The advantage of counting the number of color passes is that > >something > > >> > > >> counts for each pass which can be shown to a user. Also > >accounting > > >> may > > >> want to charge for each color pass. Conceivably, there might > >be a > > >> variable > > >> number of passes, depending on the colors demanded by each > >image? > > >> > > >> The advantage of only counting once per side, is that you can > >then > > >> compare > > >> the number of impressions for the job with the number of > > >> fullColorImpressionsCompleted and determine the percentage of > >color > > >> impressions in the job. Also this definition seems to be > >more in > > >> keeping > > >> with the > > >> concept of "stacking" the media mentioned in the definition. > > >> > > >> Since Xerox proposed this attribute, what did we have in > >mind? > > >> > > >> Thanks, > > >> Tom > > > > > > > > > > From ipp-owner@pwg.org Thu Dec 18 12:23:57 1997 Delivery-Date: Thu, 18 Dec 1997 12:23:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA11843 for ; Thu, 18 Dec 1997 12:23:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15350 for ; Thu, 18 Dec 1997 12:26:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA13072 for ; Thu, 18 Dec 1997 12:23:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 12:15:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11733 for ipp-outgoing; Thu, 18 Dec 1997 11:46:43 -0500 (EST) Message-ID: From: "Wagner, William" Cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p age back sides or not? Date: Thu, 18 Dec 1997 11:44:14 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org This was discussed in great detail at the LA meeting. If one agrees that the MIB is to provide information on what the printer does, which may not necessarily agree with what the rate structures may or may not be at a particular place at a particular time, then I think the contention that sending a sheet side through transfer and fixing steps constitutes making an impression. The question of how much colorant is put on that page is a separate one. If it is a single period, a fully colored page or a blank page, colorant use is a different characteristic from impression, and one which could be instrumented. In most page printers, the information that a page has no marking is not readily available. The page goes though the same processes, takes pretty much the same time and the same wear and tear on the mechanism. I suggest that, unless the printer has a way of separately ejecting such sheet sides, from a printer point of view, treating a blank side differently is an artificial distinction. The point may be moot. I am told that commercial duplication houses charge by the sheet, with perhaps a different sheet rate for duplex (but no distinction for blank sides). A large in-house reports person told me that there are no blank pages; there is a header or footer, a page number, or a "This page intentionally left blank" message. I suggest that a measure of importance from those actually concerned with the accounting be obtained before the MIB imposes the derivation of another parameter on the printer. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Wednesday, December 17, 1997 11:50 PM > To: Tom Hastings > Cc: jmp@pwg.org; ipp@pwg.org > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > last page back sides or not? > > Sorry, but I must agree with Angelo Caruso with the position > that most folks are going to be pretty upset if they are > charged for blanks sides of sheets. Can't say that I like > that idea at all. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Dec 18 12:28:46 1997 Delivery-Date: Thu, 18 Dec 1997 12:28:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA11897 for ; Thu, 18 Dec 1997 12:28:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15362 for ; Thu, 18 Dec 1997 12:31:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA13481 for ; Thu, 18 Dec 1997 12:27:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 12:20:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11953 for ipp-outgoing; Thu, 18 Dec 1997 11:53:09 -0500 (EST) Message-ID: From: "Wagner, William" To: jmp@pwg.org Cc: ipp@pwg.org Subject: RE: IPP> URGENT: Should impressions include blank last page back sides or not? Date: Thu, 18 Dec 1997 11:50:43 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Tom, I suggest that making it optional (should) is undesirable since it merely adds to the confusion. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Wednesday, December 17, 1997 4:04 PM > To: jmp@pwg.org > Cc: ipp@pwg.org; szilles@Adobe.COM > Subject: IPP> URGENT: Should impressions include blank last page > back sides or not? > > At the JMP meeting on 12/5, we agreed that the definitions of > impressions would count the number of times a media side goes past > the marker, even if there are no marks made. > > I think we agreed to that, becasue impressions is supposed to count > after the sheet is stacked, so that the sheet counter doesn't know > whether > the back side of the last page (documents with an odd number of > pages), > was marked or not, so we said that it SHALL count. > > Howver, for an accounting application, the customers may get pretty > unhappy with having to pay for the final side they didn't use, as > Angelo points out, when their document has an odd number of pages. > > URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. > HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: > > So how about RECOMMENDING (but not requiring) that the number of > impressions > for two-sided printing not include counting both sides of sheets > marked on > only one side. It may be that the interpreter has to be involved in > counting impressions, rather than the sheet counter in the stacker or > maybe > the implementation only worries about the last sheet and so there is > just > an internal status bit that says whether a document has an odd number > or an > even number of sides in order to know whether to count the last sheet > as 1 > or 2 impressions. > > I suggest changing the sentence in the definition of impression: > > If a two-sided document has an odd number of pages, the last sheet > still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > > > to: > > If a two-sided document has some sheets that only have marks on one > side > (such as on the last sheet of a document with an odd-number of > impressions), those sheets SHOULD count as one impression, instead of > two, > even if that sheet makes two passes through the marker. > > BTW, the current definition of "impression" in the IPP Model is: > > 12.2.15 impressions > > An "impression" is the image (possibly many print-stream pages in > different > configurations) imposed onto a single media page. > > So it seems that the IPP Job Model is in agreement with the following > recommendation for the Job Mon MIB: > > > The full definition of the term impressions (as sent yesterday) is > for the Job Monitoring MIB: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an > odd > number of pages, the last sheet still counts as two impressions, if > that > sheet makes two passes through the marker or the marker marks on both > sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single > impression. > See "page" and "sheet". > > > I propose to soften that definition to: > > Impression: For a print job, an impression is the passage of the > entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the > marker. > Thus a four pass color process counts as a single impression. > One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has some > sheets that only have marks on one side (such as on the last sheet of > a > document with an odd-number of impressions), those sheets SHOULD count > as > one impression, instead of two, even if that sheet makes two passes > through > the marker. Two-up printing is the placement of two logical pages on > one > side of a sheet and so is still a single impression. See "page" and > "sheet". > > > PLEASE SEND ANY COMMENTS BY THURSDAY EVENING. NOT HEARING ANY > OBJECTIONS, > I'M GOING WITH THE ABOVE DEFINITION FOR THE JOB MONITORING MIB. > > Thanks, > Tom > > > > At 07:18 12/17/1997 PST, Caruso, Angelo wrote: > >Tom, > > > snip... > > >Your proposed definition of impressions is great except for the > sentence > >"If a two-sided document has an odd number of pages, the last sheet > >still counts as two impressions, if that sheet makes two passes > through > >the marker or the marker marks on both sides of a sheet in a single > >pass." I disagree with this. Why should the odd side count as an > >impression if it is not marked? And which impressions counters would > you > >increment for the unmarked odd side? Some engine architectures > require > >that the sheet pass through the marker twice even though the sheet > only > >gets marked on one side. This seems like a rather arbitrary and > unfair > >policy, especially from the customer's point of view. With this > policy, > >if I printed 100 copies of a 5 page duplex document, I would pay for > 600 > >impressions even though I only made 500 impressions. > > > >Thanks, > >Angelo > > > > > > > > -----Original Message----- > > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > Sent: Tuesday, December 16, 1997 5:37 PM > > To: jmp@pwg.org; Caruso, Angelo > > Cc: XCMI Editors only > > Subject: URGENT: Ambiguity in > >impressions|fullColor|highlighColorComppleteddefns > > > > Angelo, > > > > You've come up with a third interpretation of the > >impressionsCompleted, > > fullColorImpressionsCompleted and > >highlightColorImpressionsCompleted! > > > > > > I'm proposing the interpretation based on our discussion at the > > Dec 5 JMP meeting (which you did not have the benefit of > >attending). > > > > > > PEOPLE, > > PLEASE RESPOND TO THE DL THIS WEEK, THURSDAY, 12/18/98, IF YOU > >OBJECT TO > > MY CLARIFICATIONS. > > AGREEMENT REPLIES WELCOME, BUT SILENCE WILL BE INTERPRETED AS > >AGREEMENT. > > I'M STILL PLAN TO FORWARD THE JOB MON MIB TO THE IESG THIS WEEK > >AS WE > > AGREED AT THE JMP MEETING. > > > > First, here is the definition of the term "impression" that we > > came up with at the meeting (please review the text too, since > >it was only > > the ideas that we agreed to at the meeting): > > > > Impression: For a print job, an impression is the passage of > >the entire > > side of a sheet by the marker, whether or not any marks are made > >and > > independent of the number of passes that the side makes past the > >marker. > > Thus a four pass color process counts as a single impression. > >One-sided > > processing involves one impression per sheet. Two-sided > >processing > > involves two impressions per sheet. If a two-sided document has > >an odd > > number of pages, the last sheet still counts as two impressions, > >if that > > sheet makes two passes through the marker or the marker marks on > >both sides > > of a sheet in a single pass. Two-up printing is the placement > >of two > > logical pages on one side of a sheet and so is still a single > >impression. > > See "page" and "sheet". > > > > The three interpretations of these three attributes are: > > > > 1. Does impressionsCompleted increment or not when a highlight > >or full color > > impression is made? The current above definition of impressions > >suggests > > that it does, since an impressions is the passing of one side of > >the > > media past the marker whether color or not. > > > > 2. Does the fullColorImpressionsCompleted count once for each > >side of > > a full color impression or once for each color pass past the > >side of > > a medium? > > > > For example, if I had a 16-page document that had 10 black and > >white pages, > > 5 highlight color pages, and 1 full 4-color page, (number-up=1, > >sides=1), > > would the counts at the end of my job be: > > > > highlightColor fullColor > > impressionsCompleted ImpressionsCompleted > >ImpressionsCompleted > > > > 1. 16 5 1 > > 2. 16 5 20 > > 3. 10 5 1 > > 4. 10 5 20 > > > > I suggest that it is interpretation 1 that we are agreeing to > >and I'll clarify > > the fullColorImpressionsCompleted, by adding the phrase, > >"independent > > of the number of colors or color passes" to the end of the first > > sentence, yielding: > > > > The number of full color impressions completed by the device for > >this job > > so far independent of the number of colors or color passes. > > > > I'll also add the parenthetical remake to the > >impressionsCompleted > > "(monochome, highlight color, and full color)" to the first > >sentence, > > since it is clear from the definition of impression that it > >includes > > all, yielding: > > > > The total number of impressions (monochome, highlight color, and > >full > > color) completed for this job so far. > > > > Ok? > > > > AGAIN, PLEASSE SEND E-MAIL, IF YOU DISAGREE WITH THESE > >CLARIFICATION. > > > > Thanks, > > Tom > > > > The current definitions of impressionsCompleted, > > highlightColorImpressionsCompleted, and > >fullColorImpressionsCompleted are: > > > > OBJECT-TYPE > > SYNTAX Integer32(-2..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The total number of impressions completed for this job so far. > >For > > printing devices, the impressions completed includes > >interpreting, marking, > > and stacking the output. For other types of job services, the > >number of > > impressions completed includes the number of impressions > >processed. > > > > NOTE - See the impressionsCompletedCurrentCopy and > > pagesCompletedCurrentCopy attributes for attributes that are > >reset on each > > document copy. > > > > NOTE - The jmJobImpressionsCompleted object can be used with the > > jmJobImpressionsPerCopyRequested object to provide an indication > >of the > > relative progress of the job, provided that the multiplicative > >factor is > > taken into account for some implementations of multiple copies." > > REFERENCE > > "See the definition of the term "impression" in Section 2 and > >the counting > > example in Section 3.4 entitled 'Monitoring Job Progress'." > > DEFVAL { 0 } -- default is no octets > > ::= { jmJobEntry 8 } > > > > fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > INTEGER: The number of full color impressions completed by the > >device for > > this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Full color impressions are typically > >defined as > > those requiring 3 or more colorants, but this MAY vary by > >implementation. > > > > highlightColorImpressionsCompleted(115), > >Integer32(-2..2147483647) > > INTEGER: The number of highlight color impressions completed by > >the device > > for this job so far. For printing, the impressions completed > >includes > > interpreting, marking, and stacking the output. For other types > >of job > > services, the number of impressions completed includes the > >number of > > impressions processed. Highlight color impressions are > >typically defined > > as those requiring black plus one other colorant, but this MAY > >vary by > > implementation. > > > > > > > > > > At 12:37 12/12/1997 PST, Caruso, Angelo wrote: > > >Tom, > > > > > >There's no ambiguity in my mind. You increment exactly one of > >the three > > >counters ([monochrome]impressionsCompleted, > > >fullColorImpressionsCompleted, or > >highlightColorImpressionsCompleted) > > >for each SIDE completed. If the side requires 3 or more > >colorants to > > >produce the impression then it's Full Color, black plus one > >other > > >colorant would be Highlight color, and a side that uses only > >black would > > >cause the monochrome counter to increment. To display job > >progress to a > > >user you need to sum all three of these counters. > > > > The advantage to saying that impressionsCompleted, counts > >black/white, > > highlight color, and full color, is that an application only > >need to > > look at one attribute if it doesn't care about the distinction > >of b/w, > > highlight and full color. Also the device might not implement > > the other two, so it is easier for an application to just look > >at the > > one attribute if that is all it is interested in. Ok? > > > > > > > >For example, if you produce a duplex sheet with full process > >color > > >graphics on the front side and black text on the back side, > >then you > > >would increment fullColorImpressionsCompleted when the front > >side was > > >completed and [monochrome]impressionsCompleted when the back > >was > > >complete. Since the descriptions of these attributes were > >changed to say > > >"For printing, the impressions completed includes interpreting, > >marking, > > >and stacking the output", then this implies to me that both > >counters > > >would be incremented simultaneously when this completed duplex > >sheet was > > >delivered to the output. > > > > So with my suggested resolution, the > >fullColorImpressionsCompleted > > would count by 1 and the impressionsCompleted would count by 2 > >in > > your example. > > > > > > > >Is there something else I'm missing here? > > > > > >Obviously these objects do not provide detailed colorant use > >information > > >for each page. To do so would require objects to count the > >actual amount > > >of each colorant transferred to each side. So as a compromise, > >we > > >proposed these two new objects (which complement the previously > >existing > > >[monochrome]impressionsCompleted counter) to provide enough > >information > > >for an accounting application to bill at different rates for > >monochrome, > > >highlight color, and full color impressions within a job. > > > > I think that the accounting program can still bill correctly > >with > > impressionsCompleted counting highlight and fullColor as well as > >monochrome. > > It can substract out the monochrome, if it wants to, or build in > >the > > charge for color to be less that the correct charge for coloer > >by the amount > > charged for monochrome and avoid subtracting. > > > > > > > >Thanks, > > >Angelo > > > > > >> -----Original Message----- > > >> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > > >> Sent: Friday, December 12, 1997 11:26 AM > > >> To: Angelo_Caruso@wb.xerox.com > > >> Cc: XCMI Editors only > > >> Subject: Ambiguity in XCMI & PWG Job Mon: > > >> fullColorImpressionsCompleted(1 > > >> > > >> URGENT: > > >> > > >> The current definition of fullColorImpressionsCompleted(114) > >and > > >> highlightColorImpressionsCompleted(115) is: > > >> > > >> fullColorImpressionsCompleted(114), > >Integer32(-2..2147483647) > > >> INTEGER: The number of full color impressions completed by > >the device > > >> for > > >> this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Full color impressions are typically > >defined as > > >> those requiring 3 or more colorants, but this MAY vary by > > >> implementation. > > >> > > >> highlightColorImpressionsCompleted(115), > > >> Integer32(-2..2147483647) > > >> INTEGER: The number of highlight color impressions completed > >by the > > >> device > > >> for this job so far. For printing, the impressions completed > >includes > > >> interpreting, marking, and stacking the output. For other > >types of > > >> job > > >> services, the number of impressions completed includes the > >number of > > >> impressions processed. Highlight color impressions are > >typically > > >> defined > > >> as those requiring black plus one other colorant, but this > >MAY vary by > > >> implementation. > > >> > > >> > > >> Suppose you have a 4 color process that makes four passes > >through the > > >> marker > > >> for each side, does this attribute count by 1 for each pass > >or does > > >> it still > > >> count just the number of sides? > > >> > > >> The advantage of counting the number of color passes is that > >something > > >> > > >> counts for each pass which can be shown to a user. Also > >accounting > > >> may > > >> want to charge for each color pass. Conceivably, there might > >be a > > >> variable > > >> number of passes, depending on the colors demanded by each > >image? > > >> > > >> The advantage of only counting once per side, is that you can > >then > > >> compare > > >> the number of impressions for the job with the number of > > >> fullColorImpressionsCompleted and determine the percentage of > >color > > >> impressions in the job. Also this definition seems to be > >more in > > >> keeping > > >> with the > > >> concept of "stacking" the media mentioned in the definition. > > >> > > >> Since Xerox proposed this attribute, what did we have in > >mind? > > >> > > >> Thanks, > > >> Tom > > > > > > > > > > From ipp-owner@pwg.org Thu Dec 18 13:29:30 1997 Delivery-Date: Thu, 18 Dec 1997 13:29:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12416 for ; Thu, 18 Dec 1997 13:29:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15586 for ; Thu, 18 Dec 1997 13:32:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA14313 for ; Thu, 18 Dec 1997 13:29:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 13:20:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13697 for ipp-outgoing; Thu, 18 Dec 1997 13:04:02 -0500 (EST) X-Sender: spencerdr@vipmail.earthlink.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Dec 1997 13:03:04 -0500 To: "Wagner, William" From: David R Spencer Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA12416 Bill, I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. Therefore, perhaps the sentence in the definition of impression: > If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. should be: If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. David R. Spencer Spencer & Associates Publishing, Ltd. Three Giffard Way, Melville, NY 11747-2310 david@spencer.com 1-516-367-6655 Fax:1-516-367-2878 http://www.spencer.com ______________________________________________________________________ >This was discussed in great detail at the LA meeting. If one agrees >that the MIB is to provide information on what the printer does, which >may not necessarily agree with what the rate structures may or may not >be at a particular place at a particular time, then I think the >contention that sending a sheet side through transfer and fixing steps >constitutes making an impression. The question of how much colorant is >put on that page is a separate one. If it is a single period, a fully >colored page or a blank page, colorant use is a different characteristic >from impression, and one which could be instrumented. > >In most page printers, the information that a page has no marking is not >readily available. The page goes though the same processes, takes pretty >much the same time and the same wear and tear on the mechanism. I >suggest that, unless the printer has a way of separately ejecting such >sheet sides, from a printer point of view, treating a blank side >differently is an artificial distinction. > >The point may be moot. I am told that commercial duplication houses >charge by the sheet, with perhaps a different sheet rate for duplex (but >no distinction for blank sides). A large in-house reports person told >me that there are no blank pages; there is a header or footer, a page >number, or a "This page intentionally left blank" message. > >I suggest that a measure of importance from those actually concerned >with the accounting be obtained before the MIB imposes the derivation of >another parameter on the printer. > >W. A. Wagner (Bill Wagner) >OSICOM/DPI > >> -----Original Message----- >> From: Jay Martin [SMTP:jkm@underscore.com] >> Sent: Wednesday, December 17, 1997 11:50 PM >> To: Tom Hastings >> Cc: jmp@pwg.org; ipp@pwg.org >> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >> last page back sides or not? >> >> Sorry, but I must agree with Angelo Caruso with the position >> that most folks are going to be pretty upset if they are >> charged for blanks sides of sheets. Can't say that I like >> that idea at all. >> >> ...jay >> >> ---------------------------------------------------------------------- >> -- JK Martin | Email: jkm@underscore.com -- >> -- Underscore, Inc. | Voice: (603) 889-7000 -- >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >> ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Dec 18 13:39:28 1997 Delivery-Date: Thu, 18 Dec 1997 13:39:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12504 for ; Thu, 18 Dec 1997 13:39:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15618 for ; Thu, 18 Dec 1997 13:42:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA14956 for ; Thu, 18 Dec 1997 13:39:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 13:35:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13733 for ipp-outgoing; Thu, 18 Dec 1997 13:14:48 -0500 (EST) Date: Thu, 18 Dec 1997 10:08:14 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: ipp@pwg.org Subject: Re: IPP> MOD - URGENT: Ok to call 2nd printer uri: "printer-map-uri"? In-Reply-To: <3.0.1.32.19971217091500.00cf0dd0@garfield> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Tom, I agree with the other responses that "map" is not a very descriptive (and could be confusing) term. I would vote for "printer-tls-uri" but the first ("printer-secure-uri") is still better than "printer-map-uri" Ron Bergman Dataproducts Corp. On Wed, 17 Dec 1997, Tom Hastings wrote: > In Washington and before, there has been discussion that calling > the second uri, "printer-secure-uri" makes it sound like the first > "printer-uri" is not secure. So we've been searching for a better > term. > > Scott and Steve came up with the term (drum roll): > > "Mutual Authentication and Privacy (MAP). > > So ok to call the second uri Printer attribute: "printer-map-uri"? > > It will be put right after the first uri: "printer-uri" secion > 4.4.2 in the Model document. > > SEND COMMENTS TO DL, SO WE CAN FORWARD THE INTERNET-DRAFT THIS WEEK > TO THE IESG. > > Thanks, > Tom > > From ipp-owner@pwg.org Thu Dec 18 17:56:34 1997 Delivery-Date: Thu, 18 Dec 1997 17:56:35 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA14967 for ; Thu, 18 Dec 1997 17:56:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17060 for ; Thu, 18 Dec 1997 17:59:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16001 for ; Thu, 18 Dec 1997 17:56:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 17:51:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15425 for ipp-outgoing; Thu, 18 Dec 1997 17:37:41 -0500 (EST) Date: Thu, 18 Dec 1997 14:32:19 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712182232.OAA25871@woden.eng.sun.com> To: imcdonal@eso.mc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Cc: Harald.T.Alvestrand@uninett.no, ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From moore@cs.utk.edu Thu Dec 18 07:00:27 1997 > > > The IETF ADs are just plain WRONG about this > > one! Security should be a customer purchasing choice, not a "cost of > > doing business using Internet 'standards track' protocols"! If IPP > > actually does supplant LPR in the enterprise network (as we all hope) > > MOST of the printers and clients will be configured WITHOUT security. > > We respectfully disagree. Internet standards specify requirements > for interoperability over the entire Internet, not just in an > enterprise network. Many enterprise networks also need security. > > Be assured that the requirement for strong, mandatory, interoperable > authentication will not be changed. > Your comments above suggest to me that authentication (of a client) is required and that privacy and mutual authentication are not. So, would it be acceptable for IPP to drop TLS and require that all IPP clients and servers support HTTP/1.1 digest authentication? From ipp-owner@pwg.org Thu Dec 18 18:53:58 1997 Delivery-Date: Thu, 18 Dec 1997 18:53:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA15352 for ; Thu, 18 Dec 1997 18:53:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA17203 for ; Thu, 18 Dec 1997 18:56:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16680 for ; Thu, 18 Dec 1997 18:53:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 18:49:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16123 for ipp-outgoing; Thu, 18 Dec 1997 18:36:06 -0500 (EST) Message-Id: <199712182334.SAA17420@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert.Herriot@eng.sun.com (Robert Herriot) cc: imcdonal@eso.mc.xerox.com, moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Thu, 18 Dec 1997 14:32:19 PST." <199712182232.OAA25871@woden.eng.sun.com> Date: Thu, 18 Dec 1997 18:34:30 -0500 Sender: ipp-owner@pwg.org > Your comments above suggest to me that authentication (of a client) is > required and that privacy and mutual authentication are not. That's pretty much my opinion. Printers have real and significant costs associated with their use, so some kind of authentication is needed. > So, would it be acceptable for IPP to drop TLS and require that all IPP > clients and servers support HTTP/1.1 digest authentication? Not without explaining how this will scale to IPP's anticipated use. The problem is that IPP wants print servers all over the world to be usable from anywhere by any IPP client. Shared secrets don't even scale to medium size workgroups, much less user populations of the size of the Internet. Most printers aren't suitable for providing service to all comers anyway, so it doesn't make sense to require all printers to support scalable authentication. But you clearly want clients to be able to print to any of: local printers, printers in their office/workgroup/ building, and printers in Kinko's and Sir Speedy's and other service providers that will be out there. Wasn't this a primary goal of IPP? So if IPP wants clear direction about what's likely to get past IESG, I'll say that clients MUST support both digest and TLS, and servers MUST support digest and MAY support TLS. The alternative is for IPP to convince IESG that digest authentication alone really is adequate for a wide variety of printer authentication scenarios. I won't claim that it cannot be done, but offhand, I don't see how to do this. Keith From ipp-owner@pwg.org Thu Dec 18 19:52:22 1997 Delivery-Date: Thu, 18 Dec 1997 19:52:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA15644 for ; Thu, 18 Dec 1997 19:52:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA17309 for ; Thu, 18 Dec 1997 19:55:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA17736 for ; Thu, 18 Dec 1997 19:52:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 19:36:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16767 for ipp-outgoing; Thu, 18 Dec 1997 18:58:50 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Keith Moore'" , Robert.Herriot@eng.sun.com Cc: imcdonal@eso.mc.xerox.com, Harald.T.Alvestrand@uninett.no, ipp@pwg.org Subject: RE: IPP> Re: ADM - Draft minutes [client security issues] Date: Thu, 18 Dec 1997 15:56:13 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org The IPP charter says that we will provide both authentication and privacy. In trade magazines talking about internet printing, more users were worried about 3rd parties eavesdropping on the content of the print stream than making sure both ends were authenticated. If you think about it, the server side of IPP wants to make sure that the potential client is authorized to use the resources provided by the IPP service. The client (printing in an open internet arena) on the other hand, would probably not want potentially sensitive information intercepted when sending his/her job over the internet. In other words, now is not the time to be changing the charter. It is a trivial exercise to imagine large scale use of either mechanism for an "internet" printing protocol, IMHO. Randy > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Thursday, December 18, 1997 3:35 PM > To: Robert.Herriot@eng.sun.com > Cc: imcdonal@eso.mc.xerox.com; moore@cs.utk.edu; > Harald.T.Alvestrand@uninett.no; ipp@pwg.org > Subject: Re: IPP> Re: ADM - Draft minutes [client security > issues] > > > Your comments above suggest to me that authentication (of a client) > is > > required and that privacy and mutual authentication are not. > > That's pretty much my opinion. Printers have real and significant > costs associated with their use, so some kind of authentication is > needed. > > > So, would it be acceptable for IPP to drop TLS and require that all > IPP > > clients and servers support HTTP/1.1 digest authentication? > > Not without explaining how this will scale to IPP's anticipated use. > > The problem is that IPP wants print servers all over the world > to be usable from anywhere by any IPP client. Shared secrets > don't even scale to medium size workgroups, much less user > populations of the size of the Internet. > > Most printers aren't suitable for providing service to all comers > anyway, so it doesn't make sense to require all printers to support > scalable authentication. But you clearly want clients to be able > to print to any of: local printers, printers in their > office/workgroup/ > building, and printers in Kinko's and Sir Speedy's and other service > providers that will be out there. Wasn't this a primary goal of IPP? > > So if IPP wants clear direction about what's likely to get past IESG, > I'll say that clients MUST support both digest and TLS, and servers > MUST support digest and MAY support TLS. > > The alternative is for IPP to convince IESG that digest authentication > alone really is adequate for a wide variety of printer authentication > scenarios. I won't claim that it cannot be done, but offhand, I > don't > see how to do this. > > Keith From ipp-owner@pwg.org Thu Dec 18 20:00:20 1997 Delivery-Date: Thu, 18 Dec 1997 20:00:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15688 for ; Thu, 18 Dec 1997 20:00:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA17327 for ; Thu, 18 Dec 1997 20:03:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18514 for ; Thu, 18 Dec 1997 20:00:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 19:46:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16791 for ipp-outgoing; Thu, 18 Dec 1997 19:02:32 -0500 (EST) Date: Thu, 18 Dec 1997 13:31:06 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9712182131.AA16001@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Cc: Harald.T.Alvestrand@uninett.no, ipp@pwg.org Sender: ipp-owner@pwg.org Hi Keith, I agree that the IETF (and particularly you and Harald) should develop new protocol standards with provision for strong security. I just think that the interoperability question is clouding an entirely separate issue, to whit, should customers be forced to pay for security, if they don't want it. Across the public Internet, it is highly desirable (at least) for printing protocols to use strong security (and data confidentiality). Within corporate intranets, the marketplace hasn't shown much interest in paying for strong security. No printer vendor can ignore that reality. Shoving the interoperability problem onto the client end (who, per last weeks IETF discussion now have to always support TLS, in order to be IPP clients) is just pushing the problem around. Why not address the real interoperability between mutually secure clients and servers and SEPARATELY between mutually insecure (or weakly secure with HTTP/1.1 native facilities) clients and servers. Why should it matter that every IPP client implements strong security? But I agree that you should push for a solid security story in IPP. Sorry I was obscure in my previous note. Cheers, - Ira McDonald (outside consultant at Xerox) From ipp-owner@pwg.org Thu Dec 18 20:02:40 1997 Delivery-Date: Thu, 18 Dec 1997 20:02:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15703 for ; Thu, 18 Dec 1997 20:02:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA17331 for ; Thu, 18 Dec 1997 20:05:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18726 for ; Thu, 18 Dec 1997 20:02:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 19:50:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16813 for ipp-outgoing; Thu, 18 Dec 1997 19:06:35 -0500 (EST) Message-Id: <199712190004.TAA17589@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Turner, Randy" cc: "'Keith Moore'" , Robert.Herriot@eng.sun.com, imcdonal@eso.mc.xerox.com, Harald.T.Alvestrand@uninett.no, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Thu, 18 Dec 1997 15:56:13 PST." Date: Thu, 18 Dec 1997 19:04:50 -0500 Sender: ipp-owner@pwg.org > The IPP charter says that we will provide both > authentication and privacy. In trade magazines talking > about internet printing, more users were worried about > 3rd parties eavesdropping on the content of the print > stream than making sure both ends were authenticated. If IPP wants to mandate privacy in addition to authentication, I feel confident that IESG would go along with that. Keith From ipp-owner@pwg.org Thu Dec 18 20:09:07 1997 Delivery-Date: Thu, 18 Dec 1997 20:09:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15724 for ; Thu, 18 Dec 1997 20:09:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA17338 for ; Thu, 18 Dec 1997 20:11:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19339 for ; Thu, 18 Dec 1997 20:09:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 20:04:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16852 for ipp-outgoing; Thu, 18 Dec 1997 19:24:19 -0500 (EST) Message-Id: <199712190022.TAA17652@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Thu, 18 Dec 1997 13:31:06 PST." <9712182131.AA16001@snorkel.eso.mc.xerox.com> Date: Thu, 18 Dec 1997 19:22:32 -0500 Sender: ipp-owner@pwg.org > I agree that the IETF (and particularly you and Harald) should > develop new protocol standards with provision for strong security. > I just think that the interoperability question is clouding an > entirely separate issue, to whit, should customers be forced to > pay for security, if they don't want it. If the marginal cost for scalable security in clients is really that high, there will be a sizable market for cheaper clients that do only digest authentication. If by these clients turn out to be the rule rather than the exception, we can change the standard when it is revised. IETF has a strong tradition of deprecating, eliminating, or making optional unused or under-used features as specifications progress along the standards-track. > Within corporate intranets, the marketplace hasn't shown much > interest in paying for strong security. Yes, but there's a significant difference in the cost of using a technology which is (a) nonstandard, (b) in limited use, and (c) encumbered by patents, than the cost of using a standard technology which will be widely deployed and is not so encumbered. > Shoving the interoperability problem > onto the client end (who, per last weeks IETF discussion now > have to always support TLS, in order to be IPP clients) is just > pushing the problem around. Yes, but "just" pushing the problem around would appear to make the overall solution cheaper. You seem to be arguing that we don't really need interoperable security. Most of the knowledgable users of the Internet, I suspect, would strongly disagree. > Why not address the real interoperability between mutually > secure clients and servers and SEPARATELY between mutually > insecure (or weakly secure with HTTP/1.1 native facilities) > clients and servers. Why should it matter that every IPP > client implements strong security? So that all clients and servers can interoperate. Keith From jmp-owner@pwg.org Thu Dec 18 21:15:09 1997 Delivery-Date: Thu, 18 Dec 1997 21:15:10 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16052 for ; Thu, 18 Dec 1997 21:15:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA17435 for ; Thu, 18 Dec 1997 21:18:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA19959 for ; Thu, 18 Dec 1997 21:15:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 21:12:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19766 for jmp-outgoing; Thu, 18 Dec 1997 21:10:05 -0500 (EST) Date: Thu, 18 Dec 1997 18:03:29 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p age back sides or not? In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jmp-owner@pwg.org Tom, I agree with Bill on this issue, especially that "the point may be moot" Have you asked Kinkos how they charge in this situation? We should stick with the agreement per the LA meeting. Ron Bergman Dataproducts Corp. On Thu, 18 Dec 1997, Wagner, William wrote: > This was discussed in great detail at the LA meeting. If one agrees > that the MIB is to provide information on what the printer does, which > may not necessarily agree with what the rate structures may or may not > be at a particular place at a particular time, then I think the > contention that sending a sheet side through transfer and fixing steps > constitutes making an impression. The question of how much colorant is > put on that page is a separate one. If it is a single period, a fully > colored page or a blank page, colorant use is a different characteristic > from impression, and one which could be instrumented. > > In most page printers, the information that a page has no marking is not > readily available. The page goes though the same processes, takes pretty > much the same time and the same wear and tear on the mechanism. I > suggest that, unless the printer has a way of separately ejecting such > sheet sides, from a printer point of view, treating a blank side > differently is an artificial distinction. > > The point may be moot. I am told that commercial duplication houses > charge by the sheet, with perhaps a different sheet rate for duplex (but > no distinction for blank sides). A large in-house reports person told > me that there are no blank pages; there is a header or footer, a page > number, or a "This page intentionally left blank" message. > > I suggest that a measure of importance from those actually concerned > with the accounting be obtained before the MIB imposes the derivation of > another parameter on the printer. > > W. A. Wagner (Bill Wagner) > OSICOM/DPI > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Wednesday, December 17, 1997 11:50 PM > > To: Tom Hastings > > Cc: jmp@pwg.org; ipp@pwg.org > > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > > last page back sides or not? > > > > Sorry, but I must agree with Angelo Caruso with the position > > that most folks are going to be pretty upset if they are > > charged for blanks sides of sheets. Can't say that I like > > that idea at all. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > From ipp-owner@pwg.org Thu Dec 18 21:35:04 1997 Delivery-Date: Thu, 18 Dec 1997 21:35:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16128 for ; Thu, 18 Dec 1997 21:35:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA17454 for ; Thu, 18 Dec 1997 21:37:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA20560 for ; Thu, 18 Dec 1997 21:34:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 21:26:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19774 for ipp-outgoing; Thu, 18 Dec 1997 21:10:11 -0500 (EST) Date: Thu, 18 Dec 1997 18:03:29 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p age back sides or not? In-Reply-To: Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Tom, I agree with Bill on this issue, especially that "the point may be moot" Have you asked Kinkos how they charge in this situation? We should stick with the agreement per the LA meeting. Ron Bergman Dataproducts Corp. On Thu, 18 Dec 1997, Wagner, William wrote: > This was discussed in great detail at the LA meeting. If one agrees > that the MIB is to provide information on what the printer does, which > may not necessarily agree with what the rate structures may or may not > be at a particular place at a particular time, then I think the > contention that sending a sheet side through transfer and fixing steps > constitutes making an impression. The question of how much colorant is > put on that page is a separate one. If it is a single period, a fully > colored page or a blank page, colorant use is a different characteristic > from impression, and one which could be instrumented. > > In most page printers, the information that a page has no marking is not > readily available. The page goes though the same processes, takes pretty > much the same time and the same wear and tear on the mechanism. I > suggest that, unless the printer has a way of separately ejecting such > sheet sides, from a printer point of view, treating a blank side > differently is an artificial distinction. > > The point may be moot. I am told that commercial duplication houses > charge by the sheet, with perhaps a different sheet rate for duplex (but > no distinction for blank sides). A large in-house reports person told > me that there are no blank pages; there is a header or footer, a page > number, or a "This page intentionally left blank" message. > > I suggest that a measure of importance from those actually concerned > with the accounting be obtained before the MIB imposes the derivation of > another parameter on the printer. > > W. A. Wagner (Bill Wagner) > OSICOM/DPI > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Wednesday, December 17, 1997 11:50 PM > > To: Tom Hastings > > Cc: jmp@pwg.org; ipp@pwg.org > > Subject: IPP> Re: JMP> URGENT: Should impressions include blank > > last page back sides or not? > > > > Sorry, but I must agree with Angelo Caruso with the position > > that most folks are going to be pretty upset if they are > > charged for blanks sides of sheets. Can't say that I like > > that idea at all. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > From ipp-owner@pwg.org Thu Dec 18 21:47:16 1997 Delivery-Date: Thu, 18 Dec 1997 21:47:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16174 for ; Thu, 18 Dec 1997 21:47:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA17464 for ; Thu, 18 Dec 1997 21:50:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA21213 for ; Thu, 18 Dec 1997 21:47:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 21:43:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19989 for ipp-outgoing; Thu, 18 Dec 1997 21:24:39 -0500 (EST) Date: Thu, 18 Dec 1997 18:20:52 -0800 (Pacific Standard Time) From: Ron Bergman To: scott_isaacson@novell.com cc: ipp@pwg.org Subject: IPP> MOD more editorial comments Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Scott, Sorry these are so late. (You may have caught these already.) 1. section 2.4, the first line of the text reads "...Job objects be..." should this read "...Job objects SHALL be.." (or SHOULD, MUST, etc) 2. section 4.4.19 reads "...the printer is currently accepting jobs..." should be "...the printer is currently able to accept jobs..." This is a boolean and false indicates the printer is rejecting jobs. 3. section 5.4, seecond paragraph, third line. The sentence ends with two periods. Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Thu Dec 18 22:31:50 1997 Delivery-Date: Thu, 18 Dec 1997 22:31:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18076 for ; Thu, 18 Dec 1997 22:31:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA17555 for ; Thu, 18 Dec 1997 22:34:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA22113 for ; Thu, 18 Dec 1997 22:31:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 22:27:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA21321 for ipp-outgoing; Thu, 18 Dec 1997 22:11:51 -0500 (EST) Message-Id: <3.0.1.32.19971218190747.01460680@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Dec 1997 19:07:47 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Proposed text for IPP Security Application Profile for TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Here is the proposed text for the Security Application Profile for TLS to be added to the Security Considerations section of the IPP Model worked out by Randy Turner, Bob Herriot, Xavier Riley, Carl-Uno Manros, Ira McDonald, John Wenn, and Tom Hastings. Please send any comments immediately as Scott is editing this into the Model document. 8.8 IPP Security Application Profile for TLS The IPP application profile for TLS follows the standard "Mandatory Cipher Suites" requirement as documented in the TLS specification [TLS]. Client implementations MUST NOT assume any other cipher suites are supported by an IPP Printer object. A conforming IPP client MUST implement and support the "Mandatory Cipher Suites" as specified in the TLS specification and MAY support additional cipher suites. If a conforming IPP Printer object supports TLS, it MUST implement and support the "Mandatory Cipher Suites" as specified in the TLS specification and MAY support additional cipher suites. It is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to interoperate with such non- compliant versions MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is completely secure from eavesdropping. From jmp-owner@pwg.org Thu Dec 18 22:40:59 1997 Delivery-Date: Thu, 18 Dec 1997 22:40:59 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA18116 for ; Thu, 18 Dec 1997 22:40:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA17568 for ; Thu, 18 Dec 1997 22:43:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA22393 for ; Thu, 18 Dec 1997 22:40:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 22:37:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA22179 for jmp-outgoing; Thu, 18 Dec 1997 22:34:55 -0500 (EST) Message-Id: <3.0.1.32.19971218193018.00ba51a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Dec 1997 19:30:18 PST To: Ron Bergman From: Tom Hastings Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? Cc: jmp@pwg.org, ipp@pwg.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org At 18:03 12/18/1997 PST, Ron Bergman wrote: >Tom, > >I agree with Bill on this issue, especially that "the point may be moot" > >Have you asked Kinkos how they charge in this situation? I believe that Kinkos charges by the sheet for printing from a PC. For copying, they have a different rate for one versus two sided copying. So far, I have not run into a duplex printer at Kinkos, so I don't know whether they have a policy for two-sided printing. But if the printing charge is like the copying charge, this issue would be moot. > >We should stick with the agreement per the LA meeting. Then we may want to add a note that impressions is more for monitoring and sheets is for monitoring and accounting. Tom There is another comment on this issue that was sent only to the IPP DL suggesting a rather simple algorithm that only worries about the last sheet, not any other sheets, and only as a recommendation. Is that a good compromise? >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > From ipp-owner@pwg.org Thu Dec 18 23:11:43 1997 Delivery-Date: Thu, 18 Dec 1997 23:11:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA23108 for ; Thu, 18 Dec 1997 23:11:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA17618 for ; Thu, 18 Dec 1997 23:14:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA23608 for ; Thu, 18 Dec 1997 23:11:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 23:03:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA22214 for ipp-outgoing; Thu, 18 Dec 1997 22:37:13 -0500 (EST) Date: Thu, 18 Dec 1997 19:32:21 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712190332.TAA26297@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: IPP>MOD action item: revised text for requesting-user-name X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org The following wording replaces all of in section 8.6 according to the agreement at todays telcon. ---------------------------------------------- 8.6 The "requesting-user-name" Operation Attribute Each operation SHALL specify the user who is performing the operation in both of the following two ways: 1) via the MANDATORY "requesting-user-name" operation attribute that a client SHOULD supply in all operations. The client SHALL obtain the value for this attribute from an environmental or network login name for the user, rather than allowing the user to supply any value. If the client does not supply a value for "requesting-user-name", the printer SHALL assume that the client is supplying some anonymous name, such as "anonymous". 2) via an authentication mechanism of the underlying transport which may be configured to give no authentication information. There are six cases to consider: a) the authentication mechanism gives no information, and the client doesn't specify "requesting-user-name". b) the authentication mechanism gives no information, but the client specifies "requesting-user-name". c) the authentication mechanism specifies a user which has no human readable representation, and the client doesn't specify "requesting-user-name". d) the authentication mechanism specifies a user which has no human readable representation, but the client specifies "requesting-user-name". e) the authentication mechanism specifies a user which has a human readable representation. The Printer object ignores the "requesting-user-name". f) the authentication mechanism specifies a user who is trusted and whose name means that the value of the "requesting-user-name", which must be present, is treated as the authenticated name. The user-name has two forms: one that is human readable: it is held in the MANDATORY "job-originating-user-name" Job Description attribute which is set during the job creation operations. It is used for presentation only, such as returning in queries or printing on start sheets one for authorization: it is held in an undefined (by IPP) Job object attribute which is set by the job creation operation. It is used to authorize other operations, such as Send-Document, Send-URI, Cancel-Job, to determine the user when the my-jobs' attribute is specified with Get-Jobs, and to limit what attributes to return with Get-Attributes and Get-Jobs. The human readable user name: is the value of the "requesting-user-name" for cases b, d and f. comes from the authentication mechanism for case e is some anonymous name, such as "anonymous" for cases a and c. The user name used for authorization: is the value of the "requesting-user-name" for cases b and f. comes from the authentication mechanism for cases c, d and e is some anonymous name, such as "anonymous" for case a. The essence of these rules for resolving conflicting sources of user-names is that a printer implementation is free to pick either source as long as it achieves consistent results. That is, if a user uses the same path for a series of requests, the requests must all appear to come from the same user from the standpoint of both the human-readable user name and the user name for authorization This rule must continue to apply even if a request could be authenticated by two or more mechanisms. It doesn't matter which the several authentication mechanism a Printer uses as long as it achieves consistent results. If a client uses more than one authentication mechanism, it is recommended that an administrator make all credentials resolve to the same user and user-name as much as possible. From ipp-owner@pwg.org Thu Dec 18 23:11:48 1997 Delivery-Date: Thu, 18 Dec 1997 23:11:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA23113 for ; Thu, 18 Dec 1997 23:11:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA17621 for ; Thu, 18 Dec 1997 23:14:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA23619 for ; Thu, 18 Dec 1997 23:11:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Dec 1997 23:04:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA22187 for ipp-outgoing; Thu, 18 Dec 1997 22:35:01 -0500 (EST) Message-Id: <3.0.1.32.19971218193018.00ba51a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Dec 1997 19:30:18 PST To: Ron Bergman From: Tom Hastings Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? Cc: jmp@pwg.org, ipp@pwg.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 18:03 12/18/1997 PST, Ron Bergman wrote: >Tom, > >I agree with Bill on this issue, especially that "the point may be moot" > >Have you asked Kinkos how they charge in this situation? I believe that Kinkos charges by the sheet for printing from a PC. For copying, they have a different rate for one versus two sided copying. So far, I have not run into a duplex printer at Kinkos, so I don't know whether they have a policy for two-sided printing. But if the printing charge is like the copying charge, this issue would be moot. > >We should stick with the agreement per the LA meeting. Then we may want to add a note that impressions is more for monitoring and sheets is for monitoring and accounting. Tom There is another comment on this issue that was sent only to the IPP DL suggesting a rather simple algorithm that only worries about the last sheet, not any other sheets, and only as a recommendation. Is that a good compromise? >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > From ipp-owner@pwg.org Fri Dec 19 03:36:51 1997 Delivery-Date: Fri, 19 Dec 1997 03:36:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA24625 for ; Fri, 19 Dec 1997 03:36:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA18020 for ; Fri, 19 Dec 1997 03:39:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA25065 for ; Fri, 19 Dec 1997 03:36:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 03:32:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA24474 for ipp-outgoing; Fri, 19 Dec 1997 03:18:35 -0500 (EST) Message-Id: <1.5.4.32.19971219071701.00739380@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, 18 Dec 1997 23:17:01 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Two Get Attributes Operations Sender: ipp-owner@pwg.org The subject of splitting up the current Get Attributes operation into two operations, one for Get Printer Attributes and one for Get Job Attributes has been discussed earlier in the project and more lately been advocated by a couple of implementors. Comments over the last few days have all been positive to the ideas of two operations. I believe that we have consensus to make a last minute editing of our documents to provide for the two, rather than the single operation. I have spoken to the editors today and they are all in favor. If anybody objects to this, please respond immediately as we are still planning to finish off the final editing by tomorrow Friday December 19. Carl-Uno From ipp-owner@pwg.org Fri Dec 19 08:08:24 1997 Delivery-Date: Fri, 19 Dec 1997 08:08:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA26006 for ; Fri, 19 Dec 1997 08:08:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA18325 for ; Fri, 19 Dec 1997 08:11:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA26205 for ; Fri, 19 Dec 1997 08:08:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 07:57:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA25593 for ipp-outgoing; Fri, 19 Dec 1997 07:44:11 -0500 (EST) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Keith Moore cc: Robert.Herriot@eng.sun.com (Robert Herriot), imcdonal@eso.mc.xerox.com, ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] In-reply-to: Your message of "Thu, 18 Dec 1997 18:34:30 EST." <199712182334.SAA17420@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Dec 1997 13:43:57 +0100 Message-ID: <25539.882535437@dale.uninett.no> Sender: ipp-owner@pwg.org moore@cs.utk.edu said: > The alternative is for IPP to convince IESG that digest > authentication alone really is adequate for a wide variety of printer > authentication scenarios. I won't claim that it cannot be done, > but offhand, I don't see how to do this. The third alternative is, of course, to claim that the WG is now convinced that it's acceptable for an IPP client to be unable to print on any printer that requires non-shared-secret authentication. This did not seem to be the consensus in Washington, but after all, the list, not the meeting, is the final arbiter of IETF WG consensus. Remember - you are the domain experts who are supposed to know what the requirements for a print protocol are; the IESG requirement is that: - It's possible for all conformant implementations to be able to interwork, if configured to do so - Whatever functions must be implemented use neither cleartext passwords nor encumbered technology, if possible If ability of a client to print on a TLS-only-configured printer is not in your requirements set, then that should not be a requirement. Harald A From jmp-owner@pwg.org Fri Dec 19 12:05:43 1997 Delivery-Date: Fri, 19 Dec 1997 12:05:43 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA28702 for ; Fri, 19 Dec 1997 12:05:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19148 for ; Fri, 19 Dec 1997 12:08:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27411 for ; Fri, 19 Dec 1997 12:05:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 11:57:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26838 for jmp-outgoing; Fri, 19 Dec 1997 11:52:29 -0500 (EST) Date: Fri, 19 Dec 1997 08:45:03 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? In-Reply-To: <3.0.1.32.19971218193018.00ba51a0@garfield> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jmp-owner@pwg.org Tom, On Thu, 18 Dec 1997, Tom Hastings wrote: > At 18:03 12/18/1997 PST, Ron Bergman wrote: > >Tom, > > > >I agree with Bill on this issue, especially that "the point may be moot" > > > >Have you asked Kinkos how they charge in this situation? > > I believe that Kinkos charges by the sheet for printing from a PC. > For copying, they have a different rate for one versus two sided > copying. So far, I have not run into a duplex printer at Kinkos, > so I don't know whether they have a policy for two-sided printing. > But if the printing charge is like the copying charge, this issue > would be moot. > > > > >We should stick with the agreement per the LA meeting. > > Then we may want to add a note that impressions is more for monitoring > and sheets is for monitoring and accounting. > Could you post a copy of the note to be added to the DL? > Tom > > > There is another comment on this issue that was sent only to the IPP DL > suggesting a rather simple algorithm that only worries about the last > sheet, not any other sheets, and only as a recommendation. Is that a good > compromise? > The proposed change sounds reasonable. > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant difference > between blank pages within a document and documents in a duplex job with an > odd number of pages causing the COMPLETELY blank back side of the last page > to be counted? Almost all page printers include an option for not printing > such completely blank pages, and I think the point about user concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of impression: > >> If a two-sided document has an odd number of pages, the last sheet still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > >should be: > >If a two-sided document has an odd number of pages and there are no marks > to be made on second side of the last sheet, the last sheet should count as > one impression, instead of two, even if that sheet makes two passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Fri Dec 19 12:16:28 1997 Delivery-Date: Fri, 19 Dec 1997 12:16:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA28796 for ; Fri, 19 Dec 1997 12:16:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19178 for ; Fri, 19 Dec 1997 12:19:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27689 for ; Fri, 19 Dec 1997 12:16:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 11:23:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26639 for ipp-outgoing; Fri, 19 Dec 1997 11:09:33 -0500 (EST) Message-Id: <1.5.4.32.19971219150951.00678618@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: Fri, 19 Dec 1997 07:09:51 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Cc: Robert.Herriot@eng.sun.com (Robert Herriot), imcdonal@eso.mc.xerox.com, ipp@pwg.org Sender: ipp-owner@pwg.org At 01:43 PM 12/19/97 +0100, Harald.T.Alvestrand@uninett.no wrote: > >moore@cs.utk.edu said: >> The alternative is for IPP to convince IESG that digest >> authentication alone really is adequate for a wide variety of printer >> authentication scenarios. I won't claim that it cannot be done, >> but offhand, I don't see how to do this. > >The third alternative is, of course, to claim that the WG is now convinced >that it's acceptable for an IPP client to be unable to print on any >printer that requires non-shared-secret authentication. >This did not seem to be the consensus in Washington, but after all, >the list, not the meeting, is the final arbiter of IETF WG consensus. > >Remember - you are the domain experts who are supposed to know what the >requirements for a print protocol are; the IESG requirement is that: > >- It's possible for all conformant implementations to be able to > interwork, if configured to do so >- Whatever functions must be implemented use neither cleartext passwords > nor encumbered technology, if possible > >If ability of a client to print on a TLS-only-configured printer is not >in your requirements set, then that should not be a requirement. > > Harald A Well, It seems that Harald has a more liberal view on this than Keith. This seems to open up the possibility to to recommend that all clients SHOULD support TLS, but not make it an absolute MUST. Comments? Carl-Uno From ipp-owner@pwg.org Fri Dec 19 12:16:28 1997 Delivery-Date: Fri, 19 Dec 1997 12:16:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA28796 for ; Fri, 19 Dec 1997 12:16:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19178 for ; Fri, 19 Dec 1997 12:19:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27689 for ; Fri, 19 Dec 1997 12:16:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 11:23:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26639 for ipp-outgoing; Fri, 19 Dec 1997 11:09:33 -0500 (EST) Message-Id: <1.5.4.32.19971219150951.00678618@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: Fri, 19 Dec 1997 07:09:51 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Cc: Robert.Herriot@eng.sun.com (Robert Herriot), imcdonal@eso.mc.xerox.com, ipp@pwg.org Sender: ipp-owner@pwg.org At 01:43 PM 12/19/97 +0100, Harald.T.Alvestrand@uninett.no wrote: > >moore@cs.utk.edu said: >> The alternative is for IPP to convince IESG that digest >> authentication alone really is adequate for a wide variety of printer >> authentication scenarios. I won't claim that it cannot be done, >> but offhand, I don't see how to do this. > >The third alternative is, of course, to claim that the WG is now convinced >that it's acceptable for an IPP client to be unable to print on any >printer that requires non-shared-secret authentication. >This did not seem to be the consensus in Washington, but after all, >the list, not the meeting, is the final arbiter of IETF WG consensus. > >Remember - you are the domain experts who are supposed to know what the >requirements for a print protocol are; the IESG requirement is that: > >- It's possible for all conformant implementations to be able to > interwork, if configured to do so >- Whatever functions must be implemented use neither cleartext passwords > nor encumbered technology, if possible > >If ability of a client to print on a TLS-only-configured printer is not >in your requirements set, then that should not be a requirement. > > Harald A Well, It seems that Harald has a more liberal view on this than Keith. This seems to open up the possibility to to recommend that all clients SHOULD support TLS, but not make it an absolute MUST. Comments? Carl-Uno From jmp-owner@pwg.org Fri Dec 19 12:58:09 1997 Delivery-Date: Fri, 19 Dec 1997 12:58:09 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA29175 for ; Fri, 19 Dec 1997 12:58:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19341 for ; Fri, 19 Dec 1997 13:00:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28231 for ; Fri, 19 Dec 1997 12:58:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 12:50:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27964 for jmp-outgoing; Fri, 19 Dec 1997 12:45:08 -0500 (EST) Message-Id: <3.0.1.32.19971219094023.00c389b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 09:40:23 PST To: jmp@pwg.org From: Tom Hastings Subject: JMP> Proposed jobmon MIB note for impressions (that count blank pages) Cc: ipp@pwg.org In-Reply-To: References: <3.0.1.32.19971218193018.00ba51a0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org I am not proposing any change to IPP from the current definition of impression which the Model document has as: 12.2.5 impression An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. I am only proposing to add a warning note to the Job Monitoring MIB, since we have agreed that impressions include passes past the marker that don't make marks, on even the last sheet. I propose to add the following note to the definition of the term impressions (to which all attributes and objects contain a reference) that we have in the PWG Job Monitoring MIB: NOTE - Since impressions include blank sides, it is suggested that accounting application implementers consider charging for sheets, rather than impressions, possibly factoring in value of the sides attribute for possibly different charges for one versus two-sided printing, since some users may think that impressions don't include blank sides. Here is the definition that we agreed to in principle at the L.A. meeting and for which there still seems to be support from most respondents: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". If you have any objections to the note, please voice them today, since we are forwarding the Job Mon MIB as an Internet-Draft today. Thanks, Tom At 08:45 12/19/1997 PST, Ron Bergman wrote: >Tom, > >On Thu, 18 Dec 1997, Tom Hastings wrote: > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: >> >Tom, >> > >> >I agree with Bill on this issue, especially that "the point may be moot" >> > >> >Have you asked Kinkos how they charge in this situation? >> >> I believe that Kinkos charges by the sheet for printing from a PC. >> For copying, they have a different rate for one versus two sided >> copying. So far, I have not run into a duplex printer at Kinkos, >> so I don't know whether they have a policy for two-sided printing. >> But if the printing charge is like the copying charge, this issue >> would be moot. >> >> > >> >We should stick with the agreement per the LA meeting. >> >> Then we may want to add a note that impressions is more for monitoring >> and sheets is for monitoring and accounting. >> >Could you post a copy of the note to be added to the DL? > >> Tom >> >> >> There is another comment on this issue that was sent only to the IPP DL >> suggesting a rather simple algorithm that only worries about the last >> sheet, not any other sheets, and only as a recommendation. Is that a good >> compromise? >> >The proposed change sounds reasonable. > >> >X-Sender: spencerdr@vipmail.earthlink.net >> >Date: Thu, 18 Dec 1997 10:03:04 PST >> >To: "Wagner, William" >> >From: David R Spencer >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last >> > page back sides or not? >> >Cc: ipp@pwg.org >> >Sender: ipp-owner@pwg.org >> >X-MIME-Autoconverted: from quoted-printable to 8bit by >> garfield.cp10.es.xerox.com id LAA26719 >> > >> >Bill, >> > >> >I'm just monitoring the group, but isn't there a significant difference >> between blank pages within a document and documents in a duplex job with an >> odd number of pages causing the COMPLETELY blank back side of the last page >> to be counted? Almost all page printers include an option for not printing >> such completely blank pages, and I think the point about user concern is >> well taken. >> > >> >Therefore, perhaps the sentence in the definition of impression: >> >> If a two-sided document has an odd number of pages, the last sheet still >> counts as two impressions, if that sheet makes two passes through the >> marker or the marker marks on both sides of a sheet in a single pass. >> >should be: >> >If a two-sided document has an odd number of pages and there are no marks >> to be made on second side of the last sheet, the last sheet should count as >> one impression, instead of two, even if that sheet makes two passes through >> the marker. >> > >> >David R. Spencer >> > >> >Spencer & Associates Publishing, Ltd. >> >Three Giffard Way, Melville, NY 11747-2310 >> >david@spencer.com >> >1-516-367-6655 Fax:1-516-367-2878 >> >http://www.spencer.com > > > Ron Bergman > Dataproducts Corp. > > > > From ipp-owner@pwg.org Fri Dec 19 13:21:09 1997 Delivery-Date: Fri, 19 Dec 1997 13:21:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA29318 for ; Fri, 19 Dec 1997 13:21:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19412 for ; Fri, 19 Dec 1997 13:23:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00075 for ; Fri, 19 Dec 1997 13:20:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 12:59:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26897 for ipp-outgoing; Fri, 19 Dec 1997 11:53:34 -0500 (EST) Message-Id: <1.5.4.32.19971219151904.006788d0@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: Fri, 19 Dec 1997 07:19:04 -0800 To: don@lexmark.com From: Carl-Uno Manros Subject: IPP> More time for IPP in January Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Don, It turmns out that there are two kinds of things that people would like to discuss in the January IPP meeting: 1) Start discussion about various extensions that were left out from IPP 1.0. We may also need to discuss any comments from the IESG. 2) Testing and interoperability issues. I would prefer to deal with the first set of disccussions on the already scheduled Wednesday slot, but would like to find out quickly if we could get a room for the testing issue discussions on Thursday. I assume that the second day meeting would be a smaller crowd, with little or no overlap in participation to other PWG activities planned for Thursday. Please let me know ASAP, as people might have to revise their traveling plans. Thanks, Carl-Uno From ipp-owner@pwg.org Fri Dec 19 13:24:36 1997 Delivery-Date: Fri, 19 Dec 1997 13:24:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA29338 for ; Fri, 19 Dec 1997 13:24:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19427 for ; Fri, 19 Dec 1997 13:27:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00458 for ; Fri, 19 Dec 1997 13:24:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 13:03:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26836 for ipp-outgoing; Fri, 19 Dec 1997 11:52:29 -0500 (EST) Date: Fri, 19 Dec 1997 08:48:14 -0800 (Pacific Standard Time) From: Ron Bergman To: Carl-Uno Manros cc: ipp@pwg.org Subject: Re: IPP> MOD - Two Get Attributes Operations In-Reply-To: <1.5.4.32.19971219071701.00739380@pop3.holonet.net> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Carl-Uno, This proposed change appears to be well justified. Ron Bergman Dataproducts Corp. On Thu, 18 Dec 1997, Carl-Uno Manros wrote: > The subject of splitting up the current Get Attributes operation into two > operations, one for Get Printer Attributes and one for Get Job Attributes > has been discussed earlier in the project and more lately been advocated by > a couple of implementors. Comments over the last few days have all been > positive to the ideas of two operations. > > I believe that we have consensus to make a last minute editing of our > documents to provide for the two, rather than the single operation. I have > spoken to the editors today and they are all in favor. > > If anybody objects to this, please respond immediately as we are still > planning to finish off the final editing by tomorrow Friday December 19. > > Carl-Uno > > From ipp-owner@pwg.org Fri Dec 19 13:25:48 1997 Delivery-Date: Fri, 19 Dec 1997 13:25:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA29357 for ; Fri, 19 Dec 1997 13:25:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19434 for ; Fri, 19 Dec 1997 13:28:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00574 for ; Fri, 19 Dec 1997 13:25:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 13:04:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26862 for ipp-outgoing; Fri, 19 Dec 1997 11:52:47 -0500 (EST) Date: Fri, 19 Dec 1997 08:45:03 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last page back sides or not? In-Reply-To: <3.0.1.32.19971218193018.00ba51a0@garfield> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Tom, On Thu, 18 Dec 1997, Tom Hastings wrote: > At 18:03 12/18/1997 PST, Ron Bergman wrote: > >Tom, > > > >I agree with Bill on this issue, especially that "the point may be moot" > > > >Have you asked Kinkos how they charge in this situation? > > I believe that Kinkos charges by the sheet for printing from a PC. > For copying, they have a different rate for one versus two sided > copying. So far, I have not run into a duplex printer at Kinkos, > so I don't know whether they have a policy for two-sided printing. > But if the printing charge is like the copying charge, this issue > would be moot. > > > > >We should stick with the agreement per the LA meeting. > > Then we may want to add a note that impressions is more for monitoring > and sheets is for monitoring and accounting. > Could you post a copy of the note to be added to the DL? > Tom > > > There is another comment on this issue that was sent only to the IPP DL > suggesting a rather simple algorithm that only worries about the last > sheet, not any other sheets, and only as a recommendation. Is that a good > compromise? > The proposed change sounds reasonable. > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant difference > between blank pages within a document and documents in a duplex job with an > odd number of pages causing the COMPLETELY blank back side of the last page > to be counted? Almost all page printers include an option for not printing > such completely blank pages, and I think the point about user concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of impression: > >> If a two-sided document has an odd number of pages, the last sheet still > counts as two impressions, if that sheet makes two passes through the > marker or the marker marks on both sides of a sheet in a single pass. > >should be: > >If a two-sided document has an odd number of pages and there are no marks > to be made on second side of the last sheet, the last sheet should count as > one impression, instead of two, even if that sheet makes two passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Fri Dec 19 13:28:43 1997 Delivery-Date: Fri, 19 Dec 1997 13:28:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA29376 for ; Fri, 19 Dec 1997 13:28:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19458 for ; Fri, 19 Dec 1997 13:31:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00771 for ; Fri, 19 Dec 1997 13:28:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 13:07:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27195 for ipp-outgoing; Fri, 19 Dec 1997 12:00:48 -0500 (EST) Message-ID: <349AA7FB.40C071D6@underscore.com> Date: Fri, 19 Dec 1997 11:59:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] References: <1.5.4.32.19971219150951.00678618@pop3.holonet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno, > Well, > > It seems that Harald has a more liberal view on this than Keith. This seems > to open up the possibility to to recommend that all clients SHOULD support > TLS, but not make it an absolute MUST. > > Comments? One question I have has to do with the implementation complexity of adding TLS support to a client. (I have no experience in TLS at all, neither the protocol nor the implementation.) Is it difficult? Is there a public domain (ie, free) implementation of TLS that can be leveraged to provide TLS support in a client? If it's free (or very, very cheap) and it's easy to integrate, then I would be quite willing to get behind mandatory TLS support in IPP clients. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Dec 19 14:05:41 1997 Delivery-Date: Fri, 19 Dec 1997 14:05:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA29860 for ; Fri, 19 Dec 1997 14:05:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19671 for ; Fri, 19 Dec 1997 14:08:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA01967 for ; Fri, 19 Dec 1997 14:05:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 13:50:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27975 for ipp-outgoing; Fri, 19 Dec 1997 12:45:52 -0500 (EST) Message-Id: <3.0.1.32.19971219094023.00c389b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 09:40:23 PST To: jmp@pwg.org From: Tom Hastings Subject: IPP> Proposed jobmon MIB note for impressions (that count blank pages) Cc: ipp@pwg.org In-Reply-To: References: <3.0.1.32.19971218193018.00ba51a0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I am not proposing any change to IPP from the current definition of impression which the Model document has as: 12.2.5 impression An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. I am only proposing to add a warning note to the Job Monitoring MIB, since we have agreed that impressions include passes past the marker that don't make marks, on even the last sheet. I propose to add the following note to the definition of the term impressions (to which all attributes and objects contain a reference) that we have in the PWG Job Monitoring MIB: NOTE - Since impressions include blank sides, it is suggested that accounting application implementers consider charging for sheets, rather than impressions, possibly factoring in value of the sides attribute for possibly different charges for one versus two-sided printing, since some users may think that impressions don't include blank sides. Here is the definition that we agreed to in principle at the L.A. meeting and for which there still seems to be support from most respondents: Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". If you have any objections to the note, please voice them today, since we are forwarding the Job Mon MIB as an Internet-Draft today. Thanks, Tom At 08:45 12/19/1997 PST, Ron Bergman wrote: >Tom, > >On Thu, 18 Dec 1997, Tom Hastings wrote: > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: >> >Tom, >> > >> >I agree with Bill on this issue, especially that "the point may be moot" >> > >> >Have you asked Kinkos how they charge in this situation? >> >> I believe that Kinkos charges by the sheet for printing from a PC. >> For copying, they have a different rate for one versus two sided >> copying. So far, I have not run into a duplex printer at Kinkos, >> so I don't know whether they have a policy for two-sided printing. >> But if the printing charge is like the copying charge, this issue >> would be moot. >> >> > >> >We should stick with the agreement per the LA meeting. >> >> Then we may want to add a note that impressions is more for monitoring >> and sheets is for monitoring and accounting. >> >Could you post a copy of the note to be added to the DL? > >> Tom >> >> >> There is another comment on this issue that was sent only to the IPP DL >> suggesting a rather simple algorithm that only worries about the last >> sheet, not any other sheets, and only as a recommendation. Is that a good >> compromise? >> >The proposed change sounds reasonable. > >> >X-Sender: spencerdr@vipmail.earthlink.net >> >Date: Thu, 18 Dec 1997 10:03:04 PST >> >To: "Wagner, William" >> >From: David R Spencer >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last >> > page back sides or not? >> >Cc: ipp@pwg.org >> >Sender: ipp-owner@pwg.org >> >X-MIME-Autoconverted: from quoted-printable to 8bit by >> garfield.cp10.es.xerox.com id LAA26719 >> > >> >Bill, >> > >> >I'm just monitoring the group, but isn't there a significant difference >> between blank pages within a document and documents in a duplex job with an >> odd number of pages causing the COMPLETELY blank back side of the last page >> to be counted? Almost all page printers include an option for not printing >> such completely blank pages, and I think the point about user concern is >> well taken. >> > >> >Therefore, perhaps the sentence in the definition of impression: >> >> If a two-sided document has an odd number of pages, the last sheet still >> counts as two impressions, if that sheet makes two passes through the >> marker or the marker marks on both sides of a sheet in a single pass. >> >should be: >> >If a two-sided document has an odd number of pages and there are no marks >> to be made on second side of the last sheet, the last sheet should count as >> one impression, instead of two, even if that sheet makes two passes through >> the marker. >> > >> >David R. Spencer >> > >> >Spencer & Associates Publishing, Ltd. >> >Three Giffard Way, Melville, NY 11747-2310 >> >david@spencer.com >> >1-516-367-6655 Fax:1-516-367-2878 >> >http://www.spencer.com > > > Ron Bergman > Dataproducts Corp. > > > > From ipp-owner@pwg.org Fri Dec 19 14:07:46 1997 Delivery-Date: Fri, 19 Dec 1997 14:07:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA29883 for ; Fri, 19 Dec 1997 14:07:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19683 for ; Fri, 19 Dec 1997 14:10:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02125 for ; Fri, 19 Dec 1997 14:07:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 13:52:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28089 for ipp-outgoing; Fri, 19 Dec 1997 12:53:06 -0500 (EST) Message-Id: <3.0.1.32.19971219094837.01008160@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 09:48:37 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD action item: revised text for requesting-user-name In-Reply-To: <199712190332.TAA26297@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Looks good to me. A few typos indicated. MUST needs to be capitalized a few places. Also change the name from Get-Attributes to Get-Job-Attributes (I don't think that we need to add Get-Printer-Attributes to this list, since restricting Printer attributes returned in Get-Printer-Attributes wouldn't apply to end users). Tom At 19:32 12/18/1997 PST, Robert Herriot wrote: >The following wording replaces all of in section 8.6 according to the >agreement at todays telcon. >---------------------------------------------- > >8.6 The "requesting-user-name" Operation Attribute > > >Each operation SHALL specify the user who is performing the operation >in both of the following two ways: > > 1) via the MANDATORY "requesting-user-name" operation attribute that a > client SHOULD supply in all operations. The client SHALL obtain the > value for this attribute from an environmental or network login name > for the user, rather than allowing the user to supply any value. If the > client does not supply a value for "requesting-user-name", the printer > SHALL assume that the client is supplying some anonymous name, such as > "anonymous". > > 2) via an authentication mechanism of the underlying transport which > may be configured to give no authentication information. > >There are six cases to consider: > > a) the authentication mechanism gives no information, and the client > doesn't specify "requesting-user-name". > > b) the authentication mechanism gives no information, but the client > specifies "requesting-user-name". > > c) the authentication mechanism specifies a user which has no human > readable representation, and the client doesn't specify > "requesting-user-name". > > d) the authentication mechanism specifies a user which has no human > readable representation, but the client specifies > "requesting-user-name". > > e) the authentication mechanism specifies a user which has a human > readable representation. The Printer object ignores the > "requesting-user-name". > > f) the authentication mechanism specifies a user who is trusted and > whose name means that the value of the "requesting-user-name", which > must be present, is treated as the authenticated name. TH> MUST > >The user-name has two forms: > > one that is human readable: it is held in the MANDATORY > "job-originating-user-name" Job Description attribute which is set > during the job creation operations. It is used for presentation only, > such as returning in queries or printing on start sheets > > one for authorization: it is held in an undefined (by IPP) Job object > attribute which is set by the job creation operation. It is used to > authorize other operations, such as Send-Document, Send-URI, > Cancel-Job, to determine the user when the my-jobs' attribute is > specified with Get-Jobs, and to limit what attributes to return with > Get-Attributes and Get-Jobs. TH> Change to Get-Job-Attributes > >The human readable user name: > > is the value of the "requesting-user-name" for cases b, d and f. > > comes from the authentication mechanism for case e > > is some anonymous name, such as "anonymous" for cases a and c. > >The user name used for authorization: > > is the value of the "requesting-user-name" for cases b and f. > > comes from the authentication mechanism for cases c, d and e > > is some anonymous name, such as "anonymous" for case a. > >The essence of these rules for resolving conflicting sources of >user-names is that a printer implementation is free to pick either >source as long as it achieves consistent results. That is, if a user >uses the same path for a series of requests, the requests must all TH> make MUST >appear to come from the same user from the standpoint of both the >human-readable user name and the user name for authorization This rule TH> need a period: . >must continue to apply even if a request could be authenticated by two TH> make MUST >or more mechanisms. It doesn't matter which the several authentication >mechanism a Printer uses as long as it achieves consistent results. If >a client uses more than one authentication mechanism, it is recommended >that an administrator make all credentials resolve to the same user and >user-name as much as possible. > > > > From ipp-owner@pwg.org Fri Dec 19 14:17:54 1997 Delivery-Date: Fri, 19 Dec 1997 14:17:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA00077 for ; Fri, 19 Dec 1997 14:17:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19706 for ; Fri, 19 Dec 1997 14:20:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02771 for ; Fri, 19 Dec 1997 14:17:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 14:09:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00614 for ipp-outgoing; Fri, 19 Dec 1997 13:26:14 -0500 (EST) Message-ID: <349ABAA9.4B44B39B@sharplabs.com> Date: Fri, 19 Dec 1997 10:19:22 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org, Robert Herriot , imcdonal@eso.mc.xerox.com Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] References: <1.5.4.32.19971219150951.00678618@pop3.holonet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org How long are we going to keep revisiting this issue? We have a solution that meets our charter and I thought we had consensus. What IPP over TCP? What about fonts? Do we use binary or ASCII encoding? I think we have a model and have resolved our issues. Lets go with this and see what happens in the deployment of the proposed standard we have.... Randy Carl-Uno Manros wrote: > > At 01:43 PM 12/19/97 +0100, Harald.T.Alvestrand@uninett.no wrote: > > > >moore@cs.utk.edu said: > >> The alternative is for IPP to convince IESG that digest > >> authentication alone really is adequate for a wide variety of printer > >> authentication scenarios. I won't claim that it cannot be done, > >> but offhand, I don't see how to do this. > > > >The third alternative is, of course, to claim that the WG is now convinced > >that it's acceptable for an IPP client to be unable to print on any > >printer that requires non-shared-secret authentication. > >This did not seem to be the consensus in Washington, but after all, > >the list, not the meeting, is the final arbiter of IETF WG consensus. > > > >Remember - you are the domain experts who are supposed to know what the > >requirements for a print protocol are; the IESG requirement is that: > > > >- It's possible for all conformant implementations to be able to > > interwork, if configured to do so > >- Whatever functions must be implemented use neither cleartext passwords > > nor encumbered technology, if possible > > > >If ability of a client to print on a TLS-only-configured printer is not > >in your requirements set, then that should not be a requirement. > > > > Harald A > > Well, > > It seems that Harald has a more liberal view on this than Keith. This seems > to open up the possibility to to recommend that all clients SHOULD support > TLS, but not make it an absolute MUST. > > Comments? > > Carl-Uno From ipp-owner@pwg.org Fri Dec 19 14:25:27 1997 Delivery-Date: Fri, 19 Dec 1997 14:25:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA00852 for ; Fri, 19 Dec 1997 14:25:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19726 for ; Fri, 19 Dec 1997 14:28:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA03380 for ; Fri, 19 Dec 1997 14:25:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 14:21:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00907 for ipp-outgoing; Fri, 19 Dec 1997 13:49:59 -0500 (EST) Message-Id: <3.0.1.32.19971219104529.00fdb350@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 10:45:29 PST To: Carl-Uno Manros , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Two Get Attributes Operations In-Reply-To: <1.5.4.32.19971219071701.00739380@pop3.holonet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Sounds good. So the old section 3.2.5 Get-Attributes (for Printer objects) becomes 3.2.5 Get-Printer-Attributes with no changes in the spec (the target remains a printer URI). and the old section 3.3.4 Get-Attributes (for Job objects) becomes 3.3.4 Get-Job-Attributes with no changes in the spec (the target remains either a printer URI plus a job-id OR a job-uri (with no job-id). Both operations are MANDATORY. If we add new objects to IPP in the future, they will be OPTIONAL for compatibility. And we can then add an OPTIONAL Get-Object-Attributes operation which takes the URI for the object to get its attributes. We'd probably just add a new tag in the protocol for responses: object-attributes. Thus the change we are making today does not preclude our adding new OPTIONAL objects in the future. Tom At 23:17 12/18/1997 PST, Carl-Uno Manros wrote: >The subject of splitting up the current Get Attributes operation into two >operations, one for Get Printer Attributes and one for Get Job Attributes >has been discussed earlier in the project and more lately been advocated by >a couple of implementors. Comments over the last few days have all been >positive to the ideas of two operations. > >I believe that we have consensus to make a last minute editing of our >documents to provide for the two, rather than the single operation. I have >spoken to the editors today and they are all in favor. > >If anybody objects to this, please respond immediately as we are still >planning to finish off the final editing by tomorrow Friday December 19. > >Carl-Uno > > > From ipp-owner@pwg.org Fri Dec 19 15:11:41 1997 Delivery-Date: Fri, 19 Dec 1997 15:11:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01164 for ; Fri, 19 Dec 1997 15:11:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19874 for ; Fri, 19 Dec 1997 15:14:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04065 for ; Fri, 19 Dec 1997 15:11:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 15:07:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03508 for ipp-outgoing; Fri, 19 Dec 1997 14:53:26 -0500 (EST) Content-return: allowed Date: Fri, 19 Dec 1997 11:45:56 PST From: "Zehler, Peter " Subject: IPP> MOD - Automated IPP Printer Installation To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org ALL, Since IPP 1.0 is completed, here is the quick overview of an automated printer installation proposal for IPP. I have crated a new directory on the IPP site called "new_INST". In the directory I have placed a write up of this IPP extension. The write up is ID style. Below is is the quick "manager" level explanation. This is just a straw-man proposal to open discussions. Comments are welcome and encouraged. Automated printer installation is intended accommodate multiple client platforms, multiple drivers per printer and internationalization. Automated IPP printer installation takes advantage of a printer attribute that is a URL to a driver installer. I have changed the semantics slightly of this optional attribute to be a link to an IPP Installer object. Installer objects contain installer components. Installer components are executable images. They automate the installation of a printer driver, creation of a print queue or spooler, and any the installation or configuration of associated system components specific to a client OS. The installer components are provided by the printer manufacturer for target operating systems. The installer components could also be made available through an embedded web server or corporate homepage. The Installer object can be anywhere. It is a URI which can be preconfigured in printers to point back to a Manufacturer supported IPP Installer object or refer to the printer itself. A Manufacturer supported IPP Installer objects would contain installer components for all their printers. An embedded IPP Installer object would contain only the installer components for that printer. How it works. 1) User obtains IPP Printer URL.(word of mouth, search engine, LDAP, webpage link). 2) IPP protocol is native to client environment(future) or explicitly installed(providing "add printer" functionality where non exists). 3) End user begins client OS specific "add printer" feature entering in the URL of the target printer. 4) Client software sends IPP request to the printer object to retrieve the URL of the installer object and printer identification(supported PDL can also be retrieved). 5) Client software sends query request to Installer object providing printer identification. 6) Installer object returns the supported client OSs, languages, character sets, PDLs and the default PDL for that printer. The installer object also returns the date/time for the installer.(installer components are versioned, not individual subcomponents (i.e.drivers)) 7) Client software selects appropriate client OS, language, and character set(PDL can be specified or defaulted). 8) Client software send a request to retrieve installer component specifying printer identification as well as above information. 9) Installer object responds by downloading installer component. 10) Installer component is temporarily stored.(date/time stamp should be held for later comparison to detect new installer component) 11) Installer component is executed. This installs the printer in the client environment. 12) End user prints from application Note: IPP client environment can take advantage of information provided in #9 to automatically(or explicitly) update client. Note: TLS authentication can be used providing mutual authentication to insure installer component is legitimate. Pete From jmp-owner@pwg.org Fri Dec 19 15:48:15 1997 Delivery-Date: Fri, 19 Dec 1997 15:48:19 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01386 for ; Fri, 19 Dec 1997 15:48:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20034 for ; Fri, 19 Dec 1997 15:50:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04379 for ; Fri, 19 Dec 1997 15:48:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 15:45:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04185 for jmp-outgoing; Fri, 19 Dec 1997 15:43:23 -0500 (EST) Date: Fri, 19 Dec 1997 12:36:47 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: Re: JMP> Proposed jobmon MIB note for impressions (that count blank pages) In-Reply-To: <3.0.1.32.19971219094023.00c389b0@garfield> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jmp-owner@pwg.org Tom, I don't have any objections to your proposal. Ron Bergman Dataproducts Corp. On Fri, 19 Dec 1997, Tom Hastings wrote: > I am not proposing any change to IPP from the current definition > of impression which the Model document has as: > > 12.2.5 impression > > An "impression" is the image (possibly many print-stream pages in different > configurations) imposed onto a single media page. > > > > I am only proposing to add a warning note to the Job Monitoring MIB, > since we have agreed that impressions include passes past the marker > that don't make marks, on even the last sheet. > > I propose to add the following note to the definition of the > term impressions (to which all attributes and objects contain a reference) > that we have in the PWG Job Monitoring MIB: > > NOTE - Since impressions include blank sides, it is suggested that > accounting application implementers consider charging for sheets, rather > than impressions, possibly factoring in value of the sides attribute for > possibly different charges for one versus two-sided printing, since some > users may think that impressions don't include blank sides. > > > Here is the definition that we agreed to in principle at the L.A. meeting > and for which there still seems to be support from most respondents: > > Impression: For a print job, an impression is the passage of the entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the marker. > Thus a four pass color process counts as a single impression. One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an odd > number of pages, the last sheet still counts as two impressions, if that > sheet makes two passes through the marker or the marker marks on both sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single impression. > See "page" and "sheet". > > > If you have any objections to the note, please voice them today, > since we are forwarding the Job Mon MIB as an Internet-Draft today. > > Thanks, > Tom > > > At 08:45 12/19/1997 PST, Ron Bergman wrote: > >Tom, > > > >On Thu, 18 Dec 1997, Tom Hastings wrote: > > > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: > >> >Tom, > >> > > >> >I agree with Bill on this issue, especially that "the point may be moot" > >> > > >> >Have you asked Kinkos how they charge in this situation? > >> > >> I believe that Kinkos charges by the sheet for printing from a PC. > >> For copying, they have a different rate for one versus two sided > >> copying. So far, I have not run into a duplex printer at Kinkos, > >> so I don't know whether they have a policy for two-sided printing. > >> But if the printing charge is like the copying charge, this issue > >> would be moot. > >> > >> > > >> >We should stick with the agreement per the LA meeting. > >> > >> Then we may want to add a note that impressions is more for monitoring > >> and sheets is for monitoring and accounting. > >> > >Could you post a copy of the note to be added to the DL? > > > >> Tom > >> > >> > >> There is another comment on this issue that was sent only to the IPP DL > >> suggesting a rather simple algorithm that only worries about the last > >> sheet, not any other sheets, and only as a recommendation. Is that a good > >> compromise? > >> > >The proposed change sounds reasonable. > > > >> >X-Sender: spencerdr@vipmail.earthlink.net > >> >Date: Thu, 18 Dec 1997 10:03:04 PST > >> >To: "Wagner, William" > >> >From: David R Spencer > >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > >> > page back sides or not? > >> >Cc: ipp@pwg.org > >> >Sender: ipp-owner@pwg.org > >> >X-MIME-Autoconverted: from quoted-printable to 8bit by > >> garfield.cp10.es.xerox.com id LAA26719 > >> > > >> >Bill, > >> > > >> >I'm just monitoring the group, but isn't there a significant difference > >> between blank pages within a document and documents in a duplex job with an > >> odd number of pages causing the COMPLETELY blank back side of the last page > >> to be counted? Almost all page printers include an option for not printing > >> such completely blank pages, and I think the point about user concern is > >> well taken. > >> > > >> >Therefore, perhaps the sentence in the definition of impression: > >> >> If a two-sided document has an odd number of pages, the last sheet still > >> counts as two impressions, if that sheet makes two passes through the > >> marker or the marker marks on both sides of a sheet in a single pass. > >> >should be: > >> >If a two-sided document has an odd number of pages and there are no marks > >> to be made on second side of the last sheet, the last sheet should count as > >> one impression, instead of two, even if that sheet makes two passes through > >> the marker. > >> > > >> >David R. Spencer > >> > > >> >Spencer & Associates Publishing, Ltd. > >> >Three Giffard Way, Melville, NY 11747-2310 > >> >david@spencer.com > >> >1-516-367-6655 Fax:1-516-367-2878 > >> >http://www.spencer.com > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > > > From ipp-owner@pwg.org Fri Dec 19 16:03:22 1997 Delivery-Date: Fri, 19 Dec 1997 16:03:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01857 for ; Fri, 19 Dec 1997 16:03:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20091 for ; Fri, 19 Dec 1997 16:06:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04955 for ; Fri, 19 Dec 1997 16:03:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 15:59:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04193 for ipp-outgoing; Fri, 19 Dec 1997 15:43:29 -0500 (EST) Date: Fri, 19 Dec 1997 12:36:47 -0800 (Pacific Standard Time) From: Ron Bergman To: Tom Hastings cc: jmp@pwg.org, ipp@pwg.org Subject: IPP> Re: JMP> Proposed jobmon MIB note for impressions (that count blank pages) In-Reply-To: <3.0.1.32.19971219094023.00c389b0@garfield> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Tom, I don't have any objections to your proposal. Ron Bergman Dataproducts Corp. On Fri, 19 Dec 1997, Tom Hastings wrote: > I am not proposing any change to IPP from the current definition > of impression which the Model document has as: > > 12.2.5 impression > > An "impression" is the image (possibly many print-stream pages in different > configurations) imposed onto a single media page. > > > > I am only proposing to add a warning note to the Job Monitoring MIB, > since we have agreed that impressions include passes past the marker > that don't make marks, on even the last sheet. > > I propose to add the following note to the definition of the > term impressions (to which all attributes and objects contain a reference) > that we have in the PWG Job Monitoring MIB: > > NOTE - Since impressions include blank sides, it is suggested that > accounting application implementers consider charging for sheets, rather > than impressions, possibly factoring in value of the sides attribute for > possibly different charges for one versus two-sided printing, since some > users may think that impressions don't include blank sides. > > > Here is the definition that we agreed to in principle at the L.A. meeting > and for which there still seems to be support from most respondents: > > Impression: For a print job, an impression is the passage of the entire > side of a sheet by the marker, whether or not any marks are made and > independent of the number of passes that the side makes past the marker. > Thus a four pass color process counts as a single impression. One-sided > processing involves one impression per sheet. Two-sided processing > involves two impressions per sheet. If a two-sided document has an odd > number of pages, the last sheet still counts as two impressions, if that > sheet makes two passes through the marker or the marker marks on both sides > of a sheet in a single pass. Two-up printing is the placement of two > logical pages on one side of a sheet and so is still a single impression. > See "page" and "sheet". > > > If you have any objections to the note, please voice them today, > since we are forwarding the Job Mon MIB as an Internet-Draft today. > > Thanks, > Tom > > > At 08:45 12/19/1997 PST, Ron Bergman wrote: > >Tom, > > > >On Thu, 18 Dec 1997, Tom Hastings wrote: > > > >> At 18:03 12/18/1997 PST, Ron Bergman wrote: > >> >Tom, > >> > > >> >I agree with Bill on this issue, especially that "the point may be moot" > >> > > >> >Have you asked Kinkos how they charge in this situation? > >> > >> I believe that Kinkos charges by the sheet for printing from a PC. > >> For copying, they have a different rate for one versus two sided > >> copying. So far, I have not run into a duplex printer at Kinkos, > >> so I don't know whether they have a policy for two-sided printing. > >> But if the printing charge is like the copying charge, this issue > >> would be moot. > >> > >> > > >> >We should stick with the agreement per the LA meeting. > >> > >> Then we may want to add a note that impressions is more for monitoring > >> and sheets is for monitoring and accounting. > >> > >Could you post a copy of the note to be added to the DL? > > > >> Tom > >> > >> > >> There is another comment on this issue that was sent only to the IPP DL > >> suggesting a rather simple algorithm that only worries about the last > >> sheet, not any other sheets, and only as a recommendation. Is that a good > >> compromise? > >> > >The proposed change sounds reasonable. > > > >> >X-Sender: spencerdr@vipmail.earthlink.net > >> >Date: Thu, 18 Dec 1997 10:03:04 PST > >> >To: "Wagner, William" > >> >From: David R Spencer > >> >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > >> > page back sides or not? > >> >Cc: ipp@pwg.org > >> >Sender: ipp-owner@pwg.org > >> >X-MIME-Autoconverted: from quoted-printable to 8bit by > >> garfield.cp10.es.xerox.com id LAA26719 > >> > > >> >Bill, > >> > > >> >I'm just monitoring the group, but isn't there a significant difference > >> between blank pages within a document and documents in a duplex job with an > >> odd number of pages causing the COMPLETELY blank back side of the last page > >> to be counted? Almost all page printers include an option for not printing > >> such completely blank pages, and I think the point about user concern is > >> well taken. > >> > > >> >Therefore, perhaps the sentence in the definition of impression: > >> >> If a two-sided document has an odd number of pages, the last sheet still > >> counts as two impressions, if that sheet makes two passes through the > >> marker or the marker marks on both sides of a sheet in a single pass. > >> >should be: > >> >If a two-sided document has an odd number of pages and there are no marks > >> to be made on second side of the last sheet, the last sheet should count as > >> one impression, instead of two, even if that sheet makes two passes through > >> the marker. > >> > > >> >David R. Spencer > >> > > >> >Spencer & Associates Publishing, Ltd. > >> >Three Giffard Way, Melville, NY 11747-2310 > >> >david@spencer.com > >> >1-516-367-6655 Fax:1-516-367-2878 > >> >http://www.spencer.com > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > > > From ipp-owner@pwg.org Fri Dec 19 17:55:15 1997 Delivery-Date: Fri, 19 Dec 1997 17:55:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA03199 for ; Fri, 19 Dec 1997 17:55:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA20475 for ; Fri, 19 Dec 1997 17:58:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA05652 for ; Fri, 19 Dec 1997 17:55:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 17:50:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05088 for ipp-outgoing; Fri, 19 Dec 1997 17:36:27 -0500 (EST) Message-Id: <3.0.1.32.19971219143219.00a03b10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 14:32:19 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Suggested simplification of IANA Considerations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Here is my action item on the Model Section 6 IANA Considerations. I've consulted with Bob Herriot and Carl-Uno on these proposed simplfications. Please send any comments immediately. I re-read the new IANA Considerations document (draft-iesg-iana-considerations-01.txt) and see that we should make the following changes in order not to hold up IPP in the IESG: 1. The model needs to assign IPP Subject Matter Experts by name, not position. 2. The document suggests chairs, so I've talked to Carl-Uno and he suggests that Carl-Uno and Steve should be the IPP Subject Matter Experts. 3. The model needs to say who can find a replacement and suggests the A-Ds, so I've added that and included that the PWG can change them too. 4. The model needs to say who maintains each entry. Type 2 should be the PWG, type 3 should be the proposer. 5. Don't have IANA have to assign type 3 keywords and enums, lets have the Subject Matter Experts do it. So all IANA has to do for type 2 and type 3 is keep the approved registrations (the document recommends delegation). This is what we have done for the Printer MIB "printer language" registrations (document formats). Here is the complete new text for section 6. (only 6.1 has changed). I've also posted a .doc (WORD 6) and a .pdf file to show the revisions: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.pdf 6. IANA Considerations (registered and private extensions) This section describes how IPP can be extended. 6.1 Typed Extensions IPP allows for "keyword" and "enum" extensions (see sections 4.1.5 and 4.1.6). In reviewing proposals for such extensions, the IPP Subject Matter Experts are: Carl-Uno Manros (manros@cp10.es.xerox.com) and Steve Zilles (szilles@Adobe.com). If a replacement is needed, the IESG Applications Area Director, in consultation with the PWG [PWG] using pwg@pwg.org, SHALL appoint a replacement. The PWG can also specify a replacement at any time. This document uses prefixes to the "keyword" and "enum" basic syntax type in order to communicate extra information to the reader through its name. This extra information need not be represented in an implementation because it is unimportant to a client or Printer. The list below describes the prefixes and their meaning. "type1": The IPP standard must be revised to add a new keyword or a new enum. No private keywords or enums are allowed. "type2": Implementers can, at any time, add new keyword or enum values by proposing the specification to: - the IPP working group (IPP WG using ipp@pwg.org) while it is still chartered, or - the Printer Working Group [PWG] using pwg@pwg.org after the IPP working group is disbanded who will review the proposal and work with IANA to register the additional keywords and enums. For enums, the IPP WG or PWG assigns the next available unused number. When a type 2 keyword or enum is approved by the IPP WG or PWG, the PWG becomes the point of contact for any future maintenance that might be required for that registration. IANA keeps the registry of keywords and enums as it does for any registration. "type3": Implementers can, at any time, add new keyword and enum values by submitting the complete specification directly to the IPP Subject Matter Experts. While no IPP working group or Printer Working Group review is required, the IPP Subject Matter Experts may, at their discretion, forward the proposal to the IPP WG or PWG for advice and comment. For enums, the IPP Subject Matter Experts assigns the number for enum values. and keeps the registry of keywords and enums. When a type 3 keyword or enum is approved by IPP Subject Matter Experts, the original proposer becomes the point of contact for any future maintenance that might be required for that registration. IANA keeps the registry of keywords and enums as it does for any registration. "type4": Anyone (system administrators, system integrators, site managers, etc.) can, at any time, add new installation-defined values (keywords, but not enum values) to a local system. Care SHOULD be taken by the implementers to see that keywords do not conflict with other keywords defined by the standard or as defined by the implementing product. There is no registration or approval procedure for type 4 keywords. Note: Attributes with type 4 keywords also allow the 'name' attribute syntax for administrator defined names. Such names are not registered. By definition, each of the four types above assert some sort of registry or review process in order for extensions to be considered valid. Each higher level (1, 2, 3, 4) tends to be decreasingly less stringent than the previous level. Therefore, any typeN value MAY be registered using a process for some typeM where M is less than N, however such registration is NOT REQUIRED. For example, a type4 value MAY be registered in a type 1 manner (by being included in a future version of an IPP specification) however it is NOT REQUIRED. This specification defines keyword and enum values for all of the above types, including type4 keywords. For private (unregistered) keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx is the (lowercase) fully qualified company name registered with IANA for use in domain names [RFC1035]. For example, if the company XYZ Corp. had obtained the domain name "XYZ.com", then a private keyword 'abc' would be: 'xyz.com-abc'. Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. Also, the labels in a domain name must follow the rules for ARPANET host names: They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Labels must be 63 characters or less. Labels are separated by the "." character. For private (unregistered) enum extension, implementers SHALL use values in the reserved integer range which is 2**30 to 2**31-1. 6.2 Registration of MIME types/sub-types for document-formats The "document-format" attribute's syntax is 'mimeMediaType'. This means that valid values are Internet Media Types. RFC 2045 [RFC2045] defines the syntax for valid Internet media types. IANA is the registry for all Internet media types. 6.3 Attribute Extensibility Attribute names are type2 keywords. Therefore, new attributes may be registered and have the same status as attributes in this document by following the type2 extension rules. 6.4 Attribute Syntax Extensibility Attribute syntaxes are like type2 enums. Therefore, new attribute syntaxes may be registered and have the same status as attribute syntaxes in this document by following the type2 extension rules. The value codes that identify each of the attribute syntaxes are assigned in the protocol specification [IPP-PRO]. From ipp-owner@pwg.org Fri Dec 19 20:21:49 1997 Delivery-Date: Fri, 19 Dec 1997 20:21:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA03907 for ; Fri, 19 Dec 1997 20:21:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA20816 for ; Fri, 19 Dec 1997 20:24:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06374 for ; Fri, 19 Dec 1997 20:21:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 20:16:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05824 for ipp-outgoing; Fri, 19 Dec 1997 20:02:30 -0500 (EST) Message-Id: <3.0.1.32.19971219170214.0090dd30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 17:02:14 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Harald's report from the IETF meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harald has written a personal report from the IETF meeting. You can read the whole report at: http://domen.uninett.no/~hta/reiser/ietf-des97.html I have copied the part that he wrote on security for your information below. Carl-Uno ------- Security: The overarching concern There is great concern about security, with excellent reason. One report from MIT was that they estimated that aproximately 90% of the subnets had password sniffers running, up from 50% last summer - not only are those who wish to challenge us for control of our resources getting more numerous, they are also getting smarter. With this in mind, it is hard to say what is more depressing: The lack of functional standards for security, or our singular lack of success in seeing deployment of the ones we have. But things ARE improving; in new standards, cleartext passwords are no longer used - a technique called "CRAM-MD5", a challenge-response mechanism, is seeing increased usage, together with the authentication method framework called "SASL". And when securing a connection is needed, the big fights about cryptoalgorithms have now resulted in a specification called "TLS" (descendant of the "SSL" currently popular on the Web) allows one to negotiate a secure connection without the need for any license from any patent-owning organization. The feedback from these developments has been somewhat mixed; changing authentication infrastructures is real work, and CRAM-MD5 is not immediately suitable for use with existing UNIX or NT frameworks; it may, however, be that even these seemingly immovable obstacles can be overcome, in order to achieve interoperable security across open systems. If so, we will have wrought well. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Dec 19 21:02:22 1997 Delivery-Date: Fri, 19 Dec 1997 21:02:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA04076 for ; Fri, 19 Dec 1997 21:02:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20864 for ; Fri, 19 Dec 1997 21:05:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07076 for ; Fri, 19 Dec 1997 21:02:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 20:58:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06495 for ipp-outgoing; Fri, 19 Dec 1997 20:44:52 -0500 (EST) Date: Fri, 19 Dec 1997 17:43:42 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712200143.RAA27575@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol and lpd drafts X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have downloaded the latest protocol and lpd documents to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The documents are: ipp-pro-971219.doc MS Word Version 6 with no revisions ipp-pro-971219.txt text no revisions ipp-pro-971219-rev.doc MS Word Version 6 with revisions ipp-lpd-971219.doc MS Word Version 6 with no revisions ipp-lpd-971219.txt text with no revisions ipp-lpd-971219-rev.doc MS Word Version 6 with revisions One issue about printer-uri versus printer-tls-uri came up during editing. It will be in a separate email. From ipp-owner@pwg.org Fri Dec 19 21:50:14 1997 Delivery-Date: Fri, 19 Dec 1997 21:50:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA04275 for ; Fri, 19 Dec 1997 21:50:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20940 for ; Fri, 19 Dec 1997 21:53:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07719 for ; Fri, 19 Dec 1997 21:50:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 21:45:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07169 for ipp-outgoing; Fri, 19 Dec 1997 21:32:18 -0500 (EST) Message-Id: <3.0.1.32.19971219183208.01417400@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 18:32:08 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - New drafts of Model and Protocol documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, I just got word back from the editors that new drafts will be sent to the IETF secretariat tonight. However, it still seems that we have not yet reached final consensus on the security issue, and it seems improper to try to rush through a solution now when many of you have already begun your holidays. Please try to find some time between your seasonal celebrations to look over the new drafts so that we can all start with the same background knowledge of where we stand in the new year. I thank you all for the considerable time and efforts that you have spent on the IPP project in 1997 and wish you all A MERRY CHRISTMAS and A HAPPY NEW YEAR Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Dec 19 23:12:06 1997 Delivery-Date: Fri, 19 Dec 1997 23:12:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA11020 for ; Fri, 19 Dec 1997 23:12:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA21062 for ; Fri, 19 Dec 1997 23:14:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08426 for ; Fri, 19 Dec 1997 23:12:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Dec 1997 23:07:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA07847 for ipp-outgoing; Fri, 19 Dec 1997 22:53:51 -0500 (EST) Date: Fri, 19 Dec 1997 19:52:41 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199712200352.TAA27718@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD printer-uri/printer-tls-uri issues X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org While I was putting the finishing touches on the protocol document, I came across an unresolved issue which opened up a few more. NAME OF TARGET IN OPERATIONS ATTRIBUTES The initial issue was whether the printer target in the operation attributes should always be called printer-uri or whether it should be printer-tls-uri when TLS is being used. A similar question exists for jobs. For job targets, we have only defined a job-uri job attribute, even for TLS submitted jobs. So it would seem that the job target operation attribute should always be job-uri with no special job-tls-uri. I decided that the printer target would always be printer-uri, rather than printer-tls-uri for TLS requests. The code is simpler if it is always looking for the same attribute, and I couldn't see any reason for the redundancy. With the changes I suggest in the third section, printer-uri becomes the only choice. CONTAINING-PRINTER-URI But then I realized that containing-printer-uri is defined ambiguously. If I do Get-Job-Attributes by HTTP to a job submitted via HTTPS, do I get back the HTTPS printer or the HTTP printer? I am probably not using this attribute to figure out how the job was submitted, so having it return the HTTPS printer-uri to which it was submitted isn't useful. Instead, I am probably requesting the containing-printer-uri so that I can do another operation on the job's printer. Thus, I would expect the Printer to return the HTTP printer so I can continue with the same scheme I am using with the Get-Job-Attributes request. A printer might second guess me and give me the printer uri that will work best for me. So we need some words in the model document. I address that in the last section. PRINTER-URI VERSUS PRINTER-TLS-URI Finally, this leads me back to printer-uri versus printer-tls-uri. Having both seems to lead to numerous problems. I propose that the value printer-uri for Get-Printer-Attributes be defined as the printer-uri to which the Get-Printer-Attributes was targeted. So if I do Get-Printer-Attributes to "http://foo/bar", printer-uri is "http://foo/bar", and if I do Get-Printer-Attributes to "https://foo/bar", printer-uri is "https://foo/bar". For the rare case, where a client wants the "other" printer name, I suggest an attribute called "printer-alt-name", which is an alternate uri. If I do Get-Printer-Attributes to "http://foo/bar", printer-alt-uri is "https://foo/bar", and if I do Get-Printer-Attributes to "https://foo/bar", printer-alt-uri is "http://foo/bar" WHY IS THIS BETTER? Whether a printer is configured for just HTTP, just HTTPS or both, the value of "printer-uri", as seen by a client, will always be the printer uri to which the client submitted the request and is probably continuing to use. Thus, for the normal case, where the client continually uses a single uri for a printer, where it is HTTP or HTTPS, "printer-uri" holds the printer's name. For the abnormal case, of shifting to a different scheme, the printer-alt-uri is available. From a client's standpoint these are a simple rules. With this definition of printer-uri, the hand-wavy statement in section 8 about "printer-uri" standing for "printer-uri" and "printer-tsl-uri" goes away. Also, with this definition of printer-uri, the operation attribute name of "printer-uri" becomes the obvious choice, and the definition of containing-printer-uri becomes easier. 1) The scheme of the containing-printer-uri shall be the same as the scheme of the printer target of the request used to obtain the attribute. This is not a useful case because the value returned is the same as the printer target, but so is printer-uri. 2) The scheme of the containing-printer-uri shall be the same as the scheme of the job target of the request used to obtain the attribute unless that scheme would not allow the client to perform requests, such as Get-Jobs. 3) The scheme of the containing-printer-uri shall be unrelated to the scheme of the printer to which the job was submitted except by coincidence. From ipp-owner@pwg.org Sat Dec 20 00:48:56 1997 Delivery-Date: Sat, 20 Dec 1997 00:48:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA11710 for ; Sat, 20 Dec 1997 00:48:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA21182 for ; Sat, 20 Dec 1997 00:51:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA09155 for ; Sat, 20 Dec 1997 00:48:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 00:44:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA08587 for ipp-outgoing; Sat, 20 Dec 1997 00:30:30 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Robert.Herriot@Eng.Sun.COM'" Cc: "'ipp@pwg.org'" Subject: RE: IPP>MOD printer-uri/printer-tls-uri issues Date: Fri, 19 Dec 1997 21:27:54 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I have been a proponent of a single URI for some time now. (As many will remember...) The anticipated problems of identifying printer objects with multiple URIs for different capabilities (TLS or no-TLS) will not only arise in implementation, but also in deployment and administration (as I have said before). So the problem is how would we deal with specifying just one URI to identify a printer object, which in some ways is what Bob is proposing (but not exactly). I too would like to see us just use "printer-uri" as our only means of identifying the printer object. Job object URI strings take care of themselves, since they are dynamically generated. I think one way we can do this is through the use of server redirection. Since dynamic creation of job URIs eliminates the need for worrying about job URIs, similarly we could have servers dynamically generate TLS URIs, whether the server is requesting TLS-access OR the client is requesting TLS-access. With the server requesting TLS sessions, the server can just issue a redirect to a TLS-URI when a client attempts to access a particular object to which the server demands TLS access. This type of arrangement would allow the server to set access policy depending upon the type of access the client is requesting. Meaning that the server would allow non-TLS access for get-attributes types of requests, but mandate TLS access for operations which take resources (like create-job). For client-requested TLS sessions, the client would just include an operation-attribute that specifies that the client would like to use TLS, the server would then issue a redirect to a particular URI to which TLS access is allowed. Again, the client can elect to do this type of access depending upon whatever type of operation that the client wishes to be "secure". Just my suggestion for making static URI configuration decisions easier (for both implementers and administrators). Randy > -----Original Message----- > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM] > Sent: Friday, December 19, 1997 7:53 PM > To: ipp@pwg.org > Subject: IPP>MOD printer-uri/printer-tls-uri issues > > While I was putting the finishing touches on the protocol document, > I came across an unresolved issue which opened up a few more. > > NAME OF TARGET IN OPERATIONS ATTRIBUTES > > The initial issue was whether the printer target in the operation > attributes should always be called printer-uri or whether it should be > printer-tls-uri when TLS is being used. A similar question exists for > jobs. > > For job targets, we have only defined a job-uri job attribute, even > for > TLS submitted jobs. So it would seem that the job target operation > attribute should always be job-uri with no special job-tls-uri. > > I decided that the printer target would always be printer-uri, rather > than printer-tls-uri for TLS requests. The code is simpler if it is > always looking for the same attribute, and I couldn't see any reason > for > the redundancy. With the changes I suggest in the third section, > printer-uri becomes the only choice. > > CONTAINING-PRINTER-URI > > But then I realized that containing-printer-uri is defined > ambiguously. If I do Get-Job-Attributes by HTTP to a job submitted > via > HTTPS, do I get back the HTTPS printer or the HTTP printer? > > I am probably not using this attribute to figure out how the job was > submitted, so having it return the HTTPS printer-uri to which it was > submitted isn't useful. > > Instead, I am probably requesting the containing-printer-uri so that I > can do another operation on the job's printer. Thus, I would expect > the > Printer to return the HTTP printer so I can continue with the same > scheme > I am using with the Get-Job-Attributes request. > > A printer might second guess me and give me the printer uri that > will work best for me. > > So we need some words in the model document. I address that in the > last section. > > PRINTER-URI VERSUS PRINTER-TLS-URI > > Finally, this leads me back to printer-uri versus printer-tls-uri. > Having both seems to lead to numerous problems. > > I propose that the value printer-uri for Get-Printer-Attributes be > defined as the printer-uri to which the Get-Printer-Attributes was > targeted. So if I do Get-Printer-Attributes to "http://foo/bar", > printer-uri is "http://foo/bar", and if I do Get-Printer-Attributes to > "https://foo/bar", printer-uri is "https://foo/bar". > > For the rare case, where a client wants the "other" printer name, I > suggest an attribute called "printer-alt-name", which is an alternate > uri. > > If I do Get-Printer-Attributes to "http://foo/bar", printer-alt-uri is > "https://foo/bar", and if I do Get-Printer-Attributes to > "https://foo/bar", printer-alt-uri is "http://foo/bar" > > WHY IS THIS BETTER? > > Whether a printer is configured for just HTTP, just HTTPS or both, the > value of "printer-uri", as seen by a client, will always be the > printer > uri to which the client submitted the request and is probably > continuing to use. Thus, for the normal case, where the client > continually uses a single uri for a printer, where it is HTTP or > HTTPS, > "printer-uri" holds the printer's name. For the abnormal case, of > shifting to a different scheme, the printer-alt-uri is available. From > a client's standpoint these are a simple rules. > > With this definition of printer-uri, the hand-wavy statement in > section 8 > about "printer-uri" standing for "printer-uri" and "printer-tsl-uri" > goes away. > > Also, with this definition of printer-uri, the operation attribute > name > of "printer-uri" becomes the obvious choice, and the definition of > containing-printer-uri becomes easier. > > 1) The scheme of the containing-printer-uri shall be the same as > the scheme of the printer target of the request used to obtain > the attribute. This is not a useful case because the value > returned is the same as the printer target, but so is > printer-uri. > > 2) The scheme of the containing-printer-uri shall be the same as > the scheme of the job target of the request used to obtain the > attribute unless that scheme would not allow the client to > perform requests, such as Get-Jobs. > > 3) The scheme of the containing-printer-uri shall be unrelated > to > the scheme of the printer to which the job was submitted except > by coincidence. > > > From ipp-owner@pwg.org Sat Dec 20 03:47:04 1997 Delivery-Date: Sat, 20 Dec 1997 03:47:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA12243 for ; Sat, 20 Dec 1997 03:47:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA21309 for ; Sat, 20 Dec 1997 03:49:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA10188 for ; Sat, 20 Dec 1997 03:47:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 03:41:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA09608 for ipp-outgoing; Sat, 20 Dec 1997 03:27:41 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 20 Dec 1997 01:24:48 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new 971219 model document posted Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org All, I have posted a new model document at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219-ref.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-08.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.doc MANY thanks to Tom for his editing help. Also, an apology to Tom for not getting in his latest IANA considerations section. I will be sending the posted TXT doc to the IETF Internet-Drafts account. Here is a summary of the changes from since 971107 (the rev version is against 971101) which was the doc issued just prior to the WG final call. 1. Added a new Introduction that gives a better roadmap of not only the model document, but all of the IPP documents. 2. Split Get-Attributes into Get-Job-Attributes and Get-Printer-Attributes 3. Added a new MANDATORY Request ID to each Request and Response 4. Clarified the description of each of the attribute groups 5. Added length constraints for all 'text' and 'name' attribute. Overall, the MAX for 'text' and 'name' went from 4096 to 1024 6. Removed all references to HTTP/1.1 (except for referencing IPP-PRO and examples) 7. Made the target attribute ("printer-uri" for Printer etc) a MANDATORY operation attribute 8. Added -default and generated- and -configured as decided in LA 9. Clarified natural language acceptance rules and Natural Language Override rules 10. Client SHOULD NOT send invalid combo of charset and natural language (Printer will accept) 11. Clarified that "status-message" is an OPTIONAL operation attribute 12. Generally made strict rules on what a sender sends and forgiving rules on what a receiver receives. 13. Removed 3.1.5 and moved it all to section 8 14. Made version rules more practical 15. Encoding rules and order of first bytes in application/ipp is NOT ALLOWED to change (this is op, version, and request id). This will remain consistent across all versions 16. Made compression, job-k-octets, job-media-sheets, and job-impressions operation attributes. Aligned these with Job MIB 17. Clarified Unsupported Attributes group in responses and made it possible for ALL operations to return unsupported attributes 18. Added 'no-value' out-of-band value and made better rules for 'unknown' 19. Added 'textWithLanguage' and 'nameWithLanguage' 20. Removed "copies-collated-*" 21. Made priority default apply at submission time 22. Clarified that page ranges are ascending, non-overlapping 23. Removed '0' for n-up 24. "media-ready" is OPTIONAL 25. Added an ALL new security section (TLS vs non-TLS, Printers OPTOINALLY support TLS, clients SHOULD support TLS, added "printer-tls-uri", etc.) 26. Defined categories for text and name attributes (catagorized by source of value client vs Printer vs operator vs admin vs vendor etc) Placed name and text attributes in each catagory. Gave better rules for which supported and which defaults apply to which categories 27. Fixed up rules for 'requeting-user-name" vs authentication service name and which is which and who each applies to "job-originating-user" 28. Provided a TLS ciphersuite profile for IPP 29. Added 'not-accepting-jobs' error code 30. All new 15.3 and 15.4 sections on suggested steps for validating operations From ipp-owner@pwg.org Sat Dec 20 04:20:35 1997 Delivery-Date: Sat, 20 Dec 1997 04:20:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA12354 for ; Sat, 20 Dec 1997 04:20:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA21350 for ; Sat, 20 Dec 1997 04:23:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA10858 for ; Sat, 20 Dec 1997 04:20:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 04:15:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA10274 for ipp-outgoing; Sat, 20 Dec 1997 04:01:35 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Scott Isaacson'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> MOD - new 971219 model document posted Date: Sat, 20 Dec 1997 00:58:56 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I thought the wording for client support of TLS was MUST and not SHOULD? Randy > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Saturday, December 20, 1997 12:25 AM > To: ipp@pwg.org > Subject: IPP> MOD - new 971219 model document posted > > All, > > I have posted a new model document at: > > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.pdf > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219-ref.pdf > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-08.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.doc > > MANY thanks to Tom for his editing help. Also, an apology to Tom for > not getting in his latest IANA considerations section. > > I will be sending the posted TXT doc to the IETF Internet-Drafts > account. > > Here is a summary of the changes from since 971107 (the rev version is > against 971101) which was the doc issued just prior to the WG final > call. > > 1. Added a new Introduction that gives a better roadmap of not only > the > model document, but all of the IPP documents. > > 2. Split Get-Attributes into Get-Job-Attributes and > Get-Printer-Attributes > > 3. Added a new MANDATORY Request ID to each Request and Response > > 4. Clarified the description of each of the attribute groups > > 5. Added length constraints for all 'text' and 'name' attribute. > Overall, > the MAX for 'text' and 'name' went from 4096 to 1024 > > 6. Removed all references to HTTP/1.1 (except for referencing IPP-PRO > and > examples) > > 7. Made the target attribute ("printer-uri" for Printer etc) a > MANDATORY > operation attribute > > 8. Added -default and generated- and -configured as decided in LA > > 9. Clarified natural language acceptance rules and Natural Language > Override rules > > 10. Client SHOULD NOT send invalid combo of charset and natural > language > (Printer will accept) > > 11. Clarified that "status-message" is an OPTIONAL operation attribute > > 12. Generally made strict rules on what a sender sends and forgiving > rules > on what a receiver receives. > > 13. Removed 3.1.5 and moved it all to section 8 > > 14. Made version rules more practical > > 15. Encoding rules and order of first bytes in application/ipp is NOT > ALLOWED to change (this is op, version, and request id). This will > remain > consistent across all versions > > 16. Made compression, job-k-octets, job-media-sheets, and > job-impressions > operation attributes. Aligned these with Job MIB > > 17. Clarified Unsupported Attributes group in responses and made it > possible for ALL operations to return unsupported attributes > > 18. Added 'no-value' out-of-band value and made better rules for > 'unknown' > > 19. Added 'textWithLanguage' and 'nameWithLanguage' > > 20. Removed "copies-collated-*" > > 21. Made priority default apply at submission time > > 22. Clarified that page ranges are ascending, non-overlapping > > 23. Removed '0' for n-up > > 24. "media-ready" is OPTIONAL > > 25. Added an ALL new security section (TLS vs non-TLS, Printers > OPTOINALLY > support TLS, clients SHOULD support TLS, added "printer-tls-uri", > etc.) > > 26. Defined categories for text and name attributes (catagorized by > source > of value client vs Printer vs operator vs admin vs vendor etc) Placed > name > and text attributes in each catagory. Gave better rules for which > supported > and which defaults apply to which categories > > 27. Fixed up rules for 'requeting-user-name" vs authentication service > name > and which is which and who each applies to "job-originating-user" > > 28. Provided a TLS ciphersuite profile for IPP > > 29. Added 'not-accepting-jobs' error code > > 30. All new 15.3 and 15.4 sections on suggested steps for validating > operations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Sat Dec 20 10:00:52 1997 Delivery-Date: Sat, 20 Dec 1997 10:00:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13278 for ; Sat, 20 Dec 1997 10:00:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21526 for ; Sat, 20 Dec 1997 10:03:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA11724 for ; Sat, 20 Dec 1997 10:00:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 09:49:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA11134 for ipp-outgoing; Sat, 20 Dec 1997 09:36:00 -0500 (EST) Message-Id: <3.0.1.32.19971220063145.00ca27b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 20 Dec 1997 06:31:45 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO latest protocol and lpd drafts [plus the .pdf files] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've distilled the corresponding .pdf files: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-971219.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-971219-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-971219.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-971219-rev.pdf Tom >Date: Fri, 19 Dec 1997 17:43:42 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO latest protocol and lpd drafts >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > >I have downloaded the latest protocol and lpd documents to: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > >The documents are: > > ipp-pro-971219.doc MS Word Version 6 with no revisions > ipp-pro-971219.txt text no revisions > ipp-pro-971219-rev.doc MS Word Version 6 with revisions > ipp-lpd-971219.doc MS Word Version 6 with no revisions > ipp-lpd-971219.txt text with no revisions > ipp-lpd-971219-rev.doc MS Word Version 6 with revisions > >One issue about printer-uri versus printer-tls-uri came up during >editing. It will be in a separate email. > > > From ipp-owner@pwg.org Sat Dec 20 10:17:02 1997 Delivery-Date: Sat, 20 Dec 1997 10:17:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13334 for ; Sat, 20 Dec 1997 10:17:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21536 for ; Sat, 20 Dec 1997 10:19:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA12373 for ; Sat, 20 Dec 1997 10:16:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 10:12:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA11553 for ipp-outgoing; Sat, 20 Dec 1997 09:57:11 -0500 (EST) Message-Id: <3.0.1.32.19971220065302.00c45e00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 20 Dec 1997 06:53:02 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP>MOD printer-uri/printer-tls-uri issues In-Reply-To: <199712200352.TAA27718@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I think Bob has come up with a significant problem and a good solution. I suggest that the alternate URI attribute be printer-alt-uri, not printer-alt-name. And perhaps we should spell it out: printer-alternate-uri. It is an easy fix to the Model document, since it uses printer-uri throughout. Primarly the renamed section 4.2.2 printer-alternate-uri needs updating to explain and so does containing-printer-uri, as Bob explains. Maybe section 8, though I moved the paragraph about the two attributes from 8 to 4.2.2. For the Directory schema, I guess there could be the same two attributes: printer-uri printer-alternative-uri But which one would be the more secure? Do we need a convention? Another ISSUE. Before printer-uri and printer-tls-uri were both MANDATORY. Do we continue that, or does the printer-alternate-uri become OPTIONAL, only being supported by printers that do both? Another advantage of this change, is that the application/ipp payload can be stored away, without having to change the attribute name of the target printer in the application/ipp data. My understanding is that there is no problem with issuing a new Internet-Draft immediately after another one. Tom At 19:52 12/19/1997 PST, Robert Herriot wrote: >While I was putting the finishing touches on the protocol document, >I came across an unresolved issue which opened up a few more. > >NAME OF TARGET IN OPERATIONS ATTRIBUTES > >The initial issue was whether the printer target in the operation >attributes should always be called printer-uri or whether it should be >printer-tls-uri when TLS is being used. A similar question exists for >jobs. > >For job targets, we have only defined a job-uri job attribute, even for >TLS submitted jobs. So it would seem that the job target operation >attribute should always be job-uri with no special job-tls-uri. > >I decided that the printer target would always be printer-uri, rather >than printer-tls-uri for TLS requests. The code is simpler if it is >always looking for the same attribute, and I couldn't see any reason for >the redundancy. With the changes I suggest in the third section, >printer-uri becomes the only choice. > >CONTAINING-PRINTER-URI > >But then I realized that containing-printer-uri is defined >ambiguously. If I do Get-Job-Attributes by HTTP to a job submitted via >HTTPS, do I get back the HTTPS printer or the HTTP printer? > >I am probably not using this attribute to figure out how the job was >submitted, so having it return the HTTPS printer-uri to which it was >submitted isn't useful. > >Instead, I am probably requesting the containing-printer-uri so that I >can do another operation on the job's printer. Thus, I would expect the >Printer to return the HTTP printer so I can continue with the same scheme >I am using with the Get-Job-Attributes request. > >A printer might second guess me and give me the printer uri that >will work best for me. > >So we need some words in the model document. I address that in the >last section. > >PRINTER-URI VERSUS PRINTER-TLS-URI > >Finally, this leads me back to printer-uri versus printer-tls-uri. >Having both seems to lead to numerous problems. > >I propose that the value printer-uri for Get-Printer-Attributes be >defined as the printer-uri to which the Get-Printer-Attributes was >targeted. So if I do Get-Printer-Attributes to "http://foo/bar", >printer-uri is "http://foo/bar", and if I do Get-Printer-Attributes to >"https://foo/bar", printer-uri is "https://foo/bar". > >For the rare case, where a client wants the "other" printer name, I >suggest an attribute called "printer-alt-name", which is an alternate uri. > >If I do Get-Printer-Attributes to "http://foo/bar", printer-alt-uri is >"https://foo/bar", and if I do Get-Printer-Attributes to >"https://foo/bar", printer-alt-uri is "http://foo/bar" > >WHY IS THIS BETTER? > >Whether a printer is configured for just HTTP, just HTTPS or both, the >value of "printer-uri", as seen by a client, will always be the printer >uri to which the client submitted the request and is probably >continuing to use. Thus, for the normal case, where the client >continually uses a single uri for a printer, where it is HTTP or HTTPS, >"printer-uri" holds the printer's name. For the abnormal case, of >shifting to a different scheme, the printer-alt-uri is available. From >a client's standpoint these are a simple rules. > >With this definition of printer-uri, the hand-wavy statement in section 8 >about "printer-uri" standing for "printer-uri" and "printer-tsl-uri" >goes away. > >Also, with this definition of printer-uri, the operation attribute name >of "printer-uri" becomes the obvious choice, and the definition of >containing-printer-uri becomes easier. > > 1) The scheme of the containing-printer-uri shall be the same as > the scheme of the printer target of the request used to obtain > the attribute. This is not a useful case because the value > returned is the same as the printer target, but so is > printer-uri. > > 2) The scheme of the containing-printer-uri shall be the same as > the scheme of the job target of the request used to obtain the > attribute unless that scheme would not allow the client to > perform requests, such as Get-Jobs. > > 3) The scheme of the containing-printer-uri shall be unrelated to > the scheme of the printer to which the job was submitted except > by coincidence. > > > > > > From ipp-owner@pwg.org Sat Dec 20 10:56:00 1997 Delivery-Date: Sat, 20 Dec 1997 10:56:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13469 for ; Sat, 20 Dec 1997 10:55:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21563 for ; Sat, 20 Dec 1997 10:58:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA12995 for ; Sat, 20 Dec 1997 10:55:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 10:51:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA12452 for ipp-outgoing; Sat, 20 Dec 1997 10:38:16 -0500 (EST) Date: Sat, 20 Dec 1997 07:43:00 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9712201543.AA16598@snorkel.eso.mc.xerox.com> To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu Subject: Re: IPP> Re: ADM - Draft minutes [client security issues] Cc: Robert.Herriot@eng.sun.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org Sender: ipp-owner@pwg.org Hi Harald and Keith, The irony that I'm now cast as an apologist for leaving out security in networks has given me wonderful amusement for the last three days. Both here at Xerox and in the past 24 years, I have done significant design and development work on security protocols and standards. I do NOT advocate leaving out security in IPP. By a logic that escapes me entirely, it has been collectively deemed 'cheaper' for all IPP clients to implement TLS, rather than all IPP printers. That apparent concensus is heavily weighted by the backgrounds of the participants. I capitulate. Let all IPP clients implement TLS (with the one mandatory cipher suite, without encumbered technology). Cheers, - Ira McDonald (outside consultant at Xerox) From ipp-owner@pwg.org Sat Dec 20 12:35:40 1997 Delivery-Date: Sat, 20 Dec 1997 12:35:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14203 for ; Sat, 20 Dec 1997 12:35:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21697 for ; Sat, 20 Dec 1997 12:38:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA13898 for ; Sat, 20 Dec 1997 12:35:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 12:29:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13146 for ipp-outgoing; Sat, 20 Dec 1997 12:15:06 -0500 (EST) Message-Id: <1.5.4.32.19971220161633.00678b28@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, 20 Dec 1997 08:16:33 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>MOD printer-uri/printer-tls-uri issues Sender: ipp-owner@pwg.org At 06:53 AM 12/20/97 PST, you wrote: >My understanding is that there is no problem with issuing a new >Internet-Draft immediately after another one. > >Tom > Tom, Even so, I would like to give people a chance to read through the whole document before we issue yet another new draft. Carl-Uno From ipp-owner@pwg.org Sat Dec 20 15:20:55 1997 Delivery-Date: Sat, 20 Dec 1997 15:20:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14710 for ; Sat, 20 Dec 1997 15:20:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA21832 for ; Sat, 20 Dec 1997 15:23:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14694 for ; Sat, 20 Dec 1997 15:20:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 20 Dec 1997 14:33:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14059 for ipp-outgoing; Sat, 20 Dec 1997 14:19:19 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Tom Hastings'" Cc: "'ipp@pwg.org'" Subject: RE: IPP>MOD printer-uri/printer-tls-uri issues Date: Sat, 20 Dec 1997 11:15:48 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I would still like to see us remove the printer-tls-uri (or printer-alt-uri, whatever...). Having a single URI to reference the printer object removes all of the problems Bob has discovered, and many other deployment problems we haven't discovered yet. And I think we can accomplish this with the addition of a single operation attribute on all requests. Randy > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Saturday, December 20, 1997 6:53 AM > To: Robert.Herriot@Eng.Sun.COM; ipp@pwg.org > Subject: Re: IPP>MOD printer-uri/printer-tls-uri issues > > I think Bob has come up with a significant problem and a good > solution. > > I suggest that the alternate URI attribute be printer-alt-uri, not > printer-alt-name. And perhaps we should spell it out: > printer-alternate-uri. > > It is an easy fix to the Model document, since it uses printer-uri > throughout. Primarly the renamed section 4.2.2 printer-alternate-uri > needs updating to explain and so does containing-printer-uri, as Bob > explains. Maybe section 8, though I moved the paragraph about the > two attributes from 8 to 4.2.2. > > For the Directory schema, I guess there could be the same two > attributes: > printer-uri > printer-alternative-uri > > But which one would be the more secure? Do we need a convention? > > Another ISSUE. Before printer-uri and printer-tls-uri were both > MANDATORY. Do we continue that, or does the printer-alternate-uri > become OPTIONAL, only being supported by printers that do both? > > Another advantage of this change, is that the application/ipp payload > can be stored away, without having to change the attribute name of > the target printer in the application/ipp data. > > My understanding is that there is no problem with issuing a new > Internet-Draft immediately after another one. > > Tom > > > At 19:52 12/19/1997 PST, Robert Herriot wrote: > >While I was putting the finishing touches on the protocol document, > >I came across an unresolved issue which opened up a few more. > > > >NAME OF TARGET IN OPERATIONS ATTRIBUTES > > > >The initial issue was whether the printer target in the operation > >attributes should always be called printer-uri or whether it should > be > >printer-tls-uri when TLS is being used. A similar question exists for > >jobs. > > > >For job targets, we have only defined a job-uri job attribute, even > for > >TLS submitted jobs. So it would seem that the job target operation > >attribute should always be job-uri with no special job-tls-uri. > > > >I decided that the printer target would always be printer-uri, rather > >than printer-tls-uri for TLS requests. The code is simpler if it is > >always looking for the same attribute, and I couldn't see any reason > for > >the redundancy. With the changes I suggest in the third section, > >printer-uri becomes the only choice. > > > >CONTAINING-PRINTER-URI > > > >But then I realized that containing-printer-uri is defined > >ambiguously. If I do Get-Job-Attributes by HTTP to a job submitted > via > >HTTPS, do I get back the HTTPS printer or the HTTP printer? > > > >I am probably not using this attribute to figure out how the job was > >submitted, so having it return the HTTPS printer-uri to which it was > >submitted isn't useful. > > > >Instead, I am probably requesting the containing-printer-uri so that > I > >can do another operation on the job's printer. Thus, I would expect > the > >Printer to return the HTTP printer so I can continue with the same > scheme > >I am using with the Get-Job-Attributes request. > > > >A printer might second guess me and give me the printer uri that > >will work best for me. > > > >So we need some words in the model document. I address that in the > >last section. > > > >PRINTER-URI VERSUS PRINTER-TLS-URI > > > >Finally, this leads me back to printer-uri versus printer-tls-uri. > >Having both seems to lead to numerous problems. > > > >I propose that the value printer-uri for Get-Printer-Attributes be > >defined as the printer-uri to which the Get-Printer-Attributes was > >targeted. So if I do Get-Printer-Attributes to "http://foo/bar", > >printer-uri is "http://foo/bar", and if I do Get-Printer-Attributes > to > >"https://foo/bar", printer-uri is "https://foo/bar". > > > >For the rare case, where a client wants the "other" printer name, I > >suggest an attribute called "printer-alt-name", which is an alternate > uri. > > > >If I do Get-Printer-Attributes to "http://foo/bar", printer-alt-uri > is > >"https://foo/bar", and if I do Get-Printer-Attributes to > >"https://foo/bar", printer-alt-uri is "http://foo/bar" > > > >WHY IS THIS BETTER? > > > >Whether a printer is configured for just HTTP, just HTTPS or both, > the > >value of "printer-uri", as seen by a client, will always be the > printer > >uri to which the client submitted the request and is probably > >continuing to use. Thus, for the normal case, where the client > >continually uses a single uri for a printer, where it is HTTP or > HTTPS, > >"printer-uri" holds the printer's name. For the abnormal case, of > >shifting to a different scheme, the printer-alt-uri is available. > From > >a client's standpoint these are a simple rules. > > > >With this definition of printer-uri, the hand-wavy statement in > section 8 > >about "printer-uri" standing for "printer-uri" and "printer-tsl-uri" > >goes away. > > > >Also, with this definition of printer-uri, the operation attribute > name > >of "printer-uri" becomes the obvious choice, and the definition of > >containing-printer-uri becomes easier. > > > > 1) The scheme of the containing-printer-uri shall be the same as > > the scheme of the printer target of the request used to obtain > > the attribute. This is not a useful case because the value > > returned is the same as the printer target, but so is > > printer-uri. > > > > 2) The scheme of the containing-printer-uri shall be the same as > > the scheme of the job target of the request used to obtain the > > attribute unless that scheme would not allow the client to > > perform requests, such as Get-Jobs. > > > > 3) The scheme of the containing-printer-uri shall be unrelated > to > > the scheme of the printer to which the job was submitted except > > by coincidence. > > > > > > > > > > > > From ipp-owner@pwg.org Sun Dec 21 03:10:53 1997 Delivery-Date: Sun, 21 Dec 1997 03:10:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA00737 for ; Sun, 21 Dec 1997 03:10:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA00252 for ; Sun, 21 Dec 1997 03:13:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA16005 for ; Sun, 21 Dec 1997 03:10:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 21 Dec 1997 03:02:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA15437 for ipp-outgoing; Sun, 21 Dec 1997 02:49:06 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Additional proposal details Date: Sat, 20 Dec 1997 23:46:28 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD0DA1.7E4CA590" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD0DA1.7E4CA590 Content-Type: text/plain Please review the attached details to the proposal I loosely suggested earlier. This proposal addresses Bob's concerns with the problems of printer-uri and printer-tls-uri handling... Randy ------ =_NextPart_000_01BD0DA1.7E4CA590 Content-Type: text/plain; name="redir.txt" Content-Disposition: attachment; filename="redir.txt" TLS Redirection Modifications The following changes to the model document would be required in order to support my earlier redirection proposal. The changes appear to be simple, and would allow us to use the term "printer-uri" throughout the document, without all the "hand waving" (similar to Bob's proposal). Section 3.1.3.2 Response Operation Attributes An additional operation response attribute would be defined: server-redirect-uri This is a generic redirect (not TLS specific) that allows servers to redirect requests to another URI. NOTE: The redirect only applies to each request. A client should not assume the lifetime of a redirect to last beyond the particular request that was originally redirected. clients MUST recognize and use redirects. ---- For all operations, an additional operation attribute MAY be included by clients: client-TLS-requested This attribute would indicate to the server that the client wishes to use TLS for the session. If the server supports TLS, it would return the generic redirect response attribute described above. If the server DOES NOT support TLS, then the server would return the "scheme-not-supported" error code to the client. ---- On a get-printer-attributes request, the "printer-uri" returned would always be the URI that was used to issue the get-attributes request (like Bob's proposal) On a get-job-attributes request, the "containing-printer-uri" would be either the base "printer-uri" (non-TLS), or a redirected TLS URI that was actually used to submit the job. I submit that we can leave this up to implementations since I think the client results would be the same. ---- On a get-jobs request to a printer-uri, the "containing-printer-uri" attribute returned for each job would be implementation-specific. It would either be the "printer-URI" (non-TLS) for the printer, or it could be a redirected TLS URI. This needs to be implementation-specific so as to allow servers to decide how job- specific information is displayed for a particular client. -- In addition to addressing Bob's concerns with printer-uri and printer-tls-uri, this proposal also offers the following advantages: -- It allows a TLS-capable server the ability to only require TLS negotiation for particular operations that require the server to allocate resources. For instance, a server that requires all print jobs to be authenticated might still want all clients to be able to get attributes for the printer, as well as validate job parameters, without going to the expense of performing TLS negotiation. It basically allows an administrator to decide what types of operations should be authenticated. In the current spec, ALL operations are authenticated or NONE are. This is a nice scalability feature -- We no longer have to worry about publishing multiple URI strings in directories or other places in order to support TLS sessions to a server. There's only one URI for the printer. If a client attempts an operation to the printer URI, and the server deems that authentication is required, then it automatically issues a redirect, similar to the way current web browsers bounce back and forth from SSL and non-SSL connections to a a particular web "service". ------ =_NextPart_000_01BD0DA1.7E4CA590-- From owner-nat@livingston.com Sun Dec 21 11:09:21 1997 Delivery-Date: Sun, 21 Dec 1997 11:09:21 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA02192 for ; Sun, 21 Dec 1997 11:09:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA24661; Sun, 21 Dec 1997 08:03:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA28431 for nat-outgoing; Sun, 21 Dec 1997 08:05:25 -0800 (PST) Message-Id: <349D1D63.6A07@hursley.ibm.com> Date: Sun, 21 Dec 1997 13:45:07 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: Philippe OECHSLIN Cc: Kjeld Borch Egevang , nat@livingston.com Subject: Re: (NAT) tcp options and non-routable names References: <2235.882464846@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Brian E Carpenter It would certainly be exceedingly anti-social to deploy a NAT that silently discards SACK. In general the proposal to silently discard non-understood TCP options is very worrying, since it will lead to horrendous debugging problems if the option is actually doing something necessary. Brian Carpenter >-- Philippe OECHSLIN wrote: > > > > I propose that we add a section saying that the nat should look out > > > for TCP option negociation in syn and syn-ack segments. If it sees > > > an option it doesn't know, it should silently remove it. If it sees > > > an option it can handle, it should register it in the translation > > > table and handle sequence numbers (or other fields) accordingly. > > > > > I think it is very unlikely to find an FTP implementation which use > > some of the more exotic options of TCP or IP. > > Well, TCP options and FTP are independent. > > For example, most new protocol stacks now implement window scale option, > although it is disabled by default. If you configure a host to use window > scale option, then any application running on TCP will negociate that option > without the application being aware of it. > > Sack TCP is another option which will most likely be deployed in the next > years. > > There is a lot of concern in the IETF about things that NAT or NAPT can break. > I think that TCP options is one of these. We should not wish it away but > rather document the problem and its workaround in the NAT draft. > > Philippe > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe nat' in the body of the message. > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From ipp-owner@pwg.org Mon Dec 22 12:59:41 1997 Delivery-Date: Mon, 22 Dec 1997 12:59:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA20622 for ; Mon, 22 Dec 1997 12:59:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA02693 for ; Mon, 22 Dec 1997 13:02:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA19663 for ; Mon, 22 Dec 1997 12:59:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Dec 1997 12:53:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19080 for ipp-outgoing; Mon, 22 Dec 1997 12:39:21 -0500 (EST) Message-Id: <3.0.1.32.19971222093423.00f99cd0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 22 Dec 1997 09:34:23 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - FYI: RESEND: PWG Standard Job Monitoring MIB, V1, posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org For those IPP folks that are on neither the PWG list nor the JMP list, we finished the PWG Job Monitoring MIB which has a lot of compatibility with IPP, while also being useful for monitoring devices and servers that supports any job submission protocol. Tom >X-Sender: hastings@garfield >Date: Sun, 21 Dec 1997 23:23:47 PST >To: jmp@pwg.org >From: Tom Hastings >Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted >Cc: pwg@pwg.org >Sender: jmp-owner@pwg.org > >I finshed the edits that Ron and Harry found proof reading a week ago's >version of the MIB and posted them on the PWG server. This was to be the >Internet-Draft that was to be forwarded to the IESG for their four week >review in order to become an informational RFC as the first PWG standard! > >Unfortunately, there are a few minor problems with the .txt version >(extracting plain text from MS-WORD is still tricky business, especially >when switching from WORD6 to WORD97), so I haven't >actually forwarded the .txt form to the internet-drafts DL. > >I'll confer with Ron Bergman on Monday, to see if he still wants me to >send the .txt file that I just posted as an Internet-Draft or wait until >January 5, when I'm back in the office. See below for an explanation. > > >Here is the introduction that Ron and I crafted: > >This specification defines an official Printer Working Group (PWG) [PWG] >standard SNMP MIB for the monitoring of jobs on network printers. This >specification is being published as an IETF Information Document for the >convenience of the Internet community. In consultation with the IETF >Application Area Directors, we concluded that it properly belongs as an >Information document, because this MIB monitors a service node on >the network, rather than a network node proper. > > >After the cover sheet, its labeled V1 (IETF won't allow "." in the subject >line). The .txt version doesn't have the cover sheet. > >I edited all of the agreements from Harry's minutes from the L.A. meeting, >12/05/97. > >There are still a few minor problems with the plain text version only. >(The .doc and .pdf versions are fine): > >a. I was able to use my generic text driver at home where I also have WORD97 >and which produced a proper .txt file with cross references. But I forgot >to re-do the table of contents and index with the fixed pitch fonts, so >the page numbers are off by 0 to 10 pages. > >b. Also the AttributeTypeTC definition is too big for the Sun version of the >SMICng compiler I was using; it bombs out saying object too big! >However, it does compile with the Epilogue and the MOSY compilers. > >c. Finally, the text file meets the IETF standards: > - no special characters, except FF and LF. > - line length, almost: there are 275 lines with 73 characters, instead of 72 >Just another bug that MS-WORD 97 and/or the generic text driver have >introduced. > >The files are: > >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-word97.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-red.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev-word97.doc > >The .txt file is the one that was supposed to be sent as an Internet-Draft. > >The "rev" files are with revisions since the V0.86 version which was >released after the 10/31 meeting. > >The changes are: > >1. use the new PWG OIDs without the standard arc: > ... enterprises pwg(2699) jobmon(1) > >2. make the document an official PWG standard that will be sent as an >Informational Internet-Draft that will become an IETF Informational RFC, >including changing the IANA Considerations section not to use IANA, but >to use PWG registration. > >3. add natural language support like IPP, as distributed to the DL >before the L.A. meeting: >processingMessageNaturalLanguageTag(7) - language of processingMessage >jobNaturalLanguageTag(9) - language of job strings > >4. clarify that the processingMessage is intended to be for messages >generated during processing of the job, such as from the interpreter, >which is not the same as IPP "job-state-message" which is just a printable >form of "job-state" and "job-state-reasons", and that IPP doesn't have an >equivalent of processingMessage (because programs would want to parse >to take action on the message from the interpreter). These were important >clarifications from the IPP WG discussions. > > >5. fixed the issues with monitoring collated/uncollated implementations, >adding the jobCollationType attribute as agreed at the L.A. meeting: > >JmJobCollationTypeTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This value is the type of job collation. Implementations that > don't support multiple documents or don't support multiple copies > SHALL NOT support the uncollatedDocuments(5) value." > REFERENCE > "This is a type 2 enumeration. See Section 3.7.1.2. See also > Section 3.4, entitled 'Monitoring Job Progress'." > SYNTAX INTEGER { > other(1), > unknown(2), > uncollatedSheets(3), -- sheets within each document copy > -- are not collated: 1 1 ..., 2 2 ..., > collatedDocuments(4), -- internal collated sheets, > -- documents: A, B, A, B, ... > uncollatedDocuments(5) -- internal collated sheets, > -- documents: A, A, ..., B, B, ... > } > > >6. fix impressions completed, so it counts the number of sides stacked >independent of how the intepreter produces multiple copies. > >7. allows multiple Job Submission Id entries to point to the same >jmJobIndex entry > >8. added 3 new Job Submission Ids for: NetWare PServer ('B'), Server >Message Block protocol (SMB) ('C'), Transport Independent Printer/System >Interface (TIP/SI) ('D'). > >9. sort the terminology alphabetically as requested > >10. clarify how JmJobStringTC can be used with client localized strings >or with keywords which are not localized (they are in US-ASCII, U.S. >English), >like IPP. > > >Tom > > > > From ipp-owner@pwg.org Mon Dec 22 18:28:22 1997 Delivery-Date: Mon, 22 Dec 1997 18:28:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA25074 for ; Mon, 22 Dec 1997 18:28:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA03888 for ; Mon, 22 Dec 1997 18:31:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA20591 for ; Mon, 22 Dec 1997 18:28:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Dec 1997 18:22:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20001 for ipp-outgoing; Mon, 22 Dec 1997 18:08:51 -0500 (EST) From: "Rajesh Chawla" To: Subject: IPP> charset type vs charset printer attribute Date: Mon, 22 Dec 1997 18:05:23 -0500 Message-ID: <01bd0f2e$15468fa0$8dc245c6@rajesh.ari.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org Hi folks, The use of charset as a type and charset as a printer attribute is causing me problems in my implementation. What I want to do is to create an ascii file of IPP attributes that I can parse and then send to the printer using IPP. The grammar I'm working with parses lines of the following format: '=' ';' It becomes difficult to correctly parse the following line: charset charset = "en"; It would make my life a lot easier if the charset attribute name for printers changed to "printer-charset". Regards, Rajesh From ipp-owner@pwg.org Mon Dec 22 21:33:10 1997 Delivery-Date: Mon, 22 Dec 1997 21:33:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA26344 for ; Mon, 22 Dec 1997 21:33:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA04161 for ; Mon, 22 Dec 1997 21:35:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA21334 for ; Mon, 22 Dec 1997 21:33:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Dec 1997 21:27:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA20747 for ipp-outgoing; Mon, 22 Dec 1997 21:13:39 -0500 (EST) Date: Mon, 22 Dec 1997 18:09:38 -0800 (Pacific Standard Time) From: Ron Bergman To: robert.herriot@eng.sun.com cc: ipp@pwg.org Subject: IPP> PRO> Editorial Correction Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Bob, I just noticed that the name of my employeer has reverted to the old incorrect spelling. Could you please correct to either; Dataproducts Corp. -or- Dataproducts Thanks, Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Tue Dec 23 18:34:13 1997 Delivery-Date: Tue, 23 Dec 1997 18:34:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA17050 for ; Tue, 23 Dec 1997 18:33:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06615 for ; Tue, 23 Dec 1997 18:36:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA22977 for ; Tue, 23 Dec 1997 18:33:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Dec 1997 18:24:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22383 for ipp-outgoing; Tue, 23 Dec 1997 18:10:29 -0500 (EST) Date: Tue, 23 Dec 1997 15:14:57 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9712232314.AA17790@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rajesh@trcs.com Subject: Re: IPP> charset type vs charset printer attribute Sender: ipp-owner@pwg.org Hi Rajesh, Tuesday (23 December 1997) Your problem is fixed. This printer attribute has been renamed (for clarity) to "charset-configured", in the latest draft of the IPP Model (dated 19 December 1997) posted on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-08.txt Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PS - See also the related printer attributes "charset-supported", "generated-natural-language-supported", and "natural-language-configured". >----------------------------------------------------------------------< >From: "Rajesh Chawla" >To: >Subject: IPP> charset type vs charset printer attribute >Date: Mon, 22 Dec 1997 15:05:23 PST > >Hi folks, > >The use of charset as a type and charset as a printer attribute is >causing me problems in my implementation. > >What I want to do is to create an ascii file of IPP attributes that I can >parse and then send to the printer using IPP. The grammar I'm working >with parses lines of the following format: > > '=' ';' > >It becomes difficult to correctly parse the following line: > > charset charset = "en"; > >It would make my life a lot easier if the charset attribute name for >printers changed to "printer-charset". > >Regards, >Rajesh > From ipp-owner@pwg.org Tue Dec 30 20:32:58 1997 Delivery-Date: Tue, 30 Dec 1997 20:32:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA13842 for ; Tue, 30 Dec 1997 20:32:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05383 for ; Tue, 30 Dec 1997 20:35:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04522 for ; Tue, 30 Dec 1997 20:32:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 30 Dec 1997 20:22:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03946 for ipp-outgoing; Tue, 30 Dec 1997 20:09:06 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> FW: User Petition on Standards to Netscape and Microsoft Date: Tue, 30 Dec 1997 17:06:08 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org This is part of an interesting thread going on regarding the pros and cons of binary vs. ascii encodings of application layer protocols...The central theme being the use of ABNF for specifying text-based application protocols vs. ASN.1 for specifying binary application protocols. Apparently, we (the IPP WG) are breaking new ground in our use of ABNF for essentially a binary protocol. It doesn't appear that the essence of ABNF was designed for this... Randy > -----Original Message----- > From: Chris Newman [SMTP:Chris.Newman@innosoft.com] > Sent: Tuesday, December 30, 1997 4:43 PM > To: Stephen Kent > Cc: ietf@ns.ietf.org > Subject: Re: User Petition on Standards to Netscape and Microsoft > > On Tue, 30 Dec 1997, Stephen Kent wrote: > > I would not disagree with the characterization of textual > protocols > > as easier to debug without the need for more sophisticated tools. > However, > > debugging ease is not the only consideration when designing > protocols. IP, > > TCP, UDP, PPP, and other widely used Internet protocols are not > textual, > > yet we have managed to debug them and deploy interoperable > implementations > > for many years. We respectually disagree about the relative merits > of > > using non-textual syntax for protocols, whether it's ASN.1 or > alternatives. > > If you read my message carefully, you will note that I said > "application > protocols." The four protocols you've listed are not application > protocols and therefore have different design criteria (which tend to > discourage the use of ASN.1 for different reasons). > > The most successful IETF binary-encoded application protocol is > Telnet, > which is generally considered a good example of how not to design a > protocol (due to the complexity of option negotiation and debugging > thereof). It took me significantly longer to write and debug a telnet > client than it took me to write and debug clients/servers for textual > protocols. I had to build a complex debugging service into the client > which I've never needed in textual protocols. I will note that telnet > has > orders of magnitude more deployment than its ASN.1 based counterpart > which > is yet another strike against ASN.1, even when a binary encoding is > used. > > As an application protocol developer, I trust the judgement of > lower-level > protocol developers to make the right choice in the binary vs. text > encoding tradeoff. But at the applications level, both IETF history > and > my personal experience weigh heavily in favor of textual protocols. > Let's > not ignore our successful history. > > - Chris From adm Wed Dec 31 11:12:22 1997 Delivery-Date: Wed, 31 Dec 1997 11:20:47 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA28823 for ietf-123-outbound.10@ietf.org; Wed, 31 Dec 1997 11:12:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA26474; Wed, 31 Dec 1997 10:08:58 -0500 (EST) Message-Id: <199712311508.KAA26474@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-04.txt Date: Wed, 31 Dec 1997 10:08:58 -0500 Sender: cclark@cnri.reston.va.us --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) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-04.txt Pages : 8 Date : 30-Dec-97 This document describes a protocol intended to provide lossless compression for Internet Protocol 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-04.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: <19971230113232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971230113232.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jan 2 10:08:19 1998 Delivery-Date: Fri, 02 Jan 1998 10:08:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02200 for ; Fri, 2 Jan 1998 10:08:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09018 for ; Fri, 2 Jan 1998 10:11:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09015 for ; Fri, 2 Jan 1998 10:08:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 09:55:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA07857 for ipp-outgoing; Fri, 2 Jan 1998 09:29:58 -0500 (EST) Message-Id: <199801021428.JAA01051@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-08.txt Date: Fri, 02 Jan 1998 09:28:24 -0500 Sender: ipp-owner@pwg.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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-08.txt Pages : 174 Date : 31-Dec-97 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-08.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: <19971231143850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231143850.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jan 2 10:08:21 1998 Delivery-Date: Fri, 02 Jan 1998 10:08:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02205 for ; Fri, 2 Jan 1998 10:08:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09019 for ; Fri, 2 Jan 1998 10:11:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09012 for ; Fri, 2 Jan 1998 10:08:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 09:57:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA07858 for ipp-outgoing; Fri, 2 Jan 1998 09:29:59 -0500 (EST) Message-Id: <199801021428.JAA01059@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-lpd-ipp-map-03.txt Date: Fri, 02 Jan 1998 09:28:21 -0500 Sender: ipp-owner@pwg.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) : R. Herriot, T. Hastings, N. Jacobs, J. Martin Filename : draft-ietf-ipp-lpd-ipp-map-03.txt Pages : 23 Date : 31-Dec-97 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971231143451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231143451.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Fri Jan 2 10:17:13 1998 Delivery-Date: Fri, 02 Jan 1998 10:23:10 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA02493 for ietf-123-outbound.10@ietf.org; Fri, 2 Jan 1998 10:17:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01059; Fri, 2 Jan 1998 09:28:26 -0500 (EST) Message-Id: <199801021428.JAA01059@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-lpd-ipp-map-03.txt Date: Fri, 02 Jan 1998 09:28:21 -0500 Sender: cclark@cnri.reston.va.us --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) : R. Herriot, T. Hastings, N. Jacobs, J. Martin Filename : draft-ietf-ipp-lpd-ipp-map-03.txt Pages : 23 Date : 31-Dec-97 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-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: <19971231143451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231143451.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Fri Jan 2 10:22:14 1998 Delivery-Date: Fri, 02 Jan 1998 10:30:05 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA02707 for ietf-123-outbound.10@ietf.org; Fri, 2 Jan 1998 10:22:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01051; Fri, 2 Jan 1998 09:28:25 -0500 (EST) Message-Id: <199801021428.JAA01051@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-08.txt Date: Fri, 02 Jan 1998 09:28:24 -0500 Sender: cclark@cnri.reston.va.us --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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-08.txt Pages : 174 Date : 31-Dec-97 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-08.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: <19971231143850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231143850.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jan 2 13:21:26 1998 Delivery-Date: Fri, 02 Jan 1998 13:21:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA05071 for ; Fri, 2 Jan 1998 13:21:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09574 for ; Fri, 2 Jan 1998 13:24:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09887 for ; Fri, 2 Jan 1998 13:21:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 13:15:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09317 for ipp-outgoing; Fri, 2 Jan 1998 13:01:14 -0500 (EST) Message-Id: <3.0.1.32.19980102100017.0091c100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 Jan 1998 10:00:17 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes for TLS WG meeting, 12/10/97 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno > >Minutes from TLS Working Group Meeting >40th IETF, Washington, DC >10 December 1997 >Reported by Win Treese (WG Chair), based in part >on notes by Chris Allen . > >Mailing list: ietf-tls@consensus.com >Web site: http://www.consensus.com/ietf-tls > >Win Treese called the meeting to order, with the following agenda: > >- Status >- Old business: ports, patents, IANA registration >- Other drafts before the WG: Kerberos, SSL Tunneling Proxy >- Applications using TLS >- Description of server-gated crypto (Dierks) >- Implementation notes >- Next Steps >- Summary of Actions > >Status >------- >The TLS draft has been moved by the IESG to Proposed Standard, and it >will be issued as an RFC shortly. Congratulations to everyone on the >working group for contributing to this milestone. > > >Old Business >------------ > >Ports. Over time, there has been much discussion about whether or not >TLS applications should use different ports from their non-TLS >relatives. This decision must be made for each application >individually, so the issue is out of scope for the working group. As it >turns out, many applications are negotiating TLS within their own >protocols. > >Patents. There has been some concern about a patent for SSL recently >issued to Netscape. Netscape has provided a statement that is appended >to the TLS specification. In general terms, Netscape is granting a >royalty-free patent license to anyone who implements TLS, as long as >they do not assert that Netscape's implementation infringes on any >patents they hold. See the forthcoming RFC for the precise statement. > >IANA registration of ciphersuites and other numbers. Based on advice >from several sources, new TLS ciphersuites and similar identifiers will >not be registered through the IANA. Rather, they will be the subject of >new documents, which may be put on the standards track as appropriate. > >Other Drafts >------------ > >Two other drafts are before the working group: > >Kerberos ciphersuites for TLS. This document has been on hold until the >main draft moved to Proposed Standard. Now that it has, the Kerberos >document will be sent out for last call in the working group as soon >as an updated revision is available. > >SSL Tunneling for HTTP. This document is not formally before the >working group, but it might make sense for the WG to adopt it. Win >Treese will discuss this with the author. > >Applications >------------ > >Quite a few application protocols are specifying TLS. These include >SOCKS, LDAP, FTP, SMTP, IMAP4+POP3, and PPP EAP. WebDAV and IPP are in >progress and planning to use TLS. At this point, there is no draft >specifying the use of TLS with HTTP (for any version of HTTP). Eric >Rescorla volunteered to write a draft describing the current usage of >HTTP 1.0 over TLS, and we will try to find one for HTTP 1.1 as well. > >Paul Hoffman noted that LDAP with TLS is currently before IESG, with >SMTP over TLS and IMAP4+POP3 likely to follow. > >Bob Morgan, author of LDAP over TLS, is interested in hearing from WG >members about the way LDAP uses TLS. > >Carl-Uno Manros, co-chair of the IPP working group, said that IPP has >all printing related issues done, but still are wobbly on exact use of >TLS. Issues are using insecure way. They wanted to use null_null_null, >but this is not allowed. They are packaging IPP it over http. > >Micheal Bowe said the TN3270 working group has a problem: if a suitable >ciphersuite can't be negotiated, the TCP connection must be dropped. A >response from the floor was that this was changed in the latest TLS >draft. Only TLS has to be dropped, not the TCP connection. > >Discussions of TLS applications take place on the mailing list >ietf-apps-tls@imc.org. > >Server-Gated Crypto >------------------- > >Tim Dierks described a mechanism called by some "server-gated >cryptography." Variations of this are used by both Netscape and >Microsoft. The idea is that a client may be exported from the US with >both strong and export-grade cryptography, but the strong cryptography >is enabled only if the server has a particular kind of certificate. > >In both SSL and TLS, the client must drop the connection and restart >the handshake once it knows that it can use additional ciphers. It >would simplify things if the client can simply send a new hello message. > >A more detailed proposal will be forthcoming. > >TLS Implementation Warning >-------------------------- > >Tim Dierks also warned implementors about the following problem so >they would not repeat it: > > The definition of an SSL/TLS vector <1..65335> is: > > Hi Lo Contents > |LM|LL| | | | ... > In all SSL implementations, the client key exchange field is > miscoded in RSA and RSA_EXPORT key exchanges: it is missing the > length field. Please avoid this error in TLS implementations. > >Next Steps >---------- > >Chris Allen noted that the applications protocols are, in essence, our >customers now, and we should talk to them often. > >There were a number of proposed changes discussed in Memphis (two >meetings ago), but we have not seen detailed proposals or new drafts to >follow up on them. There is continued interest in combining IPSec key >exchange mechanisms with TLS. > >Thanks to Chris Allen for taking the notes during the WG meeting. > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 2 13:46:44 1998 Delivery-Date: Fri, 02 Jan 1998 13:46:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA05219 for ; Fri, 2 Jan 1998 13:46:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09642 for ; Fri, 2 Jan 1998 13:49:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA10549 for ; Fri, 2 Jan 1998 13:46:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 13:42:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09970 for ipp-outgoing; Fri, 2 Jan 1998 13:28:17 -0500 (EST) Message-Id: <3.0.1.32.19980102102724.00f95850@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 Jan 1998 10:27:24 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IETF Security policy (Re: IFax security) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org An intersting discussion about FAX security has developed over the holidays. I found the following comment from Harald worthwhile to share with those of you who are not on the IETF FAX DL. Carl-Uno >X-Sender: hta@127.0.0.1 >Date: Fri, 26 Dec 1997 18:41:45 PST >To: Mike Lake , Ned Freed >From: Harald Tveit Alvestrand >Subject: IETF Security policy (Re: IFax security) >Cc: IETF-FAX , tsg8ifax@itu.ch >Sender: owner-ietf-fax@imc.org > >At 10:01 24.12.97 +0000, Mike Lake wrote: > >>It would be nice if we could trade real products in a real world that also >>thought like this. Maybe one day the secret services will realise that the >>cold war is over and maybe one day they will relax things. The fact is >>that all the major ones got together in December 1995 and decided they >>wanted to keep the same levels of control - or even stronger ones in the >>light of various terrorist activities in the USA, Europe and elsewhere. I >>think real-world trading requirements MUST be taken into consideration when >>defining new standards that new equipment MAY, MUST or SHOULD conform to. >>It seems reasonable that if in doubt, use MAY. > >The IETF thinks that the only way we can change the behaviour of the >Real World is by consistently pointing out to the Real World that what >they have legislated is stupid, inconsistent, harmful to law-abiding citizens >and greatly overrated as a tool for law enforcement. >Read RFC 1984. > >In standards setting, this means that we specify what security is needed >to provide the level of security that engineering concerns seem to indicate is >necessary and sufficient, whether it is exportable or not. > >In today's world, implementing nonexportable-class cryptography is dead easy; >implementing it outside the US without breaking US export laws is trivial. >Look at the crypto software archives on nic.funet.fi, for instance. > >The fact that US government policy is harming US companies is not something >that the IETF is there to help alleviate. > > Harald T. Alvestrand > > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 2 17:01:11 1998 Delivery-Date: Fri, 02 Jan 1998 17:01:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA07598 for ; Fri, 2 Jan 1998 17:01:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10156 for ; Fri, 2 Jan 1998 17:03:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA11331 for ; Fri, 2 Jan 1998 17:01:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 16:55:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA10735 for ipp-outgoing; Fri, 2 Jan 1998 16:42:06 -0500 (EST) Message-Id: <3.0.1.32.19980102134104.00a08330@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 Jan 1998 13:41:04 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Wake Up Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, I hope you have had a relaxing holiday season and are prepared to help resolving the last couple of issues that we were too exhausted to tackle before Christmas. Please look at the latest drafts of the Model document (just got published by the IETF) and the Protocol document (which is still in the IETF queue, but you can get it from the IPP FTP site). Both are dated December 19, 1997. As far as I am aware there are only two remaining subjects on which we still need to reach consensus: 1) Should we specify a SHOULD or a SHALL for IPP client support of TLS? The recommendation out of IETF in Washingtomn was to make it a SHALL, but that was later challenged on the DL. After Harold's latest contribution in this discussion, the editors felt that SHOULD would more appropriately reflect the view of the WG, but I will need confirmation from you that this is correct. Randy Turner has already expressed as his view to stay with the SHALL to maximize inter-operability. 2) Can we avoid having two differeent URIs for the same IPP printer? Bob Herriot pointed out the problems with two different URIs (one for HTTP and one for HTTPS) and suggested a solution. Randy Turner came up with a counter proposal for solving the problem using HTTP's redirection feature. See the DL contributions on December 19-20. Personally I would like to have some of this prototyped to make sure we are on firm ground before making any final changes. Let us tackle these two issues with renewed power so we can fix this and get the drafts off to the IESG ASAP. I wish you all a Happy New Year, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sat Jan 3 11:22:03 1998 Delivery-Date: Sat, 03 Jan 1998 11:22:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18973 for ; Sat, 3 Jan 1998 11:22:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA11366 for ; Sat, 3 Jan 1998 11:24:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA13631 for ; Sat, 3 Jan 1998 11:22:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 3 Jan 1998 11:12:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13039 for ipp-outgoing; Sat, 3 Jan 1998 10:58:18 -0500 (EST) Date: Sat, 3 Jan 1998 08:03:04 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801031603.AA19477@snorkel.eso.mc.xerox.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM - Wake Up Call Sender: ipp-owner@pwg.org Hi Carl-Uno, Do you envision conference calls (to help sort out our few remaining issues and any edits that should have made it into the most recent Model and Protocol specs but didn't, for example the range of request-ID being '1..n' and not '0..n')? The note you forwarded with minutes from the most recent TLS WG meeting were interesting. Right at the end, there is a discussion that if TLS negotiation FAILS, then the new TLS spec does NOT say you must drop the (TCP) connection - it just says you must drop TLS - isn't this the moral equivalent of 'null_null_null' (ie, falling back to straight HTTP)? Happy New Year, - Ira McDonald (outside consultant at Xerox) 716-442-0609 ------------------------------------------ >From ipp-owner@pwg.org Fri Jan 2 17:18:09 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA19360; Fri, 2 Jan 98 17:18:08 EST Received: from by zombi (4.1/SMI-4.1) id AB28151; Fri, 2 Jan 98 17:12:59 EST Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53894(3)>; Fri, 2 Jan 1998 14:02:02 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11105 for ; Fri, 2 Jan 1998 16:58:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 2 Jan 1998 16:55:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA10735 for ipp-outgoing; Fri, 2 Jan 1998 16:42:06 -0500 (EST) Message-Id: <3.0.1.32.19980102134104.00a08330@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 2 Jan 1998 13:41:04 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Wake Up Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Status: R Hi all, I hope you have had a relaxing holiday season and are prepared to help resolving the last couple of issues that we were too exhausted to tackle before Christmas. Please look at the latest drafts of the Model document (just got published by the IETF) and the Protocol document (which is still in the IETF queue, but you can get it from the IPP FTP site). Both are dated December 19, 1997. As far as I am aware there are only two remaining subjects on which we still need to reach consensus: 1) Should we specify a SHOULD or a SHALL for IPP client support of TLS? The recommendation out of IETF in Washingtomn was to make it a SHALL, but that was later challenged on the DL. After Harold's latest contribution in this discussion, the editors felt that SHOULD would more appropriately reflect the view of the WG, but I will need confirmation from you that this is correct. Randy Turner has already expressed as his view to stay with the SHALL to maximize inter-operability. 2) Can we avoid having two differeent URIs for the same IPP printer? Bob Herriot pointed out the problems with two different URIs (one for HTTP and one for HTTPS) and suggested a solution. Randy Turner came up with a counter proposal for solving the problem using HTTP's redirection feature. See the DL contributions on December 19-20. Personally I would like to have some of this prototyped to make sure we are on firm ground before making any final changes. Let us tackle these two issues with renewed power so we can fix this and get the drafts off to the IESG ASAP. I wish you all a Happy New Year, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From tcplw-relay@services.BSDI.COM Mon Jan 5 08:53:47 1998 Delivery-Date: Mon, 05 Jan 1998 08:54:02 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA15182 for ; Mon, 5 Jan 1998 08:53:07 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA01813 for ; Mon, 5 Jan 1998 08:55:54 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.8+ESF/8.8.8) id GAA00443 for tcplw-list@bsdi.com; Mon, 5 Jan 1998 06:48:03 -0700 (MST) Received: from janus.unik.no (janus.unik.no [193.156.96.46]) by services.BSDI.COM (8.8.8+ESF/8.8.8) with ESMTP id GAA00380 for ; Mon, 5 Jan 1998 06:47:45 -0700 (MST) Received: from [193.156.96.38] (atlantis.unik.no [193.156.96.38]) by janus.unik.no (8.8.5/8.7.3) with SMTP id OAA20058; Mon, 5 Jan 1998 14:34:37 +0100 (MET) Date: Mon, 5 Jan 1998 14:34:37 +0100 (MET) X-Sender: goebel@janus.unik.no Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, cost237-teleservices@comp.lancs.ac.uk, tcplw@bsdi.com From: goebel@unik.no (Vera Goebel) Subject: CfP - IDMS'98 (reminder) Cc: idms98@unik.no Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by services.BSDI.COM id GAA00440 Please accept our apologies if you receive multiple copies of this announcement. You will be doing us a great favor if you disseminate the this Call for papers among your interested colleagues. Thanks. **************************************************************************** REMINDER: Call for Papers IDMS'98 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway The Fifth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshops held 1997 in Darmstadt and 1996 in Berlin. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services -- ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to · High-speed/ATM networks · Mobile multimedia systems · Multimedia over sattelite · Multimedia middelware · Quality of service issues · Media scaling · Resource management · Protocol design and implementation · Distributed multimedia database systems · Development tools for distributed multimedia applications · Multimedia-specific intelligent agents · Computer supported collaborative work · Distributed virtual reality systems · Distance education · Conferencing · Digital libraries · Interactive television · Video-on-demand systems · Compression algorithms IDMS'98 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavour of a workshop, the number of participants will be restricted. Furthermore, we encurage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings. The proceedings will be published in the Springer LNCS series and will be available during the workshop. It is intended to forward selected papers to a special issue of the "Computer Communications" Journal. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'98 web page: http://www.unik.no/~idms98. Authors without web access may send mail to idms98@unik.no requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to one of the workshops chairs ATTN: IDMS'98. Important dates: Submission due: February 1, 1998 Notification of acceptance: April 15, 1998 Camera ready version: May 15, 1998 Workshop: September 9 - 11, 1998 Program co-chairs: Vera Goebel and Thomas Plagemann UniK - Center for Technology at Kjeller, University of Oslo, P.O. Box 70, N-2007 Kjeller, Norway Email: {goebel; plageman}@unik.no, Phone: +47/63.81.45.70, Fax: +47/63.81.81.46 Program Committee: F. A. Aagesen, NTNU, Norway H. Affifi, ENST Bretagne, France E. Biersack, Institut Eurécom, France G. Bochmann, U. Montreal, Canada B. Butscher, DeTeBerkom, Germany A. T. Campbell, Columbia U., USA S. Chanson , Hongkong U., HK L. Delgrossi, U. Piacenza, Italy M. Diaz, LAAS-CNRS, France F. Eliassen, U. Tromsø, Norway W. Effelsberg, U. Mannheim, Germany D. Ferrari, U. Cattolica Piacenza, Italy J.-P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK W. Kalfa, TU Chemnitz, Germany T. D. C. Little, Boston U., USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA G. Parulkar, Washington U., USA B. Pehrson, KTH Stockholm, Sweden S. Pink, SICS, Sweden B. Plattner, ETH Zurich, Switzerland H. Scholten, U. Twente, Netherlands R. Steinmetz, GMD, Germany H. Tokuda, Keio U., Japan L. Wolf, TH Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany ACM Multimedia'98 takes place in Bristol (UK) in the week following IDMS'98: http://www.acm.org/sigmm/MM98. ------------------------------------------------------------------------- Dr. Vera Goebel Tel. +47/63.81.45.71.219 (direct) Associate Professor or Tel. +47/63.81.45.70 (swichboard) UNIK Center for Technology at Kjeller University of Oslo Fax. +47/63.81.81.46 PO BOX 70 N-2007 Kjeller email: goebel@unik.no Norway http://www.unik.no/~goebel/ ------------------------------------------------------------------------- From jmp-owner@pwg.org Mon Jan 5 10:47:59 1998 Delivery-Date: Mon, 05 Jan 1998 10:48:00 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17118 for ; Mon, 5 Jan 1998 10:47:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02288 for ; Mon, 5 Jan 1998 10:50:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA16213 for ; Mon, 5 Jan 1998 10:47:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 10:43:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16027 for jmp-outgoing; Mon, 5 Jan 1998 10:41:06 -0500 (EST) Content-return: allowed Date: Mon, 5 Jan 1998 07:33:56 PST From: "Caruso, Angelo " Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p ageback sides or not? To: "'Tom Hastings'" , "'jmp@pwg.org'" , "'ipp@pwg.org'" Cc: "'XCMI_Editors'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: jmp-owner@pwg.org Tom, I disagree that the impressions counters are intended only for monitoring. For monitoring, you only need the jobImpressionsCompleted and jobImpressionsRequested counters. The fullColorImpressionsCompleted and highlightColorImpressionsCompleted attributes were proposed specifically for accounting with color capable devices. Our assumption was that impressions would be more useful for accounting since they are more accurate than sheets. Though I am not an accounting expert, I think providing the impression counters gives an accounting application developer added flexibility (e.g. so that billing for blank sides could be made optional depending on the requirements of the customer). I also agree with Bill Wagner that complete accuracy would require measuring colorant use per side. We thought about this and decided it was way too complicated for the job MIB. Our compromise solution was to propose the fullColor and highlightColor impressions counters. At any rate, it is clear that we need more input from real customers on their accounting requirements. For example, if most print shops charge one per-sheet rate for color devices and another rate for monochrome devices, then the color impressions counters aren't currently needed. But providing them offers customers a competitive edge in their billing methods since they can be more accurate. Thanks, Angelo -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] Sent: Thursday, December 18, 1997 10:21 PM To: XCMI Editors only Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last pageback sides or not? What about this proposal to recommend, but not require, that the back side of the last sheet not count for impressions? Alternatively, we could make a note that impressions is intended for monitoring, not accounting, and keep the definition of the number of passes past the marker, whether marks are made or not. Sheets is intended for accounting which in combination with the 'sides' attribute selects the rate. I believe this is what Kinkos does. Tom >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > > > From ipp-owner@pwg.org Mon Jan 5 11:08:43 1998 Delivery-Date: Mon, 05 Jan 1998 11:08:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18024 for ; Mon, 5 Jan 1998 11:08:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02416 for ; Mon, 5 Jan 1998 11:11:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17004 for ; Mon, 5 Jan 1998 11:08:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 10:59:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16015 for ipp-outgoing; Mon, 5 Jan 1998 10:40:59 -0500 (EST) Content-return: allowed Date: Mon, 5 Jan 1998 07:33:56 PST From: "Caruso, Angelo " Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p ageback sides or not? To: "'Tom Hastings'" , "'jmp@pwg.org'" , "'ipp@pwg.org'" Cc: "'XCMI_Editors'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org Tom, I disagree that the impressions counters are intended only for monitoring. For monitoring, you only need the jobImpressionsCompleted and jobImpressionsRequested counters. The fullColorImpressionsCompleted and highlightColorImpressionsCompleted attributes were proposed specifically for accounting with color capable devices. Our assumption was that impressions would be more useful for accounting since they are more accurate than sheets. Though I am not an accounting expert, I think providing the impression counters gives an accounting application developer added flexibility (e.g. so that billing for blank sides could be made optional depending on the requirements of the customer). I also agree with Bill Wagner that complete accuracy would require measuring colorant use per side. We thought about this and decided it was way too complicated for the job MIB. Our compromise solution was to propose the fullColor and highlightColor impressions counters. At any rate, it is clear that we need more input from real customers on their accounting requirements. For example, if most print shops charge one per-sheet rate for color devices and another rate for monochrome devices, then the color impressions counters aren't currently needed. But providing them offers customers a competitive edge in their billing methods since they can be more accurate. Thanks, Angelo -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] Sent: Thursday, December 18, 1997 10:21 PM To: XCMI Editors only Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last pageback sides or not? What about this proposal to recommend, but not require, that the back side of the last sheet not count for impressions? Alternatively, we could make a note that impressions is intended for monitoring, not accounting, and keep the definition of the number of passes past the marker, whether marks are made or not. Sheets is intended for accounting which in combination with the 'sides' attribute selects the rate. I believe this is what Kinkos does. Tom >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > > > From ipp-owner@pwg.org Mon Jan 5 11:32:16 1998 Delivery-Date: Mon, 05 Jan 1998 11:32:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18858 for ; Mon, 5 Jan 1998 11:32:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02559 for ; Mon, 5 Jan 1998 11:35:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17687 for ; Mon, 5 Jan 1998 11:32:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 11:28:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17094 for ipp-outgoing; Mon, 5 Jan 1998 11:14:09 -0500 (EST) From: Harry Lewis To: , Cc: Subject: IPP> More Time for IPP in January Message-ID: <5030300016520297000002L072*@MHS> Date: Mon, 5 Jan 1998 11:20:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA18858 Carl-Uno wrote: >Don, > >It turmns out that there are two kinds of things that people would like to >discuss in the January IPP meeting: > >1) Start discussion about various extensions that were left out from IPP 1.0. > We may also need to discuss any comments from the IESG. > >2) Testing and interoperability issues. > >I would prefer to deal with the first set of disccussions on the already >scheduled Wednesday slot, but would like to find out quickly if we could get >a room for the testing issue discussions on Thursday. I assume that the >second day meeting would be a smaller crowd, with little or no overlap in >participation to other PWG activities planned for Thursday. > >Please let me know ASAP, as people might have to revise their traveling plans. My interests would overlap. I'd prefer to adjust agendas to fit all topics inline. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Jan 5 12:10:31 1998 Delivery-Date: Mon, 05 Jan 1998 12:10:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19646 for ; Mon, 5 Jan 1998 12:10:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA02866 for ; Mon, 5 Jan 1998 12:13:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18573 for ; Mon, 5 Jan 1998 12:10:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 12:06:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17998 for ipp-outgoing; Mon, 5 Jan 1998 11:52:09 -0500 (EST) Message-Id: <3.0.1.32.19980105084737.0107c900@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 08:47:37 PST To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), cmanros@cp10.es.xerox.com, ipp@pwg.org From: Tom Hastings Subject: IPP> Re: PRO (MOD?) - Wake Up Call [request-id needs more syntax] In-Reply-To: <9801031603.AA19477@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 08:03 01/03/1998 PST, Ira Mcdonald x10962 wrote: >Hi Carl-Uno, > >Do you envision conference calls (to help sort out our few >remaining issues and any edits that should have made it into >the most recent Model and Protocol specs but didn't, for >example the range of request-ID being '1..n' and not '0..n')? Ira, The Protocol document was changed in section 3.6 to make the example value for clients that aren't using it be the constant 1, instead of 0, so that its value is a legal value as agreed to align with the Job MIB and the SNMP requirement not to use 0 as a table index value. However, the ABNF fails to specify the syntax of the request-id token. (0 or 1). It should be SIGNED-INTEGER, as all four octet integers are, but with some restriction on the range to be 1 to 2**31-1. Also I would think that section 3.6 should also include the range limits, as has been done for other fields. Also the Model document doesn't seem to mention the request-id at all, that I could find. I'm not sure whether it should or not, since the request-id is more of a protocol mechanism. Thanks, Tom snip... From ipp-owner@pwg.org Mon Jan 5 12:47:04 1998 Delivery-Date: Mon, 05 Jan 1998 12:47:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA20210 for ; Mon, 5 Jan 1998 12:47:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03051 for ; Mon, 5 Jan 1998 12:49:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA19558 for ; Mon, 5 Jan 1998 12:47:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 12:40:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18708 for ipp-outgoing; Mon, 5 Jan 1998 12:24:20 -0500 (EST) Date: Mon, 5 Jan 1998 09:20:11 -0800 (Pacific Standard Time) From: Ron Bergman To: don@lexmark.com cc: ipp@pwg.org Subject: Re: IPP> More Time for IPP in January In-Reply-To: <5030300016520297000002L072*@MHS> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Don, I agree with Harry, let's not overlap the agenda items. I do not anticipate any time required for the Job MIB so that Thursday can be shared by IPP and SENSE. I assume that Friday is still reserved for the Finisher MIB. Ron Bergman Dataproducts Corp. On Mon, 5 Jan 1998, Harry Lewis wrote: > Carl-Uno wrote: > > >Don, > > > >It turmns out that there are two kinds of things that people would like to > >discuss in the January IPP meeting: > > > >1) Start discussion about various extensions that were left out from IPP 1.0. > > We may also need to discuss any comments from the IESG. > > > >2) Testing and interoperability issues. > > > >I would prefer to deal with the first set of disccussions on the already > >scheduled Wednesday slot, but would like to find out quickly if we could get > >a room for the testing issue discussions on Thursday. I assume that the > >second day meeting would be a smaller crowd, with little or no overlap in > >participation to other PWG activities planned for Thursday. > > > >Please let me know ASAP, as people might have to revise their traveling plans. > > My interests would overlap. I'd prefer to adjust agendas to fit all topics > inline. > > Harry Lewis - IBM Printing Systems > From adm Mon Jan 5 13:02:17 1998 Delivery-Date: Mon, 05 Jan 1998 13:09:02 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA20457 for ietf-123-outbound.10@ietf.org; Mon, 5 Jan 1998 13:02:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20432; Mon, 5 Jan 1998 13:01:36 -0500 (EST) Message-Id: <199801051801.NAA20432@ns.ietf.org> To: IETF-Announce: ; Cc: ippcp@external.cisco.com From: The IESG SUBJECT: Last Call: IP Payload Compression Protocol (IPComp) to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 05 Jan 1998 13:01:36 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the IP Payload Compression Protocol Working Group to consider IP Payload Compression Protocol (IPComp) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 19, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-04.txt From ipp-owner@pwg.org Mon Jan 5 13:21:30 1998 Delivery-Date: Mon, 05 Jan 1998 13:21:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20738 for ; Mon, 5 Jan 1998 13:21:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03186 for ; Mon, 5 Jan 1998 13:24:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20937 for ; Mon, 5 Jan 1998 13:21:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 13:12:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19300 for ipp-outgoing; Mon, 5 Jan 1998 12:43:08 -0500 (EST) Date: Mon, 5 Jan 1998 09:38:41 -0800 (Pacific Standard Time) From: Ron Bergman To: scott_isaacson@novell.com cc: ipp@pwg.org Subject: IPP> MOD New Text for Get-Printer-Attributes Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Scott, On page #40, section 3.2.5, line #1390 of the pdf file of version 0.8 reads: ...of a Printer or Job object. should be: ..of a Printer object. Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Mon Jan 5 13:22:58 1998 Delivery-Date: Mon, 05 Jan 1998 13:22:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20763 for ; Mon, 5 Jan 1998 13:22:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03240 for ; Mon, 5 Jan 1998 13:25:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA21105 for ; Mon, 5 Jan 1998 13:22:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 13:15:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19632 for ipp-outgoing; Mon, 5 Jan 1998 12:48:12 -0500 (EST) Message-ID: <34B11CBB.446A347D@underscore.com> Date: Mon, 05 Jan 1998 12:47:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ron Bergman CC: don@lexmark.com, ipp@pwg.org, Sense , Harry Lewis Subject: Re: IPP> More Time for IPP in January References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Ron Bergman wrote: > I agree with Harry, let's not overlap the agenda items. > > I do not anticipate any time required for the Job MIB so that Thursday can > be shared by IPP and SENSE. I assume that Friday is still reserved for > the Finisher MIB. Sorry, but there will be no SENSE session at the upcoming January PWG meetings in Hawaii. :-( ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Jan 5 14:30:10 1998 Delivery-Date: Mon, 05 Jan 1998 14:30:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA21690 for ; Mon, 5 Jan 1998 14:30:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04190 for ; Mon, 5 Jan 1998 14:32:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21957 for ; Mon, 5 Jan 1998 14:29:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 14:24:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21361 for ipp-outgoing; Mon, 5 Jan 1998 14:10:45 -0500 (EST) Message-Id: <3.0.1.32.19980105110919.00c72e50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 11:09:19 PST To: scott_isaacson@novell.com From: Carl-Uno Manros Subject: IPP> MOD - Reference errors in section 15.5 Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Scott, Tom and I were just looking up something in section 15.5 of the Model document. It turns out that all the references in this section are wrong. Can you please look into this and fix it. This section does not use automatic cross referencing, which has caused the problem. Thanks, Carl-uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 15:51:37 1998 Delivery-Date: Mon, 05 Jan 1998 15:51:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA22732 for ; Mon, 5 Jan 1998 15:51:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04486 for ; Mon, 5 Jan 1998 15:54:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA22763 for ; Mon, 5 Jan 1998 15:51:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 15:46:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22155 for ipp-outgoing; Mon, 5 Jan 1998 15:32:12 -0500 (EST) Content-return: allowed Date: Mon, 5 Jan 1998 12:25:27 PST From: "Zehler, Peter " Subject: IPP> TES Meeting Agenda(Proposed) To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org All, It seems we will have an entire day devoted to IPP TES at the next PWG meeting. Below are some of the agenda items that I believe we should cover. I am open to anything I have overlooked or is on anyone's mind. I think the agenda items should cover the "how", "what" and "when" of IPP testing and prototyping. I think the "why" is obvious. The "who" will also be an output from the meeting. Action items and meeting minutes will cover "who". Pete 1) Testing Methodology How are we going to test IPP? Test suites Scenarios Simple test instructions, capture of a trace and comparison of results Trace file repository Significant milestones How will we document the results? Internet pair-wise testing/bake-offs Face to face bake-offs 2) Conformance/compliance Minimal set definition Operation and attribute coverage Security coverage and interations 3) Preliminary schedule for milestones, action items and deliverables From ipp-owner@pwg.org Mon Jan 5 16:38:32 1998 Delivery-Date: Mon, 05 Jan 1998 16:38:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA23257 for ; Mon, 5 Jan 1998 16:38:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04642 for ; Mon, 5 Jan 1998 16:41:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA23697 for ; Mon, 5 Jan 1998 16:38:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 16:30:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22876 for ipp-outgoing; Mon, 5 Jan 1998 16:16:45 -0500 (EST) Message-Id: <3.0.1.32.19980105131213.0100fe60@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 13:12:13 PST To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), cmanros@cp10.es.xerox.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Re: MOD&PRO - Wake Up Call [fix request id lower bound: 1] In-Reply-To: <3.0.1.32.19980105084737.0107c900@garfield> References: <9801031603.AA19477@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 08:47 01/05/1998 PST, Tom Hastings wrote: >At 08:03 01/03/1998 PST, Ira Mcdonald x10962 wrote: >>Hi Carl-Uno, >> >>Do you envision conference calls (to help sort out our few >>remaining issues and any edits that should have made it into >>the most recent Model and Protocol specs but didn't, for >>example the range of request-ID being '1..n' and not '0..n')? > >Ira, >The Protocol document was changed in section 3.6 to make the example value >for clients that aren't using it be the constant 1, instead of 0, >so that its value is a legal value as agreed to align with the Job MIB and >the SNMP requirement not to use 0 as a table index value. > >However, the ABNF fails to specify the syntax of the request-id token. >(0 or 1). It should be SIGNED-INTEGER, as all four octet integers are, >but with some restriction on the range to be 1 to 2**31-1. > >Also I would think that section 3.6 should also include the range limits, >as has been done for other fields. > >Also the Model document doesn't seem to mention the request-id at all, >that I could find. I'm not sure whether it should or not, since the >request-id is more of a protocol mechanism. I found where "request id" is specified in the Model document. Its in section 3.1.1. In the protocol document, its called "request-id", but is called "request id" in the Model document (which is why I didn't find it when searching the Model document). However, the lower bound is still specified as 0 to 2**31-1 in section 3.1.1 in the Model document and needs to be changed to be: 1 to 2**31-1 as agreed. Perhaps the protocol document section 3.6 should also be fixed to mention the "request id" in the model document as mapping to the "request-id" in the protocol document? > >Thanks, >Tom > >snip... > > > > From ipp-owner@pwg.org Mon Jan 5 18:17:45 1998 Delivery-Date: Mon, 05 Jan 1998 18:17:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA24460 for ; Mon, 5 Jan 1998 18:17:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA04871 for ; Mon, 5 Jan 1998 18:20:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24788 for ; Mon, 5 Jan 1998 18:17:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 18:12:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24180 for ipp-outgoing; Mon, 5 Jan 1998 17:58:37 -0500 (EST) Message-Id: <3.0.1.32.19980105145707.00cb9100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 14:57:07 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Maui PWG IPP Meeting on 28 and 29 and Januari 7 Phone Conference Cc: don@lexmark.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Before Christmas I sent out a warning that we may want to use two days for IPP in the upcoming PWG meeting in Maui. Today, when most everybody seems to back in their offices again, we have now resolved the agenda problem. It turns out that there will not be much need for a Job MIB meeting and the Finisher MIB meeting will be moved to Friday. This leaves us with two days for IPP. On Wednesday January 28 we will discuss: 1) Any remaining IPP Version 1.0 issues - Hopefully NONE, but you never know. 2) How do we document resolutions for bugs that become visible after the RFCs are published? Should we start an Implementor's Guide document? 3) Discuss requirements for additional functionality that was left out of the IPP Version 1.0. This includes, but is not limited to things like: - Dictionary attribute type - Document level attributes - Asynchrounous notifications 4) We also need a slot to discuss some general PWG policy matters, which are not limited to IPP, such as IANA registration procedures. On Thursday January 29 we will have the whole day to discuss IPP Testing issues. Peter Zehler has just sent out a separate agenda for that day. -- We will start our weekly phone conferences again this Wednesday January 7, 1 - 3 pm (PST). Main agenda item is to continue our discussion about the two URI names for a Printer. I have asked Don to set this up and announce the dial-in details to the DL. I have not yet got a confirmation from him. If I do not here from Don by tomorrow morning, I will set it up myself. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 19:20:08 1998 Delivery-Date: Mon, 05 Jan 1998 19:20:09 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25085 for ; Mon, 5 Jan 1998 19:20:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05019 for ; Mon, 5 Jan 1998 19:22:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA25517 for ; Mon, 5 Jan 1998 19:20:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 19:15:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA24947 for ipp-outgoing; Mon, 5 Jan 1998 19:01:09 -0500 (EST) Message-Id: <3.0.1.32.19980105155939.00ae8c90@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 15:59:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Outside the box resolution for the two URIs issue Cc: masinter@parc.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I got some private feedback from Larry Mainter on this issue, which triggered some further thoughts that I wanted to share with you. I like Bob's approach because it provides the functionality within IPP, while Randy's approach might be easier to implement, but makes us dependent on HTTP functionality for redirects, which may not be available in other transfer protocols. Maybe we should think outside the box instead. Larry asked why do we limit ourselves to TWO URIs? Thinking about extensibility, I think Larry has a point. If we want to add a new mapping for IPP on top of HTTP NG or whatever and the IPP server can support both that and the current HTTP and HTTPS mappings, where do we put the additional URI in the IPP protocol? If instead, we made the Printer URI a MULTI-VALUED attribute, we could add any number of future transfer protocols for the same IPP Printer without having to revise our model. The IPP client would probably need to understand the scheme part of the URI, but could then choose any of the offered URI alternatives, with more or less security etc. We would probably need to add some rules about whether the same transfer protocol has to be used for a particular IPP Job, or if the client can use different ones, provided that the same level of security is maintained. Another question is whether the IPP Server would always return Job URIs with the same scheme as the one with which the job request was submitted. A consequence of this propoal is that directory entries might have multiple URIs for the same IPP Printer. Is this approach worth further discussion? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 19:40:50 1998 Delivery-Date: Mon, 05 Jan 1998 19:40:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25215 for ; Mon, 5 Jan 1998 19:40:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05066 for ; Mon, 5 Jan 1998 19:43:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA26215 for ; Mon, 5 Jan 1998 19:40:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 19:36:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25616 for ipp-outgoing; Mon, 5 Jan 1998 19:22:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl-Uno Manros'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> MOD - Outside the box resolution for the two URIs issue Date: Mon, 5 Jan 1998 16:19:33 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org If you read my earlier more detailed proposal you will see that I put the redirection mechanism into IPP, so it is not dependent on HTTP-specific redirection mechanisms. Randy > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, January 05, 1998 4:00 PM > To: ipp@pwg.org > Cc: masinter@parc.xerox.com; manchala@cp10.es.xerox.com; > xriley@cp10.es.xerox.com > Subject: IPP> MOD - Outside the box resolution for the two URIs > issue > > > I got some private feedback from Larry Mainter on this issue, which > triggered some further thoughts that I wanted to share with you. > > I like Bob's approach because it provides the functionality within > IPP, > while Randy's approach might be easier to implement, but makes us > dependent > on HTTP functionality for redirects, which may not be available in > other > transfer protocols. > > Maybe we should think outside the box instead. Larry asked why do we > limit > ourselves to TWO URIs? Thinking about extensibility, I think Larry > has a > point. > > If we want to add a new mapping for IPP on top of HTTP NG or whatever > and > the IPP server can support both that and the current HTTP and HTTPS > mappings, where do we put the additional URI in the IPP protocol? If > instead, we made the Printer URI a MULTI-VALUED attribute, we could > add any > number of future transfer protocols for the same IPP Printer without > having > to revise our model. The IPP client would probably need to understand > the > scheme part of the URI, but could then choose any of the offered URI > alternatives, with more or less security etc. We would probably need > to add > some rules about whether the same transfer protocol has to be used for > a > particular IPP Job, or if the client can use different ones, provided > that > the same level of security is maintained. Another question is whether > the > IPP Server would always return Job URIs with the same scheme as the > one > with which the job request was submitted. A consequence of this > propoal is > that directory entries might have multiple URIs for the same IPP > Printer. > > Is this approach worth further discussion? > > Carl-Uno > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 19:59:39 1998 Delivery-Date: Mon, 05 Jan 1998 19:59:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25313 for ; Mon, 5 Jan 1998 19:59:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05104 for ; Mon, 5 Jan 1998 20:02:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA26887 for ; Mon, 5 Jan 1998 19:59:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 19:55:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26172 for ipp-outgoing; Mon, 5 Jan 1998 19:40:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> MOD - Outside the box resolution for the two URIs issue Date: Mon, 5 Jan 1998 16:37:30 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Another comment... In my opinion, the IPP redirect mechanism should still be included because there are alot of cases and scenarios where it could be used; security is just one of those scenarios. I also think that redirection does not constrain the number of URIs that are supported to just "2". The server can elect to redirect to whatever URI the server feels is appropriate for access to the "resource". Of course, the client can choose not to support the redirected URI, but this possibility exists in any method we choose wherein a client may have to deal with a server supporting multiple URIs. The other scenarios (besides security) involve job redirection, and/or load balancing scenarios, etc. While we do not have to specify these capabilities in version 1.0, including the basic redirect mechanism from the outset in version 1.0 will allow us to expand in these directions (and others) if we see a need. I do agree with the overall need for scalability when it comes to supporting additional transport mappings, however, but I feel that redirection will naturally support this, and still allow publishing of a single URI in directory entries; neither would it preclude publishing multiple URIs per server if the administrator wishes to manage this type of situation. Randy > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, January 05, 1998 4:00 PM > To: ipp@pwg.org > Cc: masinter@parc.xerox.com; manchala@cp10.es.xerox.com; > xriley@cp10.es.xerox.com > Subject: IPP> MOD - Outside the box resolution for the two URIs > issue > > > I got some private feedback from Larry Mainter on this issue, which > triggered some further thoughts that I wanted to share with you. > > I like Bob's approach because it provides the functionality within > IPP, > while Randy's approach might be easier to implement, but makes us > dependent > on HTTP functionality for redirects, which may not be available in > other > transfer protocols. > > Maybe we should think outside the box instead. Larry asked why do we > limit > ourselves to TWO URIs? Thinking about extensibility, I think Larry > has a > point. > > If we want to add a new mapping for IPP on top of HTTP NG or whatever > and > the IPP server can support both that and the current HTTP and HTTPS > mappings, where do we put the additional URI in the IPP protocol? If > instead, we made the Printer URI a MULTI-VALUED attribute, we could > add any > number of future transfer protocols for the same IPP Printer without > having > to revise our model. The IPP client would probably need to understand > the > scheme part of the URI, but could then choose any of the offered URI > alternatives, with more or less security etc. We would probably need > to add > some rules about whether the same transfer protocol has to be used for > a > particular IPP Job, or if the client can use different ones, provided > that > the same level of security is maintained. Another question is whether > the > IPP Server would always return Job URIs with the same scheme as the > one > with which the job request was submitted. A consequence of this > propoal is > that directory entries might have multiple URIs for the same IPP > Printer. > > Is this approach worth further discussion? > > Carl-Uno > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 20:34:38 1998 Delivery-Date: Mon, 05 Jan 1998 20:34:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25570 for ; Mon, 5 Jan 1998 20:34:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05197 for ; Mon, 5 Jan 1998 20:37:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA27559 for ; Mon, 5 Jan 1998 20:34:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 20:30:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27014 for ipp-outgoing; Mon, 5 Jan 1998 20:16:25 -0500 (EST) Message-Id: <3.0.1.32.19980105171447.00bfa410@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 17:14:47 PST To: ietf-tls@consensus.com From: Carl-Uno Manros Subject: IPP> Re: IPP and the security area (Re: Area Directors' comments on IPP) Cc: Harald.T.Alvestrand@uninett.no, ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:14 AM 12/16/97 PST, Michael Boe wrote: >> Harald, >> >> We have been following the TLS activities for some time and have also held >> discussions with individual members of the WG. We were happy to use the TLS >> functionality as documented up to their last draft but one, but in the >> final version that was passed by the IESG they suddenly introduced some new >> mandatory stuff, for which we have so far seen little or no rationale or >> explanation. >> >> Just now I am only interested to get a recommendation, from whoever >> consider themselves qualified, about a "politically correct" combination of >> TLS security features that provides the same functionality as SSL3. Is this >> concrete enough? > >Not really concrete enough. You are leaving it to the rest of us to figure out >(by scanning the last two versions of the TLS drafts) what it is you object to. >Guessing, I suppose it's: > > a) the mandatory cipher-suite > b) the prohibition of using (NULL,NULL) as a possible cipher-suite > >Like yourself, I'm merely a "consumer" of the TLS spec. However, it became >quite clear to me at the Munich IETF that these two items were going to become >part of the standard. How did I discover this? Just by attending the meetings >and having a few very short conversations with people more familiar with TLS >than I was (and still am :-). > >As I understand your complaints, these two new provisions conflict with your >goals in the following ways: > > i) printers are not (and shouldn't be?) high-cost items. Mandating a >heavy-weight cipher suite that uses PKI-based authentication and a thick >encryption mechanism drives up the price of a printer (and the price of >education & maintenance associated with that printer). > > ii) the manufacturers want to roll out security-capable product based on >today's printer hardware specs. The technical "footprint" of most of today's >printers really isn't up to implementing provisions (a) & (b) with any speed. > > iii) the mechanism for IPP is HTTP (and, I suppose, HTTPS), and it sure would >be nice to use the same security mechanisms that HTTP/HTTPS uses. Use of >anything other than SSL/TLS is going to complicate IPP security tremendously. > >If I can be so bold, let me toss out conflict (ii) immediately. The easiest >thing to solve in computing is CPU horsepower. Just wait half a year and >somebody's going to offer a CPU unit that does things faster and with less >wattage than what they currently available units do. A spec which has a >lifetime of, say, ten to twenty years should not be hobbling itself to >yesterday's CPU speeds. > >Conflict (iii) is certainly legitimate, but is really only a conflict because >of (i) and (ii). So let's put that on hold right now and see if (i) can be >solved. > >I'm suggesting that conflict (i) is the core of your problems. Is this >correct? Can you expand on why (i) conflicts? What other conflicts am I >missing? > >/msb > Michael, Sorry for being so late to reply, but I had managed to "save" most of my vacation to the end of the year and was out of the office for most of the time since your message. Most of your analysis is correct and the main problems are really two: 1) Due to cost considerations for low end printers, it is desirable to be able to allow printers to get away with using the security features that are part of HTTP, including the features described in RFC 2069, which offers some help in protecting the printer from unautherized use. A number of IPP scenarios do not really need more protection in parallel to the use of fax machines at present. The use of TLS is therefore an IPP option that may or may not be supported by a particular printer. In the case where an IPP Printer only supports either HTTP or HTTPS there is no problem, but in the case where it may supports both, we still need a negotiation mechanism, for which we had hoped to use the TLS negotion, with the option to come out with the NULL-NULL-NULL case if only HTTP was needed. We now have to build that kind of negotiation into our own application protocol instead (which is probably a better solution after all). 2) Even in the case where printer vendors want to include TLS in IPP products that are currently under development we have a timing problem. My understanding is that there is only a handful or so guys that actually build this kind of security software. They then produce SDKs that are being used by everybody else, including some of the bigger guys. Last I checked, nobody seemed to be prepared to supply a production quality SDK for TLS earlier than mid to late 1998, to which you then need to add the time to actually use the SDK and integrate and test it with the "real" product. I am sure that you would have some sympathy for not including somebody elses prototype or alpha code for TLS in a product that you expect to sell for money and risk your good name as a vendor on. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 5 21:59:13 1998 Delivery-Date: Mon, 05 Jan 1998 21:59:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA26195 for ; Mon, 5 Jan 1998 21:59:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05295 for ; Mon, 5 Jan 1998 22:01:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28646 for ; Mon, 5 Jan 1998 21:59:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 21:50:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27690 for ipp-outgoing; Mon, 5 Jan 1998 21:25:12 -0500 (EST) Date: Mon, 5 Jan 1998 18:17:06 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801060217.SAA12333@woden.eng.sun.com> To: imcdonal@eso.mc.xerox.com, cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> Re: MOD&PRO - Wake Up Call [fix request id lower bound: 1] X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I corrected the omissions in the protocol document, including the examples. I will not download it until we finish with other minor fixes this week. Bob Herriot > From hastings@cp10.es.xerox.com Mon Jan 5 14:04:43 1998 > X-Sender: hastings@garfield > X-Mailer: Windows Eudora Pro Version 3.0.1 (32) > Date: Mon, 5 Jan 1998 13:12:13 PST > To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), cmanros@cp10.es.xerox.com, > ipp@pwg.org > From: Tom Hastings > Subject: Re: IPP> Re: MOD&PRO - Wake Up Call [fix request id lower > bound: 1] > In-Reply-To: <3.0.1.32.19980105084737.0107c900@garfield> > References: <9801031603.AA19477@snorkel.eso.mc.xerox.com> > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 46 > > At 08:47 01/05/1998 PST, Tom Hastings wrote: > >At 08:03 01/03/1998 PST, Ira Mcdonald x10962 wrote: > >>Hi Carl-Uno, > >> > >>Do you envision conference calls (to help sort out our few > >>remaining issues and any edits that should have made it into > >>the most recent Model and Protocol specs but didn't, for > >>example the range of request-ID being '1..n' and not '0..n')? > > > >Ira, > >The Protocol document was changed in section 3.6 to make the example value > >for clients that aren't using it be the constant 1, instead of 0, > >so that its value is a legal value as agreed to align with the Job MIB and > >the SNMP requirement not to use 0 as a table index value. > > > >However, the ABNF fails to specify the syntax of the request-id token. > >(0 or 1). It should be SIGNED-INTEGER, as all four octet integers are, > >but with some restriction on the range to be 1 to 2**31-1. > > > >Also I would think that section 3.6 should also include the range limits, > >as has been done for other fields. > > > >Also the Model document doesn't seem to mention the request-id at all, > >that I could find. I'm not sure whether it should or not, since the > >request-id is more of a protocol mechanism. > > I found where "request id" is specified in the Model document. Its in > section 3.1.1. In the protocol document, its called "request-id", but > is called "request id" in the Model document (which is why I didn't > find it when searching the Model document). However, the lower bound > is still specified as 0 to 2**31-1 in section 3.1.1 in the Model document > and needs to be changed to be: 1 to 2**31-1 as agreed. > > Perhaps the protocol document section 3.6 should also be fixed to mention > the "request id" in the model document as mapping to the "request-id" > in the protocol document? > > > > >Thanks, > >Tom > > > >snip... > > > > > > > > > From ipp-owner@pwg.org Mon Jan 5 22:01:01 1998 Delivery-Date: Mon, 05 Jan 1998 22:01:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA26216 for ; Mon, 5 Jan 1998 22:01:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA05301 for ; Mon, 5 Jan 1998 22:03:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA28910 for ; Mon, 5 Jan 1998 22:01:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 5 Jan 1998 21:54:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27705 for ipp-outgoing; Mon, 5 Jan 1998 21:29:20 -0500 (EST) Message-Id: <3.0.1.32.19980105182448.00e74b10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 5 Jan 1998 18:24:48 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - "orientation" enum should have values 3, 4, 5, not 1, 2, 3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org When we assigned enum values for the "orientation" attribute, we started at 1, instead of 3, since the Job Monitoring MIB doesn't currently have an orientation attribute. But if we added one to the Job Monitoring MIB in the future, or a private implementation did, the values would have to be offset from the IPP values. To avoid such an implementation nusiance, lets offset the IPP values now, as if we had obtained them from a MIB. So change 'portrait' to be '3', 'landscape' to be '4', and 'reverse-landscape' to be '5' in section 4.2.10. Then the enum values will also agree with the note in section 4.1.6 'enum': Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP out of band value 'unknown'. See the description of the "out-of-band" values at the beginning of Section Attribute Syntaxes. Therefore, most attributes of type 'enum' often start at '3'. In fact, we could delete "most" and "often" in the note, so that it reads: Therefore, attributes of type 'enum' start at '3'. since there are no other enum attributes that use '1' and '2' values and there shouldn't be any in the future either. Here is the current text for the "orientation" attribute: 4.2.10 orientation (type2 enum) This attribute specifies the orientation of the content of the print-stream pages to be printed. In most cases, the orientation of the content is specified within the document format generated by the device driver at print time. However, some document formats (such as 'text/plain') do not support the notion of page orientation, and it is possible to bind the orientation after the document content has been generated. This attribute provides an end user with the means to specify orientation for such documents. Standard values are: Value Symbolic Name and Description '1' 'portrait': The content will be imaged across the short edge of the medium. '2' 'landscape': The content will be imaged across the long edge of the medium. Landscape is defined to be a rotation of the print-stream page to be imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from the portrait orientation. Note: The +90 direction was chosen because simple finishing on the long edge is the same edge whether portrait or landscape '3' 'reverse-landscape': The content will be imaged across the long edge of the medium. Reverse-landscape is defined to be a rotation of the print-stream page to be imaged by -90 degrees with respect to the medium (i.e. clockwise) from the portrait orientation. Note: The 'reverse-landscape' value was added because some applications rotate landscape -90 degrees from portrait, rather than +90 degrees. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section multiple-document-handling (type2 keyword)) and the relationship of this attribute and the other attributes that control document processing is described in section Using Job Template Attributes During Document Processing.. From ipp-owner@pwg.org Tue Jan 6 08:55:22 1998 Delivery-Date: Tue, 06 Jan 1998 08:55:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA07361 for ; Tue, 6 Jan 1998 08:55:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA06002 for ; Tue, 6 Jan 1998 08:58:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA01023 for ; Tue, 6 Jan 1998 08:55:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 08:42:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA29851 for ipp-outgoing; Tue, 6 Jan 1998 08:18:51 -0500 (EST) From: don@lexmark.com Message-Id: <199801061318.AA03853@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 6 Jan 1998 08:18:40 -0500 Subject: IPP> ADM: Conference Calls 1/7, 1/14, 1/21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the details on the next three IPP conference calls. Date: 1/7, 1/14, 1/21 Call-in: 1-423-523-7162 Access: 190148 Time: 4PM EST (1PM PST) Duration: 2.5 hours See you then! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Jan 6 08:55:24 1998 Delivery-Date: Tue, 06 Jan 1998 08:55:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA07366 for ; Tue, 6 Jan 1998 08:55:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA06005 for ; Tue, 6 Jan 1998 08:58:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA01029 for ; Tue, 6 Jan 1998 08:55:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 08:47:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA29866 for ipp-outgoing; Tue, 6 Jan 1998 08:24:57 -0500 (EST) From: Roger K Debry To: Subject: IPP>TES - January agenda Message-ID: <5030100015762054000002L042*@MHS> Date: Tue, 6 Jan 1998 08:24:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA07366 I wonder how fruitful it will be to devote an entire day to Testing, given the low participation thus far in these discussions. There has not even been any active teleconference sessions recently. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Jan 6 14:53:21 1998 Delivery-Date: Tue, 06 Jan 1998 14:53:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA14107 for ; Tue, 6 Jan 1998 14:53:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA07551 for ; Tue, 6 Jan 1998 14:56:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA03394 for ; Tue, 6 Jan 1998 14:53:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 14:48:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02825 for ipp-outgoing; Tue, 6 Jan 1998 14:34:26 -0500 (EST) From: Carl Kugler To: Subject: IPP> FW: User Petition on Standards to Netscape and Microsof Message-ID: <5030100015780812000002L022*@MHS> Date: Tue, 6 Jan 1998 14:34:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA14107 I agree. When I see BNF I think of implementing with tools like lex & yacc or JavaCC, but I don't think they would work too well for IPP. I think it would be great to have a machine-readable grammar for IPP. Or, less preferably, an ASN.1 definition, naturally machine-readable. -Carl ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/06/98 10:52 AM --------------------------- ipp-owner@pwg.org on 12/30/97 01:25:17 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> FW: User Petition on Standards to Netscape and Microsof This is part of an interesting thread going on regarding the pros and cons of binary vs. ascii encodings of application layer protocols...The central theme being the use of ABNF for specifying text-based application protocols vs. ASN.1 for specifying binary application protocols. Apparently, we (the IPP WG) are breaking new ground in our use of ABNF for essentially a binary protocol. It doesn't appear that the essence of ABNF was designed for this... Randy > -----Original Message----- > From: Chris Newman [SMTP:Chris.Newman@innosoft.com] > Sent: Tuesday, December 30, 1997 4:43 PM > To: Stephen Kent > Cc: ietf@ns.ietf.org > Subject: Re: User Petition on Standards to Netscape and Microsoft > > On Tue, 30 Dec 1997, Stephen Kent wrote: > > I would not disagree with the characterization of textual > protocols > > as easier to debug without the need for more sophisticated tools. > However, > > debugging ease is not the only consideration when designing > protocols. IP, > > TCP, UDP, PPP, and other widely used Internet protocols are not > textual, > > yet we have managed to debug them and deploy interoperable > implementations > > for many years. We respectually disagree about the relative merits > of > > using non-textual syntax for protocols, whether it's ASN.1 or > alternatives. > > If you read my message carefully, you will note that I said > "application > protocols." The four protocols you've listed are not application > protocols and therefore have different design criteria (which tend to > discourage the use of ASN.1 for different reasons). > > The most successful IETF binary-encoded application protocol is > Telnet, > which is generally considered a good example of how not to design a > protocol (due to the complexity of option negotiation and debugging > thereof). It took me significantly longer to write and debug a telnet > client than it took me to write and debug clients/servers for textual > protocols. I had to build a complex debugging service into the client > which I've never needed in textual protocols. I will note that telnet > has > orders of magnitude more deployment than its ASN.1 based counterpart > which > is yet another strike against ASN.1, even when a binary encoding is > used. > > As an application protocol developer, I trust the judgement of > lower-level > protocol developers to make the right choice in the binary vs. text > encoding tradeoff. But at the applications level, both IETF history > and > my personal experience weigh heavily in favor of textual protocols. > Let's > not ignore our successful history. > > - Chris From ipp-owner@pwg.org Tue Jan 6 15:35:26 1998 Delivery-Date: Tue, 06 Jan 1998 15:35:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14907 for ; Tue, 6 Jan 1998 15:35:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA07710 for ; Tue, 6 Jan 1998 15:37:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04195 for ; Tue, 6 Jan 1998 15:35:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 15:30:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03529 for ipp-outgoing; Tue, 6 Jan 1998 15:16:22 -0500 (EST) Message-Id: <3.0.1.32.19980106101210.00af8150@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 10:12:10 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>TES - January agenda In-Reply-To: <5030100015762054000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 05:24 AM 1/6/98 PST, Roger K Debry wrote: >I wonder how fruitful it will be to devote an entire day to Testing, given the >low >participation thus far in these discussions. There has not even been any active >teleconference sessions recently. > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > Roger, The intent of the Maui day on testing is really to make it more into a workshop in which we can initiate the necessary activities in this area. I hope that we can get enough of the right people to attend so that we can achieve that goal. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jan 6 16:18:30 1998 Delivery-Date: Tue, 06 Jan 1998 16:18:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA15398 for ; Tue, 6 Jan 1998 16:18:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA07894 for ; Tue, 6 Jan 1998 16:21:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA05171 for ; Tue, 6 Jan 1998 16:18:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 16:14:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04515 for ipp-outgoing; Tue, 6 Jan 1998 15:59:59 -0500 (EST) Message-Id: <3.0.1.32.19980106124048.00e73ba0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 12:40:48 PST To: Carl-Uno Manros , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Outside the box resolution for the two URIs issue Cc: masinter@parc.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com In-Reply-To: <3.0.1.32.19980105155939.00ae8c90@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Refining this proposal a bit (after discussions with Scott and Carl-Uno): The changes to the current Model document would be: 1. Remove the "printer-tls-uri" attribute from the Printer object and the directory. 2. Rename the "printer-uri" Printer and Directory attribute to "printer-uri-supported" and make it multi-valued, i.e., 1setOf uri. 3. Keep the "printer-uri" Operation attribute as a single-valued attribute that is the uri being used on this operation. Thus its single value is just like the single value of the "document-format" operation attribute, i.e., one of the values of the curresponding "xxx-suported" attribute ("printer-uri-supuported" in this case). At 15:59 01/05/1998 PST, Carl-Uno Manros wrote: > >I got some private feedback from Larry Mainter on this issue, which >triggered some further thoughts that I wanted to share with you. > >I like Bob's approach because it provides the functionality within IPP, >while Randy's approach might be easier to implement, but makes us dependent >on HTTP functionality for redirects, which may not be available in other >transfer protocols. > >Maybe we should think outside the box instead. Larry asked why do we limit >ourselves to TWO URIs? Thinking about extensibility, I think Larry has a >point. > >If we want to add a new mapping for IPP on top of HTTP NG or whatever and >the IPP server can support both that and the current HTTP and HTTPS >mappings, where do we put the additional URI in the IPP protocol? If >instead, we made the Printer URI a MULTI-VALUED attribute, we could add any >number of future transfer protocols for the same IPP Printer without having >to revise our model. The IPP client would probably need to understand the >scheme part of the URI, but could then choose any of the offered URI >alternatives, with more or less security etc. We would probably need to add >some rules about whether the same transfer protocol has to be used for a >particular IPP Job, or if the client can use different ones, provided that >the same level of security is maintained. Another question is whether the >IPP Server would always return Job URIs with the same scheme as the one >with which the job request was submitted. A consequence of this propoal is >that directory entries might have multiple URIs for the same IPP Printer. > >Is this approach worth further discussion? > >Carl-Uno > > > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Tue Jan 6 16:40:23 1998 Delivery-Date: Tue, 06 Jan 1998 16:40:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA15732 for ; Tue, 6 Jan 1998 16:40:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA08005 for ; Tue, 6 Jan 1998 16:43:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06133 for ; Tue, 6 Jan 1998 16:40:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 16:33:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05214 for ipp-outgoing; Tue, 6 Jan 1998 16:18:50 -0500 (EST) Message-Id: <3.0.1.32.19980106125710.01021cb0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 12:57:10 PST To: Jay Martin , Ron Bergman From: Tom Hastings Subject: Re: IPP> More Time for IPP in January [agenda: IPP notification] Cc: don@lexmark.com, ipp@pwg.org, Sense , Harry Lewis In-Reply-To: <34B11CBB.446A347D@underscore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Jay, I assume that you are unable to attend the meeting? Thats too bad, because I though we were making some good progress on understanding SENSE. One of the hot items for IPP is how to do notifications which we deleted at the last minute from the Model document, so that we could publish the RFC without notification for the time being and work a real solution in a short time period after publishing V1.0. The desire is to agree on something quick enough that IPP implementations can converge on it, rather than implementors coming up with their own (different) solutions. We need to avoid the problem in IPP that we see in SNMP where each implementor does his/her own private trap registration mechanism. I hope that we can discuss IPP notification in the IPP meeting, anyway, and use as much of SENSE as makes sense. So others of us need to read the SENSE specs for the IPP discussion. Tom At 09:47 01/05/1998 PST, Jay Martin wrote: >Ron Bergman wrote: > >> I agree with Harry, let's not overlap the agenda items. >> >> I do not anticipate any time required for the Job MIB so that Thursday can >> be shared by IPP and SENSE. I assume that Friday is still reserved for >> the Finisher MIB. > >Sorry, but there will be no SENSE session at the upcoming January >PWG meetings in Hawaii. :-( > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From ipp-owner@pwg.org Tue Jan 6 17:38:28 1998 Delivery-Date: Tue, 06 Jan 1998 17:38:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA16608 for ; Tue, 6 Jan 1998 17:38:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA08268 for ; Tue, 6 Jan 1998 17:41:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07344 for ; Tue, 6 Jan 1998 17:38:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 17:34:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06755 for ipp-outgoing; Tue, 6 Jan 1998 17:19:53 -0500 (EST) Message-Id: <3.0.1.32.19980106141302.00a0ecc0@tralfaz> X-Sender: sjohnson@tralfaz X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 14:13:02 PST To: ipp@pwg.org From: Swen Johnson Subject: IPP> MOD - Send-URI "document-uri" and "last-document" Cc: xriley@cp10.es.xerox.com, rick@cp10.es.xerox.com, sjohnson@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org 3.3.1.2 Send-Document Response says, "... since a client might not know that the previous document sent with a Send-Document operation was the last document... it is legal to send a Send-Document request with no document data where the "last-document" flag is set to 'true'".) 3.3.2 Send-URI Operation says, "This OPTIONAL operation is identical to the Send-Document Operation ... except that a client MUST supply a URI reference ... rather than the document data itself..." Is this intended to imply that the client must supply a "document-uri" even when "last-document" is 'true' ? Or is the "document-uri" to be treated analogously to the document data ? -- Swen From ipp-owner@pwg.org Tue Jan 6 19:33:57 1998 Delivery-Date: Tue, 06 Jan 1998 19:33:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA18301 for ; Tue, 6 Jan 1998 19:33:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA08520 for ; Tue, 6 Jan 1998 19:36:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA08081 for ; Tue, 6 Jan 1998 19:33:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 19:29:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07536 for ipp-outgoing; Tue, 6 Jan 1998 19:15:21 -0500 (EST) Date: Tue, 6 Jan 1998 16:10:21 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801070010.QAA13269@woden.eng.sun.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Outside the box resolution for the two URIs issue Cc: masinter@parc.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have a concern about the proposal for printer-uri-supported. In our current model, there are at most 2 URIs, one for HTTP and the other for HTTPS. With my proposed printer-alt-uri, the client knows that it can access the URI specified by printer-alt-uri via the alternate mechanism, e.g. TLS if the client obtained the URI via HTTP. With the new more general mechanism that you are suggesting, a printer could have many URIs, but a client has no way to determine what mechanism should be used for each member of the printer-uri-supported. So this is an incomplete mechanism which I don't suggest we complete at this stage. In addition, for the current HTTP/HTTPS model, the client must determine the alternate printer URI by finding the URI not equal to the one it knows about. This is more difficult than getting the value of printer-alt-uri. So, printer-uri-supported is certainly the more general solution and it may be better in the future if we add another attribute to indicate the mechanism associated with the URI. But, in the context of version 1.0, it just adds complexity. Bob Herriot > From hastings@cp10.es.xerox.com Tue Jan 6 13:14:44 1998 > X-Sender: hastings@garfield > X-Mailer: Windows Eudora Pro Version 3.0.1 (32) > Date: Tue, 6 Jan 1998 12:40:48 PST > To: Carl-Uno Manros , ipp@pwg.org > From: Tom Hastings > Subject: Re: IPP> MOD - Outside the box resolution for the two URIs > issue > Cc: masinter@parc.xerox.com, manchala@cp10.es.xerox.com, > xriley@cp10.es.xerox.com > In-Reply-To: <3.0.1.32.19980105155939.00ae8c90@garfield> > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 58 > > Refining this proposal a bit (after discussions with Scott and Carl-Uno): > > The changes to the current Model document would be: > > 1. Remove the "printer-tls-uri" attribute from the Printer object and > the directory. > 2. Rename the "printer-uri" Printer and Directory attribute to > "printer-uri-supported" and make it multi-valued, i.e., 1setOf uri. > 3. Keep the "printer-uri" Operation attribute as a single-valued > attribute that is the uri being used on this operation. Thus its single > value is just like the single value of the "document-format" operation > attribute, i.e., one of the values of the curresponding "xxx-suported" > attribute ("printer-uri-supuported" in this case). > > > At 15:59 01/05/1998 PST, Carl-Uno Manros wrote: > > > >I got some private feedback from Larry Mainter on this issue, which > >triggered some further thoughts that I wanted to share with you. > > > >I like Bob's approach because it provides the functionality within IPP, > >while Randy's approach might be easier to implement, but makes us dependent > >on HTTP functionality for redirects, which may not be available in other > >transfer protocols. > > > >Maybe we should think outside the box instead. Larry asked why do we limit > >ourselves to TWO URIs? Thinking about extensibility, I think Larry has a > >point. > > > >If we want to add a new mapping for IPP on top of HTTP NG or whatever and > >the IPP server can support both that and the current HTTP and HTTPS > >mappings, where do we put the additional URI in the IPP protocol? If > >instead, we made the Printer URI a MULTI-VALUED attribute, we could add any > >number of future transfer protocols for the same IPP Printer without having > >to revise our model. The IPP client would probably need to understand the > >scheme part of the URI, but could then choose any of the offered URI > >alternatives, with more or less security etc. We would probably need to add > >some rules about whether the same transfer protocol has to be used for a > >particular IPP Job, or if the client can use different ones, provided that > >the same level of security is maintained. Another question is whether the > >IPP Server would always return Job URIs with the same scheme as the one > >with which the job request was submitted. A consequence of this propoal is > >that directory entries might have multiple URIs for the same IPP Printer. > > > >Is this approach worth further discussion? > > > >Carl-Uno > > > > > > > > > >Carl-Uno Manros > >Principal Engineer - Advanced Printing Standards - Xerox Corporation > >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > >Phone +1-310-333 8273, Fax +1-310-333 5514 > >Email: manros@cp10.es.xerox.com > > > > > From jmp-owner@pwg.org Tue Jan 6 20:48:02 1998 Delivery-Date: Tue, 06 Jan 1998 20:48:03 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA18683 for ; Tue, 6 Jan 1998 20:48:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA08605 for ; Tue, 6 Jan 1998 20:50:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA08407 for ; Tue, 6 Jan 1998 20:47:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 20:45:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08214 for jmp-outgoing; Tue, 6 Jan 1998 20:43:03 -0500 (EST) Message-Id: <3.0.1.32.19980106173722.01024550@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 17:37:22 PST To: "Caruso, Angelo " , "'jmp@pwg.org'" , "'ipp@pwg.org'" From: Tom Hastings Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p ageback sides or not? Cc: "'XCMI_Editors'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org At 07:33 01/05/1998 PST, Caruso, Angelo wrote: >Tom, > >I disagree that the impressions counters are intended only for >monitoring. For monitoring, you only need the jobImpressionsCompleted >and jobImpressionsRequested counters. The fullColorImpressionsCompleted >and highlightColorImpressionsCompleted attributes were proposed >specifically for accounting with color capable devices. I was only talking about jobImpressionsCompleted, not fullColorImpressionsCompleted and highlightColorImpressionsCompleted. I agree with you that the latter two are useful for accounting as well as monitoring. > >Our assumption was that impressions would be more useful for accounting >since they are more accurate than sheets. Though I am not an accounting >expert, I think providing the impression counters gives an accounting >application developer added flexibility (e.g. so that billing for blank >sides could be made optional depending on the requirements of the >customer). That was always our thinking in doing the Job Monitoring MIB as well. That is why we made the impressions MANDATORY objects, and sheets as OPTIONAL attributes. It was only at the last minute that we discussed the issue of actually implementing impression counters in devices, that we came up with the idea that "impressions" are really counting sides that pass past the marker, whether marks are made or not (again, I'm not talking about color or high light multi-passes). > >I also agree with Bill Wagner that complete accuracy would require >measuring colorant use per side. We thought about this and decided it >was way too complicated for the job MIB. Our compromise solution was to >propose the fullColor and highlightColor impressions counters. > >At any rate, it is clear that we need more input from real customers on >their accounting requirements. For example, if most print shops charge >one per-sheet rate for color devices and another rate for monochrome >devices, then the color impressions counters aren't currently needed. >But providing them offers customers a competitive edge in their billing >methods since they can be more accurate. > >Thanks, >Angelo > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Thursday, December 18, 1997 10:21 PM > To: XCMI Editors only > Subject: RE: IPP> Re: JMP> URGENT: Should impressions >include blank last pageback sides or not? > > What about this proposal to recommend, but not require, that the > back side of the last sheet not count for impressions? > > Alternatively, we could make a note that impressions is intended > for monitoring, not accounting, and keep the definition of the >number > of passes past the marker, whether marks are made or not. > Sheets is intended for accounting > which in combination with the 'sides' attribute selects the >rate. > I believe this is what Kinkos does. > > Tom > > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include >blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant >difference > between blank pages within a document and documents in a duplex >job with an > odd number of pages causing the COMPLETELY blank back side of >the last page > to be counted? Almost all page printers include an option for >not printing > such completely blank pages, and I think the point about user >concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of >impression: > >> If a two-sided document has an odd number of pages, the last >sheet still > counts as two impressions, if that sheet makes two passes >through the > marker or the marker marks on both sides of a sheet in a single >pass. > >should be: > >If a two-sided document has an odd number of pages and there >are no marks > to be made on second side of the last sheet, the last sheet >should count as > one impression, instead of two, even if that sheet makes two >passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com > >>______________________________________________________________________ > > > > > >>This was discussed in great detail at the LA meeting. If one >agrees > >>that the MIB is to provide information on what the printer >does, which > >>may not necessarily agree with what the rate structures may or >may not > >>be at a particular place at a particular time, then I think >the > >>contention that sending a sheet side through transfer and >fixing steps > >>constitutes making an impression. The question of how much >colorant is > >>put on that page is a separate one. If it is a single period, >a fully > >>colored page or a blank page, colorant use is a different >characteristic > >>from impression, and one which could be instrumented. > >> > >>In most page printers, the information that a page has no >marking is not > >>readily available. The page goes though the same processes, >takes pretty > >>much the same time and the same wear and tear on the >mechanism. I > >>suggest that, unless the printer has a way of separately >ejecting such > >>sheet sides, from a printer point of view, treating a blank >side > >>differently is an artificial distinction. > >> > >>The point may be moot. I am told that commercial duplication >houses > >>charge by the sheet, with perhaps a different sheet rate for >duplex (but > >>no distinction for blank sides). A large in-house reports >person told > >>me that there are no blank pages; there is a header or footer, >a page > >>number, or a "This page intentionally left blank" message. > >> > >>I suggest that a measure of importance from those actually >concerned > >>with the accounting be obtained before the MIB imposes the >derivation of > >>another parameter on the printer. > >> > >>W. A. Wagner (Bill Wagner) > >>OSICOM/DPI > >> > >>> -----Original Message----- > >>> From: Jay Martin [SMTP:jkm@underscore.com] > >>> Sent: Wednesday, December 17, 1997 11:50 PM > >>> To: Tom Hastings > >>> Cc: jmp@pwg.org; ipp@pwg.org > >>> Subject: IPP> Re: JMP> URGENT: Should impressions include >blank > >>> last page back sides or not? > >>> > >>> Sorry, but I must agree with Angelo Caruso with the position > >>> that most folks are going to be pretty upset if they are > >>> charged for blanks sides of sheets. Can't say that I like > >>> that idea at all. > >>> > >>> ...jay > >>> > >>> >---------------------------------------------------------------------- > >>> -- JK Martin | Email: jkm@underscore.com >-- > >>> -- Underscore, Inc. | Voice: (603) 889-7000 >-- > >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 >-- > >>> -- Hudson, NH 03051-4915 | Web: >http://www.underscore.com -- > >>> >---------------------------------------------------------------------- > > > > > > > > > > > > From ipp-owner@pwg.org Tue Jan 6 21:04:23 1998 Delivery-Date: Tue, 06 Jan 1998 21:04:24 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA18799 for ; Tue, 6 Jan 1998 21:04:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA08616 for ; Tue, 6 Jan 1998 21:07:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08966 for ; Tue, 6 Jan 1998 21:04:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 20:59:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08222 for ipp-outgoing; Tue, 6 Jan 1998 20:43:10 -0500 (EST) Message-Id: <3.0.1.32.19980106173722.01024550@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 17:37:22 PST To: "Caruso, Angelo " , "'jmp@pwg.org'" , "'ipp@pwg.org'" From: Tom Hastings Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last p ageback sides or not? Cc: "'XCMI_Editors'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 07:33 01/05/1998 PST, Caruso, Angelo wrote: >Tom, > >I disagree that the impressions counters are intended only for >monitoring. For monitoring, you only need the jobImpressionsCompleted >and jobImpressionsRequested counters. The fullColorImpressionsCompleted >and highlightColorImpressionsCompleted attributes were proposed >specifically for accounting with color capable devices. I was only talking about jobImpressionsCompleted, not fullColorImpressionsCompleted and highlightColorImpressionsCompleted. I agree with you that the latter two are useful for accounting as well as monitoring. > >Our assumption was that impressions would be more useful for accounting >since they are more accurate than sheets. Though I am not an accounting >expert, I think providing the impression counters gives an accounting >application developer added flexibility (e.g. so that billing for blank >sides could be made optional depending on the requirements of the >customer). That was always our thinking in doing the Job Monitoring MIB as well. That is why we made the impressions MANDATORY objects, and sheets as OPTIONAL attributes. It was only at the last minute that we discussed the issue of actually implementing impression counters in devices, that we came up with the idea that "impressions" are really counting sides that pass past the marker, whether marks are made or not (again, I'm not talking about color or high light multi-passes). > >I also agree with Bill Wagner that complete accuracy would require >measuring colorant use per side. We thought about this and decided it >was way too complicated for the job MIB. Our compromise solution was to >propose the fullColor and highlightColor impressions counters. > >At any rate, it is clear that we need more input from real customers on >their accounting requirements. For example, if most print shops charge >one per-sheet rate for color devices and another rate for monochrome >devices, then the color impressions counters aren't currently needed. >But providing them offers customers a competitive edge in their billing >methods since they can be more accurate. > >Thanks, >Angelo > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Thursday, December 18, 1997 10:21 PM > To: XCMI Editors only > Subject: RE: IPP> Re: JMP> URGENT: Should impressions >include blank last pageback sides or not? > > What about this proposal to recommend, but not require, that the > back side of the last sheet not count for impressions? > > Alternatively, we could make a note that impressions is intended > for monitoring, not accounting, and keep the definition of the >number > of passes past the marker, whether marks are made or not. > Sheets is intended for accounting > which in combination with the 'sides' attribute selects the >rate. > I believe this is what Kinkos does. > > Tom > > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include >blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant >difference > between blank pages within a document and documents in a duplex >job with an > odd number of pages causing the COMPLETELY blank back side of >the last page > to be counted? Almost all page printers include an option for >not printing > such completely blank pages, and I think the point about user >concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of >impression: > >> If a two-sided document has an odd number of pages, the last >sheet still > counts as two impressions, if that sheet makes two passes >through the > marker or the marker marks on both sides of a sheet in a single >pass. > >should be: > >If a two-sided document has an odd number of pages and there >are no marks > to be made on second side of the last sheet, the last sheet >should count as > one impression, instead of two, even if that sheet makes two >passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com > >>______________________________________________________________________ > > > > > >>This was discussed in great detail at the LA meeting. If one >agrees > >>that the MIB is to provide information on what the printer >does, which > >>may not necessarily agree with what the rate structures may or >may not > >>be at a particular place at a particular time, then I think >the > >>contention that sending a sheet side through transfer and >fixing steps > >>constitutes making an impression. The question of how much >colorant is > >>put on that page is a separate one. If it is a single period, >a fully > >>colored page or a blank page, colorant use is a different >characteristic > >>from impression, and one which could be instrumented. > >> > >>In most page printers, the information that a page has no >marking is not > >>readily available. The page goes though the same processes, >takes pretty > >>much the same time and the same wear and tear on the >mechanism. I > >>suggest that, unless the printer has a way of separately >ejecting such > >>sheet sides, from a printer point of view, treating a blank >side > >>differently is an artificial distinction. > >> > >>The point may be moot. I am told that commercial duplication >houses > >>charge by the sheet, with perhaps a different sheet rate for >duplex (but > >>no distinction for blank sides). A large in-house reports >person told > >>me that there are no blank pages; there is a header or footer, >a page > >>number, or a "This page intentionally left blank" message. > >> > >>I suggest that a measure of importance from those actually >concerned > >>with the accounting be obtained before the MIB imposes the >derivation of > >>another parameter on the printer. > >> > >>W. A. Wagner (Bill Wagner) > >>OSICOM/DPI > >> > >>> -----Original Message----- > >>> From: Jay Martin [SMTP:jkm@underscore.com] > >>> Sent: Wednesday, December 17, 1997 11:50 PM > >>> To: Tom Hastings > >>> Cc: jmp@pwg.org; ipp@pwg.org > >>> Subject: IPP> Re: JMP> URGENT: Should impressions include >blank > >>> last page back sides or not? > >>> > >>> Sorry, but I must agree with Angelo Caruso with the position > >>> that most folks are going to be pretty upset if they are > >>> charged for blanks sides of sheets. Can't say that I like > >>> that idea at all. > >>> > >>> ...jay > >>> > >>> >---------------------------------------------------------------------- > >>> -- JK Martin | Email: jkm@underscore.com >-- > >>> -- Underscore, Inc. | Voice: (603) 889-7000 >-- > >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 >-- > >>> -- Hudson, NH 03051-4915 | Web: >http://www.underscore.com -- > >>> >---------------------------------------------------------------------- > > > > > > > > > > > > From ipp-owner@pwg.org Tue Jan 6 21:56:47 1998 Delivery-Date: Tue, 06 Jan 1998 21:56:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA19060 for ; Tue, 6 Jan 1998 21:56:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA08678 for ; Tue, 6 Jan 1998 21:59:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA10553 for ; Tue, 6 Jan 1998 21:56:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 21:44:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09041 for ipp-outgoing; Tue, 6 Jan 1998 21:05:56 -0500 (EST) Message-Id: <3.0.1.32.19980106180057.00e786c0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 6 Jan 1998 18:00:57 PST To: "Turner, Randy" , "'ipp@pwg.org'" From: Tom Hastings Subject: Re: IPP> Additional proposal details In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, I have a few questions on your proposal to use an IPP redirect mechanism. But it does seem to be simple and allows scalability where a print job could be performed on a different server than to which it was originally submitted. This was a feature that Kinko's liked. Also, as you point out, it allows an implementor and/or system administrator to decide on an operation by operation basis, which operations needs more security and which do not. The key is that all clients MUST support the redirect mechanism. I'm trying to compare your scheme with Carl-Uno and Larry's of having a single multi-valued "printer-uri-supported" Printer attribute and a single-valued "printer-uri" operation attribute. The directory entry would also be the multi-valued "printer-uri-supported" attribute. Both schemes simplify our current document and have a single attribute. See comments marked TH> below on your proposal. Tom Here is your attachment as text: TLS Redirection Modifications The following changes to the model document would be required in order to support my earlier redirection proposal. The changes appear to be simple, and would allow us to use the term "printer-uri" throughout the document, without all the "hand waving" (similar to Bob's proposal). Section 3.1.3.2 Response Operation Attributes An additional operation response attribute would be defined: server-redirect-uri This is a generic redirect (not TLS specific) that allows servers to redirect requests to another URI. NOTE: The redirect only applies to each request. A client should not assume the lifetime of a redirect to last beyond the particular request that was originally redirected. TH> Presumably, this "server-redirect-uri" Operation attribute is TH> MANDATORY for a Printer to support, but is only returned on TH> a redirect response, correct? TH> Also we need to add a redirect status code in section 13.1.3 TH> Redirection Status Codes, say, "server-redirect", correct? clients MUST recognize and use redirects. ---- For all operations, an additional operation attribute MAY be included by clients: client-TLS-requested TH> Presumably, a 'boolean' attribute, correct? TH> How about making the value of this attribute specifying what TH> security is requested, perhaps as a keyword value? TH> Something like "client-security-requested" with values: 'tls' and TH> 'digest'. This attribute would indicate to the server that the client wishes to use TLS for the session. If the server supports TLS, it would return the generic redirect response attribute described above. If the server DOES NOT support TLS, then the server would return the "scheme-not-supported" error code to the client. TH> Presumably the server rejects the request as well, correct? TH> Also this attribute is MANDATORY for a server to support, TH> but which values depends on implementation. ---- On a get-printer-attributes request, the "printer-uri" returned would always be the URI that was used to issue the get-attributes request (like Bob's proposal) On a get-job-attributes request, the "containing-printer-uri" would be either the base "printer-uri" (non-TLS), or a redirected TLS URI that was actually used to submit the job. I submit that we can leave this up to implementations since I think the client results would be the same. ---- On a get-jobs request to a printer-uri, the "containing-printer-uri" attribute returned for each job would be implementation-specific. It would either be the "printer-URI" (non-TLS) for the printer, or it could be a redirected TLS URI. This needs to be implementation-specific so as to allow servers to decide how job- specific information is displayed for a particular client. -- In addition to addressing Bob's concerns with printer-uri and printer-tls-uri, this proposal also offers the following advantages: -- It allows a TLS-capable server the ability to only require TLS negotiation for particular operations that require the server to allocate resources. For instance, a server that requires all print jobs to be authenticated might still want all clients to be able to get attributes for the printer, as well as validate job parameters, without going to the expense of performing TLS negotiation. It basically allows an administrator to decide what types of operations should be authenticated. In the current spec, ALL operations are authenticated or NONE are. This is a nice scalability feature TH> This is a good feature. However, if a client wants security and TH> only has an HTTP URL, how does it get started? It certainly doesn't TH> want to do a Print-Job and send valuable data, before gettting the TH> TLS URL. So this means that the client that wants security is forced TH> to do a Validate-Job with the HTTP://... URL in order to get back TH> the redirect HTTPS://... URL, correct? TH> After getting back the HTTPS:// URL, the client can either do another TH> Validate-Job operation to validate the attributes before wasting time TH> sending the data, or it can do the Print-Job operation and send the TH> data and risk wasting the time sending the data for a job that is TH> rejected. TH> Presumably, before doing the second validate or Print-Job, the TH> client and server perform the TLS handshake. TH> Presumably, the TLS handshake doesn't have to be repeated for the TH> Print-Job, after the second Validate-Job, correct? In other words, TH> the TLS handshake is for the session, not for each operation? TH> Only after a redirect, does the client have to repeat the TLS TH> handshake, correct? -- We no longer have to worry about publishing multiple URI strings in directories or other places in order to support TLS sessions to a server. There's only one URI for the printer. If a client attempts an operation to the printer URI, and the server deems that authentication is required, then it automatically issues a redirect, similar to the way current web browsers bounce back and forth from SSL and non-SSL connections to a a particular web "service". At 23:46 12/20/1997 PST, Turner, Randy wrote: > >Please review the attached details to the >proposal I loosely suggested earlier. This >proposal addresses Bob's concerns with >the problems of printer-uri and printer-tls-uri >handling... > >Randy > > > >Attachment Converted: "C:\WINNT\Profiles\hastings\Personal\Attach\redir.txt" > From ipp-owner@pwg.org Tue Jan 6 21:58:28 1998 Delivery-Date: Tue, 06 Jan 1998 21:58:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA19090 for ; Tue, 6 Jan 1998 21:58:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA08681 for ; Tue, 6 Jan 1998 22:01:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA10763 for ; Tue, 6 Jan 1998 21:58:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 21:47:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09036 for ipp-outgoing; Tue, 6 Jan 1998 21:05:53 -0500 (EST) Date: Tue, 6 Jan 1998 18:07:10 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801070207.AA21080@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> MOD - IPP clients SHOULD implement TLS Sender: ipp-owner@pwg.org Hi folks, At Tom and Carl-Uno's request I am casting my vote that we specify in the IPP/1.0 Model spec that, in order to facilitate interoperability of secure IPP implementations, all IPP clients SHOULD implement TLS with the "Mandatory Cipher Suites", but an IPP client MAY claim conformance (to IPP/1.0) without implementing TLS. Cheers, - Ira McDonald From ipp-owner@pwg.org Tue Jan 6 22:00:00 1998 Delivery-Date: Tue, 06 Jan 1998 22:00:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA19108 for ; Tue, 6 Jan 1998 21:59:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA08684 for ; Tue, 6 Jan 1998 22:02:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA10944 for ; Tue, 6 Jan 1998 21:59:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 21:49:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09100 for ipp-outgoing; Tue, 6 Jan 1998 21:11:53 -0500 (EST) Message-ID: <34B2E44A.4F9ACC9C@parc.xerox.com> Date: Tue, 6 Jan 1998 18:11:22 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Robert Herriot CC: cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com Subject: Re: IPP> MOD - Outside the box resolution for the two URIs issue References: <199801070010.QAA13269@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org You know, I still haven't understood why you need more than one URI. A printer is a resource. The URI is a resource identifier. A URL is a resource locator, and determines the access method by the scheme. So why do you need a resource to know about other access methods for the same resource? Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Jan 6 23:06:36 1998 Delivery-Date: Tue, 06 Jan 1998 23:06:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA26098 for ; Tue, 6 Jan 1998 23:06:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA08802 for ; Tue, 6 Jan 1998 23:09:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA12377 for ; Tue, 6 Jan 1998 23:06:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 22:59:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA11534 for ipp-outgoing; Tue, 6 Jan 1998 22:45:37 -0500 (EST) Date: Tue, 6 Jan 1998 19:40:53 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801070340.TAA13440@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, masinter@parc.xerox.com Subject: Re: IPP> MOD - Outside the box resolution for the two URIs issue Cc: cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org You ask a question that I have wondered about too. I think that the attribute for the other URI is there "just in case" some client needs it. But we aren't sure that any client will ever need it. Perhaps our reasoning should instead be: "leave it out until we find a problem needing this solution". In that case, we don't need either printer-alt-uri or printer-uri-supported. Printer-uri suffices. Bob Herriot > From masinter@parc.xerox.com Tue Jan 6 18:10:25 1998 > Date: Tue, 6 Jan 1998 18:11:22 PST > From: Larry Masinter > Organization: Xerox PARC > X-Mailer: Mozilla 4.04 [en] (Win95; U) > MIME-Version: 1.0 > To: Robert Herriot > CC: cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com, > manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com > Subject: Re: IPP> MOD - Outside the box resolution for the two URIs > issue > References: <199801070010.QAA13269@woden.eng.sun.com> > Content-Transfer-Encoding: 7bit > X-Lines: 9 > > You know, I still haven't understood why you need more than one > URI. A printer is a resource. The URI is a resource identifier. > A URL is a resource locator, and determines the access method > by the scheme. So why do you need a resource to know about other > access methods for the same resource? > > Larry > -- > http://www.parc.xerox.com/masinter > From ipp-owner@pwg.org Tue Jan 6 23:38:52 1998 Delivery-Date: Tue, 06 Jan 1998 23:39:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA26538 for ; Tue, 6 Jan 1998 23:38:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA08837 for ; Tue, 6 Jan 1998 23:41:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA13186 for ; Tue, 6 Jan 1998 23:38:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 6 Jan 1998 23:34:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA12625 for ipp-outgoing; Tue, 6 Jan 1998 23:20:34 -0500 (EST) Message-Id: <1.5.4.32.19980107031245.0073de10@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, 06 Jan 1998 19:12:45 -0800 To: Larry Masinter , Robert Herriot From: Carl-Uno Manros Subject: Re: IPP> MOD - Outside the box resolution for the two URIs issue Cc: cmanros@cp10.es.xerox.com, ipp@pwg.org, hastings@cp10.es.xerox.com, manchala@cp10.es.xerox.com, xriley@cp10.es.xerox.com Sender: ipp-owner@pwg.org At 06:11 PM 1/6/98 PST, Larry Masinter wrote: >You know, I still haven't understood why you need more than one >URI. A printer is a resource. The URI is a resource identifier. >A URL is a resource locator, and determines the access method >by the scheme. So why do you need a resource to know about other >access methods for the same resource? > >Larry >-- >http://www.parc.xerox.com/masinter > Larry, The problem is that HTTP without TLS and HTTP with TLS are using two different schemes. We have specified that the URL resource locator part of the URI SHOULD be the same, but you might for instance have different ports for the two schemes, which would result in differences. BTW has there been any discussion in the W3C HTTP NG project about whether it would share the scheme with the current HTTP or be a totally new scheme? Carl-Uno From ipp-owner@pwg.org Wed Jan 7 02:18:47 1998 Delivery-Date: Wed, 07 Jan 1998 02:18:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA27784 for ; Wed, 7 Jan 1998 02:18:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA08986 for ; Wed, 7 Jan 1998 02:21:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA14779 for ; Wed, 7 Jan 1998 02:18:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 02:14:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA13822 for ipp-outgoing; Wed, 7 Jan 1998 01:56:10 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Tom Hastings'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Additional proposal details Date: Tue, 6 Jan 1998 22:53:16 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org See my response to your comments below. My comments are marked RT> R. > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Tuesday, January 06, 1998 6:01 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> Additional proposal details > > Randy, > > I have a few questions on your proposal to use an IPP redirect > mechanism. > But it does seem to be simple and allows scalability where a print job > could > be performed on a different server than to which it was originally > submitted. This was a feature that Kinko's liked. > > Also, as you point out, it allows an implementor and/or system > administrator > to decide on an operation by operation basis, which operations needs > more security and which do not. > > The key is that all clients MUST support the redirect mechanism. > > I'm trying to compare your scheme with Carl-Uno and Larry's > of having a single multi-valued "printer-uri-supported" Printer > attribute > and a single-valued "printer-uri" operation attribute. The directory > entry would also be the multi-valued "printer-uri-supported" > attribute. > > Both schemes simplify our current document and have a single > attribute. > > See comments marked TH> below on your proposal. > > Tom > > > Here is your attachment as text: > > > TLS Redirection Modifications > > The following changes to the model document > would be required in order to support my > earlier redirection proposal. The changes > appear to be simple, and would allow us to > use the term "printer-uri" throughout the > document, without all the "hand waving" > (similar to Bob's proposal). > > > Section 3.1.3.2 Response Operation Attributes > > > An additional operation response > attribute would be defined: > > server-redirect-uri > > This is a generic redirect (not TLS specific) > that allows servers to redirect requests to > another URI. NOTE: The redirect only applies > to each request. A client should not assume > the lifetime of a redirect to last beyond the > particular request that was originally > redirected. > > TH> Presumably, this "server-redirect-uri" Operation attribute is > TH> MANDATORY for a Printer to support, but is only returned on > TH> a redirect response, correct? > RT> Yes. > TH> Also we need to add a redirect status code in section 13.1.3 > TH> Redirection Status Codes, say, "server-redirect", correct? > RT>I think we need an indication (like a status code) so RT>that the client knows that it received a redirect. If we RT>don't have a status code, then the operation response RT>attributes would have to be examined on every response RT>to see if the original request was redirected. Having a RT>status code like you suggested is better and more RT>efficient since we're already paying the price of having RT>to check the status code on all responses. > > > clients MUST recognize and use redirects. > > ---- > > For all operations, an additional operation > attribute MAY be included by clients: > > client-TLS-requested > > TH> Presumably, a 'boolean' attribute, correct? > TH> How about making the value of this attribute specifying what > TH> security is requested, perhaps as a keyword value? > TH> Something like "client-security-requested" with values: 'tls' and > TH> 'digest'. > RT>I really wouldn't like to preclude other security mechanisms RT>to be used in future IPP revisions, but I would like to nail RT>down TLS for version 1.0. I intended this operation attribute RT>to be a BOOLEAN so that (for IPP version 1.0) I'm putting a RT>stick in the mud with regards to interoperable security. RT>Having said that, we might want to say that this is an RT>enumeration, and that for version 1.0 we are only defining RT>(mandating) that this must be set to the value of "enum-tls" RT>or whatever. This would save us the hassle of having to RT>deal with the boolean for legacy IPP 1.0 implementations RT>in the future. Because if we allow more than one security RT>mechanism to be specified, then we would have to add RT>another attribute that was an enum; meaning we would RT>have to support both the boolean for legacy IPP, AND the RT>new enum. If we start out with this operation attribute as RT>an enum and mandate that for 1.0 it only has one value, RT>then we can add other possible enum values to this RT>attribute for later revisions of the protocol, and we don't RT>have the "legacy" IF statements in our code for both old RT>and new operation attributes. comments? > This attribute would indicate to the server > that the client wishes to use TLS for the > session. > > If the server supports TLS, it would return > the generic redirect response attribute > described above. If the server DOES NOT > support TLS, then the server would return the > "scheme-not-supported" error code to the > client. > > TH> Presumably the server rejects the request as well, correct? > TH> Also this attribute is MANDATORY for a server to support, > TH> but which values depends on implementation. > RT>All of the attributes and associated status codes would RT>be mandatory to support for both servers and clients. RT>However, certain schemed URIs that are returned in a RT>redirect response may not be supported by all clients. RT>(unless its an HTTPS-schemed URI, then it must be RT>supported). > > ---- > > On a get-printer-attributes request, the > "printer-uri" returned would always be the > URI that was used to issue the get-attributes > request (like Bob's proposal) > > On a get-job-attributes request, the > "containing-printer-uri" would be either the > base "printer-uri" (non-TLS), or a > redirected TLS URI that was actually used to > submit the job. I submit that we can leave > this up to implementations since I think the > client results would be the same. > > ---- > > On a get-jobs request to a printer-uri, the > "containing-printer-uri" attribute returned > for each job would be implementation-specific. > It would either be the "printer-URI" (non-TLS) > for the printer, or it could be a redirected > TLS URI. This needs to be implementation-specific > so as to allow servers to decide how job- > specific information is displayed for a > particular client. > > -- > > In addition to addressing Bob's concerns > with printer-uri and printer-tls-uri, this > proposal also offers the following > advantages: > > > -- It allows a TLS-capable server the ability > to only require TLS negotiation for > particular operations that require the server > to allocate resources. For instance, a > server that requires all print jobs to be > authenticated might still want all clients > to be able to get attributes for the printer, > as well as validate job parameters, without > going to the expense of performing TLS > negotiation. It basically allows an > administrator to decide what types of > operations should be authenticated. In the > current spec, ALL operations are authenticated > or NONE are. This is a nice scalability > feature > > TH> This is a good feature. However, if a client wants security and > TH> only has an HTTP URL, how does it get started? It certainly > doesn't > TH> want to do a Print-Job and send valuable data, before gettting the > TH> TLS URL. So this means that the client that wants security is > forced > TH> to do a Validate-Job with the HTTP://... URL in order to get back > TH> the redirect HTTPS://... URL, correct? > RT>You'll note that most of the scalability and flexibility of RT>this proposal mostly applies to IPP servers and subsequently RT>server administration framework. If a CLIENT wants a particular RT>operation to be "secure" , then it includes the RT>"client-security-requested" operation attribute with whatever RT>operation it is attempting. > TH> After getting back the HTTPS:// URL, the client can either do > another > TH> Validate-Job operation to validate the attributes before wasting > time > TH> sending the data, or it can do the Print-Job operation and send > the > TH> data and risk wasting the time sending the data for a job that is > TH> rejected. > RT>This is basically true, but we don't really define what the client RT>does, you've just outlined some potential client policies but we RT>don't "standardize" the clients behavior with regards to the RT>order of operations. We can suggest, but I don't think we need RT>to mandate. > TH> Presumably, before doing the second validate or Print-Job, the > TH> client and server perform the TLS handshake. > RT>When the client requested security using the RT>"client-security-requested" attribute, the server returned RT>a redirect response. In the normal case, the redirected RT>URI would be an HTTPS-schemed URI to which the client RT>would then re-issue the operation and negotiate security. > TH> Presumably, the TLS handshake doesn't have to be repeated for the > TH> Print-Job, after the second Validate-Job, correct? In other > words, > TH> the TLS handshake is for the session, not for each operation? > TH> Only after a redirect, does the client have to repeat the TLS > TH> handshake, correct? > RT>This is correct, TLS handshakes are expensive and the RT>successful TLS-handshake negotiated session can be used RT>for as many operations as the server decides it allows before RT>a new handshake is required. This isn't my specification, its RT>defined in detail in the TLS 1.0 specification. > -- We no longer have to worry about publishing > multiple URI strings in directories or other > places in order to support TLS sessions to > a server. There's only one URI for the > printer. If a client attempts an operation to > the printer URI, and the server deems that > authentication is required, then it > automatically issues a redirect, similar to > the way current web browsers bounce back and > forth from SSL and non-SSL connections to a > a particular web "service". > > At 23:46 12/20/1997 PST, Turner, Randy wrote: > > > >Please review the attached details to the > >proposal I loosely suggested earlier. This > >proposal addresses Bob's concerns with > >the problems of printer-uri and printer-tls-uri > >handling... > > > >Randy > > > > > > > >Attachment Converted: > "C:\WINNT\Profiles\hastings\Personal\Attach\redir.txt" > > From ipp-owner@pwg.org Wed Jan 7 09:20:21 1998 Delivery-Date: Wed, 07 Jan 1998 09:20:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00658 for ; Wed, 7 Jan 1998 09:20:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA09593 for ; Wed, 7 Jan 1998 09:23:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA16141 for ; Wed, 7 Jan 1998 09:20:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 09:09:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA15138 for ipp-outgoing; Wed, 7 Jan 1998 08:47:22 -0500 (EST) From: Roger K Debry To: Subject: IPP> MOD - IPP clients SHOULD implement TLS Message-ID: <5030100015820686000002L062*@MHS> Date: Wed, 7 Jan 1998 08:47:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA00658 RKD> **MAY** it support another security mechanism, such as SSL????? Roger K deBry Senior Technical 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 01/07/98 06:46 AM --------------------------- ipp-owner@pwg.org on 01/06/98 02:51:07 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> MOD - IPP clients SHOULD implement TLS Hi folks, At Tom and Carl-Uno's request I am casting my vote that we specify in the IPP/1.0 Model spec that, in order to facilitate interoperability of secure IPP implementations, all IPP clients SHOULD implement TLS with the "Mandatory Cipher Suites", but an IPP client MAY claim conformance (to IPP/1.0) without implementing TLS. Cheers, - Ira McDonald From ipp-owner@pwg.org Wed Jan 7 09:26:58 1998 Delivery-Date: Wed, 07 Jan 1998 09:26:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00715 for ; Wed, 7 Jan 1998 09:26:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA09627 for ; Wed, 7 Jan 1998 09:29:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA16781 for ; Wed, 7 Jan 1998 09:26:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 09:23:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA15174 for ipp-outgoing; Wed, 7 Jan 1998 08:58:23 -0500 (EST) From: Roger K Debry To: Subject: IPP> redirection Message-ID: <5030100015821236000002L062*@MHS> Date: Wed, 7 Jan 1998 08:58:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA00715 Well, I've finally made it through all of me email after being on vacation over the the holidays. Maybe I'm getting too old and slow to keep up with the rest of you guys, but frankly I am not sure I understand clearly what the various proposals are that are on the table with respect to handling TLS connections. It would be helpful if some good soul could summarize the current state of the proposals - - or have we reached agreement?? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Jan 7 10:14:59 1998 Delivery-Date: Wed, 07 Jan 1998 10:14:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA01400 for ; Wed, 7 Jan 1998 10:14:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09790 for ; Wed, 7 Jan 1998 10:17:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA18078 for ; Wed, 7 Jan 1998 10:14:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 10:10:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA16952 for ipp-outgoing; Wed, 7 Jan 1998 09:51:58 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> Additional proposal details Message-ID: <5030100015823604000002L042*@MHS> Date: Wed, 7 Jan 1998 09:51:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA01400 Comment on Randy's proposal ... TLS Redirection Modifications The following changes to the model document would be required in order to support my earlier redirection proposal. The changes appear to be simple, and would allow us to use the term "printer-uri" throughout the document, without all the "hand waving" (similar to Bob's proposal). Section 3.1.3.2 Response Operation Attributes An additional operation response attribute would be defined: server-redirect-uri We've not introduced a formal server object up to this point. It seems that using this naming convention now requires us to say something about a server, although it may not be an IPP object. Is this construed to be a print server, a connection server, a web server? This is a generic redirect (not TLS specific) that allows servers to redirect requests to another URI. NOTE: The redirect only applies to each request. A client should not assume the lifetime of a redirect to last beyond the particular request that was originally redirected. Any rules about cascading redirects? clients MUST recognize and use redirects. ---- For all operations, an additional operation attribute MAY be included by clients: client-TLS-requested This attribute would indicate to the server that the client wishes to use TLS for the session. What is a session? Do we need to define it in IPP terms? Why not define a new operation, called Request-TLS-Connection? This would seem much cleaner than allowing the client-TLS requested operation attribute in every existing operation. It sems that the latter requires a lot of "programming hints" to make it work efficiently. For example, you would never send a print-job with real data with a client-TLS-requested attribute, would you? If the server supports TLS, it would return the generic redirect response attribute described above. If the server DOES NOT support TLS, then the server would return the "scheme-not-supported" error code to the client. The term "redirect" doesn't seem quite right here. I haven't really re-directed the request someplace else, as occurs in HTTP. I've simply responded with an address to be used when the client wants a TLS session. In effect, it seems I've done nothing more than made it difficult for the client to retrieve the "printer-tls-uri" attribute that could have been in the directory to start with! ---- On a get-printer-attributes request, the "printer-uri" returned would always be the URI that was used to issue the get-attributes request (like Bob's proposal) Which URI would you expect the user to issue on a get-print-attributes request? The redirected one, or the original one? Would the responses be different? On a get-job-attributes request, the "containing-printer-uri" would be either the base "printer-uri" (non-TLS), or a redirected TLS URI that was actually used to submit the job. I submit that we can leave this up to implementations since I think the client results would be the same. It seems to me that the semantics are different though. If I return a re- directed TLS URI, Aren't I saying to you that you must use this secure connection to take any subsequent actions on this job? ---- On a get-jobs request to a printer-uri, the "containing-printer-uri" attribute returned for each job would be implementation-specific. It would either be the "printer-URI" (non-TLS) for the printer, or it could be a redirected TLS URI. This needs to be implementation-specific so as to allow servers to decide how job- specific information is displayed for a particular client. Sorry, but I'm totally confused here. I guess I missed it when "containing- printer-uri" slipped into the specification. Why do I ask a printer to tell me what jobs are queued on it, and expect every job to come back telling me what printer it is queued on??? -- In addition to addressing Bob's concerns with printer-uri and printer-tls-uri, this proposal also offers the following advantages: -- It allows a TLS-capable server the ability to only require TLS negotiation for particular operations that require the server to allocate resources. For instance, a server that requires all print jobs to be authenticated might still want all clients to be able to get attributes for the printer, as well as validate job parameters, without going to the expense of performing TLS negotiation. It basically allows an administrator to decide what types of operations should be authenticated. In the current spec, ALL operations are authenticated or NONE are. This is a nice scalability feature I guess I don't understand why this proposal does anything better than Bob's. With Bob's proposal why can't I require printer-tls-uri for some operations and allow printer-uri for others, knowing that they both apply to the same printer -- one just being a secure connection? -- We no longer have to worry about publishing multiple URI strings in directories or other places in order to support TLS sessions to a server. There's only one URI for the printer. If a client attempts an operation to the printer URI, and the server deems that authentication is required, then it automatically issues a redirect, similar to the way current web browsers bounce back and forth from SSL and non-SSL connections to a a particular web "service". See my previous comment. It appears to me that all you have done is to force the client to use an operation attribute (and thereby possibly end up with some weird flows) to find out what the URI is for a secure conenction, instead of simply looking in the directory. From ipp-owner@pwg.org Wed Jan 7 10:55:21 1998 Delivery-Date: Wed, 07 Jan 1998 10:55:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02073 for ; Wed, 7 Jan 1998 10:55:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10006 for ; Wed, 7 Jan 1998 10:58:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA18882 for ; Wed, 7 Jan 1998 10:55:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 10:51:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA18262 for ipp-outgoing; Wed, 7 Jan 1998 10:36:42 -0500 (EST) Message-Id: <1.5.4.32.19980107143530.00704d78@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: Wed, 07 Jan 1998 06:35:30 -0800 To: "Turner, Randy" , "'Tom Hastings'" From: Carl-Uno Manros Subject: RE: IPP> Additional proposal details Cc: "'ipp@pwg.org'" Sender: ipp-owner@pwg.org At 10:53 PM 1/6/98 -0800, Turner, Randy wrote: > >See my response to your comments below. > >My comments are marked RT> > >R. > Randy, I have not copied your while message, only one comment from you, where I think you are breaking the security. Carl-Uno >> -- It allows a TLS-capable server the ability >> to only require TLS negotiation for >> particular operations that require the server >> to allocate resources. For instance, a >> server that requires all print jobs to be >> authenticated might still want all clients >> to be able to get attributes for the printer, >> as well as validate job parameters, without >> going to the expense of performing TLS >> negotiation. It basically allows an >> administrator to decide what types of >> operations should be authenticated. In the >> current spec, ALL operations are authenticated >> or NONE are. This is a nice scalability >> feature >> >> TH> This is a good feature. However, if a client wants security and >> TH> only has an HTTP URL, how does it get started? It certainly >> doesn't >> TH> want to do a Print-Job and send valuable data, before gettting the >> TH> TLS URL. So this means that the client that wants security is >> forced >> TH> to do a Validate-Job with the HTTP://... URL in order to get back >> TH> the redirect HTTPS://... URL, correct? >> > RT>You'll note that most of the scalability and flexibility of > RT>this proposal mostly applies to IPP servers and subsequently > RT>server administration framework. If a CLIENT wants a >particular > RT>operation to be "secure" , then it includes the > RT>"client-security-requested" operation attribute with whatever > RT>operation it is attempting. > CM> If you try this with a job submission operation, you have already sent CM> your MIME type application/ipp, which means that all your data were sent CM> unencrypted before you got the secure URI back, so your feature does CM> not make any sense in combination with certain operations. It is not as CM> generic as you describe it above. Instead you might actually mislead CM> a user to think that their transmission is secure, when in reality CM> it is not. --- From ipp-owner@pwg.org Wed Jan 7 11:24:19 1998 Delivery-Date: Wed, 07 Jan 1998 11:24:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA02545 for ; Wed, 7 Jan 1998 11:24:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10128 for ; Wed, 7 Jan 1998 11:27:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19659 for ; Wed, 7 Jan 1998 11:24:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 11:19:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19042 for ipp-outgoing; Wed, 7 Jan 1998 11:05:21 -0500 (EST) Message-Id: <1.5.4.32.19980107150147.006f9594@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: Wed, 07 Jan 1998 07:01:47 -0800 To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP> Additional proposal details Sender: ipp-owner@pwg.org Some comments on Roger's comments below. Carl-Uno At 09:51 AM 1/7/98 -0500, Roger K Debry wrote: >Comment on Randy's proposal ... > >TLS Redirection Modifications > >The following changes to the model document >would be required in order to support my >earlier redirection proposal. The changes >appear to be simple, and would allow us to >use the term "printer-uri" throughout the >document, without all the "hand waving" >(similar to Bob's proposal). > > >Section 3.1.3.2 Response Operation Attributes > > >An additional operation response >attribute would be defined: > >server-redirect-uri > > We've not introduced a formal server > object up to this point. It seems that > using this naming convention now > requires us to say something about a > server, although it may not be an IPP > object. Is this construed to be a print > server, a connection server, a web server? CM> I think we could call it printer-.... CM> as this does not apply to job operations (which CM> would need to use the URI they were originally CM> given as result of the job submission. We will CM> need to introduce a rule that if a job CM> submission used TLS, the JobURI also has to CM> be from the HTTPS scheme. > >This is a generic redirect (not TLS specific) >that allows servers to redirect requests to >another URI. NOTE: The redirect only applies >to each request. A client should not assume >the lifetime of a redirect to last beyond the >particular request that was originally >redirected. > > Any rules about cascading redirects? > >clients MUST recognize and use redirects. > >---- > >For all operations, an additional operation >attribute MAY be included by clients: > >client-TLS-requested > >This attribute would indicate to the server >that the client wishes to use TLS for the >session. > > What is a session? Do we need to > define it in IPP terms? CM> This only needs to be talked about in the CM> protocol document, and there a session is CM> what HTTP defines as a session. > > Why not define a new operation, called > Request-TLS-Connection? This would seem > much cleaner than allowing the client-TLS > requested operation attribute in every > existing operation. It sems that the latter > requires a lot of "programming hints" to > make it work efficiently. For example, you > would never send a print-job with real data > with a client-TLS-requested attribute, > would you? CM> We had this in our internal discussion yesterday, CM> and the more I think about it, the more sense it CM> makes to have a separate operation for the scheme CM> switching, initiated by the IPP client. > > >If the server supports TLS, it would return >the generic redirect response attribute >described above. If the server DOES NOT >support TLS, then the server would return the >"scheme-not-supported" error code to the >client. > > The term "redirect" doesn't seem quite > right here. I haven't really re-directed > the request someplace else, as occurs in > HTTP. I've simply responded with an address > to be used when the client wants a TLS > session. In effect, it seems I've done > nothing more than made it difficult for the > client to retrieve the "printer-tls-uri" > attribute that could have been in the > directory to start with! CM> I think Roger is right again about the terminology, CM> we are trying to use this for both scheme switching CM> and redirects, the first one intitated by the client, CM> the second by the server. CM> Whatever we do with the redirect, I still support the CM> idea of having a multi-valued printer-URI attribute CM> where the right URI scheme can be picked up directly, CM> as Roger points out. > >---- > >On a get-printer-attributes request, the >"printer-uri" returned would always be the >URI that was used to issue the get-attributes >request (like Bob's proposal) > > Which URI would you expect the user to > issue on a get-print-attributes request? > The redirected one, or the original one? > Would the responses be different? > >On a get-job-attributes request, the >"containing-printer-uri" would be either the >base "printer-uri" (non-TLS), or a >redirected TLS URI that was actually used to >submit the job. I submit that we can leave >this up to implementations since I think the >client results would be the same. > > It seems to me that the semantics are > different though. If I return a re- > directed TLS URI, Aren't I saying to you > that you must use this secure connection > to take any subsequent actions on this > job? > >---- > >On a get-jobs request to a printer-uri, the >"containing-printer-uri" attribute returned >for each job would be implementation-specific. >It would either be the "printer-URI" (non-TLS) >for the printer, or it could be a redirected >TLS URI. This needs to be implementation-specific >so as to allow servers to decide how job- >specific information is displayed for a >particular client. > > Sorry, but I'm totally confused here. I > guess I missed it when "containing- > printer-uri" slipped into the specification. > Why do I ask a printer to tell me what jobs > are queued on it, and expect every job to > come back telling me what printer it is > queued on??? > >-- > >In addition to addressing Bob's concerns >with printer-uri and printer-tls-uri, this >proposal also offers the following >advantages: > > >-- It allows a TLS-capable server the ability > to only require TLS negotiation for > particular operations that require the server > to allocate resources. For instance, a > server that requires all print jobs to be > authenticated might still want all clients > to be able to get attributes for the printer, > as well as validate job parameters, without > going to the expense of performing TLS > negotiation. It basically allows an > administrator to decide what types of > operations should be authenticated. In the > current spec, ALL operations are authenticated > or NONE are. This is a nice scalability > feature > > I guess I don't understand why this proposal > does anything better than Bob's. With Bob's > proposal why can't I require printer-tls-uri > for some operations and allow printer-uri for > others, knowing that they both apply to the > same printer -- one just being a secure > connection? > >-- We no longer have to worry about publishing > multiple URI strings in directories or other > places in order to support TLS sessions to > a server. There's only one URI for the > printer. If a client attempts an operation to > the printer URI, and the server deems that > authentication is required, then it > automatically issues a redirect, similar to > the way current web browsers bounce back and > forth from SSL and non-SSL connections to a > a particular web "service". > > See my previous comment. It appears to me > that all you have done is to force the > client to use an operation attribute (and > thereby possibly end up with some weird > flows) to find out what the URI is for a > secure conenction, instead of simply looking > in the directory. > > > > From ipp-owner@pwg.org Wed Jan 7 11:59:36 1998 Delivery-Date: Wed, 07 Jan 1998 11:59:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03145 for ; Wed, 7 Jan 1998 11:59:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10278 for ; Wed, 7 Jan 1998 12:02:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20549 for ; Wed, 7 Jan 1998 11:59:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 11:54:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19878 for ipp-outgoing; Wed, 7 Jan 1998 11:39:43 -0500 (EST) Message-Id: <3.0.1.32.19980107083458.00fbfb20@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 08:34:58 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Contradictions on client MUST/SHOULD support TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org 1. There is a contradiction in the conformance requirements for clients for implementing TLS between section 5.4 and section 8.5. In changing from MUST to SHOULD after the last IPP telecon of 1997, we changed section 8.5 from MUST to SHOULD, but left section 5.4 with a MUST. Section 5.4 is a good high level summary of the security requirments with a reference to all of section 8. We just need to change section 5.4 agree with our intent which is SHOULD, as expressed in section 8.5. 2. There is a second possible contridiction with section 8.5 itself (but I'm no security expert). The sentence from section 8.5 seems to contradict itself: A conforming IPP client SHOULD support TLS, and it MUST implement and support the "Mandatory Cipher Suites" as specified in the TLS specification and MAY support additional cipher suites. If a client MUST implement and support the "Mandatory Cipher Suites" as specified in TLS, isn't that saying that the client MUST support TLS, rather than saying that a client SHOULD support TLS? Here are the two sections from the 12/19/97 Model Internet-Drafts: 5.4 Security Conformance Requirements Conforming IPP Printer objects MAY support Transport Layer Security (TLS) access, support access without TLS or support both means of access. Conforming IPP clients MUST support TLS access and non-TLS access. Note: This client requirement to support both means that conforming IPP clients will be able to inter-operate with any IPP Printer object. For a detailed discussion of security considerations and the IPP application security profile required for TLS support, see section 8. Security Considerations. 8.5 IPP Security Application Profile for TLS The IPP application profile for TLS follows the standard "Mandatory Cipher Suites" requirement as documented in the TLS specification [TLS]. Client implementations MUST NOT assume any other cipher suites are supported by an IPP Printer object. If a conforming IPP object supports TLS, it MUST implement and support the "Mandatory Cipher Suites" as specified in the TLS specification and MAY support additional cipher suites. A conforming IPP client SHOULD support TLS, and it MUST implement and support the "Mandatory Cipher Suites" as specified in the TLS specification and MAY support additional cipher suites. It is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to inter-operate with such non-compliant versions MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is completely secure from eavesdropping. From ipp-owner@pwg.org Wed Jan 7 12:16:50 1998 Delivery-Date: Wed, 07 Jan 1998 12:16:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03364 for ; Wed, 7 Jan 1998 12:16:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10344 for ; Wed, 7 Jan 1998 12:19:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21230 for ; Wed, 7 Jan 1998 12:16:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 12:12:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20370 for ipp-outgoing; Wed, 7 Jan 1998 11:56:55 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl-Uno Manros'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Additional proposal details Date: Wed, 7 Jan 1998 08:53:58 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org A client IPP implementation would never issue a "print-job" operation in the clear, and it would know that if it is using an "HTTP:" scheme that thats what is happening. An HTTP client wanting to use security for the connection would never use "print-job". It would always use "create-job" with a "client-security-requested" attribute. It would then send issue "send-data" ops , etc.. This is because its possible for redirection ot occur with any operation, and a client would want to make sure that a TLS-session is in progress to a particular IPP server before sending any sensitive data. Keep in mind that this is not only possible with IPP redirects, but is possible with standard HTTP redirects as well, which is out-of-band to actual IPP operations, and our normative scope as well (except for the protocol doc). By the way, it is possible to issue a "print-job" operation within the context of a TLS session. The client would issue a "validate-job" with the "client-security-requested" operation attribute set, and then use the returned redirect URI to issue the "print-job" operation securely. Randy > -----Original Message----- > From: Carl-Uno Manros [SMTP:carl@manros.com] > Sent: Wednesday, January 07, 1998 6:36 AM > To: Turner, Randy; 'Tom Hastings' > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Additional proposal details > > At 10:53 PM 1/6/98 -0800, Turner, Randy wrote: > > > >See my response to your comments below. > > > >My comments are marked RT> > > > >R. > > > > Randy, I have not copied your while message, only one comment from > you, > where I think you are breaking the security. > > Carl-Uno > > > >> -- It allows a TLS-capable server the ability > >> to only require TLS negotiation for > >> particular operations that require the server > >> to allocate resources. For instance, a > >> server that requires all print jobs to be > >> authenticated might still want all clients > >> to be able to get attributes for the printer, > >> as well as validate job parameters, without > >> going to the expense of performing TLS > >> negotiation. It basically allows an > >> administrator to decide what types of > >> operations should be authenticated. In the > >> current spec, ALL operations are authenticated > >> or NONE are. This is a nice scalability > >> feature > >> > >> TH> This is a good feature. However, if a client wants security > and > >> TH> only has an HTTP URL, how does it get started? It certainly > >> doesn't > >> TH> want to do a Print-Job and send valuable data, before gettting > the > >> TH> TLS URL. So this means that the client that wants security is > >> forced > >> TH> to do a Validate-Job with the HTTP://... URL in order to get > back > >> TH> the redirect HTTPS://... URL, correct? > >> > > RT>You'll note that most of the scalability and flexibility of > > RT>this proposal mostly applies to IPP servers and subsequently > > RT>server administration framework. If a CLIENT wants a > >particular > > RT>operation to be "secure" , then it includes the > > RT>"client-security-requested" operation attribute with whatever > > RT>operation it is attempting. > > > > CM> If you try this with a job submission operation, you have already > sent > CM> your MIME type application/ipp, which means that all your data > were sent > CM> unencrypted before you got the secure URI back, so your feature > does > CM> not make any sense in combination with certain operations. It is > not as > CM> generic as you describe it above. Instead you might actually > mislead > CM> a user to think that their transmission is secure, when in reality > CM> it is not. > > --- From ipp-owner@pwg.org Wed Jan 7 12:54:47 1998 Delivery-Date: Wed, 07 Jan 1998 12:54:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03714 for ; Wed, 7 Jan 1998 12:54:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10444 for ; Wed, 7 Jan 1998 12:57:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22065 for ; Wed, 7 Jan 1998 12:54:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 12:48:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21363 for ipp-outgoing; Wed, 7 Jan 1998 12:33:46 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl-Uno Manros'" , Roger K Debry , ipp@pwg.org Subject: RE: IPP> Additional proposal details Date: Wed, 7 Jan 1998 09:30:52 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org See my comments below, marked RT2> I am using this iresponse to respond to both Roger's and Carl-Uno's comments. Randy > -----Original Message----- > From: Carl-Uno Manros [SMTP:carl@manros.com] > Sent: Wednesday, January 07, 1998 7:02 AM > To: Roger K Debry; ipp@pwg.org > Subject: Re: IPP> Additional proposal details > > Some comments on Roger's comments below. > > Carl-Uno > > At 09:51 AM 1/7/98 -0500, Roger K Debry wrote: > >Comment on Randy's proposal ... > > > >TLS Redirection Modifications > > > >The following changes to the model document > >would be required in order to support my > >earlier redirection proposal. The changes > >appear to be simple, and would allow us to > >use the term "printer-uri" throughout the > >document, without all the "hand waving" > >(similar to Bob's proposal). > > > > > >Section 3.1.3.2 Response Operation Attributes > > > > > >An additional operation response > >attribute would be defined: > > > >server-redirect-uri > > > > We've not introduced a formal server > > object up to this point. It seems that > > using this naming convention now > > requires us to say something about a > > server, although it may not be an IPP > > object. Is this construed to be a print > > server, a connection server, a web server? > > CM> I think we could call it printer-.... > CM> as this does not apply to job operations (which > CM> would need to use the URI they were originally > CM> given as result of the job submission. We will > CM> need to introduce a rule that if a job > CM> submission used TLS, the JobURI also has to > CM> be from the HTTPS scheme. > RT2>You can put HTTPS restrictions in the protocol RT2>document, but I don't think it belongs in the RT2>model document. Also with regards to the name RT2>of the attribute, this is an IPP ATTRIBUTE, so RT2>the "server" in the "server-redirect-uri" is always RT2>an IPP server. The IPP protocol itself is opaque RT2>to whatever transport it runs over. And we've always RT2>had the idea of IPP clients and servers in the RT2>documents. RT2> ..snip.. > > > >client-TLS-requested > > > >This attribute would indicate to the server > >that the client wishes to use TLS for the > >session. > > > > What is a session? Do we need to > > define it in IPP terms? > > CM> This only needs to be talked about in the > CM> protocol document, and there a session is > CM> what HTTP defines as a session. > RT2>I meant that this is a TLS session, and TLS RT2>sessions are defined by the TLS document. > > > > Why not define a new operation, called > > Request-TLS-Connection? This would seem > > much cleaner than allowing the client-TLS > > requested operation attribute in every > > existing operation. It sems that the latter > > requires a lot of "programming hints" to > > make it work efficiently. For example, you > > would never send a print-job with real data > > with a client-TLS-requested attribute, > > would you? > > CM> We had this in our internal discussion yesterday, > CM> and the more I think about it, the more sense it > CM> makes to have a separate operation for the scheme > CM> switching, initiated by the IPP client. > > > > > >If the server supports TLS, it would return > >the generic redirect response attribute > >described above. If the server DOES NOT > >support TLS, then the server would return the > >"scheme-not-supported" error code to the > >client. > > > > The term "redirect" doesn't seem quite > > right here. I haven't really re-directed > > the request someplace else, as occurs in > > HTTP. I've simply responded with an address > > to be used when the client wants a TLS > > session. In effect, it seems I've done > > nothing more than made it difficult for the > > client to retrieve the "printer-tls-uri" > > attribute that could have been in the > > directory to start with! > > CM> I think Roger is right again about the terminology, > CM> we are trying to use this for both scheme switching > CM> and redirects, the first one intitated by the client, > CM> the second by the server. > RT2>The term redirect does not necessarily mean we RT2>are redirecting to another host or machine. Its RT2>none of the clients business to actually know RT2>which components of a URL we are redirecting. RT2>The "host" part is only one of a number of URL RT2>components a server might redirect. URL RT2>redirection has a "de-facto" definition that has RT2>been used by the HTTP community, and it is RT2>this definition I am using. NOTE however I am RT2>still putting the redirection in the IPP layer, and RT2>not attempting to overload HTTP redirection, RT2>which might happen totally independently of RT2>IPP protocol messages. RT2>Given this, I don't think we have an attribute RT2>naming problem. > CM> Whatever we do with the redirect, I still support the > CM> idea of having a multi-valued printer-URI attribute > CM> where the right URI scheme can be picked up directly, > CM> as Roger points out. > > > >---- > > > >On a get-printer-attributes request, the > >"printer-uri" returned would always be the > >URI that was used to issue the get-attributes > >request (like Bob's proposal) > > > > Which URI would you expect the user to > > issue on a get-print-attributes request? > > The redirected one, or the original one? > > Would the responses be different? > RT2>It wouldn't matter which URI the server RT2>returned, in this particular case, because RT2>using either one gets the same result. > > > >On a get-job-attributes request, the > >"containing-printer-uri" would be either the > >base "printer-uri" (non-TLS), or a > >redirected TLS URI that was actually used to > >submit the job. I submit that we can leave > >this up to implementations since I think the > >client results would be the same. > > > > It seems to me that the semantics are > > different though. If I return a re- > > directed TLS URI, Aren't I saying to you > > that you must use this secure connection > > to take any subsequent actions on this > > job? > RT2>It depends. I would issue job-information RT2>requests to the job-uri I used to send the job, RT2>and not to the containing-printer-uri. But if RT2>you wanted to submit this request to the RT2>printer-uri, then you're right it might be an RT2>optimization for the client to remember the RT2>secure-URI to which it submitted the job, but RT2>ultimately whether the client used the redirected RT2>or "base" URI, the results would be the same, RT2>because if the client issued the request to the RT2>"base" URI, it would then be redirected again, and RT2>it would use the redirected URL. So basically RT2>you're suggesting a client optimization step RT2>which is an implementation detail, and something RT2>we wouldn't have to "standardize" in the documents. > > > >---- > > > >On a get-jobs request to a printer-uri, the > >"containing-printer-uri" attribute returned > >for each job would be implementation-specific. > >It would either be the "printer-URI" (non-TLS) > >for the printer, or it could be a redirected > >TLS URI. This needs to be implementation-specific > >so as to allow servers to decide how job- > >specific information is displayed for a > >particular client. > > > > Sorry, but I'm totally confused here. I > > guess I missed it when "containing- > > printer-uri" slipped into the specification. > > Why do I ask a printer to tell me what jobs > > are queued on it, and expect every job to > > come back telling me what printer it is > > queued on??? > RT2>Isn't it possible for a client to issue a get-jobs RT2>operation to a printer-uri, and specify which RT2>job attributes are returned for each job? If RT2>so, it is possible that one of the requested RT2>attributes that are returned might be the RT2>"containing-printer-uri" attribute. > > > >In addition to addressing Bob's concerns > >with printer-uri and printer-tls-uri, this > >proposal also offers the following > >advantages: > > > > > >-- It allows a TLS-capable server the ability > > to only require TLS negotiation for > > particular operations that require the server > > to allocate resources. For instance, a > > server that requires all print jobs to be > > authenticated might still want all clients > > to be able to get attributes for the printer, > > as well as validate job parameters, without > > going to the expense of performing TLS > > negotiation. It basically allows an > > administrator to decide what types of > > operations should be authenticated. In the > > current spec, ALL operations are authenticated > > or NONE are. This is a nice scalability > > feature > > > > I guess I don't understand why this proposal > > does anything better than Bob's. With Bob's > > proposal why can't I require printer-tls-uri > > for some operations and allow printer-uri for > > others, knowing that they both apply to the > > same printer -- one just being a secure > > connection? > RT2>Bob's proposal ONLY addresses how to RT2>establish a "secure" connection. Client discovery RT2>of security-related URIs is only one feature RT2>that redirection might support. > > > >-- We no longer have to worry about publishing > > multiple URI strings in directories or other > > places in order to support TLS sessions to > > a server. There's only one URI for the > > printer. If a client attempts an operation to > > the printer URI, and the server deems that > > authentication is required, then it > > automatically issues a redirect, similar to > > the way current web browsers bounce back and > > forth from SSL and non-SSL connections to a > > a particular web "service". > > > > See my previous comment. It appears to me > > that all you have done is to force the > > client to use an operation attribute (and > > thereby possibly end up with some weird > > flows) to find out what the URI is for a > > secure conenction, instead of simply looking > > in the directory. > RT2>I don't know what a "weird" flow is. > > > > > > > > From ipp-owner@pwg.org Wed Jan 7 16:45:37 1998 Delivery-Date: Wed, 07 Jan 1998 16:45:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA06482 for ; Wed, 7 Jan 1998 16:45:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA11553 for ; Wed, 7 Jan 1998 16:48:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24359 for ; Wed, 7 Jan 1998 16:45:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 16:11:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22974 for ipp-outgoing; Wed, 7 Jan 1998 15:42:05 -0500 (EST) Message-Id: <3.0.1.32.19980107122625.00ec5450@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 12:26:25 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - client scenarios with security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org After discussing the four approaches of handling the two URIs: 1. Current Model document: "printer-uri" and "printer-tls-uri" operation and printer/directory attribute 2. Bob Herriot's alternate URI scheme: "printer-uri" operation and printer/directory attribute and "printer-alt-uri" printer/directory attribute 3. Randy's: redirect mechanism: "printer-uri" operation and printer/directory attribute 4. Carl-Uno's multi-valued printer-uri-supported scheme: "printer-uri" operation attribute and "printer-uri-supported" (multi-valued) printer/directory attribute its time to write down the client scenario for using these schemes. I'll start with Randy's. Also based on recent e-mail, its not clear that a client can know whether the scheme is different for TLS vs. non-TLS. But this isn't a problem, and makes the client's life easier, not harder, as it turns out. Also we are not sure whether an IPP Printer can support both TLS and non-TLS on the same URI or not. If the client wants security to submit a print job: 1. The client assumes that the URI that it has supports TLS, and the client begins with a TLS handshake for a Print-Job operation. The following responses could occur: A. The IPP Printer doesn't support TLS, and rejects the TLS handshake (before the Print-Job is even executed). In this case, the client: tries the same URI without the TLS handshake, supplies Randy's new client-tls-requested" operation attribute, but uses a Validate-Job, instead of a Print-Job, since the client doesn't want to expose unencrypted data before the Printer has been authenticated to the client and the following responses could occur: a. The IPP Printer doesn't support TLS, and rejects the Validate-Job with the 'client-error-attributes-or-values-not-supported' error having copied the "client-tls-requested" attribute to the Unsupported Attributes group in the response. b. The IPP Printer supports TLS, but on a different URI, so the IPP Printer rejects the Validate-Job operation and returns Randy's new redirect status code and the new "server-redirect-uri" operation attribute. The client now goes back to step 1 above using the new URI and the Print-Job operation. B. The IPP Printer supports TLS, but this user is NOT authorized, so the IPP Printer rejects the TLS handshake. C. The IPP Printer suupports TLS, the client is authenticated, but the client supplied "ipp-attribute-fidelity" = 'true' and at least one supported attribute value, so the IPP Printer rejects the operation. D. The IPP Printer supports TLS, the client is authorized, client-supplied attributes pass validation, and the IPP Printer object accepts the encrypted data. NOTE: the only reason that the client might assume TLS and send a Validate-Job operation, instead of a Print-Job operation, is if the client is supplying the "ipp-attributes-fidelity" explicitly with a 'true' value and the clent likes to avoid sending (a large amount of) data that might be rejected because of an unsupported attribute value, thereby keeping the user waiting for a response that is eventally rejected. E. For any subsequent operations on the same session, such as Get-Job-Attributes (using the Printer URI and job-id attribute), the client need not repeat the TLS handshake, which is expensive as Randy points out. This scheme needs only a single "printer-uri" operation attribute and a single single-valued "printer-uri" Printer and directory attribute. Tom From ipp-owner@pwg.org Wed Jan 7 17:05:57 1998 Delivery-Date: Wed, 07 Jan 1998 17:05:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06760 for ; Wed, 7 Jan 1998 17:05:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11637 for ; Wed, 7 Jan 1998 17:08:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA24985 for ; Wed, 7 Jan 1998 17:05:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 16:26:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22971 for ipp-outgoing; Wed, 7 Jan 1998 15:42:02 -0500 (EST) Message-Id: <3.0.1.32.19980107123547.00fc1d80@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 12:35:47 PST To: Swen Johnson , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Send-URI "document-uri" and "last-document" Cc: xriley@cp10.es.xerox.com, rick@cp10.es.xerox.com, sjohnson@cp10.es.xerox.com In-Reply-To: <3.0.1.32.19980106141302.00a0ecc0@tralfaz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 14:13 01/06/1998 PST, Swen Johnson wrote: >3.3.1.2 Send-Document Response says, "... since a client might not know >that the previous document sent with a Send-Document operation was the last >document... it is legal to send a Send-Document request with no document >data where the "last-document" flag is set to 'true'".) > >3.3.2 Send-URI Operation says, "This OPTIONAL operation is identical to the >Send-Document Operation ... except that a client MUST supply a URI >reference ... rather than the document data itself..." > >Is this intended to imply that the client must supply a "document-uri" even >when "last-document" is 'true' ? Or is the "document-uri" to be treated >analogously to the document data ? Thanks for pointing out this subtelity in the language. Happily, I think that the current language is just what we want. If a client needs to tell the IPP Printer that the previous Send-Document or Send-URI operation was the last, the client MUST send a Send-Document with no data. The client cannot send a Send-URI with no data. It is better to have only one way for the client to end such a sequence. Also, the Send-URI operation NEED not be supported when supporting Send-Document. So the answer to your first question is yes and the second question is no. Thanks, Tom > > >-- Swen > > From ipp-owner@pwg.org Wed Jan 7 18:30:05 1998 Delivery-Date: Wed, 07 Jan 1998 18:30:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA07592 for ; Wed, 7 Jan 1998 18:30:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12062 for ; Wed, 7 Jan 1998 18:32:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA26839 for ; Wed, 7 Jan 1998 18:29:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:04:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23098 for ipp-outgoing; Wed, 7 Jan 1998 16:07:25 -0500 (EST) Message-Id: <3.0.1.32.19980107103536.00fc0e50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 10:35:36 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Formatting problem with note on unknown/unsupported attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id LAA03025 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA07592 Page 144, end of section 15.3.5 Validate the values of the OPTIONAL Operation attributes contains the handling of unknown or unsupported attributes, followed by a one paragraph note and a series of dashes. The two paragraphs following the dashes should be part of the note, since all three paragraphs are explaning the handling of unknown or unsupported operation attributes. I suggest that the dashed line be deleted and the two last paragraphs be indented at the same level as the first paragraph of the note. Here is the text: unknown or unsupported attribute IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN 'client-error-bad-request'. ELSE copy the attribute and value to the Unsupported Attributes response group and change the attribute value to the out-of-band 'unsupported' value, but otherwise ignore the attribute. Note: Future Operation attributes may be added to the protocol specification that may occur anywhere in the specified group. When the operation is otherwise successful, the IPP object returns the 'successful-ok-ignored-or-substituted-attributes' status code. Ignoring unsupported Operation attributes in all operations is analogous to the handling of unsupported Job Template attributes in the create and Validate-Job operations when the client supplies the "ipp-attribute-fidelity" Operation attribute with the 'false' value. ----------------------------------------------- This last rule is so that we can add OPTIONAL Operation attributes to future versions of IPP so that older clients can inter-work with new IPP objects and newer clients can inter-work with older IPP objects. (If the new attribute cannot be ignored without performing unexpectedly, the major version number would have been increased in the protocol document and in the request). This rule for Operation attributes is independent of the value of the "ipp-attribute-fidelity" attribute. For example, if an IPP object doesn’t support the OPTIONAL "job-k-octets" attribute (because of the implementation or because of some administrator’s choice not to configure a value for the Printer object's "job-k-octets-supported" attribute, leaving it with a 'no-value' out-of-band value), the IPP object treats "job-k-octets" as an unknown attribute and only checks the length for the 'integer' attribute syntax supplied by the client. If it is not four octets, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code, else the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the out-of-band 'unsupported' value, but otherwise ignores the attribute. From ipp-owner@pwg.org Wed Jan 7 18:30:16 1998 Delivery-Date: Wed, 07 Jan 1998 18:30:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA07602 for ; Wed, 7 Jan 1998 18:30:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12067 for ; Wed, 7 Jan 1998 18:33:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA26849 for ; Wed, 7 Jan 1998 18:30:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:06:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23097 for ipp-outgoing; Wed, 7 Jan 1998 16:07:21 -0500 (EST) Message-Id: <3.0.1.32.19980107102406.00f41e00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 10:24:06 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Contradictoy handling of "xxx-supported" with 'no-value' Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id LAA03076 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA07602 There are three places in section 15.3 and 15.4 where a value of the Printer object's "xxx-supported" of 'no-value' (meaning that the system administrator hasn't configured supported value(s)), indicates that the validation fails, and one place where it says that the client supplied "xxx" attribute validation is accepted. The three places are: In 15.3.4 Validate the values of the MANDATORY Operation attributes In addition, the IPP object checks each Operation attribute value against some Printer object attribute or some hard-coded value if there is no "xxx-supported" Printer object attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table by the second IF statement. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. In 15.3.5 Validate the values of the OPTIONAL Operation attributes In addition, the IPP object checks each Operation attribute value against some Printer attribute or some hard-coded value if there is no "xxx-supported" Printer attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. and in 15.4.2 Validate the values of the Job Template attributes In addition, the IPP object loops through all the client-supplied Job Template attributes, checking to see if the supplied attribute value(s) are supported or in the range supported, i.e., the value of the "xxx" attribute in the request is (1) a member of the set of values or is in the range of values of the Printer' objects "xxx-supported" attribute. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. If the check fails, the IPP object copies the attribute to the Unsupported Attributes response group with its unsupported value. If the attribute contains more than one value, each value is checked and each unsupported value is separately copied, while supported values are not copied. If an IPP object doesn’t recognize/support a Job Template attribute, i.e., there is no corresponding Printer object "xxx-supported" attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below). However, at the end of 15.3.5 it contradicts that 'no-value' fails: For example, if an IPP object doesn’t support the OPTIONAL "job-k-octets" attribute (because of the implementation or because of some administrator’s choice not to configure a value for the Printer object's "job-k-octets-supported" attribute, leaving it with a 'no-value' out-of-band value), the IPP object treats "job-k-octets" as an unknown attribute and only checks the length for the 'integer' attribute syntax supplied by the client. If it is not four octets, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code, else the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the out-of-band 'unsupported' value, but otherwise ignores the attribute. 1. Suggested fix: just delete the entire parenthetical remark: (because of the implementation or because of some administrator’s choice not to configure a value for the Printer object's "job-k-octets-supported" attribute, leaving it with a 'no-value' out-of-band value) so that an unconfigured "xxx-supported" attribute causes the validation check to fail. Then there is nothing special about the compare. If the user supplies a value 'yyy' for attribute "xxx", and the corresponding "xxx-supported" doesn't contain 'yyy', the validation check fails. Thus we have no way for an administrator to configure the Printer to accept any value of an attribute (a requirement that we have seen yet.) If we ever get such a requirement, I suggest that we add another out-of-band value that can only be used in "xxx-supported" attributes, like 'no-value' and call it, say, 'any'. NOTE: if a Job Template attribute "xxx" has a corresponding "xxx-supported" Printer attribute that is not configured, the validation fails, but the request is accepted or rejected depending on whether the value of "ipp-attribute-fidelity" is 'false' or 'true, respectively. Not configuring "xxx-supported" doesn't change how "ipp-attribute-fidelity" works. NOTE: Clients MUST NOT supply the out-of-band value of 'no-value' as specified in section 4.1, else the validation check with an configured "xxx-supported" value would succeed. From ipp-owner@pwg.org Wed Jan 7 19:18:17 1998 Delivery-Date: Wed, 07 Jan 1998 19:18:17 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA07925 for ; Wed, 7 Jan 1998 19:18:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12137 for ; Wed, 7 Jan 1998 19:21:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29107 for ; Wed, 7 Jan 1998 19:18:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:50:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23225 for ipp-outgoing; Wed, 7 Jan 1998 16:14:03 -0500 (EST) Message-Id: <3.0.1.32.19980107113236.00fc2710@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 11:32:36 PST To: Roger K Debry , From: Tom Hastings Subject: Re: IPP> Additional proposal details [why "containing-printer-uri"] In-Reply-To: <5030100015823604000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 06:51 01/07/1998 PST, Roger K Debry wrote: ... On a get-jobs request to a printer-uri, the "containing-printer-uri" attribute returned for each job would be implementation-specific. It would either be the "printer-URI" (non-TLS) for the printer, or it could be a redirected TLS URI. This needs to be implementation-specific so as to allow servers to decide how job- specific information is displayed for a particular client. Sorry, but I'm totally confused here. I guess I missed it when "containing- printer-uri" slipped into the specification. Why do I ask a printer to tell me what jobs are queued on it, and expect every job to come back telling me what printer it is queued on??? TH> If a client only has a job URI, but not the Printer URI that goes TH> with the job, then the "containing-printer-uri" TH> job attribute allows such a client to find out about the printer TH> which contains the job. (Its like an up level pointer, if you TH> think of the Printer object containing Job objects as a two-level TH> tree of objects.) From ipp-owner@pwg.org Wed Jan 7 19:18:19 1998 Delivery-Date: Wed, 07 Jan 1998 19:18:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA07930 for ; Wed, 7 Jan 1998 19:18:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12140 for ; Wed, 7 Jan 1998 19:21:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29116 for ; Wed, 7 Jan 1998 19:18:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:51:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23272 for ipp-outgoing; Wed, 7 Jan 1998 16:15:20 -0500 (EST) Message-Id: <3.0.1.32.19980107095802.00fbea50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 09:58:02 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - A reference to number-up '0' needs to be removed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org When we agreed to remove the '0' value for "number-up" to turn off embellishments, there was a reference to this value that we didn't catch. On page section 15.4.2 Validate "ipp-attribute-fidelity" if not supplied line 4954, there is the mention of the '0' value that should be deleted: The entire paragraph is: If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document-format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format, but not for the 'application/postscript' document format, or if only the '0' (none) value is supported for 'application/postscript', the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in section 3.2.1.1. Fixes: 1. Just delete the phrase: , or if only the '0' (none) value is supported for 'application/postscript', 2. While we are at it, the reference to "document-format" that is in section 3.2.1.1 Print-Job Request which does not have the explanation about the validation depending on the document format. Its the "document-format" description in section 3.2.5.1 Get-Printer-Attributes Request that has that explanation. So add " and 3.2.5.1" to the end of the above paragraph. From ipp-owner@pwg.org Wed Jan 7 19:23:41 1998 Delivery-Date: Wed, 07 Jan 1998 19:23:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA07969 for ; Wed, 7 Jan 1998 19:23:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12153 for ; Wed, 7 Jan 1998 19:26:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29446 for ; Wed, 7 Jan 1998 19:23:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:54:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25193 for ipp-outgoing; Wed, 7 Jan 1998 17:36:47 -0500 (EST) Message-Id: <199801072234.RAA19988@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: ietf-tls@consensus.com, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, ipp@pwg.org Subject: IPP> Re: URI scheme and port numbers for TLS In-reply-to: Your message of "Wed, 07 Jan 1998 10:12:53 PST." <3.0.1.32.19980107101253.00c68770@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jan 1998 17:34:02 -0500 Sender: ipp-owner@pwg.org > Is it assumed that each application that uses TLS uses its own original > scheme e.g. "http" or should it allocate a new scheme if combined with TLS > (Annex E seems to suggest that you use "https" as for SSL3)? Ideally, a single URL scheme could be used either with or without TLS, with the authentication and privacy technology to be used negotiated by the client and server. Client and server should each be configurable as to which ciphersuites, CAs, etc. are acceptable to each party. In general, neither the scheme name, nor the port number, is sufficient for such configuration. For instance, "https" (and port 443) can be used with many different ciphersuites, covering a wide variety of services and strengths, some of which are unlikely to be acceptable. While we don't intend to deprecate https/http and the other dual-port schemes that are widely deployed, neither do we want to propagate this mechanism to new protocols. > Do you see any reasons to allocate new schemes and/or port numbers for IPP > (differently from HTTP) when using HTTP as transport? If you think new > schemes and ports are needed, do we need one for use of IPP without TLS, > and another set for use with TLS? IANA has been requested to not assign any new "SSL" or "TLS" ports. For new protocols, TLS must either to be explicitly configured separately from the port number, negotiated in-band (using STARTTLS or some such), or assumed by default. As for IPP: + IPP servers listening on port 443 should assume TLS/SSL will be used when the connection is opened. IPP clients should use "https:", without overriding the port #, to indicate they want to talk to an IPP server on port 443. + IPP servers listening on other ports, including any port that might be designated specifically for IPP, should assume that neither TLS nor SSL is used when the connection is established. TLS or other security technologies might eventually be used on such servers, if someone defines a means of negotiating security in-band over HTTP. IPP clients should specify "http:", perhaps with a port # (other than 443), to indicate that they want to talk to such servers. + If a specific port is to be allocated for IPP, there should be an "ipp:" URL scheme defined, which defaults to that port. The definition of the ipp: scheme should also define how security is to be negotiated on that port - whether it defaults to TLS (perhaps with the possibility of fallback to a null encryption layer) or whether it uses in-band negotiation. In every case it remains necessary for clients and servers to be configurable as to which TLS ciphersuites are acceptable. Keith From ipp-owner@pwg.org Wed Jan 7 19:26:29 1998 Delivery-Date: Wed, 07 Jan 1998 19:26:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA07985 for ; Wed, 7 Jan 1998 19:26:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12161 for ; Wed, 7 Jan 1998 19:29:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29571 for ; Wed, 7 Jan 1998 19:26:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 18:57:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23466 for ipp-outgoing; Wed, 7 Jan 1998 16:23:14 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Tom Hastings'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Additional proposal details Date: Wed, 7 Jan 1998 13:19:45 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Yes, the redirection mechanism can be used for these and other purposes, such as redirecting jobs depending upon the document format selected, or any other parameters that describe the job, etc..etc...etc.. in some ways the inclusion of redirection might be orthogonal to the problem of trying to select a security URI. Randy > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Wednesday, January 07, 1998 12:40 PM > To: Larry Masinter; Carl-Uno Manros > Cc: Turner, Randy > Subject: Re: IPP> Additional proposal details > > Gee, I think that Randy's redirection is useful for any type of > transport > for the two stated purposes: > > 1. Changing URIs for security > 2. Handing jobs off to other servers > > Correct? > > Tom > > > At 09:38 01/07/1998 PST, Larry Masinter wrote: > >What do you think of this line of reasoning: > > > >Use features of the transport (transport = HTTP, feature = > redirection) > >when you're trying to accomplish something > >that is transport specific. If you were to layer IPP on top of > >a different transport (Corba IIOP, direct TCP or whatever), would > >you still need the redirection? > > > >Maybe not, so you're probably safe using HTTP redirection to > >accomplish IPP redirection. > > > >Larry > >-- > >http://www.parc.xerox.com/masinter > > > > From ipp-owner@pwg.org Wed Jan 7 19:59:35 1998 Delivery-Date: Wed, 07 Jan 1998 19:59:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA08198 for ; Wed, 7 Jan 1998 19:59:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12229 for ; Wed, 7 Jan 1998 20:02:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA00810 for ; Wed, 7 Jan 1998 19:59:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 19:37:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23120 for ipp-outgoing; Wed, 7 Jan 1998 16:08:07 -0500 (EST) Message-Id: <3.0.1.32.19980107101253.00c68770@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 10:12:53 PST To: ietf-tls@consensus.com From: Carl-Uno Manros Subject: IPP> URI scheme and port numbers for TLS Cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org When trying to apply TLS to our IPP scenarios, we have run into a few questions relating to TLS and URI schemes and port numbers. We had had this discussion going on for many months already on the IPP DL, and I am now trying to see if I can get some additional input from the TLS DL. It seems that the overall TLS draft specification (version 5) is silent on TLS's use of schemes and port numbers apart from discussing in Annex E that TLS might share the "https" scheme and port 443 with SSL3, when both are supported. Is it assumed that each application that uses TLS uses its own original scheme e.g. "http" or should it allocate a new scheme if combined with TLS (Annex E seems to suggest that you use "https" as for SSL3)? The same question goes for the use of port numbers. E.g. should you still use port 80 for the combination of HTTP and TLS (Annex E seems to suggest that you use port 443 as for SSL3)? Do you see any reasons to allocate new schemes and/or port numbers for IPP (differently from HTTP) when using HTTP as transport? If you think new schemes and ports are needed, do we need one for use of IPP without TLS, and another set for use with TLS? BTW, how is the draft on a TLS profile for HTTP coming along? Anybody started work on that yet? It seems that these questions need to be addressed in that draft. We need some authoritative answers on this in order to finalize our IPP specifications. Hope that somebody can help clarify what the rules of the game is here. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jan 7 20:11:43 1998 Delivery-Date: Wed, 07 Jan 1998 20:11:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA08313 for ; Wed, 7 Jan 1998 20:11:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12246 for ; Wed, 7 Jan 1998 20:14:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA01664 for ; Wed, 7 Jan 1998 20:11:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 19:48:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23224 for ipp-outgoing; Wed, 7 Jan 1998 16:14:01 -0500 (EST) Message-Id: <3.0.1.32.19980107113711.00e8ad10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 11:37:11 PST To: "Turner, Randy" , "'Carl-Uno Manros'" From: Tom Hastings Subject: RE: IPP> Additional proposal details Cc: "'ipp@pwg.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org A minor quibble: A client should NOT use Create-Job, instead of Print-Job, when the client wants security, because Create-Job is an OPTIONAL operation, so that the Printer object might not have implemented it. As you later suggest the client should use the Validate-Job operation first, not the Create-Job operation. Tom At 08:53 01/07/1998 PST, Turner, Randy wrote: > > > A client IPP implementation would never issue a > "print-job" operation in the clear, and it would know > that if it is using an "HTTP:" scheme that thats what > is happening. An HTTP client wanting to use security > for the connection would never use "print-job". It would > always use "create-job" with a > "client-security-requested" attribute. It would then > send issue "send-data" ops , etc.. > > This is because its possible for redirection ot occur with > any operation, and a client would want to make sure that > a TLS-session is in progress to a particular IPP server > before sending any sensitive data. Keep in mind that this > is not only possible with IPP redirects, but is possible with > standard HTTP redirects as well, which is out-of-band to > actual IPP operations, and our normative scope as well > (except for the protocol doc). > > By the way, it is possible to issue a "print-job" operation > within the context of a TLS session. The client would issue > a "validate-job" with the "client-security-requested" operation > attribute set, and then use the returned redirect URI to issue > the "print-job" operation securely. > > Randy > > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:carl@manros.com] >> Sent: Wednesday, January 07, 1998 6:36 AM >> To: Turner, Randy; 'Tom Hastings' >> Cc: 'ipp@pwg.org' >> Subject: RE: IPP> Additional proposal details >> >> At 10:53 PM 1/6/98 -0800, Turner, Randy wrote: >> > >> >See my response to your comments below. >> > >> >My comments are marked RT> >> > >> >R. >> > >> >> Randy, I have not copied your while message, only one comment from >> you, >> where I think you are breaking the security. >> >> Carl-Uno >> >> >> >> -- It allows a TLS-capable server the ability >> >> to only require TLS negotiation for >> >> particular operations that require the server >> >> to allocate resources. For instance, a >> >> server that requires all print jobs to be >> >> authenticated might still want all clients >> >> to be able to get attributes for the printer, >> >> as well as validate job parameters, without >> >> going to the expense of performing TLS >> >> negotiation. It basically allows an >> >> administrator to decide what types of >> >> operations should be authenticated. In the >> >> current spec, ALL operations are authenticated >> >> or NONE are. This is a nice scalability >> >> feature >> >> >> >> TH> This is a good feature. However, if a client wants security >> and >> >> TH> only has an HTTP URL, how does it get started? It certainly >> >> doesn't >> >> TH> want to do a Print-Job and send valuable data, before gettting >> the >> >> TH> TLS URL. So this means that the client that wants security is >> >> forced >> >> TH> to do a Validate-Job with the HTTP://... URL in order to get >> back >> >> TH> the redirect HTTPS://... URL, correct? >> >> >> > RT>You'll note that most of the scalability and flexibility of >> > RT>this proposal mostly applies to IPP servers and subsequently >> > RT>server administration framework. If a CLIENT wants a >> >particular >> > RT>operation to be "secure" , then it includes the >> > RT>"client-security-requested" operation attribute with whatever >> > RT>operation it is attempting. >> > >> >> CM> If you try this with a job submission operation, you have already >> sent >> CM> your MIME type application/ipp, which means that all your data >> were sent >> CM> unencrypted before you got the secure URI back, so your feature >> does >> CM> not make any sense in combination with certain operations. It is >> not as >> CM> generic as you describe it above. Instead you might actually >> mislead >> CM> a user to think that their transmission is secure, when in reality >> CM> it is not. >> >> --- > > From ipp-owner@pwg.org Wed Jan 7 20:19:06 1998 Delivery-Date: Wed, 07 Jan 1998 20:19:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA08393 for ; Wed, 7 Jan 1998 20:19:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12253 for ; Wed, 7 Jan 1998 20:21:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA02075 for ; Wed, 7 Jan 1998 20:18:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 19:54:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28370 for ipp-outgoing; Wed, 7 Jan 1998 19:07:49 -0500 (EST) Message-Id: <3.0.1.32.19980107160520.009da430@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 16:05:20 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Use of TLS in IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Keith has at long last put something down in writing which describes in clear language what he suggests to be the actual solution for IPP. The following, shortened, paragraphs are taken from his latest message: + IPP servers listening on port 443 should assume TLS/SSL will be used when the connection is opened. IPP clients should use "https:", without overriding the port #, to indicate they want to talk to an IPP server on port 443. + IPP servers listening on other ports should assume that neither TLS nor SSL is used when the connection is established. This seems good enough to me. Any objections to include this text in a suitable place in one of our documents? I assume that the right place is in the Protocol document? I do not suggest that we now try to start defining our own ipp://... scheme for IPP Version 1.0, which Keith outlined as a possible further option. Comments please? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jan 7 20:27:51 1998 Delivery-Date: Wed, 07 Jan 1998 20:27:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA08479 for ; Wed, 7 Jan 1998 20:27:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12266 for ; Wed, 7 Jan 1998 20:30:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA02303 for ; Wed, 7 Jan 1998 20:27:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 19:53:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23283 for ipp-outgoing; Wed, 7 Jan 1998 16:15:40 -0500 (EST) Message-Id: <3.0.1.32.19980107115941.00b674e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 11:59:41 PST To: minutes@ns.ietf.org From: Carl-Uno Manros Subject: IPP> Meeting Minutes and Presentations from the IPP WG meeting in DC Cc: szilles@adobe.com, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, ipp@pwg.org, manros@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_884231981==_" Sender: ipp-owner@pwg.org --=====================_884231981==_ Content-Type: text/plain; charset="us-ascii" Please find attached the final minutes and copies of the two presentations from the IPP WG meeting at IETF40. The Model document presentation is in RTF format (or WinWord if you want), hope that you can still use that. Regards, Carl-Uno Manros Co-chair IETF IPP WG --=====================_884231981==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IETF40-IPP.txt" Minutes IETF IPP WG Meeting, 97/12/10, Washington DC 1-3PM, Executive Meeting Room These minutes were taken by Steve Zilles. Carl-Uno Manros began the meeting with an overview of the documents and the agenda for the meeting: Review suggested resolution of existing issues on: - Model and Semantics document, presented by Scott Isaacson - Protocol Specification document, presented by Bob Herriot In the recording below, issues and their suggested resolution are recorded as presented (sometimes with some expansion for clarity). In most cases there was no discussion and the proposed solution was accepted as presented. If there was a discussion, this is recorded after the presented solution and if a different decision was made, this is recorded after the discussion as a decision. Model Document Issues, Scott Isaacson 1. Major/Minor Versioning Rules Mandate common encoding across all versions All elements added in a new minor version can be ignored New major version indicates new support requirements 2. Allow empty attribute groups Be conservative in what is sent; send an empty group Be liberal in what is received; allow missing group on reception 3. ALL operations MAY return "Unsupported Attributes" 4. Define protocol value-size upper bounds for URIs, charsets, natural languages, identifiers, ... 5. MUST-implement requirements for text and name strings; each string has a maximum length specification: some 63 octets, others 127 or 1023 octets Clarified validation checks for operation processing Non-secure implementation client supplies "requesting-user-name" If client does not supply a name, the printer will generate one (which need not be unique) Discussion: Is an authenticated mode required of all Printers Keith Moore would like to have this be true; without it the protocol will not be interoperable; that is, two implementations of the spec may not be able to find a common (authenticated) communication path Keith asserts that the current rules require this, because use of an Internet accessible printer will require authentication; Keith believes that submitting it as documented will cause kick back from the IESG. But, for interoperability, it is not the case that both client and server must do all the mechanisms as long on one or the other must do all; that means that requiring all clients to do the secure solution is enough to meet Keith's understanding of the rules Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving a single site; It appears that Digest Authentication (with a few tweaks based on an idea of Paul Leach) may meet this need.(and that Microsoft and Netscape may be likely to implement Digest) Details on this discussion will play-out on the HTTP mailing list over the next few weeks. Keith Moore: Whether Digest Authentication is enough is not an issue of whether it is secure enough, but whether this solution is sufficiently scalable (Jim G asserts that Paul Leach's solution may solve the scalability issue) Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for key exchange and should be relatively easy to implement. It is noted that there are two different classes of interoperation over the Internet: (1) remote access to a private resource (such as the printer on my desk) versus (2) providing a service to all comers (such as a Kinko's service) over the Internet. Scalability is not an issue in the first case. It was suggested that we identify the basic mode as "authenticated" mode (because Digest Authentication is already mandated for all HTTP/1.1 clients) and the full TLS based mode as secure mode. Decision: Digest authentication is already mandated for all HTTP/1.1 clients IPP will mandate TLS for all clients 8. Removed "copies-collated" attribute 9. Identified sources for all text and name valued attributes: end user device vendor, operator administrator allow any natural language for non-generated strings name change to "generated-natural-languages-supported" 10. Keep "charset-supported" 11. Clarified semantics of "page-range" attribute 12. Support for Media attributes If supporting "media-default", then MANDATORY If supporting "media-supported", then MANDATORY If supporting "media-ready", then OPTIONAL 13. Added missing status codes "server-error-not-accepting-jobs" "server-error-version-not-supported" 14. Asserted that IPP is already aligned with 15. Made "application/ipp" a "common usage" media type added "request ID" to allow matching of responses to corresponding request for protocols other than HTTP (e.g. SMTP) included all parameters, including the target object URI, within the application/ipp body 16. Security Allow for "non-secure", really "authenticated" servers If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows Decision: rename "non-secure" to "authenticated" rename "secure" to "private and authenticated" (or something similar Discussion: WEBDAV has been asked to not allow basic authentication. 17. Provide input to the SVRLOC Printer Scheme I-D 18. Register all the SNMP printer languages as a (MIME) media types with cross references to the SNMP enums 19. Register "application/ipp" as a media type Keith said the preferred method for handling the MIME type registration is to put the registration text (as per RFC2048) into the standards track RFC that uses/defines it. IANA should then automatically add it to the registry within a few days of the publication of the RFC. New Issues: 20. Should we register new ports for IPP use Keith Moore: a reason for a separate port number is to allow firewalls to be configured to allow or block the printing port. But, Keith observes that firewall usage is typically to block all access except to particular servers and if HTTP is not allowed, then it is likely that printing would also not be allowed so this is not a big issue. Hence, Keith is neutral on registering a port for IPP. IESG has made TLS remove creation of new ports for other protocols than HTTP. Ones that are already deployed were kept, but no new ones. Therefore, we should not have a separate new port for IPP over TLS. Other than the port discussion, no new issues were raise Protocol Document Issues since August 1997, Bob Herriot 1. Attribute Group Tags Sender (of request or response) SHOULD send attribute group tag with no following attributes with the exception of the unsupported-attributes-tag which SHOULD be omitted. Recipient (of request or response) MUST accept as equivalent representations of an empty attribute group: - attribute group tag with no following attributes - expected but missing attribute tag 2. Identified a subset of the tag types (0-0xf) as being attribute group tags (some of which have not yet be assigned); these should be handled like attribute tags by any application/ipp recipient. The subset of tag types (0x10-oxff) are "value tags". 3. A recipient of a request or response MAY skip all attributes in an unknown group. 4. Printer-uri and job-uri MUST be on HTTP request line MUST also be in operation attributes 5. Job operations MUST be supported with both job-uri target printer-uri target with job-id attribute 6. Create-job operation returns job-uri and job-id 7. Handling of localized text and names Added two new data types: localized text localized name both of these are represented as an octet string with four fields: length of natural language identification natural language identification (per RFC length of text/name content of text/name 8. Request ID added to all requests and responses server returns received request-id in the response to the request that had the request-id client may match response with requests using the request-id; client is responsible for management of request id numbering space; in HTTP, the client can always use 0 as the request-id because HTTP guarantees responses in the order requests are made. 9. Renamed 'data-tag' to 'end-of-attributes' tag 10. Added new out-of-band values for no-value unknown 11. Definition of status codes and operations moved to model document No new issues were raised at the meeting Mapping between LPD to IPP, Bob Herriot, the document was updated as follows: 1. added statement that this is informational and its intent is to help implements of gateways between IPP and LPD 2. job-id now both job-id and job-uri are available allows job-id to be same as LPD job-id in relevant cases 3. job-originating-host was removed from IPP model; IPP-to-LPD must use some other means to supply the 'H'(host) parameter. 4. job-k-octets was clarified to count octets in one copy, not all copies; file size in lpq response does contain copies 5. Notification was removed from the IPP model; therefore support for LPD email notification is not possible 6. For document format, SNMP Printer MIB enums were replace by (MIME) media types 7. Authentication job-originating-user replaced by job-originating-user-name value is (explicitly) a human readable name value comes from underlying authentication mechanism and the attribute: requesting-user-name No other issues were raised Since all issues presented had a proposed solution that was acceptable to the meeting; final copies of the documents, containing the proposed resolutions, will be prepared and circulated to the mailing list by the end of the week. Assuming there are no significant comments received by Dec 18, the revised documents will be transmitted to the IESG for processing before the end of the year. IPP Summary Paragraph The standards track documents on the IPP Model and Semantics and the IPP Protocol Specification and the informational documents on IPP Requirements, IPP Rationale and Mapping between IPP and LPD were discussed. WG final calls for these had either expired or were about to expire. Proposed solutions to all known problems were reviewed (and, where necessary, corrected) during the WG meeting. Unless some new issue arises, it is the intent that final documents that include the proposed solutions will be given to the IESG for final processing before the end of the year. With this action, we consider the WG's charter to be fulfilled and do not expect to meet at the next IETF meeting. --=====================_884231981==_ Content-Type: application/octet-stream; name="ietf40-Protocol.ppt"; x-mac-type="534C4433"; x-mac-creator="50505433" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ietf40-Protocol.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAWgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////ZAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAP7////+////bQAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAAD+//// /v///2YAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAAD+////bgAAAG8AAABwAAAAcQAAAHIAAAD+ /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAcK576jv7zRGpAwCqAFEOowAAAAAAAAAAAAAAAHBrDzLrGr0B WwAAAEAMAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgEFAAAAAgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA0q8AAAAAAABQAGUAcgBzAGkAcwB0AGUAbgB0AFMAdABvAHIAYQBn AGUAIABEAGkAcgBlAGMAdABvAHIAeQAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+AAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAAAAQAAAAAAAAAwAA AP//AADCrwAAAAAAAOgDAAD//wAAmq8AAAAAAADpAwAABAAAACwAAAAAAAAAgBYAAOAQAADPEAAA HxcAAAAAAQA05hIAizMIUAHmAAAOAAAABQAAAAoAAADyAwAA//8AANgXAAAVAAAA6wcAAP//AACI AAAAEgAAANgPAAAAAAAAAgAAAAAAAAAAAOEHAAAAAAAAAAAAAAAAAADYDwAAAAAAAAIAAAAAAAAA DwDhBwAAAAAAAAAAAAABAAAA2A8AAAAAAAACAAAAAAAAABAA4QcAAAAAAAAAAAAAAgAAANgPAAAA AAAAAgAAAAAAAAAOAOEHAAAAAAAAAAAAAAMAAADIDwAA//8AADQAAAAGAAAA0g8AAAAAAAAEAAAA KAAAAM3Nzc26DwAA//8AAAAAAAAEAAAAug8AAP//AAAAAAAABQAAANYHAAD//wAAIAAAABcAAADi BwAAAAAAAAAAAAAAAAAA4QcAAAAAAAAAAAAAAAAAALAPAAD//wAAjAEAABgAAADlDwAA//8AAFQA AAAJAAAAsw8AAAAAAAA0AAAAAAAAANgAAAAAAAAA1AEAACABAADQAgAAQAIAAPADAABgAwAAEAUA AIAEAAADAAAAQAIAAAAAAADmDwAAAAAAAAAAAAAAAAAAyw8AAAAAAAAAAAAAAAAAAOEHAAAAAAAA AAAAAAAAAADlDwAA//8AAFQAAAAJAAAAsw8AAAAAAAA0AAAAAAAAAAAAAAAAAAAAIAEAACABAABA AgAAQAIAAGADAABgAwAAgAQAAIAEAAADAAAAQAIAAAAAAADmDwAAAAAAAAAAAAAAAAAAyw8AAAAA AAAAAAAAAAAAAOEHAAAAAAAAAAAAAAEAAADlDwAA//8AAFQAAAAJAAAAsw8AAAAAAAA0AAAAAAAA AJMBAAAAAAAA0AIAAEACAADwAwAAYAMAABAFAACABAAAMAYAAKAFAAADAAAAQAIAAAAAAADmDwAA AAAAAAAAAAAAAAAAyw8AAAAAAAAAAAAAAAAAAOEHAAAAAAAAAAAAAAIAAADVBwAA//8AAHQBAAAZ AAAAtg8AAP//AABMAAAACQAAALcPAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAEAAAAA AAAAAAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAADKDwAAAAAAAAAAAAAAAAAA4QcA AAAAAAAAAAAAAAAAALYPAAD//wAATAAAAAkAAAC3DwAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJABAAAAAAAAAAAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyg8AAAAAAAAA AAAAAAAAAOEHAAAAAAAAAAAAAAEAAAC2DwAA//8AAEwAAAAJAAAAtw8AAAAAAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAACQAQAA/wAAAAAAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAA AMoPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAAAAACAAAA1QcAAP//AAAAAAAAGgAAAO8HAAAAAAAA BAAAACQAAAAAAAAA5AcAAP//AAAAAAAAKQAAAAQEAAD//wAAQhEAACoAAAAFBAAAAAAAAAoAAAAA AAAAAQEBAQEBAQAAedQPAAAAAAAA2AEAAAAAAAABAAAABDzoABPgEgAfAAAAAAACACwAAAAAAAAA AAMAAAAAAAAAAAAAAAACACwAAAAAAAAAAAP//wAAAAAAAAAAAAACACwAAAAAAAAAAAMAAAAAAAAA AAAAAAACACwAAAAAAAAAAAMAUAAAAAAAAAAAAAACACwAAAAAAAAAAAMAUAAAAAAAAAAA//8CAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAA AAAAAAAAAAAAAAABAADkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAEAAAABAAAAZAAAAAAAAAAAAAAA AAAAAAAAAQAANwAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAA AAEAADUAAAD9lQD//wIAZAAAAAAAAAAAAAAAAwAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAABAAAA AAAA/ZUA//8CAGQAAAAAAAAAAAAAAAQAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQAA5QAAAP8A AP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA1A8AAAAAAADYAQAA AAAAAAAAAAAEPOgAA+ASAB8AAAAAAAIAIAAAAAAAAAAAAQAAAAAAAAAAAAAAAAIAHAAAAAAAAAAA Af//AAAAAAAAAAAAAAIAGAAAAAAAAAAAAQAAAAAAAAAAAAAAAAIAFAAAAAAAAAAAAQBQAAAAAAAA AAAAAAIAFAAAAAAAAAAAAQBQAAAAAAAAAAD//wIAAAAAAAAAAAAA/wAAAAAAAAAAAAABAAAAAP2V AP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAAeQAAAD9lgD//wIA ZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAAE3AAAA/ZUA//8CAGQAAAAA AAAAAAAAAAIAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAAAAQABNQAAAP2WAP//AgBkAAAAAAAAAAAA AAADAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAABAAA AAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAADlAAAA/wAA//8CAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQDUDwAAAAAAANgBAAAAAAAAAQAAAAQ86AAD4BIAHwAAAAAAAgAM AAAAAAAAAAABAAAAAAAAAAAAAAAAAgAMAAAAAAAAAAAB//8AAAAAAAAAAAAAAgAMAAAAAAAAAAAB AAAAAAAAAAAAAAAAAgAMAAAAAAAAAAABAFAAAAAAAAAAAAAAAgAMAAAAAAAAAAABAFAAAAAAAAAA AP//AgAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAA ZAAAAB4AAAAAAAAAAAAAAAAAAQAA5AAAAP2VAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAe AAAAAAAAAAAAAAAAAAEAADcAAAD9lQD//wIAZAAAAAAAAAAAAAAAAgAAAAAAAABkAAAAHgAAAAAA AAAAAAAAAAABAAA1AAAA/ZUA//8CAGQAAAAAAAAAAAAAAAMAAAAAAAAAZAAAAB4AAAAAAAAAAAAA AAAAAQAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAEAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAAEA AOUAAAD/AAD//wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABANQPAAAA AAAA2AEAAAAAAAACAAAABDzoAAPgEgAfAAAAAQACAB4AAAAAAAAAAAEAAAAAAAAAAAAAAQACAB4A AAAAAAAAAAH//wAAAAAAAAAAAQACAB4AAAAAAAAAAAEAAAAAAAAAAAAAAQACAB4AAAAAAAAAAAEA UAAAAAAAAAAAAQACAB4AAAAAAAAAAAEAUAAAAAAAAAAA//8CAAAAAAAAAAAAAP8AAAAAAAAAAAAA FQAAAAABlQAAAAIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAP7///8AAAAAAAABABXkAAAA AZUAAAACAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAABQAAAD+////AAAAAAAAAQAVNwAAAAGVAAAA AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQAAAAUAAAA/v///wAAAAAAAAEAFTUAAAABlQAAAAIAZAAA AAAAAAAAAAAAAwAAAAAAAABkAAAAFAAAAP7///8AAAAAAAABABUAAAAAAZUAAAACAGQAAAAAAAAA AAAAAAQAAAAAAAAAZAAAABQAAAD+////AAAAAAAAAQAA5QAAAP8AAP//AgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA1A8AAAAAAADYAQAAAAAAAAEAAAAFPOgAA+ASAB8A AAAAAAIAGAAAAAAAAAAAAQAAAAAAAAAAAAAAAAIAGAAAAAAAAAAAAf//AAAAAAAAAAAAAAIAGAAA AAAAAAAAAQAAAAAAAAAAAAAAAAIAGAAAAAAAAAAAAQBQAAAAAAAAAAAAAAIAGAAAAAAAAAAAAQBQ AAAAAAAAAAD//wIAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAA AAAAAAAAAGQAAAAAAAAAAAAAAAAAAAAAAAEAAOQAAAD9lQD//wIAZAAAAAAAAAAAAAAAAQAAAAAA AABkAAAAAAAAAAAAAAAAAAAAAAABAAA3AAAA/ZUA//8CAGQAAAAAAAAAAAAAAAIAAAAAAAAAZAAA AAAAAAAAAAAAAAAAAAAAAQAANQAAAP2VAP//AgBkAAAAAAAAAAAAAAADAAAAAAAAAGQAAAAAAAAA AAAAAAAAAAAAAAEAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAABAAAAAAAAABkAAAAAAAAAAAAAAAA AAAAAAABAADlAAAA/wAA//8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQDUDwAAAAAAANgBAAAAAAAAAAAAAAQ86AAD4BIAHwAAAAAAAgAgAAAAAAAAAAABAAAAAAAAAAAA AAAAAgAcAAAAAAAAAAAB//8AAAAAAAAAAAAAAgAYAAAAAAAAAAABAAAAAAAAAAAAAAAAAgAUAAAA AAAAAAABAFAAAAAAAAAAAAAAAgAUAAAAAAAAAAABAFAAAAAAAAAAAP//AgAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAwAAABAAAAZAAAABQAAAAAAAAAAAAAAAAA AQAA5AAAAP2WAP//AgBkAAAAAAAAAAAAAAABMAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAADcA AAD9lQD//wIAZAAAAAAAAAAAAAAAAjAAAAEAAABkAAAAFAAAAAAAAAAAAAAAAAABAAA1AAAA/ZYA //8CAGQAAAAAAAAAAAAAAAMwAAABAAAAZAAAABQAAAAAAAAAAAAAAAAAAQAAAAAAAP2VAP//AgBk AAAAAAAAAAAAAAAEMAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAAOUAAAD/AAD//wIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABANQPAAAAAAAA2AEAAAAAAAABAAAABDzo ABPgEgAfAAAAAAACACwAAAAAAAAAAAMAAAAAAAAAAAAAAAACACwAAAAAAAAAAAP//wAAAAAAAAAA AAACACwAAAAAAAAAAAMAAAAAAAAAAAAAAAACACwAAAAAAAAAAAMAUAAAAAAAAAAAAAACACwAAAAA AAAAAAMAUAAAAAAAAAAA//8CAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAD9lQD//wIAZAAAAAAA AAAAAAAAADAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAABAADkAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAEwAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQAANwAAAP2VAP//AgBkAAAAAAAAAAAAAAACMAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEAADUAAAD9lQD//wIAZAAAAAAAAAAAAAAAAzAAAAEAAABk AAAAAAAAAAAAAAAAAAAAAAABAAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAQwAAABAAAAZAAAAAAA AAAAAAAAAAAAAAAAAQAA5QAAAP8AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEA1A8AAAAAAADYAQAAAAAAAP////8NPOgAzeESAAAAAAD//wIAAAAAAAAAAAAA/wAA AAAAAAAAAAD//wIAAAAAAAAAAAAA////AAAAAAAAAAD//wIAAAAAAAAAAAAA/wAAAAAAAAAAAAD/ /wIAAAAAAAAAAAAA/wBQAAAAAAAAAAD//wIAAAAAAAAAAAAA/wBQAAAAAAAAAAD//wIAAAAAAAAA AAAA/wAAAAAAAAAAAAAAAAAAAP8AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAOQAAAD/AAD//wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAA3AAAA/wAA//8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA NQAAAP8AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAD/ AAD//wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAADlAAAA/wAA//8C AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQDUDwAAAAAAANgBAAAAAAAA /////w086ADN4RIAAAAAAP//AgAAAAAAAAAAAAD/AAAAAAAAAAAAAP//AgAAAAAAAAAAAAD///8A AAAAAAAAAP//AgAAAAAAAAAAAAD/AAAAAAAAAAAAAP//AgAAAAAAAAAAAAD/AFAAAAAAAAAAAP// AgAAAAAAAAAAAAD/AFAAAAAAAAAAAP//AgAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAA/wAA//8C AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA5AAAAP8AAP//AgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAADcAAAD/AAD//wIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA1AAAA/wAA//8CAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAP8AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAOUAAAD/AAD//wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAMQLAAD//wAAFgIAABYAAADFCwAAAAAAAAIAAAAAAAAAAADBCwAAAAAA ACgAAAAAAAAA/f///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD9////AQB6AL0LAAABAAAA OAAAAAAAAAAAAAAAAAAAAQAAAAAAAQAAAAAAAAAAAAQAAAAB/wEAAAACAAAwAAAAMAAAAAAAAAAA AAAAAAAAAKEPAAD//wAAdAEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADAbgdQE+QSAKIP AAD//wAARAEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAAAAAAATAAAAAID//wAAAAAAAAAAAAAA AAAAAAAAAAAAtQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AAOwAAAAAAAAA4w8AAAAAAAA0AAAA MgAAAADjAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDi DwAAAAAAABgAAAAzAAAAAAACABgAAAAAAAAAAAEAAAAAAAAAAAAA7gcAAAAAAAAAAAAANQAAAOwH AAD//wAAEAAAAC8AAADuBwAAAAAAAAAAAAAvAAAA7AcAAP//AAAQAAAAMAAAAO4HAAAAAAAAAAAA ADAAAADsBwAA//8AABAAAAAxAAAA7gcAAAAAAAAAAAAAMQAAAK0PAAAAAAAAAAAAAAAAAADQBwAA //8AADR1AAAKAAAA0QcAAAAAAAAEAAAAAAAAAA4AAADuAwAA//8AAGgGAAAQAAAA7wMAAAAAAAAI AAAAAAAAAAABAAACAACA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9///QAsAAHAIAAABAQAAAQAAAPcD AAABAAAADAAAAAAAAAAAAAAADxAAAAAAAADZDwAA//8AAFsAAAAAAAAA2g8AAAAAAAAIAAAAAAAA AAEBAAAAAQEBug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AABMAAAAwAAAA SVBQIHNlc3Npb24gYXQgSUVURvQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAAAAAAACAAAAP// /wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAA AAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABwCAAAAAAAAP3///8AAHoAvQsAAAEAAAA4AAAA AAAAAP8AAAAAAAABAAAAAAABewAAAAAAAAAAAAAAAAH/AQAAAAIAADAAAAAwAAAAAOUSAAAAAAAA AAAAuAsAAP//AAC9BAAAFAAAAMILAAD//wAASAIAABMAAADDCwAAAAAAAAgAAAAAAAAADwASAAAA AADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//zD9//+QCQAAAAAAAAAAAAD9////AQB7 AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAA MAAAAADkEgAAAAAAAAAAAKEPAAD//wAAoAEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADE bgdQE+QSAKIPAAD//wAAcAEAAAAAAACjDwAAAAAAACQAAAAAAAAABgAAAAQAAAATAAAAAID//wAA AACq9v//Tf3//1YJAADj////tQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AABgBAAAAAAAA7gcA AAAAAAAMAAAANQAAAElQUCBQcm90b2NvbOwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAA DAAAAOIPAAAAAAAAGAAAAGh/egAAAAIALAAAAAAAAAAAAxIAAAAAAAAAAADsBwAA//8AAFgAAAAw AAAA7gcAAAAAAABIAAAAMAAAAAwAAADjDwAAAAAAADQAAABof3oAAAAAAAD9lQD//wIAZAAAAAAA AAAAAAAAADAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAA ABgAAAAxAAAADAAAAOEPAAAAAAAABAAAAGh/egD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAA VQIAABMAAADDCwAAAAAAAAgAAAAAAAAAEAASAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA MwhQIPj//yABAADgBwAAcAUAAAAAAAD9////AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAA AAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAArQEA AB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQA+QSAKIPAAD//wAAfQEAAAAAAACjDwAA AAAAACQAAAAAAAAABQAAAAQAAAADAAAAAID//wAAAABa+P//PQEAAKYHAABTBQAAtQ8AAAAAAAAE AAAAAAAAAAAAAADgDwAA//8AACUBAAAAAAAA7gcAAAAAAAAZAAAANQAAAENoYW5nZXMgc2luY2Ug QXVndXN0IElFVEbsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAABkAAADiDwAAAAAAABgA AABwg3oAAAACACAAAAAAAAAAAAESAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAA ADAAAAAZAAAA4w8AAAAAAAA0AAAAcIN6AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAwAAABAAAA ZAAAABQAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAABkAAADh DwAAAAAAAAQAAABwg3oA/////60PAAAAAAAAAAAAAAAAAADuAwAA//8AAHcIAAAQAAAA7wMAAAAA AAAIAAAAAAAAAAEBAAACAACA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9///QAsAAHAIAAABAQAAAeUS APcDAAABAAAADAAAAAAAAAABAAAADA0AAAAAAADZDwAA//8AAFsAAAAAAAAA2g8AAAAAAAAIAAAA AAAAAAEBAAAAAQEBug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AABMAAAAw AAAASVBQIHNlc3Npb24gYXQgSUVURvQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAAAAAAACAAA AP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAA KAAAAAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABwCAAAAAAAAP3///8AAHoAvQsAAAEAAAA4 AAAAAAAAAP8AAAAAAAABAAAAAAABewAAAAAAAAAAAAAAAAH/AQAAAAIAADAAAAAwAAAAAOUSAAAA AAAAAAAAuAsAAP//AADMBgAAFAAAAMILAAD//wAATQIAABMAAADDCwAAAAAAAAgAAAAAAAAADAAS AAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//xD5//+QCQAA4Pv//wAAAAD9//// AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAw AAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAApQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0A AADEbgdQE+QSAKIPAAD//wAAdQEAAAAAAACjDwAAAAAAACQAAAAAAAAAAAAAAAQAAAATAAAAAID/ /wAAAACq9v//Lfn//1YJAADD+///tQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AAB0BAAAAAAAA 7gcAAAAAAAARAAAANQAAAEF0dHJpYnV0ZXMgR3JvdXBz7AcAAP//AAA8AAAALwAAAO4HAAAAAAAA LAAAAC8AAAARAAAA4g8AAAAAAAAYAAAAELd6AAAAAgAsAAAAAAAAAAADEgAAAAAAAAAAAOwHAAD/ /wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAEQAAAOMPAAAAAAAANAAAABC3egAAAAAAAP2VAP// AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAoAAAAMQAA AO4HAAAAAAAAGAAAADEAAAARAAAA4Q8AAAAAAAAEAAAAELd6AP////+tDwAAAAAAAAAAAAAAAAAA wgsAAP//AABfBAAAEwAAAMMLAAAAAAAACAAAAAAAAAANABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9 ////AAAAAAAzCFBw9v//cPz//5AJAACQBgAAAAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8A AAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8A AP//AAC3AwAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AD5BIAog8AAP//AACHAwAA AAAAAKMPAAAAAAAAJAAAAAAAAAABAAAARAAAAAMAAAAAgP//AAAAAKr2//+N/P//VgkAAHMGAAC1 DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAALwMAAAAAAADuBwAAAAAAAI8AAAA1AAAAUGFyYW1l dGVyL0F0dHJpYnV0ZSBkaXN0aW5jdGlvbiByZW1vdmVkDUF0dHJpYnV0ZSBHcm91cHMgY3JlYXRl ZDoNb3BlcmF0aW9uIGF0dHJpYnV0ZXMNam9iIGF0dHJpYnV0ZXMNcHJpbnRlciBhdHRyaWJ1dGVz DXVuc3VwcG9ydGVkIGF0dHJpYnV0ZXPsBwAA//8AAGgAAAAvAAAA7gcAAAAAAABYAAAALwAAAEIA AADiDwAAAAAAABgAAAAgu3oAAAACACAAAAAAAAAAAAESAAAAAAAAAAAATQAAAOIPAAAAAAAAGAAA ACC7egAAAAIAHAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAMABAAAwAAAA7gcAAAAAAACwAQAA MAAAACgAAADjDwAAAAAAADQAAAAgu3oAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAABABoAAADjDwAAAAAAADQAAAAgu3oAAQAAAAD9lQD//wIAZAAAAAAA AAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABABUAAADjDwAAAAAAADQAAAAgu3oAAQAA AAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAA8AAADjDwAA AAAAADQAAAAgu3oAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAA AAAAAAABABMAAADjDwAAAAAAADQAAAAgu3oAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAA AABkAAAAFAAAAAAAAAAAAAAAAAABABYAAADjDwAAAAAAADQAAAAgu3oAAQAAAAD9lgD//wIAZAAA AAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAA AAAAABgAAAAxAAAAjwAAAOEPAAAAAAAABAAAACC7egD/////rQ8AAAAAAAAAAAAAAAAAAO4DAAD/ /wAAmgkAABAAAADvAwAAAAAAAAgAAAAAAAAABQEAAAIAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3 //9ACwAAcAgAAAEBAAAB5RIA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAWwAA AAAAAADaDwAAAAAAAAgAAAAAAAAAAQEAAAABAQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAA LwAAALoPAAD//wAAEwAAADAAAABJUFAgc2Vzc2lvbiBhdCBJRVRG9AMAAP//AAA0AAAAeAAAAO8H AAAAAAAAJAAAAAAAAAAIAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8A AIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAA /f///wAAegC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAAAAF7AAAAAAAAAAAAAAAAAf8BAAAA AgAAMAAAADAAAAAA5RIAAAAAAAAAAAC4CwAA//8AAO8HAAAUAAAAwgsAAP//AABSAgAAEwAAAMML AAAAAAAACAAAAAAAAAAMABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//EPn/ /5AJAADg+///AAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAA AAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP//AACqAQAAHgAAAKAPAAAA AAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AT5BIAog8AAP//AAB6AQAAAAAAAKMPAAAAAAAAJAAAAAAA AAAAAAAARAAAABMAAAAAgP//AAAAAKr2//8t+f//VgkAAMP7//+1DwAAAAAAAAQAAAAAAAAAAQAA AOAPAAD//wAAIgEAAAAAAADuBwAAAAAAABYAAAA1AAAARW1wdHkgQXR0cmlidXRlIEdyb3Vwc+wH AAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAFgAAAOIPAAAAAAAAGAAAAHDEegAAAAIALAAA AAAAAAAAAxIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAABYAAADjDwAA AAAAADQAAABwxHoAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAA AAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAFgAAAOEPAAAAAAAABAAAAHDE egD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAfQUAABMAAADDCwAAAAAAAAgAAAAAAAAADQAS AAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//3D8//+QCQAAkAYAAAAAAAD9//// AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAw AAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAA1QQAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0A AADEbgdQA+QSAKIPAAD//wAApQQAAAAAAACjDwAAAAAAACQAAAAAAAAAAQAAAEQAAAADAAAAAID/ /wAAAACq9v//jfz//1YJAABzBgAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAE0EAAAAAAAA 7gcAAAAAAAApAQAANQAAAFNlbmRlciAob2YgcmVxdWVzdCBvciByZXNwb25zZSkgc2hvdWxkIHNl bmQNYXR0cmlidXRlIGdyb3VwIHRhZyB3aXRoIG5vIGZvbGxvd2luZyBhdHRyaWJ1dGVzDWV4Y2Vw dCBmb3IgdW5zdXBwb3J0ZWQtYXR0cmlidXRlcy10YWcNUmVjZWl2ZXIgb2YgKHJlcXVlc3Qgb3Ig cmVwb25zZSkgbXVzdCBhY2NlcHQgYXMgZXF1aXZhbGVudCBlbXB0eSBhdHRyaWJ1dGUgZ3JvdXBz Og1hdHRyaWJ1dGUgZ3JvdXAgdGFnIHdpdGggbm8gZm9sbG93aW5nIGF0dHJpYnV0ZXMNZXhwZWN0 ZWQgYnV0IG1pc3NpbmcgYXR0cmlidXRlIHRhZ+wHAAD//wAA7AAAAC8AAADuBwAAAAAAANwAAAAv AAAALAAAAOIPAAAAAAAAGAAAAITIegAAAAIAIAAAAAAAAAAAARIAAAAAAAAAAAAxAAAA4g8AAAAA AAAYAAAAhMh6AAAAAgAcAAAAAAAAAAABEgAAAAAAAAAAACYAAADiDwAAAAAAABgAAACEyHoAAAAC ABgAAAAAAAAAAAESAAAAAAAAAAAAUwAAAOIPAAAAAAAAGAAAAITIegAAAAIAIAAAAAAAAAAAARIA AAAAAAAAAABTAAAA4g8AAAAAAAAYAAAAhMh6AAAAAgAcAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD/ /wAAwAEAADAAAADuBwAAAAAAALABAAAwAAAALAAAAOMPAAAAAAAANAAAAITIegABAAAAAP2VAP// AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAMQAAAOMPAAAAAAAANAAA AITIegABAAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEA JgAAAOMPAAAAAAAANAAAAITIegABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQAAAAU AAAAAAAAAAAAAAAAAAEAUwAAAOMPAAAAAAAANAAAAITIegABAAAAAP2VAP//AgBkAAAAAAAAAAAA AAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAMQAAAOMPAAAAAAAANAAAAITIegABAAAAAP2W AP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAIgAAAOMPAAAAAAAA NAAAAITIegABAAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAA AAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAApAQAA4Q8AAAAAAAAEAAAAhMh6AP// //+tDwAAAAAAAAAAAAAAAAAA7gMAAP//AABmCAAAEAAAAO8DAAAAAAAACAAAAAAAAAAHAQAAAgAA gO0DAAABAAAAGAAAAAAAAADA9P//kPf//0ALAABwCAAAAQEAAAHlEgD3AwAAAQAAAAwAAAAAAAAA AQAAAAwNAAAAAAAA2Q8AAP//AABbAAAAAAAAANoPAAAAAAAACAAAAAAAAAABAQAAAAEBAboPAAD/ /wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8AAP//AAATAAAAMAAAAElQUCBzZXNzaW9uIGF0 IElFVEb0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAAAAAAAgAAAD///8AAAAAAJaWlgAAAAAA AMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA AAAAwPT//5D3//9ACwAAcAgAAAAAAAD9////AAB6AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAA AAAAAXsAAAAAAAAAAAAAAAAB/wEAAAACAAAwAAAAMAAAAADlEgAAAAAAAAAAALgLAAD//wAAuwYA ABQAAADCCwAA//8AAFoCAAATAAAAwwsAAAAAAAAIAAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAA AAAAAP3///8AAAAAADMIUHD2//8Q+f//kAkAAOD7//8AAAAA/f///wEAewC9CwAAAQAAADgAAAAA AAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAA AAChDwAA//8AALIBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUBPkEgCiDwAA//8A AIIBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAAAAABEAAAAEwAAAACA//8AAAAAqvb//y35//9WCQAA w/v//7UPAAAAAAAABAAAAAAAAAABAAAA4A8AAP//AAAqAQAAAAAAAO4HAAAAAAAAHgAAADUAAABF eHRlbnNpYmlsaXR5IGZvciBVbmtub3duIFRhZ3PsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAA LwAAAB4AAADiDwAAAAAAABgAAADw03oAAAACACwAAAAAAAAAAAMSAAAAAAAAAAAA7AcAAP//AABY AAAAMAAAAO4HAAAAAAAASAAAADAAAAAeAAAA4w8AAAAAAAA0AAAA8NN6AAAAAAAA/ZUA//8CAGQA AAAAAAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcA AAAAAAAYAAAAMQAAAB4AAADhDwAAAAAAAAQAAADw03oA/////60PAAAAAAAAAAAAAAAAAADCCwAA //8AAEEEAAATAAAAwwsAAAAAAAAIAAAAAAAAAA0AEgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8A AAAAADMIUHD2//9w/P//kAkAAJAGAAAAAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAA AAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8A AJkDAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUAPkEgCiDwAA//8AAGkDAAAAAAAA ow8AAAAAAAAkAAAAAAAAAAEAAABEAAAAAwAAAACA//8AAAAAqvb//438//9WCQAAcwYAALUPAAAA AAAABAAAAAAAAAAAAAAA4A8AAP//AAARAwAAAAAAAO4HAAAAAAAA1QAAADUAAABVbmtub3duIHRh Z3MgZmFsbCBpbnRvIHR3byBjYXRlZ29yaWVzOg1kZWxpbWl0ZXIgdGFnLCAwLTB4ZjogYmVnaW5u aW5nIG9mIGF0dHJpYnV0ZSBncm91cA12YWx1ZSB0YWcsIDB4MTAtMHhmZjogc2luZ2xlIHZhbHVl DUFsbG93cyB0aGUgcmVjZWl2ZXIgb2YgYSByZXF1ZXN0IG9yIHJlc3BvbnNlIHRvIHNraXAgYWxs IGF0dHJpYnV0ZXMgaW4gYW4gdW5rbm93biBncm91cC7sBwAA//8AAJQAAAAvAAAA7gcAAAAAAACE AAAALwAAACcAAADiDwAAAAAAABgAAAAw2HoAAAACACAAAAAAAAAAAAESAAAAAAAAAAAAVgAAAOIP AAAAAAAAGAAAADDYegAAAAIAHAAAAAAAAAAAARIAAAAAAAAAAABYAAAA4g8AAAAAAAAYAAAAMNh6 AAAAAgAgAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAAMAEAADAAAADuBwAAAAAAACABAAAwAAAA JwAAAOMPAAAAAAAANAAAADDYegABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAU AAAAAAAAAAAAAAAAAAEAMwAAAOMPAAAAAAAANAAAADDYegABAAAAAP2WAP//AgBkAAAAAAAAAAAA AAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAIwAAAOMPAAAAAAAANAAAADDYegABAAAAAP2W AP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAWAAAAOMPAAAAAAAA NAAAADDYegABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAA AAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAADVAAAA4Q8AAAAAAAAEAAAAMNh6AP// //+tDwAAAAAAAAAAAAAAAAAA7gMAAP//AAC0CQAAEAAAAO8DAAAAAAAACAAAAAAAAAADAQAAAgAA gO0DAAABAAAAGAAAAAAAAADA9P//kPf//0ALAABwCAAAAQEAAAHlEgD3AwAAAQAAAAwAAAAAAAAA AQAAAAwNAAAAAAAA2Q8AAP//AABbAAAAAAAAANoPAAAAAAAACAAAAAAAAAABAQAAAAEBAboPAAD/ /wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8AAP//AAATAAAAMAAAAElQUCBzZXNzaW9uIGF0 IElFVEb0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAAAAAAAgAAAD///8AAAAAAJaWlgAAAAAA AMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA AAAAwPT//5D3//9ACwAAcAgAAAAAAAD9////AAB6AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAA AAAAAXsAAAAAAAAAAAAAAAAB/wEAAAACAAAwAAAAMAAAAADlEgAAAAAAAAAAALgLAAD//wAACQgA ABQAAADCCwAA//8AAEwCAAATAAAAwwsAAAAAAAAIAAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAA AAAAAP3///8AAAAAADMIUHD2//8Q+f//kAkAAOD7//8AAAAA/f///wEAewC9CwAAAQAAADgAAAAA AAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAA AAChDwAA//8AAKQBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUBPkEgCiDwAA//8A AHQBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAAAAABEAAAAEwAAAACA//8AAAAAqvb//y35//9WCQAA w/v//7UPAAAAAAAABAAAAAAAAAABAAAA4A8AAP//AAAcAQAAAAAAAO4HAAAAAAAAEAAAADUAAABP cGVyYXRpb24gVGFyZ2V07AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAAQAAAA4g8AAAAA AAAYAAAAJOF6AAAAAgAsAAAAAAAAAAADEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAA AEgAAAAwAAAAEAAAAOMPAAAAAAAANAAAACThegAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAQ AAAA4Q8AAAAAAAAEAAAAJOF6AP////+tDwAAAAAAAAAAAAAAAAAAwgsAAP//AACdBQAAEwAAAMML AAAAAAAACAAAAAAAAAANABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//cPz/ /1AKAACQBgAAAAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAA AAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP//AAD1BAAAHgAAAKAPAAAA AAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AD5BIAog8AAP//AADFBAAAAAAAAKMPAAAAAAAAJAAAAAAA AAABAAAAhAAAAAMAAAAAgP//AAAAAKr2//+N/P//FgoAAHMGAAC1DwAAAAAAAAQAAAAAAAAAAAAA AOAPAAD//wAAbQQAAAAAAADuBwAAAAAAAAEBAAA1AAAAUHJpbnRlci11cmkgYW5kIGpvYi11cmkg dGFyZ2V0IG9mIG9wZXJhdGlvbg1tdXN0IGJlIG9uIEhUVFAgcmVxdWVzdCBsaW5lDW1heSBhbHNv IGJlIGluIG9wZXJhdGlvbiBhdHRyaWJ1dGVzIA1Kb2Igb3BlcmF0aW9ucyBtdXN0IGJlIHN1cHBv cnRlZCB3aXRoIGJvdGgNam9iLXVyaSB0YXJnZXQgDXByaW50ZXItdXJpIHRhcmdldCB3aXRoIGpv Yi1pZCBhdHRyaWJ1dGUNQ3JlYXRlIGpvYiBvcGVyYXRpb24gcmV0dXJucyBqb2ItdXJpIGFuZCBq b2ItaWTsBwAA//8AAOwAAAAvAAAA7gcAAAAAAADcAAAALwAAACwAAADiDwAAAAAAABgAAAAw5XoA AAACACAAAAAAAAAAAAESAAAAAAAAAAAAQgAAAOIPAAAAAAAAGAAAADDlegAAAAIAHAAAAAAAAAAA ARIAAAAAAAAAAAArAAAA4g8AAAAAAAAYAAAAMOV6AAAAAgAgAAAAAAAAAAABEgAAAAAAAAAAADkA AADiDwAAAAAAABgAAAAw5XoAAAACABwAAAAAAAAAAAESAAAAAAAAAAAALwAAAOIPAAAAAAAAGAAA ADDlegAAAAIAIAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAAgCAAAwAAAA7gcAAAAAAAD4AQAA MAAAACwAAADjDwAAAAAAADQAAAAw5XoAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAABAB0AAADjDwAAAAAAADQAAAAw5XoAAQAAAAD9lgD//wIAZAAAAAAA AAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABACUAAADjDwAAAAAAADQAAAAw5XoAAQAA AAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABACsAAADjDwAA AAAAADQAAAAw5XoAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAA AAAAAAABABAAAADjDwAAAAAAADQAAAAw5XoAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAA AABkAAAAFAAAAAAAAAAAAAAAAAABACkAAADjDwAAAAAAADQAAAAw5XoAAQAAAAD9lgD//wIAZAAA AAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAC8AAADjDwAAAAAAADQAAAAw5XoA AQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAOwHAAD/ /wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQEAAOEPAAAAAAAABAAAADDlegD/////rQ8AAAAA AAAAAAAAAAAAAO4DAAD//wAANQkAABAAAADvAwAAAAAAAAgAAAAAAAAAAgEAAAIAAIDtAwAAAQAA ABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB5RIA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAA AAAAANkPAAD//wAAWwAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQEAAAABAQG6DwAA//8AAAAAAAAu AAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAEwAAADAAAABJUFAgc2Vzc2lvbiBhdCBJRVRG9AMA AP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAAAAAAAIAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wA zMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAMD0//+Q 9///QAsAAHAIAAAAAAAA/f///wAAegC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAAAAF7AAAA AAAAAAAAAAAAAf8BAAAAAgAAMAAAADAAAAAA5RIAAAAAAAAAAAC4CwAA//8AAIoHAAAUAAAAwgsA AP//AABUAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAMABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9//// AAAAAAAzCFBw9v//EPn//5AJAADg+///AAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAA AAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP// AACsAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AT5BIAog8AAP//AAB8AQAAAAAA AKMPAAAAAAAAJAAAAAAAAAAAAAAAhAAAABMAAAAAgP//AAAAAKr2//8t+f//VgkAAMP7//+1DwAA AAAAAAQAAAAAAAAAAQAAAOAPAAD//wAAJAEAAAAAAADuBwAAAAAAABgAAAA1AAAATG9jYWxpemVk IFRleHQgYW5kIE5hbWVz7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAAYAAAA4g8AAAAA AAAYAAAAtO96AAAAAgAsAAAAAAAAAAADEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAA AEgAAAAwAAAAGAAAAOMPAAAAAAAANAAAALTvegAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAY AAAA4Q8AAAAAAAAEAAAAtO96AP////+tDwAAAAAAAAAAAAAAAAAAwgsAAP//AAAWBQAAEwAAAMML AAAAAAAACAAAAAAAAAANABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//cPz/ /5AJAACQBgAAAAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAA AAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP//AABuBAAAHgAAAKAPAAAA AAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AD5BIAog8AAP//AAA+BAAAAAAAAKMPAAAAAAAAJAAAAAAA AAABAAAAhAAAAAMAAAAAgP//AAAAAKr2//+N/P//VgkAAHMGAAC1DwAAAAAAAAQAAAAAAAAAAAAA AOAPAAD//wAA5gMAAAAAAADuBwAAAAAAADYBAAA1AAAAVGhlIG5hdHVyYWwgbGFuZ3VhZ2UgYXNz b2NpYXRlZCB3aXRoIFRleHQgYW5kIE5hbWUgdmFsdWVzIG1heSBkaWZmZXIgZnJvbSB0aGUgbmF0 dXJhbC1sYW5ndWFnZSBvZiB0aGUgb3BlcmF0aW9uLg10cmllZCBhbmQgcmVqZWN0ZWQgc2V2ZXJh bCBkaWZmZXJlbnQgc29sdXRpb25zDXNldHRsZWQgb24gdHdvIG5ldyB0eXBlczogDWxvY2FsaXpl ZC10ZXh0IGFuZCBsb2NhbGl6ZWQtbmFtZQ1jb25zaXN0cyBvZiBhbiBvY3RldCBzdHJpbmcgd2l0 aCA0IGZpZWxkczoLICAgICBsZW5ndGggIG5hdHVyYWwtbGFuZ3VhZ2UgbGVuZ3RoIHRleHQvbmFt ZewHAAD//wAAwAAAAC8AAADuBwAAAAAAALAAAAAvAAAAcQAAAOIPAAAAAAAAGAAAAMjzegAAAAIA IAAAAAAAAAAAARIAAAAAAAAAAABKAAAA4g8AAAAAAAAYAAAAyPN6AAAAAgAcAAAAAAAAAAABEgAA AAAAAAAAACIAAADiDwAAAAAAABgAAADI83oAAAACABgAAAAAAAAAAAESAAAAAAAAAAAAWQAAAOIP AAAAAAAAGAAAAMjzegAAAAIAHAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAHgBAAAwAAAA7gcA AAAAAABoAQAAMAAAAHEAAADjDwAAAAAAADQAAADI83oAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAA AAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAC8AAADjDwAAAAAAADQAAADI83oAAQAAAAD9lgD/ /wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABABsAAADjDwAAAAAAADQA AADI83oAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAAB ACIAAADjDwAAAAAAADQAAADI83oAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAgAAAAAAAABkAAAA FAAAAAAAAAAAAAAAAAABAFkAAADjDwAAAAAAADQAAADI83oAAQAAAAD9lgD//wIAZAAAAAAAAAAA AAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgA AAAxAAAANgEAAOEPAAAAAAAABAAAAMjzegD/////rQ8AAAAAAAAAAAAAAAAAAO4DAAD//wAAjgcA ABAAAADvAwAAAAAAAAgAAAAAAAAABAEAAAIAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAA cAgAAAEBAAAB5RIA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAWwAAAAAAAADa DwAAAAAAAAgAAAAAAAAAAQEAAAABAQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoP AAD//wAAEwAAADAAAABJUFAgc2Vzc2lvbiBhdCBJRVRG9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAA JAAAAAAAAAAIAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAc AAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAA/f///wAA egC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAAAAF7AAAAAAAAAAAAAAAAAf8BAAAAAgAAMAAA ADAAAAAA5RIAAAAAAAAAAAC4CwAA//8AAOMFAAAUAAAAwgsAAP//AABGAgAAEwAAAMMLAAAAAAAA CAAAAAAAAAAMABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//EPn//5AJAADg +///AAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAA AAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP//AACeAQAAHgAAAKAPAAAAAAAAEAAA AAAAAAA6AAAAHQAAAMRuB1AT5BIAog8AAP//AABuAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAAAAAA hAAAABMAAAAAgP//AAAAAKr2//8t+f//VgkAAMP7//+1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD/ /wAAFgEAAAAAAADuBwAAAAAAAAoAAAA1AAAAUmVxdWVzdCBJZOwHAAD//wAAPAAAAC8AAADuBwAA AAAAACwAAAAvAAAACgAAAOIPAAAAAAAAGAAAAAz+egAAAAIALAAAAAAAAAAAAxIAAAAAAAAAAADs BwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAoAAADjDwAAAAAAADQAAAAM/noAAE0AAAD9 lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAA ADEAAADuBwAAAAAAABgAAAAxAAAACgAAAOEPAAAAAAAABAAAAAz+egD/////rQ8AAAAAAAAAAAAA AAAAAMILAAD//wAAfQMAABMAAADDCwAAAAAAAAgAAAAAAAAADQASAAEAAADBCwAAAAAAACgAAAAA AAAA/f///wAAAAAAMwhQcPb//3D8//8gCgAAkAYAAAAAAAD9////AQB7AL0LAAABAAAAOAAAAAAA AAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAAAADkEgAAAAAAAAAA AKEPAAD//wAA1QIAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQA+QSAKIPAAD//wAA pQIAAAAAAACjDwAAAAAAACQAAAAAAAAAAQAAAIQAAAADAAAAAID//wAAAACq9v//jfz//+YJAABz BgAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAE0CAAAAAAAA7gcAAAAAAACFAAAANQAAAFJl cXVlc3QgSWQgYWRkZWQgdG8gYWxsIHJlcXVlc3RzIGFuZCByZXBvbnNlcw1zZXJ2ZXIgcmV0dXJu cyByZWNlaXZlZCByZXF1ZXN0LWlkIGluIHJlc3BvbnNlDWNsaWVudCBtYXkgbWF0Y2ggcmVzcG9u c2VzIHdpdGggcmVxdWVzdHPsBwAA//8AAGgAAAAvAAAA7gcAAAAAAABYAAAALwAAAC4AAADiDwAA AAAAABgAAAA4y3oAAAACACAAAAAAAAAAAAESAAAAAAAAAAAAVwAAAOIPAAAAAAAAGAAAADjLegAA AAIAHAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAOgAAAAwAAAA7gcAAAAAAADYAAAAMAAAAC4A AADjDwAAAAAAADQAAAA4y3oAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAA AAAAAAAAAAAAAAABAC8AAADjDwAAAAAAADQAAAA4y3oAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAA AQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABACgAAADjDwAAAAAAADQAAAA4y3oAAQAAAAD9lgD/ /wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEA AADuBwAAAAAAABgAAAAxAAAAhQAAAOEPAAAAAAAABAAAADjLegD/////rQ8AAAAAAAAAAAAAAAAA AO4DAAD//wAAKAcAABAAAADvAwAAAAAAAAgAAAAAAAAACQEAAAIAAIDtAwAAAQAAABgAAAAAAAAA wPT//5D3//9ACwAAcAgAAAEBAAAB5RIA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD/ /wAAWwAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQEAAAABAQG6DwAA//8AAAAAAAAuAAAAug8AAP// AAAAAAAALwAAALoPAAD//wAAEwAAADAAAABJUFAgc2Vzc2lvbiBhdCBJRVRG9AMAAP//AAA0AAAA eAAAAO8HAAAAAAAAJAAAAAAAAAAIAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgDA CwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAMD0//+Q9///QAsAAHAI AAAAAAAA/f///wAAegC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAAAAF7AAAAAAAAAAAAAAAA Af8BAAAAAgAAMAAAADAAAAAA5RIAAAAAAAAAAAC4CwAA//8AAH0FAAAUAAAAwgsAAP//AABEAgAA EwAAAMMLAAAAAAAACAAAAAAAAAAMABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw 9v//EPn//5AJAADg+///AAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8B AAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAAoQ8AAP//AACcAQAAHgAA AKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AT5BIAog8AAP//AABsAQAAAAAAAKMPAAAAAAAA JAAAAAAAAAAAAAAAhAAAABMAAAAAgP//AAAAAKr2//8t+f//VgkAAMP7//+1DwAAAAAAAAQAAAAA AAAAAQAAAOAPAAD//wAAFAEAAAAAAADuBwAAAAAAAAgAAAA1AAAAU2VjdXJpdHnsBwAA//8AADwA AAAvAAAA7gcAAAAAAAAsAAAALwAAAAgAAADiDwAAAAAAABgAAABQA3sAAAACACwAAAAAAAAAAAMS AAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAAIAAAA4w8AAAAAAAA0AAAA UAN7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDs BwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAgAAADhDwAAAAAAAAQAAABQA3sA/////60P AAAAAAAAAAAAAAAAAADCCwAA//8AABkDAAATAAAAwwsAAAAAAAAIAAAAAAAAAA0AEgABAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAADMIUHD2//9w/P//kAkAAJAGAAAAAAAA/f///wEAewC9CwAA AQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA 5BIAAAAAAAAAAAChDwAA//8AAHECAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUAPk EgCiDwAA//8AAEECAAAAAAAAow8AAAAAAAAkAAAAAAAAAAEAAADEAAAAAwAAAACA//8AAAAAqvb/ /438//9WCQAAcwYAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AADpAQAAAAAAAO4HAAAAAAAA lQAAADUAAABBIHNlY3VyZSBJUFAgaW1wbGVtZW5hdGlvbiBtdXN0IHVzZSBUTFMNSVBQIGltcGxl bWVuYXRpb25zIGNhbiBhbHNvIHVzZSBzZWN1cml0eSBtZWNoYW5pc21zIGRlZmluZWQgYnkgSFRU UC8xLjEgW3JmYyAyMDY4XSBhbmQgZXh0ZW5zaW9ucyBbcmZjIDIwNjldLuwHAAD//wAAPAAAAC8A AADuBwAAAAAAACwAAAAvAAAAlQAAAOIPAAAAAAAAGAAAAFQHewAAAAIAIAAAAAAAAAAAARIAAAAA AAAAAADsBwAA//8AAKAAAAAwAAAA7gcAAAAAAACQAAAAMAAAACgAAADjDwAAAAAAADQAAABUB3sA AQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAG0AAADj DwAAAAAAADQAAABUB3sAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAA AAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAlQAAAOEPAAAAAAAABAAA AFQHewD/////rQ8AAAAAAAAAAAAAAAAAAO4DAAD//wAAaAgAABAAAADvAwAAAAAAAAgAAAAAAAAA CAEAAAIAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB5RIA9wMAAAEAAAAM AAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAWwAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQEAAAAB AQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAEwAAADAAAABJUFAgc2Vz c2lvbiBhdCBJRVRG9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAAAAAAAIAAAA////AAAAAACW lpYAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3/ //8AAAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAA/f///wAAewC9CwAAAQAAADgAAAAAAAAA/wAA AAAAAAEAAAAAAAF7AAAAAAAAAAAAAAAAAf8BAAAAAgAAMAAAADAAAAAA5RIAAAAAAAAAAAC4CwAA //8AAL0GAAAUAAAAwgsAAP//AABJAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAMABIAAAAAAMELAAAA AAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//EPn//5AJAADg+///AAAAAP3///8BAHsAvQsAAAEA AAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQS AAAAAAAAAAAAoQ8AAP//AAChAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AT5BIA og8AAP//AABxAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAAAAAAxAAAABMAAAAAgP//AAAAAKr2//8t +f//VgkAAMP7//+1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAAGQEAAAAAAADuBwAAAAAAAA0A AAA1AAAATWlub3IgY2hhbmdlc+wHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAADQAAAOIP AAAAAAAAGAAAAFgPewAAAAIALAAAAAAAAAAAAxIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcA AAAAAABIAAAAMAAAAA0AAADjDwAAAAAAADQAAABYD3sAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAA AAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAx AAAADQAAAOEPAAAAAAAABAAAAFgPewD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAVAQAABMA AADDCwAAAAAAAAgAAAAAAAAADQASAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb/ /3D8//8gCgAAkAYAAAAAAAD9////AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAA AAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAArAMAAB4AAACg DwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQA+QSAKIPAAD//wAAfAMAAAAAAACjDwAAAAAAACQA AAAAAAAAAQAAAMQAAAADAAAAAID//wAAAACq9v//jfz//+YJAABzBgAAtQ8AAAAAAAAEAAAAAAAA AAAAAADgDwAA//8AACQDAAAAAAAA7gcAAAAAAACgAAAANQAAAFJlbmFtZWQgkWRhdGEtdGFnkiB0 byCRZW5kLW9mLWF0dHJpYnV0ZXMtdGFnkg1BZGRlZCBuZXcgb3V0LW9mLWJhbmQgdmFsdWVzOiAN bm8tdmFsdWUgDXVua25vd24NRGVmaW5pdGlvbiBvZiBzdGF0dXMgY29kZXMgYW5kIG9wZXJhdGlv bnMgbW92ZWQgdG8gbW9kZWwgZG9jdW1lbnTsBwAA//8AAJQAAAAvAAAA7gcAAAAAAACEAAAALwAA AE0AAADiDwAAAAAAABgAAABkE3sAAAACACAAAAAAAAAAAAESAAAAAAAAAAAAEgAAAOIPAAAAAAAA GAAAAGQTewAAAAIAHAAAAAAAAAAAARIAAAAAAAAAAABBAAAA4g8AAAAAAAAYAAAAZBN7AAAAAgAg AAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAAeAEAADAAAADuBwAAAAAAAGgBAAAwAAAALgAAAOMP AAAAAAAANAAAAGQTewABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAA AAAAAAAAAAEAHwAAAOMPAAAAAAAANAAAAGQTewABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAA AAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEACgAAAOMPAAAAAAAANAAAAGQTewABAAAAAP2WAP//AgBk AAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEACAAAAOMPAAAAAAAANAAAAGQT ewABAAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAQQAA AOMPAAAAAAAANAAAAGQTewABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAA AAAAAAAAAAAAAAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAACgAAAA4Q8AAAAAAAAE AAAAZBN7AP////+tDwAAAAAAAAAAAAAAAAAA7gMAAP//AAB3BgAAEAAAAO8DAAAAAAAACAAAAAAA AAAKAQAAAgAAgO0DAAABAAAAGAAAAAAAAADA9P//kPf//0ALAABwCAAAAQEAAAHlEgD3AwAAAQAA AAwAAAAAAAAAAAAAAA8QAAAAAAAA2Q8AAP//AABbAAAAAAAAANoPAAAAAAAACAAAAAAAAAABAQAA AAEBAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8AAP//AAATAAAAMAAAAElQUCBz ZXNzaW9uIGF0IElFVEb0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAAAAAAAgAAAD///8AAAAA AJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA /f///wAAAAAAAAAAwPT//5D3//9ACwAAcAgAAAAAAAD9////AAB7AL0LAAABAAAAOAAAAAAAAAD/ AAAAAAAAAQAAAAAAAXsAAAAAAAAAAAAAAAAB/wEAAAACAAAwAAAAMAAAAADlEgAAAAAAAAAAALgL AAD//wAAzAQAABQAAADCCwAA//8AAFcCAAATAAAAwwsAAAAAAAAIAAAAAAAAAA8AEgAAAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAADMIUHD2//8w/f//kAkAAAAAAAAAAAAA/f///wEAewC9CwAA AQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA 5BIAAAAAAAAAAAChDwAA//8AAK8BAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUBPk EgCiDwAA//8AAH8BAAAAAAAAow8AAAAAAAAkAAAAAAAAAAYAAADEAAAAEwAAAACA//8AAAAAqvb/ /039//9WCQAA4////7UPAAAAAAAABAAAAAAAAAABAAAA4A8AAP//AAAnAQAAAAAAAO4HAAAAAAAA GwAAADUAAABNYXBwaW5nIGJldHdlZW4gTFBEIGFuZCBJUFDsBwAA//8AADwAAAAvAAAA7gcAAAAA AAAsAAAALwAAABsAAADiDwAAAAAAABgAAABcHHsAAAACACwAAAAAAAAAAAMSAAAAAAAAAAAA7AcA AP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAAbAAAA4w8AAAAAAAA0AAAAXBx7AAAAAAAA/ZUA //8CAGQAAAAAAAAAAAAAAAAwAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAx AAAA7gcAAAAAAAAYAAAAMQAAABsAAADhDwAAAAAAAAQAAABcHHsA/////60PAAAAAAAAAAAAAAAA AADCCwAA//8AAFUCAAATAAAAwwsAAAAAAAAIAAAAAAAAABAAEgABAAAAwQsAAAAAAAAoAAAAAAAA AP3///8AAAAAADMIUCD4//8gAQAA4AcAAHAFAAAAAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA /wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAACh DwAA//8AAK0BAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUAPkEgCiDwAA//8AAH0B AAAAAAAAow8AAAAAAAAkAAAAAAAAAAUAAADEAAAAAwAAAACA//8AAAAAWvj//z0BAACmBwAAUwUA ALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAAlAQAAAAAAAO4HAAAAAAAAGQAAADUAAABDaGFu Z2VzIHNpbmNlIEF1Z3VzdCBJRVRG7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAAZAAAA 4g8AAAAAAAAYAAAAdCB7AAAAAgAgAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADu BwAAAAAAAEgAAAAwAAAAGQAAAOMPAAAAAAAANAAAAHQgewAAAAAAAP2VAP//AgBkAAAAAAAAAAAA AAAAMAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAA ADEAAAAZAAAA4Q8AAAAAAAAEAAAAdCB7AP////+tDwAAAAAAAAAAAAAAAAAA7gMAAP//AAA4BwAA EAAAAO8DAAAAAAAACAAAAAAAAAAOAQAAAgAAgO0DAAABAAAAGAAAAAAAAADA9P//kPf//0ALAABw CAAAAQEAAAHlEgD3AwAAAQAAAAwAAAAAAAAAAQAAAAwNAAAAAAAA2Q8AAP//AABbAAAAAAAAANoP AAAAAAAACAAAAAAAAAABAQAAAAEBAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8A AP//AAATAAAAMAAAAElQUCBzZXNzaW9uIGF0IElFVEb0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAk AAAAAAAAAAgAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwA AADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAwPT//5D3//9ACwAAcAgAAAAAAAD9////AAB7 AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAAAAXsAAAAAAAAAAAAAAAAB/wEAAAACAAAwAAAA MAAAAADlEgAAAAAAAAAAALgLAAD//wAAjQUAABQAAADCCwAA//8AAFMCAAATAAAAwwsAAAAAAAAI AAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAADMIUHD2//8Q+f//kAkAAOD7 //8AAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAA Af8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8AAKsBAAAeAAAAoA8AAAAAAAAQAAAA AAAAADoAAAAdAAAAxG4HUBPkEgCiDwAA//8AAHsBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAAAAAAE AQAAEwAAAACA//8AAAAAqvb//y35//9WCQAAw/v//7UPAAAAAAAABAAAAAAAAAABAAAA4A8AAP// AAAjAQAAAAAAAO4HAAAAAAAAFwAAADUAAABDaGFuZ2UgdG8gSW5mb3JtYXRpb25hbOwHAAD//wAA PAAAAC8AAADuBwAAAAAAACwAAAAvAAAAFwAAAOIPAAAAAAAAGAAAAAgnewAAAAIALAAAAAAAAAAA AxIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAABcAAADjDwAAAAAAADQA AAAIJ3sAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAAB AOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAFwAAAOEPAAAAAAAABAAAAAgnewD///// rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAGgMAABMAAADDCwAAAAAAAAgAAAAAAAAADQASAAEAAADB CwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//3D8//+QCQAAkAYAAAAAAAD9////AQB7AL0L AAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAA AADkEgAAAAAAAAAAAKEPAAD//wAAcgIAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQ A+QSAKIPAAD//wAAQgIAAAAAAACjDwAAAAAAACQAAAAAAAAAAQAAAAQBAAADAAAAAID//wAAAACq 9v//jfz//1YJAABzBgAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAOoBAAAAAAAA7gcAAAAA AADeAAAANQAAAJNUaGlzIGRvY3VtZW50IGlzIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhh dCBpcyBub3Qgb24gdGhlIHN0YW5kYXJkcyB0cmFjay4gIEl0IGlzIGludGVuZGVkIHRvIGhlbHAg aW1wbGVtZW50b3JzIG9mIGdhdGV3YXlzIGJldHdlZW4gSVBQIGFuZCBMUEQuICBJdCBhbHNvIHBy b3ZpZGVzIGFuIGV4YW1wbGUsICB3aGljaCBnaXZlcyBhZGRpdGlvbmFsIGluc2lnaHQgaW50byBJ UFAulOwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAA3gAAAOIPAAAAAAAAGAAAABwrewAA AAIAIAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAN4A AADjDwAAAAAAADQAAAAcK3sAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAA AGAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAA3gAAAOEPAAAAAAAA BAAAABwrewD/////rQ8AAAAAAAAAAAAAAAAAAO4DAAD//wAA9wgAABAAAADvAwAAAAAAAAgAAAAA AAAACwEAAAIAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB5RIA9wMAAAEA AAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAWwAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQEA AAABAQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAEwAAADAAAABJUFAg c2Vzc2lvbiBhdCBJRVRG9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAAAAAAAIAAAA////AAAA AACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAA AP3///8AAAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAA/f///wAAewC9CwAAAQAAADgAAAAAAAAA /wAAAAAAAAEAAAAAAAF7AAAAAAAAAAAAAAAAAf8BAAAAAgAAMAAAADAAAAAA5RIAAAAAAAAAAAC4 CwAA//8AAEwHAAAUAAAAwgsAAP//AABNAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAMABIAAAAAAMEL AAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//EPn//5AJAADg+///AAAAAP3///8BAHsAvQsA AAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAA AOQSAAAAAAAAAAAAoQ8AAP//AAClAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AT 5BIAog8AAP//AAB1AQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAAAAAABAEAABMAAAAAgP//AAAAAKr2 //8t+f//VgkAAMP7//+1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAAHQEAAAAAAADuBwAAAAAA ABEAAAA1AAAAQXR0cmlidXRlIENoYW5nZXPsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAA ABEAAADiDwAAAAAAABgAAABwMnsAAAACACwAAAAAAAAAAAMSAAAAAAAAAAAA7AcAAP//AABYAAAA MAAAAO4HAAAAAAAASAAAADAAAAARAAAA4w8AAAAAAAA0AAAAcDJ7AAAAAAAA/ZUA//8CAGQAAAAA AAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcAAAAA AAAYAAAAMQAAABEAAADhDwAAAAAAAAQAAABwMnsA/////60PAAAAAAAAAAAAAAAAAADCCwAA//8A AN8EAAATAAAAwwsAAAAAAAAIAAAAAAAAAA0AEgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA ADMIUHD2//9w/P//kAkAAJAGAAAAAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEA AAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8AADcE AAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUAPkEgCiDwAA//8AAAcEAAAAAAAAow8A AAAAAAAkAAAAAAAAAAEAAAAEAQAAAwAAAACA//8AAAAAqvb//438//9WCQAAcwYAALUPAAAAAAAA BAAAAAAAAAAAAAAA4A8AAP//AACvAwAAAAAAAO4HAAAAAAAA/wAAADUAAABqb2ItaWQgYnJvdWdo dCBiYWNrDW5vdyBib3RoIGpvYi1pZCBhbmQgam9iLXVyaSBhcmUgYXZhaWxhYmxlDXNpbXBsaWZp ZXMgaW1wbGVtZW50YXRpb24gd2l0aCBqb2ItaWQgd2hpY2ggY2FuIGJlIHRoZSBzYW1lIGFzIExQ RCBqb2IgbnVtYmVyDWpvYi1vcmlnaW5hdGluZy1ob3N0IG5vIGxvbmdlciBhdmFpbGFibGUuIA1J UFAtdG8tTFBEIG11c3QgdXNlIHNvbWUgb3RoZXIgbWVhbnMgdG8gc3VwcGx5IHRoZSCRSJIgKGhv c3QpIHBhcmFtZXRlci7sBwAA//8AAMAAAAAvAAAA7gcAAAAAAACwAAAALwAAABQAAADiDwAAAAAA ABgAAACANnsAAAACACAAAAAAAAAAAAESAAAAAAAAAAAAeAAAAOIPAAAAAAAAGAAAAIA2ewAAAAIA HAAAAAAAAAAAARIAAAAAAAAAAAArAAAA4g8AAAAAAAAYAAAAgDZ7AAAAAgAgAAAAAAAAAAABEgAA AAAAAAAAAEgAAADiDwAAAAAAABgAAACANnsAAAACABwAAAAAAAAAAAESAAAAAAAAAAAA7AcAAP// AAB4AQAAMAAAAO4HAAAAAAAAaAEAADAAAAAUAAAA4w8AAAAAAAA0AAAAgDZ7AAEAAAAA/ZUA//8C AGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAAAAQAqAAAA4w8AAAAAAAA0AAAA gDZ7AAEAAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAAAAQBO AAAA4w8AAAAAAAA0AAAAgDZ7AAEAAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAABQA AAAAAAAAAAAAAAAAAQArAAAA4w8AAAAAAAA0AAAAgDZ7AAEAAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAAAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAAAAQBIAAAA4w8AAAAAAAA0AAAAgDZ7AAEAAAAA/ZYA //8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAx AAAA7gcAAAAAAAAYAAAAMQAAAP8AAADhDwAAAAAAAAQAAACANnsA/////60PAAAAAAAAAAAAAAAA AADuAwAA//8AAMAJAAAQAAAA7wMAAAAAAAAIAAAAAAAAAAwBAAACAACA7QMAAAEAAAAYAAAAAAAA AMD0//+Q9///QAsAAHAIAAABAQAAAeUSAPcDAAABAAAADAAAAAAAAAABAAAADA0AAAAAAADZDwAA //8AAFsAAAAAAAAA2g8AAAAAAAAIAAAAAAAAAAEBAAAAAQEBug8AAP//AAAAAAAALgAAALoPAAD/ /wAAAAAAAC8AAAC6DwAA//8AABMAAAAwAAAASVBQIHNlc3Npb24gYXQgSUVURvQDAAD//wAANAAA AHgAAADvBwAAAAAAACQAAAAAAAAACAAAAP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIA wAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABw CAAAAAAAAP3///8AAHsAvQsAAAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAAABewAAAAAAAAAAAAAA AAH/AQAAAAIAADAAAAAwAAAAAOUSAAAAAAAAAAAAuAsAAP//AAAVCAAAFAAAAMILAAD//wAAUgIA ABMAAADDCwAAAAAAAAgAAAAAAAAADAASAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQ cPb//xD5//+QCQAA4Pv//wAAAAD9////AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/ AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAAqgEAAB4A AACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQE+QSAKIPAAD//wAAegEAAAAAAACjDwAAAAAA ACQAAAAAAAAAAAAAAAQBAAATAAAAAID//wAAAACq9v//Lfn//1YJAADD+///tQ8AAAAAAAAEAAAA AAAAAAEAAADgDwAA//8AACIBAAAAAAAA7gcAAAAAAAAWAAAANQAAAE1vcmUgQXR0cmlidXRlIENo YW5nZXPsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAABYAAADiDwAAAAAAABgAAABUQHsA AAACACwAAAAAAAAAAAMSAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAAW AAAA4w8AAAAAAAA0AAAAVEB7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAAAAA AAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAABYAAADhDwAAAAAA AAQAAABUQHsA/////60PAAAAAAAAAAAAAAAAAADCCwAA//8AAKMFAAATAAAAwwsAAAAAAAAIAAAA AAAAAA0AEgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAADMIUHD2//9w/P//kAkAAJAGAAAA AAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8B AAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8AAPsEAAAeAAAAoA8AAAAAAAAQAAAAAAAA ADoAAAAdAAAAxG4HUAPkEgCiDwAA//8AAMsEAAAAAAAAow8AAAAAAAAkAAAAAAAAAAEAAAAEAQAA AwAAAACA//8AAAAAqvb//438//9WCQAAcwYAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AABz BAAAAAAAAO4HAAAAAAAA2wAAADUAAABKb2Itay1vY3RldHMgY2xhcmllZCBhcyBub3QgY29udGFp bmluZyBjb3BpZXMNZmlsZSBzaXplIGluIGxwcSBkb2VzIGNvbnRhaW4gY29waWVzDUlQUCBub3Rp ZmljYXRpb24gZ29uZQ1jYW5ub3Qgc3VwcG9ydCBMUEQgZW1haWwgbm90aWZpY2F0aW9uDWRvY3Vt ZW50IGZvcm1hdHMgY29udmVyc2lvbiBpcyBkaWZmZXJlbnQNYXJlIG1pbWUgbWVkaWEgdHlwZXMg bm93DXdlcmUgZW51bXPsBwAA//8AABgBAAAvAAAA7gcAAAAAAAAIAQAALwAAAC4AAADiDwAAAAAA ABgAAABoRHsAAAACACAAAAAAAAAAAAESAAAAAAAAAAAAJQAAAOIPAAAAAAAAGAAAAGhEewAAAAIA HAAAAAAAAAAAARIAAAAAAAAAAAAWAAAA4g8AAAAAAAAYAAAAaER7AAAAAgAgAAAAAAAAAAABEgAA AAAAAAAAACYAAADiDwAAAAAAABgAAABoRHsAAAACABwAAAAAAAAAAAESAAAAAAAAAAAAKQAAAOIP AAAAAAAAGAAAAGhEewAAAAIAIAAAAAAAAAAAARIAAAAAAAAAAAAjAAAA4g8AAAAAAAAYAAAAaER7 AAAAAgAcAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAACAIAADAAAADuBwAAAAAAAPgBAAAwAAAA LgAAAOMPAAAAAAAANAAAAGhEewABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAU AAAAAAAAAAAAAAAAAAEAJQAAAOMPAAAAAAAANAAAAGhEewABAAAAAP2WAP//AgBkAAAAAAAAAAAA AAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAFgAAAOMPAAAAAAAANAAAAGhEewABAAAAAP2V AP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEAJgAAAOMPAAAAAAAA NAAAAGhEewABAAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAA AAEAKQAAAOMPAAAAAAAANAAAAGhEewABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQA AAAUAAAAAAAAAAAAAAAAAAEAGQAAAOMPAAAAAAAANAAAAGhEewABAAAAAP2WAP//AgBkAAAAAAAA AAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEACgAAAOMPAAAAAAAANAAAAGhEewABAAAA AP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAo AAAAMQAAAO4HAAAAAAAAGAAAADEAAADbAAAA4Q8AAAAAAAAEAAAAaER7AP////+tDwAAAAAAAAAA AAAAAAAA7gMAAP//AAD0CAAAEAAAAO8DAAAAAAAACAAAAAAAAAANAQAAAgAAgO0DAAABAAAAGAAA AAAAAADA9P//kPf//0ALAABwCAAAAQEAAAHlEgD3AwAAAQAAAAwAAAAAAAAAAQAAAAwNAAAAAAAA 2Q8AAP//AABbAAAAAAAAANoPAAAAAAAACAAAAAAAAAABAQAAAAEBAboPAAD//wAAAAAAAC4AAAC6 DwAA//8AAAAAAAAvAAAAug8AAP//AAATAAAAMAAAAElQUCBzZXNzaW9uIGF0IElFVEb0AwAA//8A ADQAAAB4AAAA7wcAAAAAAAAkAAAAAAAAAAgAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8A srKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAwPT//5D3//9A CwAAcAgAAAAAAAD9////AAB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAAAAXsAAAAAAAAA AAAAAAAB/wEAAAACAAAwAAAAMAAAAADlEgAAAAAAAAAAALgLAAD//wAASQcAABQAAADCCwAA//8A AEoCAAATAAAAwwsAAAAAAAAIAAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA ADMIUHD2//8Q+f//kAkAAOD7//8AAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEA AAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8AAKIB AAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAAxG4HUBPkEgCiDwAA//8AAHIBAAAAAAAAow8A AAAAAAAkAAAAAAAAAAAAAABEAQAAEwAAAACA//8AAAAAqvb//y35//9WCQAAw/v//7UPAAAAAAAA BAAAAAAAAAABAAAA4A8AAP//AAAaAQAAAAAAAO4HAAAAAAAADgAAADUAAABBdXRoZW50aWNhdGlv buwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAADgAAAOIPAAAAAAAAGAAAAHhPewAAAAIA LAAAAAAAAAAAAxIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAA4AAADj DwAAAAAAADQAAAB4T3sAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAAAAAA AAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAADgAAAOEPAAAAAAAABAAA AHhPewD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAA3wQAABMAAADDCwAAAAAAAAgAAAAAAAAA DQASAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//3D8//+QCQAAkAYAAAAAAAD9 ////AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAAC fAAwAAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAANwQAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAA AB0AAADEbgdQA+QSAKIPAAD//wAABwQAAAAAAACjDwAAAAAAACQAAAAAAAAAAQAAAEQBAAADAAAA AID//wAAAACq9v//jfz//1YJAABzBgAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAK8DAAAA AAAA7gcAAAAAAAC3AAAANQAAAG5ldyBhdHRyaWJ1dGU6IGpvYi1vcmdpbmF0aW5nLXVzZXItbmFt ZSANd2FzIGpvYi1vcmdpbmF0aW5nLXVzZXINZXhwbGljaXRseSBob2xkcyBhIGh1bWFuIHJlYWRh YmxlIG5hbWUNdmFsdWUgY29tZXMgZnJvbSANYXV0aGVudGljYXRpb24gYW5kIA1vcGVyYXRpb24g YXR0cmlidXRlOiByZXF1ZXN0aW5nLXVzZXItbmFtZewHAAD//wAAwAAAAC8AAADuBwAAAAAAALAA AAAvAAAAKQAAAOIPAAAAAAAAGAAAAIRTewAAAAIAIAAAAAAAAAAAARIAAAAAAAAAAAAYAAAA4g8A AAAAAAAYAAAAhFN7AAAAAgAcAAAAAAAAAAABEgAAAAAAAAAAADkAAADiDwAAAAAAABgAAACEU3sA AAACACAAAAAAAAAAAAESAAAAAAAAAAAAPQAAAOIPAAAAAAAAGAAAAIRTewAAAAIAHAAAAAAAAAAA ARIAAAAAAAAAAADsBwAA//8AAMABAAAwAAAA7gcAAAAAAACwAQAAMAAAACkAAADjDwAAAAAAADQA AACEU3sAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAAB ABgAAADjDwAAAAAAADQAAACEU3sAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAA FAAAAAAAAAAAAAAAAAABACcAAADjDwAAAAAAADQAAACEU3sAAQAAAAD9lQD//wIAZAAAAAAAAAAA AAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABABIAAADjDwAAAAAAADQAAACEU3sAAQAAAAD9 lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABABQAAADjDwAAAAAA ADQAAACEU3sAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAA AAABACkAAADjDwAAAAAAADQAAACEU3sAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAtwAAAOEP AAAAAAAABAAAAIRTewD/////rQ8AAAAAAAAAAAAAAAAAANAHAAD//wAA9hAAAAsAAADRBwAAAAAA AAQAAAAAAAAAAQAAAPgDAAD//wAA0hAAABAAAADvAwAAAAAAAAgAAAAAAAAAAgAAgAAAAADtAwAA AQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB5RIA7wcAAAAAAAAkAAAANwAAAAgAAAD/ //8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAO8HAAAAAAAAJAAAADcAAAAIAAAAAAD/AP// /wAAAAAA//8AAP+ZAAAA//8A/wAzAJaWlgDvBwAAAAAAACQAAAA3AAAACAAAAP//zAAAAAAAgIAA AJmZMwAzmTMAgAAAAAAzzAD/zGYA7wcAAAAAAAAkAAAANwAAAAgAAAD///8AAAAAADk5OQAAAAAA y8vLAIaGhgBNTU0A6urqAO8HAAAAAAAAJAAAADcAAAAIAAAA////AAAAAACfn58AAAAAAP/MZgAA AP8AzADMAMDAwADvBwAAAAAAACQAAAA3AAAACAAAAP///wAAAAAAhoaGAAAAAADLy8sAAGb/AP8A MwAAmQAA7wcAAAAAAAAkAAAANwAAAAgAAAD///8AAAAAAJaWlgAAAAAAM5n/AJn/zADMAMwAsrKy APcDAAABAAAADAAAAAAAAAABAAAAAQIGCAcAAADZDwAA//8AAFsAAAAAAAAA2g8AAAAAAAAIAAAA AAAAAAEBAAAAAQEBug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AABMAAAAw AAAASVBQIHNlc3Npb24gYXQgSUVURvQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAAAAAAACAAA AP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAA KAAAAAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABwCAAAAAAAAP3///8AAHsAvQsAAAEAAAA4 AAAAAAAAAP8AAAAAAAABAAAAAAABewAAAAAAAAAAAAAAAAH/AQAAAAIAADAAAAAwAAAAAOUSAAAA AAAAAAAAuAsAAP//AACVDQAAFAAAAMILAAD//wAAXAIAABMAAADDCwAAAAAAAAgAAAAAAAAAAQAS AAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb//xD5//+QCQAA4Pv//wAAAAD9//// AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAw AAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAAtAEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0A AADEbgdQE+ASAOQPAAD//wAAhAEAAAAAAACjDwAAAAAAACQAAAAAAAAAAAAAAEQBAAATAAAAAID/ /wAAAACq9v//Lfn//1YJAADD+///tQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AACwBAAAAAAAA 7gcAAAAAAAAgAAAANQAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl7AcAAP//AAA8 AAAALwAAAO4HAAAAAAAALAAAAC8AAAAgAAAA4g8AAAAAAAAYAAAASGB7AAAAAgAsAAAAAAAAAAAD EgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAIAAAAOMPAAAAAAAANAAA AEhgewAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA 7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAgAAAA4Q8AAAAAAAAEAAAASGB7AP////+t DwAAAAAAAAAAAAAAAAAAwgsAAP//AAAyBAAAEwAAAMMLAAAAAAAACAAAAAAAAAACABIAAQAAAMEL AAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFBw9v//cPz//5AJAACQBgAAAAAAAP3///8BAHsAvQsA AAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAA AOQSAAAAAAAAAAAAoQ8AAP//AACKAwAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMRuB1AD 4BIA5A8AAP//AABaAwAAAAAAAKMPAAAAAAAAJAAAAAAAAAABAAAARAEAAAMAAAAAgP//AAAAAKr2 //+N/P//VgkAAHMGAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAAAgMAAAAAAADuBwAAAAAA AFIAAAA1AAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRo aXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbOwHAAD//wAAwAAAAC8AAADuBwAAAAAA ALAAAAAvAAAAIQAAAOIPAAAAAAAAGAAAAGxkewAAAAIAIAAAAAAAAAAAARIAAAAAAAAAAAANAAAA 4g8AAAAAAAAYAAAAbGR7AAAAAgAcAAAAAAAAAAABEgAAAAAAAAAAAAwAAADiDwAAAAAAABgAAABs ZHsAAAACABgAAAAAAAAAAAESAAAAAAAAAAAAGAAAAOIPAAAAAAAAGAAAAGxkewAAAAIAFAAAAAAA AAAAARIAAAAAAAAAAADsBwAA//8AAHgBAAAwAAAA7gcAAAAAAABoAQAAMAAAACEAAADjDwAAAAAA ADQAAABsZHsAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAA AAABAA0AAADjDwAAAAAAADQAAABsZHsAAQAAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAABAAwAAADjDwAAAAAAADQAAABsZHsAAQAAAAD9lQD//wIAZAAAAAAA AAAAAAAAAgAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAA0AAADjDwAAAAAAADQAAABsZHsAAQAA AAD9lgD//wIAZAAAAAAAAAAAAAAAAwAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAABAAsAAADjDwAA AAAAADQAAABsZHsAAQAAAAD9lQD//wIAZAAAAAAAAAAAAAAABAAAAAAAAABkAAAAFAAAAAAAAAAA AAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAUgAAAOEPAAAAAAAABAAAAGxk ewD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAABgES AAIAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQcPb///AGAAAg+///EAgAAAAAAAD9//// AQB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAw AAAAMAAAAADkEgAAAAAAAAAAAKEPAAD//wAAlQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0A AADAbgdQE+ASAKIPAAD//wAAZQEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAEABAAATAAAAAID/ /wAAAACq9v//DQcAAOb6///zBwAAtQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AAA0BAAAAAAAA 7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAA AAAAABgAAAAwansAAAACAA4AAACAAAAAAAESAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAA AAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAAMGp7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAA AAAAAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAA AAEAAADhDwAAAAAAAAQAAAAwansAAAAAAK0PAAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAA wwsAAAAAAAAIAAAAAAAAAAgCEgADAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAADMIUHD8///w BgAAkAMAABAIAAAAAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA/wEAAAAA AAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5BIAAAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8A AAAAAAAQAAAAAAAAADoAAAAdAAAAwG4HUBPgEgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAA AAAAAAQAAABAAQAAEwAAAACA//8AAAAAqvz//w0HAABWAwAA8wcAALUPAAAAAAAABAAAAAAAAAAB AAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAA AAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAAMG57AAAAAgAOAAAAgAAAAAABEgAAAAAAAAAAAOwH AAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAAADBuewAAAAAAAP2V AP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA7AcAAP//AAAoAAAA MQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8AAAAAAAAEAAAAMG57AAEAAACtDwAAAAAAAAAAAAAA AAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAACAAAAAAAAAAHAhIABAAAAMELAAAAAAAAKAAAAAAA AAD9////AAAAAAAzCFDgBAAA8AYAAJAJAAAQCAAAAAAAAP3///8BAHsAvQsAAAEAAAA4AAAAAAAA AP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOQSAAAAAAAAAAAA oQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAMBuB1AT4BIAog8AAP//AABl AQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAAQAEAABMAAAAAgP//AAAAABoFAAANBwAAVgkAAPMH AAC1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwH AAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAAQAAAOIPAAAAAAAAGAAAADByewAAAAIADgAA AIAAAAAAARIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAA AAAAADQAAAAwcnsAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAIAAABkAAAAAAAAAAAAAAAA AAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADBy ewACAAAArQ8AAAAAAAAAAAAAAAAAALoPAAD//wAAFgAAAIwAAABCbGFuayBQcmVzZW50YXRpb24u cG908AMAAP//AABmDwAAJwAAAPEDAAAAAAAABAAAAAAAAAACAACA7QMAAAEAAAAYAAAAAAAAAJn3 //9x9P//aAgAAJALAAABAQAAATkIUNkPAAD//wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAA AAEBAQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA //8AADQAAAB4AAAA7wcAAAAAAAAkAAAAAAAAAAgAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADM zP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAmff//3H0 //9oCAAAkAsAAAAAAAD9////AAB7AL0LAAABAAAAOAAAAAAAAAD/AAAAAAAAAQAAAAAAAXsAAAAA AAAAAAAAAAAB/wEAAAACAAAwAAAAMAAAAADlEgAAAAAAAAAAALgLAAD//wAA7g0AABQAAADCCwAA //8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAkCEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8A AAAAADMIUJj3//9w9P//4f7//5j1//8AAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAA AAEAAAAA/wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5RIAAAAAAAAAAAChDwAA//8A AJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAAAwAAAAAAAAAxG4HUAPkEgCiDwAA//8AAGUBAAAAAAAA ow8AAAAAAAAkAAAAAAAAAAQAAACEAQAAAwAAAACA//8AAAAApPf//3D0///V/v//mPX//7UPAAAA AAAABAAAAAAAAAABAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8 AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAAkHh7AAIAAgAKAAAAggAAAAAB EgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAA AJB4ewAAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA 7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8AAAAAAAAEAAAAkHh7AAMAAACt DwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAACAAAAAAAAAAGAhIAAwAAAMEL AAAAAAAAKAAAAAAAAAD9////AAAAAAAzCFAfAQAAcPT//2gIAACY9f//AAAAAP3///8BAHsAvQsA AAEAAAA4AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAA AOUSAAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAAMAAAAAAAAAMRuB1AD 5BIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAAhAEAAAMAAAAAgP//AAAAACsB AABw9P//XAgAAJj1//+1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAADQEAAAAAAADuBwAAAAAA AAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAAQAAAOIPAAAAAAAAGAAA AJB8ewACAAIACgAAAIIAAAAAARIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAA MAAAAAEAAADjDwAAAAAAADQAAACQfHsAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAIAAABk AAAAAAAAAAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQAAAOEP AAAAAAAABAAAAJB8ewAAAAAArQ8AAAAAAAAAAAAAAAAAAMILAAD//wAA7AAAABMAAADDCwAAAAAA AAgAAAAAAAAABAASAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAMwhQOPr//yz2///IBQAA 2P7//wAAAAD9////AAF7AL0LAAABAAAAOAAAAAAAAAAAAAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQA AAAB/wEAAAACfAAwAAAAMAAAAADlEgAAAAAAAAAAAK4PAAD//wAARAAAAB8AAACvDwAAAAAAABAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAANYPAAD//wAAFAAAAAAAAADADwAAAAAAAAQAAAAAAAAAAgAA gMILAAD//wAArgMAABMAAADDCwAAAAAAAAgAAAAAAAAABQASAAIAAADBCwAAAAAAACgAAAAAAAAA /f///wAAAAAAMwhQ1vn//2z///8qBgAA1AkAAAAAAAD9////AQB7AL0LAAABAAAAOAAAAAAAAAD/ AAAAAAAAAQAAAAD/AQAAAAAAAAAAAAQAAAAB/wEAAAACfAAwAAAAMAAAAADlEgAAAAAAAAAAAKEP AAD//wAABgMAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAADEbgdQA+QSAOQPAAD//wAA1gIA AAAAAACjDwAAAAAAACQAAAAAAAAAAgAAAIQBAAADAAAAAID//wAAAAAQ+v//if////AFAAC3CQAA tQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AAH4CAAAAAAAA7gcAAAAAAABSAAAANQAAAENsaWNr IHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3Vy dGggbGV2ZWwNRmlmdGggbGV2ZWzsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAFIAAADi DwAAAAAAABgAAADwgXsAAAACAAwAAAAAAAAAAAESAAAAAAAAAAAA7AcAAP//AAB4AQAAMAAAAO4H AAAAAAAAaAEAADAAAAAhAAAA4w8AAAAAAAA0AAAA8IF7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAAAAAAAAAAAZAAAAB4AAAAAAAAAAAAAAAAAAQANAAAA4w8AAAAAAAA0AAAA8IF7AAAAAAAA/ZUA //8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAAB4AAAAAAAAAAAAAAAAAAQAMAAAA4w8AAAAAAAA0 AAAA8IF7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAIAAAAAAAAAZAAAAB4AAAAAAAAAAAAAAAAA AQANAAAA4w8AAAAAAAA0AAAA8IF7AAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAMAAAAAAAAAZAAA AB4AAAAAAAAAAAAAAAAAAQALAAAA4w8AAAAAAAA0AAAA8IF7AAAAAAAA/ZUA//8CAGQAAAAAAAAA AAAAAAQAAAAAAAAAZAAAAB4AAAAAAAAAAAAAAAAAAQDsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAY AAAAMQAAAFIAAADhDwAAAAAAAAQAAADwgXsA/////60PAAAAAAAAAAAAAAAAAADCCwAA//8AAD0C AAATAAAAwwsAAAAAAAAIAAAAAAAAAAgCEgAEAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAADMI UJj3//9oCgAA4f7//5ALAAAAAAAA/f///wEAewC9CwAAAQAAADgAAAAAAAAA/wAAAAAAAAEAAAAA /wEAAAAAAAAAAAAEAAAAAf8BAAAAAnwAMAAAADAAAAAA5RIAAAAAAAAAAAChDwAA//8AAJUBAAAe AAAAoA8AAAAAAAAQAAAAAAAAAAwAAAAAAAAAxG4HUCPkEgCiDwAA//8AAGUBAAAAAAAAow8AAAAA AAAkAAAAAAAAAAQAAACEAQAAIwAAAACA//8AAAAApPf//2gKAADV/v//kAsAALUPAAAAAAAABAAA AAAAAAABAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAA AO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAAtId7AAIAAgAKAAAAggAAAAABEgAAAAAA AAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAAALSHewAA AAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAAAAAAAAAAAAAAAAAAAEA7AcAAP// AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8AAAAAAAAEAAAAtId7AAEAAACtDwAAAAAA AAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAACAAAAAAAAAAHAhIABQAAAMELAAAAAAAA KAAAAAAAAAD9////AAAAAAAzCFAfAQAAaAoAAGgIAACQCwAAAAAAAP3///8BAHsAvQsAAAEAAAA4 AAAAAAAAAP8AAAAAAAABAAAAAP8BAAAAAAAAAAAABAAAAAH/AQAAAAJ8ADAAAAAwAAAAAOUSAAAA AAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAAMAAAAAAAAAMRuB1Aj5BIAog8A AP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAAhAEAACMAAAAAgP//AAAAACsBAABoCgAA XAgAAJALAAC1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1 AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAAQAAAOIPAAAAAAAAGAAAALSLewAC AAIACgAAAIIAAAAAARIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEA AADjDwAAAAAAADQAAAC0i3sAAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAIAAABkAAAAAAAA AAAAAAAAAAAAAAABAOwHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAA BAAAALSLewACAAAArQ8AAAAAAAAAAAAAAAAAANAHAAD//wAAYgEAAAwAAADRBwAAAAAAAAQAAAAA AAAABwAAAP8DAAD//wAARAAAABAAAAAABAAAAQAAAAgAAAAAAAAAAAAAAAAAAAC6DwAA//8AAAwA AAAHAAAAX1ZCQV9QUk9KRUNUug8AAP//AAAAAAAAoAAAAPoDAAD//wAAlgAAALQAAAD+AwAAAQAA AAIAAAAAAAAAAAHqBwAA//8AADAAAAAAAAAA+wMAAAAAAAAIAAAAAAAAAAEAAAAAAAAA+wMAAAAA AAAIAAAAAAAAAAAAAAAAAAAA/QMAAAEAAAA0AAAAAAAAADgAAABkAAAAOAAAAGQAAAAiAAAAZAAA ACIAAABkAAAAjhEAACwKAAA89///6vr//wEAegAIBAAA//8AAEQAAAAAAAAA/QMAAAEAAAA0AAAA AAAAAGQAAABkAAAAZAAAAGQAAABkAAAAZAAAAGQAAABkAAAAyBYAABwOAAAAAAAAuAsAAAAAewAC BAAA//8AACQAAABkAAAA4wcAAP//AAAUAAAAZQAAAOkHAAAAAAAABAAAACwAAAABAAAA6gMAAAAA AAAAAAAAAAAAAAoAAAAAAAAACAAAAAAAAAABAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA AAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAA ABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA JgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA/v////7////+//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////wcA4AMAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAABQAAABQ b3dlclBvaW50IERvY3VtZW50AAEAAAAAAAAAAABJUFAgUHJvdG9jb2wNDUNoYW5nZXMgc2luY2Ug QXVndXN0IElFVEYNDUF0dHJpYnV0ZXMgR3JvdXBzDQ1QYXJhbWV0ZXIvQXR0cmlidXRlIGRpc3Rp bmN0aW9uIHJlbW92ZWQNQXR0cmlidXRlIEdyb3VwcyBjcmVhdGVkOg1vcGVyYXRpb24gYXR0cmli dXRlcw1qb2IgYXR0cmlidXRlcw1wcmludGVyIGF0dHJpYnV0ZXMNdW5zdXBwb3J0ZWQgYXR0cmli dXRlcw0NRW1wdHkgQXR0cmlidXRlIEdyb3Vwcw0NU2VuZGVyIChvZiByZXF1ZXN0IG9yIHJlc3Bv bnNlKSBzaG91bGQgc2VuZA1hdHRyaWJ1dGUgZ3JvdXAgdGFnIHdpdGggbm8gZm9sbG93aW5nIGF0 dHJpYnV0ZXMNZXhjZXB0IGZvciB1bnN1cHBvcnRlZC1hdHRyaWJ1dGVzLXRhZw1SZWNlaXZlciBv ZiAocmVxdWVzdCBvciByZXBvbnNlKSBtdXN0IGFjY2VwdCBhcyBlcXVpdmFsZW50IGVtcHR5IGF0 dHJpYnV0ZSBncm91cHM6DWF0dHJp/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAjAQAAA0AAAABAAAAcAAAAAIAAAB4AAAABAAAAJAAAAAHAAAAnAAAAAgAAADU AAAACQAAAOAAAAASAAAA7AAAAAoAAAAMAQAACwAAABgBAAAMAAAAJAEAAA0AAAAwAQAADwAAADwB AAARAAAARAEAAAIAAADkBAAAHgAAAA0AAABJUFAgUHJvdG9jb2wAAAAAHgAAAAQAAABib2IAHgAA AC0AAABDOlxNU09mZmljZVxUZW1wbGF0ZXNcQmxhbmsgUHJlc2VudGF0aW9uLnBvdAAAAAAeAAAA BAAAAGJvYgAeAAAAAgAAADQAAAAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAEAAAABQ 1ZIZEAAAAEAAAACAnGaDQAS9AUAAAABw/S9pCj26AUAAAABwqGgk6hq9AQMAAADGAQAARwAAAD4D AAD/////AwAAAAgAgjEbJQAAAQAJAAADlwEAAAUALQAAAAAAEQAAACYGDwAYAP////8AABAAYPr/ /8j7//+aBQAAMgQAAAkAAAAmBg8ACAD/////AgAAABAAAAAmBg8AFgD/////BAAOAFROUFAHAKhi PVBVB3niCgAAACYGDwAKAFROUFAAAAIA8AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5Q UAQADAABAAAAAQAAAAAAAAAFAAAACwLI+2D6BQAAAAwCagg6CwgAAAD6AgUAAQAAAAAAAAAEAAAA LQEAAAcAAAD8AgAA////AAAABAAAAC0BAQAFAAAACQL///8CBQAAAAQBDQAAAAcAAAAbBDoEogXI +2D6HAAAAPsCUP8AAAAAAACQAQAAAAAAAAASVGltZXMgTmV3IFJvbWFuAGt+7XfAV+93mgYKBwAA CgAEAAAALQECAAUAAAAuARgAAAAFAAAACgIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgEB AAAAGQAAADIKgf9B/gwAAABJUFAgUHJvdG9jb2w7AGIAYgAsAGIAOgBYADEAWABOAFgAMQAFAAAA AgECAAAAHAAAAPsCgP8AAAAAAACQAQAAAAAAAAASVGltZXMgTmV3IFJvbWFuAGt+7XfAV+93qwYK cQAACgAEAAAALQEDAAUAAAAuARgAAAAFAAAACgIAAAAABQAAAAkCAAAAAgUAAAAUAuTMLCYFAAAA AgEBAAAALQAAADIKEgEw/RkAAABDaGFuZ2VzIHNpbmNlIEF1Z3VzdCBJRVRGAFYAQAA4AEAAQAA5 ADIAIAAyACMAQAA5ADkAIABdAEAAQABAADEAJAAgACsATgBOAEcABQAAAAIBAgAAAA8AAAAmBg8A FABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAQAAAAtAQAABwAAAPwCAQAA AAAAAAAEAAAALQEEAAQAAADwAQEAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAHeZBmYN BwCKAQAACgAGAAAABwCKAQAACgAEAAAALQEBAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAA//////////84AAIA//////////////////////////////////////////8A AAAAAAAAAAAAAAAAAAAAZQAAAAAQAAD/////VABlAHgAdABfAEMAbwBuAHQAZQBuAHQAAAD///// /////////////////////////////////////////////xoAAgAHAAAAAwAAAP////////////// /////////////////wAAAAAAAAAAAAAAAAAAAAABAAAAVgsAAP////9DAHUAcgByAGUAbgB0ACAA VQBzAGUAcgAAAP//////////////////////////////////////////////////GgACAP////// ////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAC8AAAAHAAAA/////0gA ZQBhAGQAZQByAAAA//////////////////////////////////////////////////////////// //////8OAAIB/////wYAAAD///////////////////////////////8AAAAAAAAAAAAAAAAAAAAA MAAAADkAAAD//////v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4w AAAAoAIAAAsAAAABAAAAYAAAAAMAAABoAAAABAAAAIAAAAAGAAAAiAAAAAcAAACQAAAACAAAAJgA AAAJAAAAoAAAAAsAAACoAAAAEAAAALAAAAANAAAAuAAAAAwAAAA+AgAAAgAAAOQEAAAeAAAADwAA AE9uLXNjcmVlbiBTaG93AAADAAAAwq8AAAMAAABJAAAAAwAAAA4AAAADAAAAAAAAAAMAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAARAAAABgAAAEFyaWFsABAAAABUaW1lcyBOZXcgUm9tYW4AFwAA AEJsYW5rIFByZXNlbnRhdGlvbi5wb3QADQAAAElQUCBQcm90b2NvbAASAAAAQXR0cmlidXRlcyBH cm91cHMAFwAAAEVtcHR5IEF0dHJpYnV0ZSBHcm91cHMAHwAAAEV4dGVuc2liaWxpdHkgZm9yIFVu a25vd24gVGFncwARAAAAT3BlcmF0aW9uIFRhcmdldAAZAAAATG9jYWxpemVkIFRleHQgYW5kIE5h bWVzAAsAAABSZXF1ZXN0IElkAAkAAABTZWN1cml0eQAOAAAATWlub3IgY2hhbmdlcwAcAAAATWFw cGluZyBiZXR3ZWVuIExQRCBhbmQgSVBQABgAAABDaGFuZ2UgdG8gSW5mb3JtYXRpb25hbAASAAAA QXR0cmlidXRlIENoYW5nZXMAFwAAAE1vcmUgQXR0cmlidXRlIENoYW5nZXMADwAAAEF1dGhlbnRp Y2F0aW9uAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAACAAAAHgAAABAAAABEZXNpZ24g VGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAADgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGJ1dGUgZ3JvdXAgdGFnIHdpdGggbm8gZm9sbG93aW5nIGF0dHJpYnV0ZXMNZXhwZWN0ZWQg YnV0IG1pc3NpbmcgYXR0cmlidXRlIHRhZw0NRXh0ZW5zaWJpbGl0eSBmb3IgVW5rbm93biBUYWdz DQ1Vbmtub3duIHRhZ3MgZmFsbCBpbnRvIHR3byBjYXRlZ29yaWVzOg1kZWxpbWl0ZXIgdGFnLCAw LTB4ZjogYmVnaW5uaW5nIG9mIGF0dHJpYnV0ZSBncm91cA12YWx1ZSB0YWcsIDB4MTAtMHhmZjog c2luZ2xlIHZhbHVlDUFsbG93cyB0aGUgcmVjZWl2ZXIgb2YgYSByZXF1ZXN0IG9yIHJlc3BvbnNl IHRvIHNraXAgYWxsIGF0dHJpYnV0ZXMgaW4gYW4gdW5rbm93biBncm91cC4NDU9wZXJhdGlvbiBU YXJnZXQNDVByaW50ZXItdXJpIGFuZCBqb2ItdXJpIHRhcmdldCBvZiBvcGVyYXRpb24NbXVzdCBi ZSBvbiBIVFRQIHJlcXVlc3QgbGluZQ1tYXkgYWxzbyBiZSBpbiBvcGVyYXRpb24gYXR0cmlidXRl cyANSm9iIG9wZXJhdGlvbnMgbXVzdCBiZSBzdXBwb3J0ZWQgd2l0aCBib3RoDWpvYi11cmkgdGFy Z2V0IA1wcmludGVyLXVyaSB0YXJnZXQgd2l0aCBqb2ItaWQgYXR0cmlidXRlDUNyZWF0ZSBqb2Ig b3BlcmF0aW9uIHJldHVybnMgam9iLXVyaSBhbmQgam9iLWlkDQ1Mb2NhbGl6ZWQgVGV4dCBhbmQg TmFtZXMNDVRoZSBuYXR1cmFsIGxhbmd1YWdlIGFzc29jaWF0ZWQgd2l0aCBUZXh0IGFuZCBOYW1l IHZhbHVlcyBtYXkgZGlmZmVyIGZyb20gdGhlIG5hdHVyYWwtbGFuZ3VhZ2Ugb2YgdGhlIG9wZXJh dGlvbi4NdHJpZWQgYW5kIHJlamVjdGVkIHNldmVyYWwgZGlmZmVyZW50IHNvbHV0aW9ucw1zZXR0 bGVkIG9uIHR3byBuZXcgdHlwZXM6IA1sb2NhbGl6ZWQtdGV4dCBhbmQgbG9jYWxpemVkLW5hbWUN Y29uc2lzdHMgb2YgYW4gb2N0ZXQgc3RyaW5nIHdpdGggNCBmaWVsZHM6CyAgICAgbGVuZ3RoICBu YXR1cmFsLWxhbmd1YWdlIGxlbmd0aCB0ZXh0L25hbWUNDVJlcXVlc3QgSWQNDVJlcXVlc3QgSWQg YWRkZWQgdG8gYWxsIHJlcXVlc3RzIGFuZCByZXBvbnNlcw1zZXJ2ZXIgcmV0dXJucyByZWNlaXZl ZCByZXF1ZXN0LWlkIGluIHJlc3BvbnNlDWNsaWVudCBtYXkgbWF0Y2ggcmVzcG9uc2VzIHdpdGgg cmVxdWVzdHMNDVNlY3VyaXR5DQ1BIHNlY3VyZSBJUFAgaW1wbGVtZW5hdGlvbiBtdXN0IHVzZSBU TFMNSVBQIGltcGxlbWVuYXRpb25zIGNhbiBhbHNvIHVzZSBzZWN1cml0eSBtZWNoYW5pc21zIGRl ZmluZWQgYnkgSFRUUC8xLjEgW3JmYyAyMDY4XSBhbmQgZXh0ZW5zaW9ucyBbcmZjIDIwNjldLg0N TWlub3IgY2hhbmdlcw0NUmVuYW1lZCCRZGF0YS10YWeSIHRvIJFlbmQtb2YtYXR0cmlidXRlcy10 YWeSDUFkZGVkIG5ldyBvdXQtb2YtYmFuZCB2YWx1ZXM6IA1uby12YWx1ZSANdW5rbm93bg1EZWZp bml0aW9uIG9mIHN0YXR1cyBjb2RlcyBhbmQgb3BlcmF0aW9ucyBtb3ZlZCB0byBtb2RlbCBkb2N1 bWVudA0NTWFwcGluZyBiZXR3ZWVuIExQRCBhbmQgSVBQDQ1DaGFuZ2VzIHNpbmNlIEF1Z3VzdCBJ RVRGDQ1DaGFuZ2UgdG8gSW5mb3JtYXRpb25hbA0Nk1RoaXMgZG9jdW1lbnQgaXMgYW4gaW5mb3Jt YXRpb25hbCBkb2N1bWVudCB0aGF0IGlzIG5vdCBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrLiAgSXQg aXMgaW50ZW5kZWQgdG8gaGVscCBpbXBsZW1lbnRvcnMgb2YgZ2F0ZXdheXMgYmV0d2VlbiBJUFAg YW5kIExQRC4gIEl0IGFsc28gcHJvdmlkZXMgYW4gZXhhbXBsZSwgIHdoaWNoIGdpdmVzIGFkZGl0 aW9uYWwgaW5zaWdodCBpbnRvIElQUC6UDQ1BdHRyaWJ1dGUgQ2hhbmdlcw0Nam9iLWlkIGJyb3Vn aHQgYmFjaw1ub3cgYm90aCBqb2ItaWQgYW5kIGpvYi11cmkgYXJlIGF2YWlsYWJsZQ1zaW1wbGlm aWVzIGltcGxlbWVudGF0aW9uIHdpdGggam9iLWlkIHdoaWNoIGNhbiBiZSB0aGUgc2FtZSBhcyBM UEQgam9iIG51bWJlcg1qb2Itb3JpZ2luYXRpbmctaG9zdCBubyBsb25nZXIgYXZhaWxhYmxlLiAN SVBQLXRvLUxQRCBtdXN0IHVzZSBzb21lIG90aGVyIG1lYW5zIHRvIHN1cHBseSB0aGUgkUiSICho b3N0KSBwYXJhbWV0ZXIuDQ1Nb3JlIEF0dHJpYnV0ZSBDaGFuZ2VzDQ1Kb2Itay1vY3RldHMgY2xh cmllZCBhcyBub3QgY29udGFpbmluZyBjb3BpZXMNZmlsZSBzaXplIGluIGxwcSBkb2VzIGNvbnRh aW4gY29waWVzDUlQUCBub3RpZmljYXRpb24gZ29uZQ1jYW5ub3Qgc3VwcG9ydCBMUEQgZW1haWwg bm90aWZpY2F0aW9uDWRvY3VtZW50IGZvcm1hdHMgY29udmVyc2lvbiBpcyBkaWZmZXJlbnQNYXJl IG1pbWUgbWVkaWEgdHlwZXMgbm93DXdlcmUgZW51bXMNDUF1dGhlbnRpY2F0aW9uDQ1uZXcgYXR0 cmlidXRlOiBqb2Itb3JnaW5hdGluZy11c2VyLW5hbWUgDXdhcyBqb2Itb3JnaW5hdGluZy11c2Vy DWV4cGxpY2l0bHkgaG9sZHMgYSBodW1hbiByZWFkYWJsZSBuYW1lDXZhbHVlIGNvbWVzIGZyb20g DWF1dGhlbnRpY2F0aW9uIGFuZCANb3BlcmF0aW9uIGF0dHJpYnV0ZTogcmVxdWVzdGluZy11c2Vy LW5hbWUNDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAABDU0cA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABN aWNyb3NvZnQgKFIpIFBvd2VyUG9pbnQgKFIpIFdpbmRvd3MgIAAHAAAA8AMAAF/AkeMBAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --=====================_884231981==_ Content-Type: application/rtf; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IETF40-Model.rtf" {\rtf1\ansi\ansicpg1252\uc1= \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\pan= ose 02020603050405020304}Times New= Roman;}{\f2\fmodern\fcharset0\fprq1{\*\panose 02070309020205020404}Courier= New;}}{\colortbl;\red0\green0\blue0; \red0\green0\blue255;\red0\green255\blue255;\red0\green255\blue0;\red255\gre= en0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blu= e255;\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red12= 8\green0\blue128; \red128\green0\blue0;\red128\green128\blue0;\red128\green128\blue128;\red192= \green192\blue192;}{\stylesheet{\nowidctlpar\widctlpar\adjustright= \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph= Font;}{\s15\nowidctlpar\widctlpar \tqc\tx4320\tqr\tx8640\adjustright \fs20\cgrid \sbasedon0 \snext15= header;}{\s16\nowidctlpar\widctlpar\tqc\tx4320\tqr\tx8640\adjustright= \fs20\cgrid \sbasedon0 \snext16 footer;}{\*\cs17 \additive \sbasedon10 page= number;}}{\info {\title IPP Minutes, 11/7/96}{\author Don Wright}{\operator Scott A.= Isaacson}{\creatim\yr1998\mo1\dy6\hr13\min9}{\revtim\yr1998\mo1\dy6\hr13\mi= n9}{\printim\yr1997\mo12\dy9\hr21\min48}{\version2}{\edmins0}{\nofpages5}{\n= ofwords266}{\nofchars1520} {\*\company Lexmark= International}{\nofcharsws1866}{\vern71}}\paperw15840\paperh12240\margl1440= \margr1440\margt1800\margb1800= \widowctrl\ftnbj\aenddoc\lytprtmet\formshade\viewkind1\viewscale70\viewzk2\= pgbrdrhead\pgbrdrfoot \fet0\sectd= \lndscpsxn\psz1\linex0\endnhere\sectdefaultcl {\header \pard\plain= \s15\nowidctlpar\widctlpar\brdrb\brdrs\brdrw30\brsp20= \tqc\tx6480\tqr\tx12960\adjustright \fs20\cgrid {\f2\fs18 \tab IPP Model= and Semantics Final Call Issues\tab \par }}{\footer \pard\plain= \s16\nowidctlpar\widctlpar\brdrt\brdrs\brdrw30\brsp20= \tqc\tx6480\tqr\tx12960\adjustright \fs20\cgrid {\f2\fs18 IETF IPP WG\tab= 12/10/97\tab }{\field{\*\fldinst {\cs17 PAGE }}{\fldrslt {\cs17\lang1024= 1}}}{\f2\fs18 \par }}{\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta= .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta= .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta= .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta= )}} {\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta= )}}{\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta= )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta= )}}{\*\pnseclvl8 \pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta= )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta= )}}\pard\plain \nowidctlpar\widctlpar\adjustright \fs20\cgrid {\b\fs48 1.= Versioning rules: \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - Mandate= common encoding across all versions \par - Ignore new elements for minor versions \par - New major versions indicate support requirements \par \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 2. Allow empty= attribute groups \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - Be= conservative in what is sent \par }\pard \li720\nowidctlpar\widctlpar\adjustright {\b\fs48 - Be liberal= (forgiving) in what is accepted. \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \par 3. ALL operations MAY return "Unsupported Attributes" \par \par 4. Define protocol upper bounds for \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - URIs,= charsets, natural language identifiers, etc. \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \par \par 5. MUST implement requirements for text and name strings \par \tab - Some strings 63 octets, others 127, other 1023 \par \par 6. Clarified validation checks for operation processing \par \par 7. Non-secure implementations \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - Client= supplied "requesting-user-name" \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \tab - If not,= Printer generates a name (NEED NOT be unique) \par \par 8. Removed "copies-collated" attributes \par \par 9. Identified source(s) for text and name attributes \par \tab - end user, device vendor, operator, administrator \par \tab - allow any natural language for non-generated strings \par \tab - "generated-natural-language-supported" \par 10. Keep "charset-supported" \par \par 11. Clarified semantics of "page-range" attribute \par \par 12. Media attributes \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - If support= "media-default" then MANDATORY \par - If support "media-supported" then MANDATORY \par - If support "media-ready" then OPTIONAL \par \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \par 13. Added missing status codes \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 -= "server-error-not-accepting-jobs" \par }\pard \li720\nowidctlpar\widctlpar\adjustright {\b\fs48 -= "server-error-version-not-supported" \par \par \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 14. Note that IPP is= already aligned with \par \par 15. Made "application/ipp" a "common usage" MIME type \par }\pard \fi720\nowidctlpar\widctlpar\adjustright {\b\fs48 - added= "request ID" for other transports (SMTP) \par - "application/ipp" is self-contained \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \par 16. Security: \par \tab - Allow for "non-secure" \par \tab - If security, then TLS \par }\pard \fi720\li720\nowidctlpar\widctlpar\adjustright {\b\fs48 mutual= authentication \par secure channel \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \tab - For HTTP/1.1= mapping \par }\pard \fi720\li720\nowidctlpar\widctlpar\adjustright {\b\fs48 mandate= only what HTTP/1.1 mandates \par }\pard \nowidctlpar\widctlpar\adjustright {\b\fs48 \par 17. Provide input to SRVLOC Printer Scheme I-D \par \par 18. Register SNMP document formats as MIME media types \par \par 19. Register "application/ipp as MIME media type \par }} --=====================_884231981==_ Content-Type: text/plain; charset="us-ascii" Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com --=====================_884231981==_-- From ipp-owner@pwg.org Wed Jan 7 20:58:01 1998 Delivery-Date: Wed, 07 Jan 1998 20:58:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA08613 for ; Wed, 7 Jan 1998 20:58:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12295 for ; Wed, 7 Jan 1998 21:00:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA03307 for ; Wed, 7 Jan 1998 20:57:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 20:39:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27290 for ipp-outgoing; Wed, 7 Jan 1998 18:54:32 -0500 (EST) Message-Id: <3.0.1.32.19980107155202.0098f880@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 15:52:02 PST To: ipp@pwg.org From: EKR (by way of Carl-Uno Manros ) Subject: IPP> Re: URI scheme and port numbers for TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, This is first reply I got back on my enquiry to the TLS DL. Carl-Uno EKR writes: Carl-Uno Mamros writes: > It seems that the overall TLS draft specification (version 5) is silent on > TLS's use of schemes and port numbers apart from discussing in Annex E that > TLS might share the "https" scheme and port 443 with SSL3, when both are > supported. That was my intention. Since TLS/SSL3 implementations can transparently negotiate a common protocol, this seems ok--and it avoids further proliferation of ports. Anyone have other opinions. It's important to distinguish between the two HTTP/TLS drafts in progress. The one that I'm working on describes current practice for HTTP over SSL, extending it to TLS. I understand that Rohit Khare is working on a draft that allows (the more principled thing) HTTP implementations to negotiate to HTTP/TLS over the common HTTP port. Everything in this message, then, refers to the draft that I'm working on. > The same question goes for the use of port numbers. E.g. should you still > use port 80 for the combination of HTTP and TLS (Annex E seems to suggest > that you use port 443 as for SSL3)? That's current practice. > Do you see any reasons to allocate new schemes and/or port numbers for IPP > (differently from HTTP) when using HTTP as transport? I'm not very familiar with IPP. If IPP runs over HTTP, you should be able to use the same port numbers. > BTW, how is the draft on a TLS profile for HTTP coming along? I've got a rough draft. There turn out to be some issues that impact TLS in general, that I'd like to to iron out before sending it off. -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From ipp-owner@pwg.org Wed Jan 7 21:07:22 1998 Delivery-Date: Wed, 07 Jan 1998 21:07:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA08658 for ; Wed, 7 Jan 1998 21:07:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12314 for ; Wed, 7 Jan 1998 21:10:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA03834 for ; Wed, 7 Jan 1998 21:07:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 20:46:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28378 for ipp-outgoing; Wed, 7 Jan 1998 19:07:49 -0500 (EST) Message-Id: <3.0.1.32.19980107150020.00cd59b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 15:00:20 PST To: (Scott Isaacson) From: Tom Hastings Subject: IPP> MOD - RESEND: Suggested simplified IANA Considerations Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_884242820==_" Sender: ipp-owner@pwg.org --=====================_884242820==_ Content-Type: text/plain; charset="us-ascii" Here is the header for the IANA document: INTERNET-DRAFT Thomas Narten IBM Harald Tveit Alvestrand UNINETT November 21, 1997 Guidelines for Writing an IANA Considerations Section in RFCs Here is the resend of the original mail, including posting of the .doc (WORD6 so you'll need to fix up any cross references) and the .pdf versions: X-Sender: hastings@garfield Date: Fri, 19 Dec 1997 14:32:19 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Suggested simplification of IANA Considerations Sender: ipp-owner@pwg.org Here is my action item on the Model Section 6 IANA Considerations. I've consulted with Bob Herriot and Carl-Uno on these proposed simplfications. Please send any comments immediately. I re-read the new IANA Considerations document (draft-iesg-iana-considerations-01.txt) and see that we should make the following changes in order not to hold up IPP in the IESG: 1. The model needs to assign IPP Subject Matter Experts by name, not position. 2. The document suggests chairs, so I've talked to Carl-Uno and he suggests that Carl-Uno and Steve should be the IPP Subject Matter Experts. 3. The model needs to say who can find a replacement and suggests the A-Ds, so I've added that and included that the PWG can change them too. 4. The model needs to say who maintains each entry. Type 2 should be the PWG, type 3 should be the proposer. 5. Don't have IANA have to assign type 3 keywords and enums, lets have the Subject Matter Experts do it. So all IANA has to do for type 2 and type 3 is keep the approved registrations (the document recommends delegation). This is what we have done for the Printer MIB "printer language" registrations (document formats). Here is the complete new text for section 6. (only 6.1 has changed). I've also posted a .doc (WORD 6) and a .pdf file to show the revisions: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.pdf 6. IANA Considerations (registered and private extensions) This section describes how IPP can be extended. 6.1 Typed Extensions IPP allows for "keyword" and "enum" extensions (see sections 4.1.5 and 4.1.6). In reviewing proposals for such extensions, the IPP Subject Matter Experts are: Carl-Uno Manros (manros@cp10.es.xerox.com) and Steve Zilles (szilles@Adobe.com). If a replacement is needed, the IESG Applications Area Director, in consultation with the PWG [PWG] using pwg@pwg.org, SHALL appoint a replacement. The PWG can also specify a replacement at any time. This document uses prefixes to the "keyword" and "enum" basic syntax type in order to communicate extra information to the reader through its name. This extra information need not be represented in an implementation because it is unimportant to a client or Printer. The list below describes the prefixes and their meaning. "type1": The IPP standard must be revised to add a new keyword or a new enum. No private keywords or enums are allowed. "type2": Implementers can, at any time, add new keyword or enum values by proposing the specification to: - the IPP working group (IPP WG using ipp@pwg.org) while it is still chartered, or - the Printer Working Group [PWG] using pwg@pwg.org after the IPP working group is disbanded who will review the proposal and work with IANA to register the additional keywords and enums. For enums, the IPP WG or PWG assigns the next available unused number. When a type 2 keyword or enum is approved by the IPP WG or PWG, the PWG becomes the point of contact for any future maintenance that might be required for that registration. IANA keeps the registry of keywords and enums as it does for any registration. "type3": Implementers can, at any time, add new keyword and enum values by submitting the complete specification directly to the IPP Subject Matter Experts. While no IPP working group or Printer Working Group review is required, the IPP Subject Matter Experts may, at their discretion, forward the proposal to the IPP WG or PWG for advice and comment. For enums, the IPP Subject Matter Experts assigns the number for enum values. and keeps the registry of keywords and enums. When a type 3 keyword or enum is approved by IPP Subject Matter Experts, the original proposer becomes the point of contact for any future maintenance that might be required for that registration. IANA keeps the registry of keywords and enums as it does for any registration. "type4": Anyone (system administrators, system integrators, site managers, etc.) can, at any time, add new installation-defined values (keywords, but not enum values) to a local system. Care SHOULD be taken by the implementers to see that keywords do not conflict with other keywords defined by the standard or as defined by the implementing product. There is no registration or approval procedure for type 4 keywords. Note: Attributes with type 4 keywords also allow the 'name' attribute syntax for administrator defined names. Such names are not registered. By definition, each of the four types above assert some sort of registry or review process in order for extensions to be considered valid. Each higher level (1, 2, 3, 4) tends to be decreasingly less stringent than the previous level. Therefore, any typeN value MAY be registered using a process for some typeM where M is less than N, however such registration is NOT REQUIRED. For example, a type4 value MAY be registered in a type 1 manner (by being included in a future version of an IPP specification) however it is NOT REQUIRED. This specification defines keyword and enum values for all of the above types, including type4 keywords. For private (unregistered) keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-" where xxx is the (lowercase) fully qualified company name registered with IANA for use in domain names [RFC1035]. For example, if the company XYZ Corp. had obtained the domain name "XYZ.com", then a private keyword 'abc' would be: 'xyz.com-abc'. Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. Also, the labels in a domain name must follow the rules for ARPANET host names: They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Labels must be 63 characters or less. Labels are separated by the "." character. For private (unregistered) enum extension, implementers SHALL use values in the reserved integer range which is 2**30 to 2**31-1. 6.2 Registration of MIME types/sub-types for document-formats The "document-format" attribute's syntax is 'mimeMediaType'. This means that valid values are Internet Media Types. RFC 2045 [RFC2045] defines the syntax for valid Internet media types. IANA is the registry for all Internet media types. 6.3 Attribute Extensibility Attribute names are type2 keywords. Therefore, new attributes may be registered and have the same status as attributes in this document by following the type2 extension rules. 6.4 Attribute Syntax Extensibility Attribute syntaxes are like type2 enums. Therefore, new attribute syntaxes may be registered and have the same status as attribute syntaxes in this document by following the type2 extension rules. The value codes that identify each of the attribute syntaxes are assigned in the protocol specification [IPP-PRO]. --=====================_884242820==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-iesg-iana-considerations-01.txt" INTERNET-DRAFT Thomas Narten = IBM Harald Tveit Alvestrand UNINETT November 21, 1997 Guidelines for Writing an IANA Considerations Section in RFCs 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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. This Internet Draft expires May 21, 1998. Abstract Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., a new option type in DHCP). To insure that such quantities have unique values, their assignment must be administered by a central authority. In the Internet, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given numbering space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a numbering space, the IANA must be given clear and= concise draft-iesg-iana-considerations-01.txt [Page= 1] =0C INTERNET-DRAFT November 21, 1997 instructions describing that role. This document discusses issues that should be considered in formulating an identifier assignment policy and provides guidelines to document authors on the specific text that must be included in documents that place demands on the = IANA. draft-iesg-iana-considerations-01.txt [Page= 2] =0C INTERNET-DRAFT November 21, 1997 Contents Status of this Memo.......................................... 1 1. Introduction............................................. 3 2. Issues To Consider....................................... 4 3. Registration maintenance................................. 6 4. What To Put In Documents................................. 6 5. Security Considerations.................................. 8 6. References............................................... 8 7. Acknowledgements......................................... 9 8. Authors' Addresses....................................... 9 1. Introduction Many protocols make use of fields that contain constants and other well-known values (e.g., the Protocol field in the IP header [IP] or MIME types in mail messages [MIME-REG]). Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., a new option type in DHCP [DHCP]). To insure that such fields have unique values, their assignment must be administered by a central authority. In the Internet, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given numbering space prudently, it needs guidelines describing the conditions under which new values should be assigned. This document provides guidelines to authors on what sort of text should be added to their documents, and reviews issues that should be considered in formulating an appropriate policy for assigning identifiers. Not all name spaces require centralized administration. In some cases, it is possible to delegate a name space in such a way that further assignments can be made independently and with no further (central) coordination. In the Domain Name System, for example, the IANA only deals with assignments at the higher-levels, while subdomains are administered by the organization to which the space has been delegated. As another example, Object Identifiers (OIDs) as defined by the ITU are also delegated [ASSIGNED]. When a name space can be delegated, the IANA only deals with assignments at the= top draft-iesg-iana-considerations-01.txt [Page= 3] =0C INTERNET-DRAFT November 21, 1997 level. 2. Issues To Consider The primary issue to consider in managing a numbering space is its size. If the space is small and limited in size, assignments must be made carefully to insure that the space doesn't become exhausted. If the space is essentially unlimited, on the other hand, it may be perfectly reasonable to hand out new values to anyone that wants one. Even when the space is essentially unlimited, however, it is usually desirable to have a minimal review to prevent hoarding of the space. For example, if the space consists of text strings, it may be desirable to prevent organizations from obtaining large sets of strings that correspond to the "best" names (e.g., existing company names). A second consideration is whether it makes sense to delegate the name space in some manner. This route should be pursued when appropriate, as it lessens the burden on the IANA for dealing with assignments. In most cases, some review of prospective allocations is appropriate, and the first question to answer is who should perform the review. In some cases, reviewing requests is straightforward and requires no subject subjective decision making. On those cases, it is reasonable for the IANA to review prospective assignments, provided that the IANA is given specific guidelines on what types of requests it should grant, and what information must be provided before a request of an assigned number will be considered. Note that the IANA will not define an assignment policy; it should be given a set of guidelines that allow it to make allocation decisions with little subjectivity. The following are example policies, some of which are in use today: Free For All - For local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability. Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. Hierarchical allocation - Delegated managers can assign identifiers provided they have been given control over that part of the identifier space. IANA controls the higher levels of the namespace according to one of the other policies. draft-iesg-iana-considerations-01.txt [Page= 4] =0C INTERNET-DRAFT November 21, 1997 Examples: DNS names, Object Identifiers First Come First Served - Anyone can obtain an identifier, so long as they provide a point of contact and a brief description of what the identifier would be used for. For numbers, the exact value is generally assigned by the IANA, with names, specific names are usually requested. Examples: vnd. MIME types [MIME-REG], TCP and UDP port numbers. Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Examples: SCSP [SCSP] IESG Action - IESG must explicitly approve new values. Examples: SMTP extensions [SMTP-EXT] Standards Action - Only identifiers that have been documented in standards track RFCs approved by the IESG will be registered. Examples: MIME top level types [MIME-REG] In some cases, it may be appropriate for the IANA to serve as a point-of-contact for publishing information about numbers that have been assigned, without actually having it evaluate and grant requests. For example, it is useful (and sometimes necessary) to discuss proposed additions on a mailing list dedicated to the purpose (e.g., the ietf-types@iana.org for media types) or on a more general mailing list on which (e.g., that of a current or former IETF Working Group). Such a mailing list may serve to give new registrations a public review before getting registered, or give advice for persons who want help in understanding what a proper registration should contain. Since the IANA cannot participate in all of these mailing lists and cannot determine if or when such discussion reaches a consensus, the IANA will rely on a designated subject matter expert to advise it in these matters. That is, the IANA must be directed to forward the requests it receives to a specific point-of-contact (one or a small number of individuals) and act upon the returned recommendation from the designated subject matter expert. In all cases, it is= the draft-iesg-iana-considerations-01.txt [Page= 5] =0C INTERNET-DRAFT November 21, 1997 designated subject matter expert that the IANA relies on for an authoritative response. In those cases where wide review of a request is needed, it is the responsibility of the designated subject matter expert to initiate such a review (e.g., by engaging the relevant mailing lists). In no cases will the IANA allow general mailing lists (e.g., that of a former or existing IETF Working Group) to fill the role of the designated subject matter expert. In some cases, it makes sense to partition the number space into several categories, with assignments out of each category handled differently. For example, the DHCP option space [DHCP] is split into two parts. Option numbers in the range of 1-127 are globally unique and assigned according to the Specification Required policy described earlier, while options number 128-254 are "site specific", i.e., Free For All. 3. Registration maintenance Registrations sometimes contain information that needs to be maintained; in particular, point of contact information may need to be changed, claims of freedom from security problems may need to be modified, or new versions of a registration may need to be published. A document must clearly state who is responsible for such maintenance. It is appropriate to: - Let the author update the registration, subject to the same constraints and review as with new registrations - Allow some mechanism to attach comments to the registration, for cases where others have significant objections to claims in a registration, but the author does not agree to change the registration. - Designate the IESG or another authority as having the right to reassign ownership of a registration. This is mainly to get around the problem when some registration owner cannot be reached in order to make necessary updates. 4. What To Put In Documents The previous section presented some issues that should be considered in formulating a policy for assigning well-known numbers and other protocol constants. It is the Working Group and/or document author's job to formulate an appropriate policy and specify it in the appropriate document. In some cases, having an "IANA= Considerations" draft-iesg-iana-considerations-01.txt [Page= 6] =0C INTERNET-DRAFT November 21, 1997 section may be appropriate. Such a section should state clearly: - who reviews an application for an assigned number. If a request should be reviewed by a designated subject matter expert, contact information must be provided. - who has authority to replace the designated subject matter expert, should a replacement be needed (e.g., if multiple attempts to reach the designated subject matter fail). The specific procedure to appoint the person should also be indicated; it may often be appropriate to let the relevant IESG Area Director designate the subject matter expert when a replacement is necessary. - If the request should also be reviewed by a specific public mailing list (such as the ietf-types@iana.org for media types), that mailing address should be specified. Note, however, that a designated subject matter expert must also be specified. - if the IANA is expected to review requests itself, sufficient guidance must be provided so that the requests can be evaluated with minimal subjectivity. It should also be noted that the following are unacceptable: - listing a Working Group mailing list as the designated subject matter expert - specifying that "the current Working Group Chairs of the FooBar Workin Group" are the designated subject matter experts, since Working Groups eventually close down. However, it is acceptable to list the current WG Chairs individually. Finally, it is quite acceptable to pick one of the example policies cited above and refer to it by name. For example, a document could say something like: numbers are allocated as First Come First Served as defined in [IANA-CONSIDERATIONS] For examples of documents that provide good and detailed guidance to the IANA on the issue of assigning identifiers, consult [MIME-REG, MIME-LANG]. draft-iesg-iana-considerations-01.txt [Page= 7] =0C INTERNET-DRAFT November 21,= 1997 5. Security Considerations Information that creates or updates a registration needs to be authenticated. Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered protocol may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing registrations, so that users are not mislead as to the true security properties of a registered protocol. An analysis of security issues is required for for all types registered in the IETF Tree [MIME-REG]. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues must be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this type" must not be confused with "the security issues associated with this type have not been assessed". Delegations of a name space should only be assigned to someone with adequate security. 6. References [ASSIGNED] Reynolds, J., Postel, J., "Assigned Numbers", October 1994k, RFC 1700. [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP Vendor Extensions, RFC 2132, March 1997. [IANA-CONSIDERATIONS] Alvestrand, H., Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", draft- iesg-iana-considerations-01.txt. [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981. [MIME-LANG] Freed, N., Moore, K., "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August, 1997. [MIME-REG] N. Freed, J. Klensin & J. Postel, Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures. RFC 2048, November,= 1996. draft-iesg-iana-considerations-01.txt [Page= 8] =0C INTERNET-DRAFT November 21, 1997 [SCSP] Luciani, J., Armitage, G, Halpern, J., "Server Cache Synchronization Protocol (SCSP)" draft-ietf-ion-scsp- 02.txt. [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.. "SMTP Service Extensions", RFC 1869, November 1995. 7. Acknowledgements Jon Postel and Joyce Reynolds provided a detailed explanation on what the IANA needs in order to manage assignments efficiently. Brian Carpenter provided helpful comments on earlier versions of the document. One paragraph in the Security Considerations section was borrowed from [MIME-REG]. 8. Authors' Addresses Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: narten@raleigh.ibm.com Harald Tveit Alvestrand UNINETT P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY Phone: +47 73 59 70 94 EMail:= Harald.T.Alvestrand@uninett.no draft-iesg-iana-considerations-01.txt [Page 9] =0C --=====================_884242820==_-- From ipp-owner@pwg.org Wed Jan 7 21:30:17 1998 Delivery-Date: Wed, 07 Jan 1998 21:30:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA08784 for ; Wed, 7 Jan 1998 21:30:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12358 for ; Wed, 7 Jan 1998 21:33:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05537 for ; Wed, 7 Jan 1998 21:30:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 21:18:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00754 for ipp-outgoing; Wed, 7 Jan 1998 19:58:53 -0500 (EST) Message-Id: <3.0.1.32.19980107165345.00ffd1d0@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 16:53:45 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Definition for 'reverse-portrait' enum value Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Here is my action item from the telecon today to propose the definition for the new enum value of the renamed "orientation-requested" attribute: 'reverse-portrait', including a note as to why. 1. We agreed today to rename "orientation" to "orientation-requested", since this Job Template attribute is requesting the IPP Printer to format the text/plain documents, rather than declaring how the document had been formatted by the creator software. 2. Previous e-mail suggested renumbering starting with '3' for compatibility with the PWG MIB conventions, where we can't use '0', use '1' for 'other', and '2' for 'unknown'. 3. I also added: when the IPP Printer performs the formatting to the end of the description. At the end of this e-mail message, I've put a copy of the current text for reference. Proposed new text: 4.2.10 orientation-requested (type2 enum) This attribute specifies the orientation of the content of the print-stream pages to be printed. In most cases, the orientation of the content is specified within the document format generated by the device driver at print time. However, some document formats (such as 'text/plain') do not support the notion of page orientation, and it is possible to bind the orientation after the document content has been generated. This attribute provides an end user with the means to specify orientation for such documents when the IPP Printer performs the formatting. Standard values are: Value Symbolic Name and Description '3' 'portrait': The content will be imaged across the short edge of the medium. '4' 'landscape': The content will be imaged across the long edge of the medium. Landscape is defined to be a rotation of the print-stream page to be imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from the portrait orientation. Note: The +90 direction was chosen because simple finishing on the long edge is the same edge whether portrait or landscape '5' 'reverse-landscape': The content will be imaged across the long edge of the medium. Reverse-landscape is defined to be a rotation of the print-stream page to be imaged by -90 degrees with respect to the medium (i.e. clockwise) from the portrait orientation. Note: The 'reverse-landscape' value was added because some applications rotate landscape -90 degrees from portrait, rather than +90 degrees. '6' 'reverse-portrait': The content will be imaged across the short edge of the medium. Reverse-portrait is defined to be a rotation of the print-stream page to be imaged by 180 degrees with respect to the medium from the portrait orientation. Note: The 'reverse-portrait value was added for use with the "finishings" attribute in cases where the opposite edge is desired for finishing a portrait document on simple finishing devices that have only one finishing position. Thus a 'text/plain' portrait document can be stapled "on the right" by a simple finishding device as is common for use with some middle eastern languages such as Hebrew. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4 ) and the relationship of this attribute and the other attributes that control document processing is described in section 15.5. Existing text in the 12/19/97 Model document: 4.2.10 orientation (type2 enum) This attribute specifies the orientation of the content of the print-stream pages to be printed. In most cases, the orientation of the content is specified within the document format generated by the device driver at print time. However, some document formats (such as 'text/plain') do not support the notion of page orientation, and it is possible to bind the orientation after the document content has been generated. This attribute provides an end user with the means to specify orientation for such documents. Standard values are: Value Symbolic Name and Description '1' 'portrait': The content will be imaged across the short edge of the medium. '2' 'landscape': The content will be imaged across the long edge of the medium. Landscape is defined to be a rotation of the print-stream page to be imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from the portrait orientation. Note: The +90 direction was chosen because simple finishing on the long edge is the same edge whether portrait or landscape '3' 'reverse-landscape': The content will be imaged across the long edge of the medium. Reverse-landscape is defined to be a rotation of the print-stream page to be imaged by -90 degrees with respect to the medium (i.e. clockwise) from the portrait orientation. Note: The 'reverse-landscape' value was added because some applications rotate landscape -90 degrees from portrait, rather than +90 degrees. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.5. From ipp-owner@pwg.org Wed Jan 7 21:32:05 1998 Delivery-Date: Wed, 07 Jan 1998 21:32:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA08793 for ; Wed, 7 Jan 1998 21:32:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12371 for ; Wed, 7 Jan 1998 21:34:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05755 for ; Wed, 7 Jan 1998 21:32:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 21:20:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA01512 for ipp-outgoing; Wed, 7 Jan 1998 20:09:04 -0500 (EST) Message-Id: <3.0.1.32.19980107170646.00949c70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 17:06:46 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference - 980107 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference - 980107 Attending: Carl-Uno Manros Steve Zilles Scott Isaacson Roger deBry Bob Herriot Randy Turner Ron Bergman Harry Lewis Tom Hastings Peter Zehler Xavier Riley Ira Mcdonald Main agenda points were to discuss the two remaining IPP issues and to talk about plans for submission to the IESG and the upcoming meeting in Maui. The first issue discussed was whether IPP clients SHOULD or SHALL implement TLS. The decision was to go for SHOULD at this stage, considering the non-availability of TLS software at this stage. This can be upgraded to a SHALL when we move to Draft Standard, at which time everybody should have a better view of foot print, performance degradation, and costs for implementing TLS more widely. The second issue was to discuss how a user (or IPP client) finds out about the availability of TLS on a particular printer. Several proposals had been discussed on the DL, with no clear winner. It was clear that we need to do something about this in our specification as the TLS negotiation does not allow negotiation to not use TLS. Alternatives about letting this be a matter for the Directory and/or the IPP server were discussed. The agreed solution was to resolve the issue by: 1) Removing the printer-tls-uri attribute and instead extend the printer-uri to become a multi-valued attribute and call it printer-uris-supported. This value should be accessible over the Directory as well as stored in the Printer object, so that it can be retrieved with a Get Printer Attributes operation. Printer-uri in its current single value form will still be used as an operational attribute in some of the operations. 2) As we may not be able to reliably determine from the URI sheme if it supports TLS security or not, it was decided to also define a multi-valued "meta-attribute" that would match the entries in the previous attribute, describing whether security was offered by the matching uri in the "printer-uris-supported" attribute. This makes IPP independent of future changes in the use of schemes and port numbers for security. As for the previous attribute, it should appear both in directory entries as well as in the Printer object. Vales for the attribute are in the form of keywords, with the following three values initially: NONE, TLS, SSL3. Having resolved the TLS problem with the solution just described, it was decided that Randy's proposal for redirection within IPP does not neccesarily have to be included in IPP Version 1.0, so this will be left for further discussion beyond the current set of specifications. It should be on the PWG IPP agenda for Maui. Tom Hastings brought up a smaller issue related to media orientation in combination with finishing. It was decided to add another value for orientation to be called "reversed-landscape" and to make some further clarifications in the text. Tom will write up the proposed amended text for this. Some further minor suggestions about atribute name changes and value reallocation were discussed and accepted for the final draft of the Model document. The editors should also check that all references are fully up-to-date and accurate. In the light of succesful resolution of these last issues, it was decided that the editors will all have their final drafts ready and submitted to the IETF secretariat by January 9th. Carl-Uno will notify the IESG that we are ready for their review as soon as all documents are ready. We will have new versions of the Model, Protocol and Rationale documents, the other two documents for Requirements and LPD Mapping are already in their final state. Finally, some discussion of the IPP agenda for Maui was held. The latest status is that Don Wright would like to start off the Wednesday meeting with some general PWG discussions which are not limited to IPP. This might take up to two hours. The rest of the day will be used to start discussing some of the future extensions to IPP. Some of the extension discussions might be carried over to Thursday, with the rest of the day to discuss interoperability and testing. The exact split on Thursday will depend on how many people actually show up for the interoperability and testing subject. Carl-Uno will issue a more detailed agenda for Maui. --- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jan 7 21:33:09 1998 Delivery-Date: Wed, 07 Jan 1998 21:33:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA08804 for ; Wed, 7 Jan 1998 21:33:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12374 for ; Wed, 7 Jan 1998 21:35:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05938 for ; Wed, 7 Jan 1998 21:33:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 21:22:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA01966 for ipp-outgoing; Wed, 7 Jan 1998 20:16:50 -0500 (EST) Message-Id: <3.0.1.32.19980107171155.01018a30@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 7 Jan 1998 17:11:55 PST To: (Scott Isaacson) From: Tom Hastings Subject: IPP> MOD - rename "orienation-xxx" to "orientation-requested-xxx" Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org In our agreement today to rename the "orientation" job template attribute to "orientation-requested", we also need to rename "orientation-default" and "orientation-supported" to "orientation-requested-default" and "orientation-requested-supported". Tom From ipp-owner@pwg.org Wed Jan 7 23:05:25 1998 Delivery-Date: Wed, 07 Jan 1998 23:05:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA15678 for ; Wed, 7 Jan 1998 23:05:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA12489 for ; Wed, 7 Jan 1998 23:08:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA06644 for ; Wed, 7 Jan 1998 23:05:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 Jan 1998 22:59:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06066 for ipp-outgoing; Wed, 7 Jan 1998 22:44:57 -0500 (EST) Content-return: allowed Date: Wed, 07 Jan 1998 07:56:00 -0500 From: "Zehler, Peter " Subject: RE: IPP>TES - January agenda To: Roger K Debry , ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org Roger, I also wonder how fruitful it will be. I doubt we will fill the day with the discussions. However We have to get this rolling. We have to determine what we are going to do about TES. We need to get broad support for a method(s) to achieve our goals. We need to get people to commit. I hope a face to face meeting can get this going now that we have some solid specs to implement. I am ready and available to hold a teleconference on TES. Perhaps we can touch on TES in today's teleconference. Pete -----Original Message----- From: Roger K Debry [SMTP:rdebry@us.ibm.com] Sent: Tuesday, January 06, 1998 8:25 AM To: ipp@pwg.org Subject: IPP>TES - January agenda I wonder how fruitful it will be to devote an entire day to Testing, given the low participation thus far in these discussions. There has not even been any active teleconference sessions recently. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu Jan 8 00:59:59 1998 Delivery-Date: Thu, 08 Jan 1998 01:00:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA16581 for ; Thu, 8 Jan 1998 00:59:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA12602 for ; Thu, 8 Jan 1998 01:02:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA07458 for ; Thu, 8 Jan 1998 00:59:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 00:54:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA06901 for ipp-outgoing; Thu, 8 Jan 1998 00:40:29 -0500 (EST) Message-ID: <34B4119A.E909ACAC@ix.netcom.com> Date: Wed, 07 Jan 1998 23:37:00 +0000 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: ietf-tls@consensus.com CC: Carl-Uno Manros , Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, ipp@pwg.org Subject: IPP> Re: URI scheme and port numbers for TLS References: <199801072234.RAA19988@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Keith and all, Keith Moore wrote: > > Is it assumed that each application that uses TLS uses its own original > > scheme e.g. "http" or should it allocate a new scheme if combined with TLS > > (Annex E seems to suggest that you use "https" as for SSL3)? > > Ideally, a single URL scheme could be used either with or without TLS, > with the authentication and privacy technology to be used negotiated > by the client and server. Client and server should each be > configurable as to which ciphersuites, CAs, etc. are acceptable to > each party. > > In general, neither the scheme name, nor the port number, is > sufficient for such configuration. For instance, "https" (and port > 443) can be used with many different ciphersuites, covering a wide > variety of services and strengths, some of which are unlikely to be > acceptable. While we don't intend to deprecate https/http and the > other dual-port schemes that are widely deployed, neither do we want > to propagate this mechanism to new protocols. Yes, indeed this is a wise policy to persue. > > > > Do you see any reasons to allocate new schemes and/or port numbers for IPP > > (differently from HTTP) when using HTTP as transport? If you think new > > schemes and ports are needed, do we need one for use of IPP without TLS, > > and another set for use with TLS? > > IANA has been requested to not assign any new "SSL" or "TLS" ports. > For new protocols, TLS must either to be explicitly configured > separately from the port number, negotiated in-band (using STARTTLS or > some such), or assumed by default. > > As for IPP: > > + IPP servers listening on port 443 should assume TLS/SSL will > be used when the connection is opened. > IPP clients should use "https:", without overriding the port #, > to indicate they want to talk to an IPP server on port 443. > > + IPP servers listening on other ports, including any port that might > be designated specifically for IPP, should assume that neither TLS > nor SSL is used when the connection is established. TLS or other > security technologies might eventually be used on such servers, > if someone defines a means of negotiating security in-band over > HTTP. Again this is awise approach. In our "Intergration Facility or (MLPI) we provide for this option. > > > IPP clients should specify "http:", perhaps with a port # > (other than 443), to indicate that they want to talk to such servers. > > + If a specific port is to be allocated for IPP, there should be > an "ipp:" URL scheme defined, which defaults to that port. Not necessary if you use and intergration scheam or facility to provide for multipul port configuration. > > > The definition of the ipp: scheme should also define how security > is to be negotiated on that port - whether it defaults to TLS > (perhaps with the possibility of fallback to a null encryption > layer) or whether it uses in-band negotiation. Hummmmm? intresting conclusion or answer. But it would again seem unecessary if integration for IPP on multipul ports using stacked protocols or multi=leyer approach for cyphers. > > > In every case it remains necessary for clients and servers to be > configurable as to which TLS ciphersuites are acceptable. Agreed. But this should not necessarly be a configuration restriction. > > > Keith Regards, From ipp-owner@pwg.org Thu Jan 8 10:14:30 1998 Delivery-Date: Thu, 08 Jan 1998 10:14:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20918 for ; Thu, 8 Jan 1998 10:14:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA13461 for ; Thu, 8 Jan 1998 10:17:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA08938 for ; Thu, 8 Jan 1998 10:14:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 10:05:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08363 for ipp-outgoing; Thu, 8 Jan 1998 09:50:55 -0500 (EST) Message-Id: <199801081450.JAA20066@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-04.txt Date: Thu, 08 Jan 1998 09:50:06 -0500 Sender: ipp-owner@pwg.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-04.txt Pages : 31 Date : 06-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-04.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: <19980106143503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980106143503.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Jan 8 10:27:31 1998 Delivery-Date: Thu, 08 Jan 1998 10:35:19 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA21305 for ietf-123-outbound.10@ietf.org; Thu, 8 Jan 1998 10:27:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA20066; Thu, 8 Jan 1998 09:50:06 -0500 (EST) Message-Id: <199801081450.JAA20066@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-04.txt Date: Thu, 08 Jan 1998 09:50:06 -0500 Sender: cclark@cnri.reston.va.us --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-04.txt Pages : 31 Date : 06-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-04.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: <19980106143503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980106143503.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Jan 8 10:52:19 1998 Delivery-Date: Thu, 08 Jan 1998 11:01:50 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA22042 for ietf-123-outbound.10@ietf.org; Thu, 8 Jan 1998 10:52:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA20028; Thu, 8 Jan 1998 09:49:57 -0500 (EST) Message-Id: <199801081449.JAA20028@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-deflate-01.txt Date: Thu, 08 Jan 1998 09:49:52 -0500 Sender: cclark@cnri.reston.va.us --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 Using DEFLATE Author(s) : R. Pereira Filename : draft-ietf-ippcp-deflate-01.txt Pages : 5 Date : 06-Jan-98 This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. 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-deflate-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-deflate-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-deflate-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980106134944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-deflate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-deflate-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980106134944.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Thu Jan 8 11:21:27 1998 Delivery-Date: Thu, 08 Jan 1998 11:21:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA22615 for ; Thu, 8 Jan 1998 11:21:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA13815 for ; Thu, 8 Jan 1998 11:24:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09649 for ; Thu, 8 Jan 1998 11:21:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 11:17:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09042 for ipp-outgoing; Thu, 8 Jan 1998 11:02:24 -0500 (EST) Content-return: allowed Date: Thu, 8 Jan 1998 07:54:14 PST From: "Zehler, Peter " Subject: IPP> TES meeting PING To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org All, I would like to get an idea of who intends to participate in the TES meeting in Maui on Thursday January 29th. Could you send your ping to Peter.Zehler@usa.xerox.com as soon as possible. Thanks, Pete From ipp-owner@pwg.org Thu Jan 8 14:00:26 1998 Delivery-Date: Thu, 08 Jan 1998 14:00:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA24998 for ; Thu, 8 Jan 1998 14:00:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14387 for ; Thu, 8 Jan 1998 14:03:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10658 for ; Thu, 8 Jan 1998 14:00:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 13:55:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09872 for ipp-outgoing; Thu, 8 Jan 1998 13:38:26 -0500 (EST) Message-Id: <3.0.1.32.19980108073558.010052d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 07:35:58 PST To: Robert.Herriot@eng.sun.com (Robert Herriot), Robert.Herriot@eng.sun.com, rturner@sharplabs.com From: Tom Hastings Subject: Re: IPP>MOD Action Item from LA: fix requesting-user-name explanation [suggest adding Bob's comment as a note for case f] Cc: ipp@pwg.org In-Reply-To: <199712172052.MAA24362@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I suggest adding Bob's comments in answer to Randy's comment on case f as a Note in Section 8.3. Randy said that case f would take a lot explanation. I think that Bob's explanation as a note is just the explanation that is needed. Tom At 12:52 12/17/1997 PST, Robert Herriot wrote: > >> From rturner@sharplabs.com Wed Dec 17 00:38:33 1997 >> >> See my comments on the new proposed >> text below... >> >> Randy >> >> >> Robert Herriot wrote: >> snip... >> > >> > f) the authentication mechanism specifies a user which is special and >> > means that the value of the requesting-user-name, which must be >> > present, is treated as the authenticated name. >> >> I do not think scenario (f) should be included >> in this list. It sounds like a real niche >> case that might take alot of text to explain >> why this is needed. > >Case f) is intended for a tightly coupled gateway and server to work >together so that the "user" name is that of the gateway's client and >not that of the gateway. Because most if not all system vendors will >initially implement IPP via a gateway into their existing print system, >this mechansism is necessary unless the authentication mechanism allows >a gateway (client) to act on behalf of some other client. So I suggest adding Bob's explanation as a note as part of case f (changing "is" to "is able to be": Note: Case f) is intended for a tightly coupled gateway and server to work together so that the "user" name is able to be that of the gateway's client and not that of the gateway. Because most, if not all, system vendors will initially implement IPP via a gateway into their existing print system, this mechansism is necessary unless the authentication mechanism allows a gateway (client) to act on behalf of some other client. From jmp-owner@pwg.org Thu Jan 8 15:33:59 1998 Delivery-Date: Thu, 08 Jan 1998 15:34:00 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26308 for ; Thu, 8 Jan 1998 15:33:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA14817 for ; Thu, 8 Jan 1998 15:36:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11018 for ; Thu, 8 Jan 1998 15:33:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 15:30:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10817 for jmp-outgoing; Thu, 8 Jan 1998 15:28:17 -0500 (EST) Message-Id: <3.0.1.32.19980108122348.01039620@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 12:23:48 PST To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> MOD & JMP - Adding why to join ipp and jmp DLs Cc: pwg@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Both the IPP Model document and the JMP Job Monitoring MIB document list the email DL and how to join, using ipp-request@pwg.org and jmp-request@pwg.org. I'd like to see a sentence added as to why an implementor might want to join the DL. Implementors will find things that need clarification. Also both standards have registration processes for adding additional attributes and values. I've talked with Ron Bergman about this for the Job Monitoring MIB and he thought it was a good idea. How about adding the following sentence right after the mention of the ipp-request@pwg.org and jmp-request@pwg.org in the Author's addresses section: Implementors of this specification are encouraged to join this e-mail distribution list in order to partipate in any discussions of clarification issues and review of registration proposals for additional attributes and values. Comments? Thanks, Tom From pwg-owner@pwg.org Thu Jan 8 15:41:28 1998 Delivery-Date: Thu, 08 Jan 1998 15:41:29 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26588 for ; Thu, 8 Jan 1998 15:41:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA14866 for ; Thu, 8 Jan 1998 15:44:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11409 for ; Thu, 8 Jan 1998 15:41:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 15:35:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10833 for pwg-outgoing; Thu, 8 Jan 1998 15:28:36 -0500 (EST) Message-Id: <3.0.1.32.19980108122348.01039620@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 12:23:48 PST To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: PWG> MOD & JMP - Adding why to join ipp and jmp DLs Cc: pwg@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Both the IPP Model document and the JMP Job Monitoring MIB document list the email DL and how to join, using ipp-request@pwg.org and jmp-request@pwg.org. I'd like to see a sentence added as to why an implementor might want to join the DL. Implementors will find things that need clarification. Also both standards have registration processes for adding additional attributes and values. I've talked with Ron Bergman about this for the Job Monitoring MIB and he thought it was a good idea. How about adding the following sentence right after the mention of the ipp-request@pwg.org and jmp-request@pwg.org in the Author's addresses section: Implementors of this specification are encouraged to join this e-mail distribution list in order to partipate in any discussions of clarification issues and review of registration proposals for additional attributes and values. Comments? Thanks, Tom From ipp-owner@pwg.org Thu Jan 8 15:57:59 1998 Delivery-Date: Thu, 08 Jan 1998 15:57:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26799 for ; Thu, 8 Jan 1998 15:57:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14940 for ; Thu, 8 Jan 1998 16:00:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA12431 for ; Thu, 8 Jan 1998 15:57:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 15:52:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10825 for ipp-outgoing; Thu, 8 Jan 1998 15:28:24 -0500 (EST) Message-Id: <3.0.1.32.19980108122348.01039620@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 12:23:48 PST To: ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> MOD & JMP - Adding why to join ipp and jmp DLs Cc: pwg@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Both the IPP Model document and the JMP Job Monitoring MIB document list the email DL and how to join, using ipp-request@pwg.org and jmp-request@pwg.org. I'd like to see a sentence added as to why an implementor might want to join the DL. Implementors will find things that need clarification. Also both standards have registration processes for adding additional attributes and values. I've talked with Ron Bergman about this for the Job Monitoring MIB and he thought it was a good idea. How about adding the following sentence right after the mention of the ipp-request@pwg.org and jmp-request@pwg.org in the Author's addresses section: Implementors of this specification are encouraged to join this e-mail distribution list in order to partipate in any discussions of clarification issues and review of registration proposals for additional attributes and values. Comments? Thanks, Tom From ipp-owner@pwg.org Thu Jan 8 16:28:47 1998 Delivery-Date: Thu, 08 Jan 1998 16:28:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27137 for ; Thu, 8 Jan 1998 16:28:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15069 for ; Thu, 8 Jan 1998 16:31:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13099 for ; Thu, 8 Jan 1998 16:28:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 16:20:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12261 for ipp-outgoing; Thu, 8 Jan 1998 15:55:56 -0500 (EST) Date: Thu, 8 Jan 1998 12:52:13 PST From: "Chawla,Rajesh" Subject: IPP> Question about rangeOfInteger To: IPP Mailing List Message-id: <613EB5348177687C613EB5348177687C#064#X-CO-2506-MS1.XN@SMF> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Thu, 08 Jan 1998 16:02:17 -0500 Priority: normal Hop-count: 3 Sender: ipp-owner@pwg.org Hi folks, I'm confused about the rangeOfInteger type. The protocol document says that rangeOfInteger should have 2 integers that represent the min and the max. My question is where should the value go? Rajesh From ipp-owner@pwg.org Thu Jan 8 16:37:10 1998 Delivery-Date: Thu, 08 Jan 1998 16:37:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27334 for ; Thu, 8 Jan 1998 16:37:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15101 for ; Thu, 8 Jan 1998 16:39:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13738 for ; Thu, 8 Jan 1998 16:37:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 16:29:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12514 for ipp-outgoing; Thu, 8 Jan 1998 16:04:00 -0500 (EST) From: Carl Kugler To: Cc: , , , Subject: Re: IPP> Re: URI scheme and port numbers for TLS Message-ID: <5030100015898566000002L062*@MHS> Date: Thu, 8 Jan 1998 16:03:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA27334 > IPP clients should use "https:", without overriding the port #, > to indicate they want to talk to an IPP server on port 443. I'm a little confused about what it means for an IPP client to "override the port #". The port is what the client connects to, but as far as I know the number isn't passed in the HTTP or IPP protocols, right? The client has to connect to some port; should it be 443 or 80 in this case? -Carl Kugler ipp-owner@pwg.org 01/07/98 12:03 PM Please respond to ipp-owner@pwg.org @ internet To: cmanros@cp10.es.xerox.com @ internet cc: ipp@pwg.org @ internet, moore@cs.utk.edu @ internet, Harald.T.Alvestrand@uninett.no @ internet, ietf-tls@consensus.com @ internet Subject: IPP> Re: URI scheme and port numbers for TLS > Is it assumed that each application that uses TLS uses its own original > scheme e.g. "http" or should it allocate a new scheme if combined with TLS > (Annex E seems to suggest that you use "https" as for SSL3)? Ideally, a single URL scheme could be used either with or without TLS, with the authentication and privacy technology to be used negotiated by the client and server. Client and server should each be configurable as to which ciphersuites, CAs, etc. are acceptable to each party. In general, neither the scheme name, nor the port number, is sufficient for such configuration. For instance, "https" (and port 443) can be used with many different ciphersuites, covering a wide variety of services and strengths, some of which are unlikely to be acceptable. While we don't intend to deprecate https/http and the other dual-port schemes that are widely deployed, neither do we want to propagate this mechanism to new protocols. > Do you see any reasons to allocate new schemes and/or port numbers for IPP > (differently from HTTP) when using HTTP as transport? If you think new > schemes and ports are needed, do we need one for use of IPP without TLS, > and another set for use with TLS? IANA has been requested to not assign any new "SSL" or "TLS" ports. For new protocols, TLS must either to be explicitly configured separately from the port number, negotiated in-band (using STARTTLS or some such), or assumed by default. As for IPP: + IPP servers listening on port 443 should assume TLS/SSL will be used when the connection is opened. IPP clients should use "https:", without overriding the port #, to indicate they want to talk to an IPP server on port 443. + IPP servers listening on other ports, including any port that might be designated specifically for IPP, should assume that neither TLS nor SSL is used when the connection is established. TLS or other security technologies might eventually be used on such servers, if someone defines a means of negotiating security in-band over HTTP. IPP clients should specify "http:", perhaps with a port # (other than 443), to indicate that they want to talk to such servers. + If a specific port is to be allocated for IPP, there should be an "ipp:" URL scheme defined, which defaults to that port. The definition of the ipp: scheme should also define how security is to be negotiated on that port - whether it defaults to TLS (perhaps with the possibility of fallback to a null encryption layer) or whether it uses in-band negotiation. In every case it remains necessary for clients and servers to be configurable as to which TLS ciphersuites are acceptable. Keith From ipp-owner@pwg.org Thu Jan 8 17:10:02 1998 Delivery-Date: Thu, 08 Jan 1998 17:10:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27615 for ; Thu, 8 Jan 1998 17:10:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15222 for ; Thu, 8 Jan 1998 17:12:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14959 for ; Thu, 8 Jan 1998 17:09:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 17:02:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13376 for ipp-outgoing; Thu, 8 Jan 1998 16:31:11 -0500 (EST) Date: Thu, 8 Jan 1998 13:29:34 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801082129.NAA15857@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I suggest the following wording for the paragraphs 4.2.10 that Tom wrote and I enclose below: My wording: ----------------------------------------------- For documents whose document-format does not explicitly specify the orientation (e.g. text/plain), this attribute specifies the client-requested orientation of the content of the print-stream pages when they are printed. For documents whose document-format does explicitly specify the orientation (e.g. PostScript), this attribute has no meaning -- it neither alters the orientation nor specifies the existing orientation. ----------------------------------------------- Tom's wording: > From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 > Proposed new text: > > 4.2.10 orientation-requested (type2 enum) > > This attribute specifies the orientation of the content of the print-stream > pages to be printed. In most cases, the orientation of the content is > specified within the document format generated by the device driver at > print time. However, some document formats (such as 'text/plain') do not > support the notion of page orientation, and it is possible to bind the > orientation after the document content has been generated. This attribute > provides an end user with the means to specify orientation for such > documents when the IPP Printer performs the formatting. > From ipp-owner@pwg.org Thu Jan 8 17:10:02 1998 Delivery-Date: Thu, 08 Jan 1998 17:10:02 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27617 for ; Thu, 8 Jan 1998 17:10:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15223 for ; Thu, 8 Jan 1998 17:12:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14967 for ; Thu, 8 Jan 1998 17:10:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 17:01:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13611 for ipp-outgoing; Thu, 8 Jan 1998 16:34:04 -0500 (EST) Date: Thu, 8 Jan 1998 13:32:26 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801082132.NAA15864@woden.eng.sun.com> To: ipp@pwg.org, Rajesh_Chawla@xn.xerox.com Subject: Re: IPP> Question about rangeOfInteger X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > From Rajesh_Chawla@xn.xerox.com Thu Jan 8 13:22:37 1998 > > Hi folks, > > I'm confused about the rangeOfInteger type. The protocol document says > that rangeOfInteger should have 2 integers that represent the min and > the max. My question is where should the value go? The "value" in the protocol sense, is the 8 bytes of the 2 4-byte integers, the min-value first and then the max-value. > > Rajesh > From ipp-owner@pwg.org Thu Jan 8 20:41:34 1998 Delivery-Date: Thu, 08 Jan 1998 20:41:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA00160 for ; Thu, 8 Jan 1998 20:41:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15626 for ; Thu, 8 Jan 1998 20:44:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA16652 for ; Thu, 8 Jan 1998 20:41:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 20:37:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16098 for ipp-outgoing; Thu, 8 Jan 1998 20:22:55 -0500 (EST) Message-Id: <3.0.1.32.19980108171814.00c2fce0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 17:18:14 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value In-Reply-To: <199801082129.NAA15857@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I like Bob's re-write of the "orientation" attribute much better. I did not touch that description, but had only added "when the IPP Printer performs the formatting" to the end of the existing paragraph. One possible confusion is that we mean "the content of the print stream pages do not specify orientation", not the value of the "document-format" attribute, so change document-format to content (twice). Put hyphens around the "document-format" attribute when referring to that attribute, rather than the concept. Also as a matter of style, all the other descriptions start out with "This attribute ...", so I suggest re-ordering the first sentence. How about: 4.2.10 orientation-requested (type2 enum) This attribute specifies the client-requested orientation of the content of the print-stream pages when they are printed for documents whose content does not explicitly specify the orientation (e.g., "document-format" is 'text/plain'). For documents whose content does explicitly specify the orientation (e.g., PostScript), this attribute SHALL have no meaning -- it neither alters the orientation nor specifies the existing orientation. At 13:29 01/08/1998 PST, Robert Herriot wrote: >I suggest the following wording for the paragraphs 4.2.10 that Tom wrote >and I enclose below: > >My wording: >----------------------------------------------- >For documents whose document-format does not explicitly specify the >orientation (e.g. text/plain), this attribute specifies the >client-requested orientation of the content of the print-stream pages >when they are printed. For documents whose document-format does explicitly >specify the orientation (e.g. PostScript), this attribute has no meaning -- >it neither alters the orientation nor specifies the existing orientation. >----------------------------------------------- >Tom's wording: > >> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 >> Proposed new text: >> >> 4.2.10 orientation-requested (type2 enum) >> >> This attribute specifies the orientation of the content of the print-stream >> pages to be printed. In most cases, the orientation of the content is >> specified within the document format generated by the device driver at >> print time. However, some document formats (such as 'text/plain') do not >> support the notion of page orientation, and it is possible to bind the >> orientation after the document content has been generated. This attribute >> provides an end user with the means to specify orientation for such >> documents when the IPP Printer performs the formatting. >> > > > > > From ipp-owner@pwg.org Thu Jan 8 21:59:13 1998 Delivery-Date: Thu, 08 Jan 1998 21:59:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00573 for ; Thu, 8 Jan 1998 21:59:13 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15700 for ; Thu, 8 Jan 1998 22:02:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA17413 for ; Thu, 8 Jan 1998 21:59:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 21:49:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16803 for ipp-outgoing; Thu, 8 Jan 1998 21:30:26 -0500 (EST) Message-Id: <3.0.1.32.19980108182559.0103b210@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 8 Jan 1998 18:25:59 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - "compression" should not be a Job Description attribute Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org When we moved "compression", "job-k-octets", "job-impressions", and "job-media-sheets" from being Job Template attributes to being operation attributes and Job Description attributes, we made a slight mistake. The "compression" attribute is a per-document attribute and so should be treated like "document-format". Its an operation attribute, but not a Job Description attribute. In IPP/1.0, you just can't query either the "compression" or the "document-format" attribute on the job object. The summary of the changes are: 1. delete the "compression" attribute as a Job Description attribute 2. delete the "compression" as an operation attribute from the Create-Job 3. add "compressions" as an operation attribute to Send-Document and Send-URI 4. keep "compression" as an operation attribute for Print-Job, Print-URI, and Job-Validate. Here are the details: 1. In 3.2.1.1 Print-Job Request remove the sentence about populating the "compression" job description attribute: If the client supplies the attribute and the Printer object supports the attribute, the value of the attribute is used to populate the Job object's "compression" Job Description attribute. So that the operation attribute will read: "compression" (type3 keyword) The client OPTIONALLY supplies this attribute. The Printer object OPTIONALLY supports this attribute. It identifies the compression algorithm used on the document data (see section 4.3.17). If the client omits this attribute, the Printer object SHALL assume that the data is not compressed. If the client supplies this attribute, but the value is not supported by the Printer object, i.e., the value is not one of the values of the Printer object's "compression-supported" attribute, the Printer object SHALL copy the attribute and its value to the Unsupported Attributes response group, reject the request, and return the 'client-error-attributes-or-values-not-supported' status code. 2. In section 3.2.4 Create-Job Operation, add "compression" to the list of Print-Job operation attributes that are not allowed in the Create-Job operation. Also add "operation" before attributes, so that it reads: Also, the client does not supply any of the "document-name", "document-format", "document-natural-language", or "compression" operation attributes. 3. In section 3.3.1.1 Send-Document Request, add "compression" as an operation attribute, just after "document-format-language". Might as well just copy the entire paragraph from Print-Job, or reference back to it. 2. Delete the "compression" entry from the table in section 4.3 Job Description Attributes 4. In section 4.3.17 delete the entire "compression" job description attribute and move the description of the values to the 4.4.29 "compression-supported" Printer Description attribute (which is missing, along with "job-k-octets-supported", "job-impressions-supported", and "job-media-sheets-supported" attributes). I suggest something like: 4.4.29 compression-supported (1setOf type3 keyword) This Printer attribute identifies the set of compression algorithms supported by the IPP object for accepting compressed document data. Compression does not apply to the encoding of the IPP operation itself. These values are supported for use in the "compression" operation attribute. See the specification of the "compression" operation attribute in the Print-Job operation request. Standard values are: 'none': no compression is used. 'deflate': ZIP public domain inflate/deflate) compression technology 'gzip' GNU zip compression technology described in RFC 1952 [RFC1952]. 'compress': UNIX compression technology 4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) This Printer attribute specifies the lower and upper bound of sizes in K octets supported for the sum of the documents for the job. This range of values is supported for use in the "job-k-octets" operation attribute. See the specification of "job-k-octets" operation attribute in the Print-Job operation request and the corresponding "job-k-octets" job description attribute in section 4.3.18. 4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) This Printer attribute specifies the lower and upper bound of number of impressions supported for the job. This range of values is supported for use in the "job-impressions" operation attribute. See the specification of "job-impressions" operation attribute in the Print-Job operation request and the corresponding "job-impressions" job description attribute in section 4.3.19. 4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) This Printer attribute specifies the lower and upper bound of number of media sheets to be produced by a job. This range of values is supported for use in the "job-meida-sheets" operation attribute. See the specification of "job-media-sheets" operation attribute in the Print-Job operation request and the corresponding "job-media-sheets" job description attribute in section 4.3.20. 5. Add a reference to RFC 1952 in 4.4.29 and add to the References section: 'gzip' GNU zip compression technology described in RFC 1952 [RFC1952]. [RFC1952] P. Deutsch, "GZIP file format specification version 4.3", RFC 1952, May 1996 6. In section 15.3.3.3 Validate the presence of a single occurence of required Operation attributes: a. delete the "compression" operation attribute from the Create-Job operation compression (O*) b. add the "compression" operation attribute to the Send-Document operation compression (O*) c. add the "compression" operation attribute to the Send-URI operation compression (O*) From ipp-owner@pwg.org Thu Jan 8 22:21:37 1998 Delivery-Date: Thu, 08 Jan 1998 22:21:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA00786 for ; Thu, 8 Jan 1998 22:21:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15731 for ; Thu, 8 Jan 1998 22:24:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA18062 for ; Thu, 8 Jan 1998 22:21:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 22:09:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16821 for ipp-outgoing; Thu, 8 Jan 1998 21:40:31 -0500 (EST) Date: Thu, 8 Jan 1998 18:35:53 -0800 (Pacific Standard Time) From: Ron Bergman To: Robert Herriot cc: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value In-Reply-To: <199801082129.NAA15857@woden.eng.sun.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Bob, Very good! This is more direct and easier to understand. Ron Bergman Dataproducts Corp. On Thu, 8 Jan 1998, Robert Herriot wrote: > I suggest the following wording for the paragraphs 4.2.10 that Tom wrote > and I enclose below: > > My wording: > ----------------------------------------------- > For documents whose document-format does not explicitly specify the > orientation (e.g. text/plain), this attribute specifies the > client-requested orientation of the content of the print-stream pages > when they are printed. For documents whose document-format does explicitly > specify the orientation (e.g. PostScript), this attribute has no meaning -- > it neither alters the orientation nor specifies the existing orientation. > ----------------------------------------------- > Tom's wording: > > > From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 > > Proposed new text: > > > > 4.2.10 orientation-requested (type2 enum) > > > > This attribute specifies the orientation of the content of the print-stream > > pages to be printed. In most cases, the orientation of the content is > > specified within the document format generated by the device driver at > > print time. However, some document formats (such as 'text/plain') do not > > support the notion of page orientation, and it is possible to bind the > > orientation after the document content has been generated. This attribute > > provides an end user with the means to specify orientation for such > > documents when the IPP Printer performs the formatting. > > > > > > From ipp-owner@pwg.org Thu Jan 8 22:39:07 1998 Delivery-Date: Thu, 08 Jan 1998 22:39:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA02522 for ; Thu, 8 Jan 1998 22:39:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15745 for ; Thu, 8 Jan 1998 22:41:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA18714 for ; Thu, 8 Jan 1998 22:39:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 22:30:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA17262 for ipp-outgoing; Thu, 8 Jan 1998 21:56:16 -0500 (EST) Date: Thu, 8 Jan 1998 18:55:59 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801090255.SAA01213@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Tom, Your rewording may be OK, but I leave it to others to choose between the two options of: a) mine with the "for" clause at the beginning of the 1st sentence but with your other minor fixes. b) yours with the "for" clause at the end of the 1st sentence. I tried various wordings and I felt that "for" clause at the beginning made the sentence clearer. > From hastings@cp10.es.xerox.com Thu Jan 8 17:21:34 1998 > How about: > > 4.2.10 orientation-requested (type2 enum) > > This attribute specifies the client-requested orientation of the content > of the print-stream pages when they are printed for documents whose > content does not explicitly specify the orientation (e.g., "document-format" > is 'text/plain'). For documents whose content does explicitly specify the > orientation (e.g., PostScript), this attribute SHALL have no meaning -- it > neither alters the orientation nor specifies the existing orientation. > > > > > At 13:29 01/08/1998 PST, Robert Herriot wrote: > >I suggest the following wording for the paragraphs 4.2.10 that Tom wrote > >and I enclose below: > > > >My wording: > >----------------------------------------------- > >For documents whose document-format does not explicitly specify the > >orientation (e.g. text/plain), this attribute specifies the > >client-requested orientation of the content of the print-stream pages > >when they are printed. For documents whose document-format does explicitly > >specify the orientation (e.g. PostScript), this attribute has no meaning -- > >it neither alters the orientation nor specifies the existing orientation. > >----------------------------------------------- > >Tom's wording: > > > >> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 > >> Proposed new text: > >> > >> 4.2.10 orientation-requested (type2 enum) > >> > >> This attribute specifies the orientation of the content of the print-stream > >> pages to be printed. In most cases, the orientation of the content is > >> specified within the document format generated by the device driver at > >> print time. However, some document formats (such as 'text/plain') do not > >> support the notion of page orientation, and it is possible to bind the > >> orientation after the document content has been generated. This attribute > >> provides an end user with the means to specify orientation for such > >> documents when the IPP Printer performs the formatting. > >> > > > > > > > > > > > From ipp-owner@pwg.org Thu Jan 8 22:43:31 1998 Delivery-Date: Thu, 08 Jan 1998 22:43:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA02558 for ; Thu, 8 Jan 1998 22:43:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15756 for ; Thu, 8 Jan 1998 22:46:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA19346 for ; Thu, 8 Jan 1998 22:43:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 8 Jan 1998 22:39:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17498 for ipp-outgoing; Thu, 8 Jan 1998 22:08:28 -0500 (EST) Message-Id: <1.5.4.32.19980109020937.0067b064@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, 08 Jan 1998 18:09:37 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Corrections to the latest PWG IPP Teleconference Minutes Sender: ipp-owner@pwg.org Hi all, Tom Hastings has pointed out a number of minor errors anmd omissions that I made in the minutes from last Wednesday January 7. Please correct the minutes with Tom's comments replicated below: You forgot to mention in the minutes about the revised IANA consideration text that did not make it into the previous draft.. As you can see from the text we already have, IPP already has 'reverse-landscape', so it should be 'reverse-portrait'. BTW, there is no "d" in either 'reverse-landscape' or 'reverse-portrait' in IPP or DPA. Also your minutes put an "s" on "printer-uri-supported" which makes more sense for humans and directory entries for multi-valued attribute, but not for programs that map "xxx" to "xxx-supported". I specifically brought up that it should be without the 's' for consistency with our other attributes. Take a look at the last page of the Model document and see the number of multi-valued "xxx-supported" attributes we have without the 's'. So you should also change "printer-uris-supported" to "printer-uri-supported" in the minutes. Also my notes show that we agreed to a name for the parallel attribute: "uri-security-supported". Finally, all keywords are all lower case, so change 'NONE', 'SSL3', "TLS" to 'none', 'ssl3', 'tls'. --- Sorry for those mistakes, I was trying to get the minutes out too quickly. Carl-Uno From ipp-owner@pwg.org Fri Jan 9 11:05:44 1998 Delivery-Date: Fri, 09 Jan 1998 11:05:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13454 for ; Fri, 9 Jan 1998 11:05:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17018 for ; Fri, 9 Jan 1998 11:08:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21740 for ; Fri, 9 Jan 1998 11:05:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 10:53:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20662 for ipp-outgoing; Fri, 9 Jan 1998 10:31:34 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value Message-ID: <5030300016633811000002L012*@MHS> Date: Fri, 9 Jan 1998 10:37:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA13454 I tried to send this yesterday but there was a problem... Harry Lewis - IBM Printing Systems ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 01/09/98 08:22 AM --------------------------- Harry Lewis 01/08/98 04:43 PM To: ipp@pwg.org @ internet cc: From: Harry Lewis/Boulder/IBM @ IBMUS Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value Since job-template attributes are intended to override embedded print stream instructions, I'm confused by 4.2.10 orientation-requested (type2 enum) which, by its definition, indicates the opposite (this attribute WILL be overridden by the PDL as a matter of course, if I understand correctly). If we're just trying to address "plain-text" with this attribute, then maybe it should be called "plain-text-default-orientation"? Otherwise, this particular attribute appears to go against the grain with respect to the intent of job-template attributes. I think it is unique in this sense which could be why we are struggling with the definition. Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 01/08/98 10:04:56 AM Please respond to ipp-owner@pwg.org @ internet To: hastings@cp10.es.xerox.com @ internet, ipp@pwg.org @ internet cc: Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value I suggest the following wording for the paragraphs 4.2.10 that Tom wrote and I enclose below: My wording: ----------------------------------------------- For documents whose document-format does not explicitly specify the orientation (e.g. text/plain), this attribute specifies the client-requested orientation of the content of the print-stream pages when they are printed. For documents whose document-format does explicitly specify the orientation (e.g. PostScript), this attribute has no meaning -- it neither alters the orientation nor specifies the existing orientation. ----------------------------------------------- Tom's wording: > From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 > Proposed new text: > > 4.2.10 orientation-requested (type2 enum) > > This attribute specifies the orientation of the content of the print-stream > pages to be printed. In most cases, the orientation of the content is > specified within the document format generated by the device driver at > print time. However, some document formats (such as 'text/plain') do not > support the notion of page orientation, and it is possible to bind the > orientation after the document content has been generated. This attribute > provides an end user with the means to specify orientation for such > documents when the IPP Printer performs the formatting. > From ipp-owner@pwg.org Fri Jan 9 11:13:48 1998 Delivery-Date: Fri, 09 Jan 1998 11:13:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13623 for ; Fri, 9 Jan 1998 11:13:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17045 for ; Fri, 9 Jan 1998 11:16:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22544 for ; Fri, 9 Jan 1998 11:13:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 11:09:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21080 for ipp-outgoing; Fri, 9 Jan 1998 10:44:30 -0500 (EST) Date: Fri, 9 Jan 1998 07:39:52 -0800 (Pacific Standard Time) From: Ron Bergman To: Robert Herriot cc: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value In-Reply-To: <199801090255.SAA01213@woden.eng.sun.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I find the wording presented by Bob to be easier to read (and understand) than the reword suggested by Tom. Both convey the same information. Ron Bergman Dataproducts Corp. On Thu, 8 Jan 1998, Robert Herriot wrote: > Tom, > > Your rewording may be OK, but I leave it to others to choose between the > two options of: > a) mine with the "for" clause at the beginning of the 1st sentence but with > your other minor fixes. > b) yours with the "for" clause at the end of the 1st sentence. > > I tried various wordings and I felt that "for" clause at the beginning > made the sentence clearer. > > > From hastings@cp10.es.xerox.com Thu Jan 8 17:21:34 1998 > > How about: > > > > 4.2.10 orientation-requested (type2 enum) > > > > This attribute specifies the client-requested orientation of the content > > of the print-stream pages when they are printed for documents whose > > content does not explicitly specify the orientation (e.g., "document-format" > > is 'text/plain'). For documents whose content does explicitly specify the > > orientation (e.g., PostScript), this attribute SHALL have no meaning -- it > > neither alters the orientation nor specifies the existing orientation. > > > > > > > > > > At 13:29 01/08/1998 PST, Robert Herriot wrote: > > >I suggest the following wording for the paragraphs 4.2.10 that Tom wrote > > >and I enclose below: > > > > > >My wording: > > >----------------------------------------------- > > >For documents whose document-format does not explicitly specify the > > >orientation (e.g. text/plain), this attribute specifies the > > >client-requested orientation of the content of the print-stream pages > > >when they are printed. For documents whose document-format does explicitly > > >specify the orientation (e.g. PostScript), this attribute has no meaning -- > > >it neither alters the orientation nor specifies the existing orientation. > > >----------------------------------------------- > > >Tom's wording: > > > > > >> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 > > >> Proposed new text: > > >> > > >> 4.2.10 orientation-requested (type2 enum) > > >> > > >> This attribute specifies the orientation of the content of the print-stream > > >> pages to be printed. In most cases, the orientation of the content is > > >> specified within the document format generated by the device driver at > > >> print time. However, some document formats (such as 'text/plain') do not > > >> support the notion of page orientation, and it is possible to bind the > > >> orientation after the document content has been generated. This attribute > > >> provides an end user with the means to specify orientation for such > > >> documents when the IPP Printer performs the formatting. > > >> > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Fri Jan 9 11:56:00 1998 Delivery-Date: Fri, 09 Jan 1998 11:56:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14514 for ; Fri, 9 Jan 1998 11:56:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17205 for ; Fri, 9 Jan 1998 11:58:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23250 for ; Fri, 9 Jan 1998 11:55:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 11:50:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22673 for ipp-outgoing; Fri, 9 Jan 1998 11:35:57 -0500 (EST) Message-Id: <3.0.1.32.19980109083129.010259c0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 Jan 1998 08:31:29 PST To: (Scott Isaacson), ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Fix Section 2.4 Object Identify with multiple Printer URIs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At the telecon last Wednesday, we agreed to change the Printer object's single-valued "printer-uri" attribute to a multi-valued "printer-uri-supported" attribute. And keep the single-valued "printer-uri" operation attribute for use in operation requests and responses. This note looks at the first section affected by this change to show the impact. I think this is a good change, but it does require a lot of careful re-work of the wording. Here is an attempt: Now Printer objects can be identified by one or more URIs, but jobs remain with a single URI. However, each Printer object is still uniquely identified by each of its URIs, if it has more than one URI. We also need to be careful to distinguish between the concept of a Printer URI and the "printer-uri" operation attribute. The former is always two separate words (with Printer and URI capitalized) and the latter is a single hyphenated word with double quotes and all lower case. We need to fix section 2.4 and other parts of the document accordingly. Also we have to be careful, since the Printer object now has the renamed multi-valued: "printer-uri-supported" attribute. It no longer has the same name as the single-valued "printer-uri" operation attribute. So we have to be careful to update the document each time we mention "printer-uri" to make sure that is is refering to the "printer-uri" operation attribute or the "printer-uri-supported" Printer object attribute. In some places, we might be even talking about both, and so need to change the single mention of "printer-uri" attribute to "printer-uri" operation attribute and "printer-uri-supported" Printer attribute. For example of the changes, here is section 2.4 on object identity with possible changes (we can't talk about the "printer-uri" operation attribute yet, since operations are described later): >2.4 Object Identity > >All Printer and Job objects are identified by an identifier so that they >can be persistently and unambiguously referenced. The IPP/1.0 model >requires that these identifiers be Uniform Resource Identifiers (URIs) >[RFC1630]. Often, the URI is a URL [RFC1738] [RFC1808]. I suggest adding to the end of the paragraph above: A Printer object MAY have one or more identifies that uniquely identify the Printer object, depending on implementation. These Printer URIs are contained in the Printer object's potentially multi-valued "printer-uri-supported" attribute. Job objects SHALL have only one unique identifier. This Job URI is contained in the Job object's "job-uri" attribute. > >IPP/1.0 does not specify how the URI is obtained, but it is RECOMMENDED >that a Printer object is registered in a directory service which end users >and programs can interrogate. Section 16 defines a generic schema for >Printer object entries in the directory service. > >Allowing Job objects to have URIs allows for flexibility and scalability. >In some implementations, the Printer object might create Jobs that are >processed in the same local environment as the Printer object itself. In >this case, the Job URI might just be a composition of the Printer's URI and >some unique component for the Job object, such as the unique 32-bit >positive integer mentioned later in this paragraph. In other >implementations, the Printer object might be a central clearing-house for >validating all Job object creation requests, and the Job object itself >might be created in some environment that is remote from the Printer >object. In this case, the Job object's URI may have no relationship at all >to the Printer object's URI. However, many existing printing systems have >local models or interface constraints that force Job objects to be >identified using only a 32-bit positive integer rather than a URI. This >numeric Job ID is only unique within the context of the Printer object to >which the create request was originally submitted. In order to allow both >types of client access to Jobs (either by Job URI or by numeric Job ID), >when the Printer object successfully processes a create request and creates >a new Job, the Printer object SHALL generate both a Job URI and a Job ID >for the new Job object. This requirement allows all clients to access >Printer objects and Job objects no matter the local constraints imposed on >the client implementation. In order to fix the paragraph above, we need to introduce the concept that a create operation specifies a single Printer URI, without introducing the concept of operation attributes yet. I suggest adding a preceding paragraph: When a job is submitted to the Printer object, the client MUST supply a single Printer URI which is one of the URIs that uniquely identify that Printer object and is one of the values in that Printer object's "printer-uri-supported" attribute. Then the long paragraph above can be fixed by replacing "Printer's URI" and "Printer object's URI" with "Printer URI supplied by the client when submitting the job" yielding: Allowing Job objects to have URIs allows for flexibility and scalability. In some implementations, the Printer object might create Jobs that are processed in the same local environment as the Printer object itself. In this case, the Job URI might just be a composition of the Printer URI supplied by the client when submitting the job and some unique component for the Job object, such as the unique 32-bit positive integer mentioned later in this paragraph. In other implementations, the Printer object might be a central clearing-house for validating all Job object creation requests, and the Job object itself might be created in some environment that is remote from the Printer object. In this case, the Job object's URI may have no relationship at all to the Printer URI supplied by the client when submitting the job. However, many existing printing systems have local models or interface constraints that force Job objects to be identified using only a 32-bit positive integer rather than a URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. In order to allow both types of client access to Jobs (either by Job URI or by numeric Job ID), when the Printer object successfully processes a create request and creates a new Job, the Printer object SHALL generate both a Job URI and a Job ID for the new Job object. This requirement allows all clients to access Printer objects and Job objects no matter the local constraints imposed on the client implementation. > >In addition to a unique identifier, Printer objects and Job objects have >names. An object name need not be unique across all instances of all >objects. A Printer object's name is chosen and set by an administrator >through some mechanism outside the scope of IPP/1.0. A Job object's name >is optionally chosen and supplied by the IPP client submitting the job. If >the client does not supply a Job object name, the Printer object generates >a name for the new Job object. In all cases, the name only has local >meaning; the name is not constrained to be unique. Probably just replace "a unique identifier" with "unique identifiers" in the first sentence in the paragraph above. > >To summarize: > >- Each Printer object is uniquely identified with a URI. The Printer's >"printer-uri" attribute contains the URI. Change the paragraph to: - Each Printer object is identified by one or more unique URIs. The Printer's multi-valued "printer-uri-supported" attribute contains these URIs. > >- Each Job object is uniquely identified with a URI. The Job's "job-uri" >attribute contains the URI. > >- Each Job object is also uniquely identified with a combination of the URI >of the Printer object to which the create request was originally submitted >along with a Job ID (a 32-bit, positive integer) that is unique within the >context of that Printer object. The Printer object's "printer-uri" >contains the Printer URI. The Job object's "job-id" attribute contains the >numeric Job ID. In order to fix this paragraph, we need to introduce the concept that a create operation specifies a single Printer URI, without introducing the concept of operation attributes yet. Also we can introduce the "containing-printer-uri" attribute, since it is a connection between the Job object and the Printer object. I suggest re-writing the paragraph as: - When a job is submitted, the client MUST supply a single Printer URI which is one of the URIs that uniquely identify the Printer object and is one of the values in the Printer's "printer-uri-supported" attribute. Each Job object is also uniquely identified with a combination of the Printer URI supplied in the original create request along with a Job ID (a 32-bit, positive integer) that is unique within the context of that Printer object. The Printer object's "containing-printer-uri" contains the Printer URI supplied in the create request. The Job object's "job-id" attribute contains the numeric Job ID. > >- Each Printer object has a name (which is not necessarily unique). The >administrator chooses and sets this name through some mechanism outside the >scope of IPP/1.0 itself. The Printer object's "printer-name" attribute >contains the name. > >- Each Job object has a name (which is not necessarily unique). The client >optionally supplies this name in the create request. If the client does >not supply this name, the Printer object generates a name for the Job >object. The Job object's "job-name" attribute contains the name. > From ipp-owner@pwg.org Fri Jan 9 13:46:53 1998 Delivery-Date: Fri, 09 Jan 1998 13:46:54 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15949 for ; Fri, 9 Jan 1998 13:46:53 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17727 for ; Fri, 9 Jan 1998 13:49:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA24571 for ; Fri, 9 Jan 1998 13:46:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 13:39:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23404 for ipp-outgoing; Fri, 9 Jan 1998 13:21:52 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587C084B7@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Delay of IPP ratification Date: Fri, 9 Jan 1998 10:21:33 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org This is a formal request that we delay the finalization of the IPP spec until we have looked at the possibility of using XML as the protocol format. I know this is revisiting an old issue but we need to make sure we do the right thing. When the current format was proposed there was no good method for representing structured data in an ASCII data stream. XML is now available and seem to be the coming wave. I also know that most of the new standards that will come out over the next year will be based around XML (and protocol specific HTTP commands). By ensuring that we are in the centre of these standards we will be able to leverage many common tools that will emerge to support and manage these protocols. There will definitely be down-sides so we need to debate this issue - not least the investment that some of us have already made in building using the current spec. I think that somebody from MS will be in Hawaii. Paul Moore From ipp-owner@pwg.org Fri Jan 9 16:22:10 1998 Delivery-Date: Fri, 09 Jan 1998 16:22:10 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA17464 for ; Fri, 9 Jan 1998 16:22:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18367 for ; Fri, 9 Jan 1998 16:24:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25370 for ; Fri, 9 Jan 1998 16:22:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 16:13:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24783 for ipp-outgoing; Fri, 9 Jan 1998 15:53:30 -0500 (EST) From: Roger K Debry To: Cc: Subject: IPP> Delay of IPP ratification Message-ID: <5030100015953865000002L052*@MHS> Date: Fri, 9 Jan 1998 15:52:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA17464 If XML has the promise of providing a better protocol format, then I am willing to take a look at it. If we decide that XML does make sense, will Microsoft have a reasonably complete mapping to propose? I would be hesitant to sign up for a completely new approach without the promise of being able to quickly produce a mapping document with the same level of function and detail as the current one. If there's six months of effort required to figure out how to use XML in IPP, then I'd most certainly vote against it! I assume that this does not affect the model and semantics! Roger K deBry Senior Technical 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 01/09/98 01:44 PM --------------------------- ipp-owner@pwg.org on 01/09/98 06:42:40 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Delay of IPP ratification This is a formal request that we delay the finalization of the IPP spec until we have looked at the possibility of using XML as the protocol format. I know this is revisiting an old issue but we need to make sure we do the right thing. When the current format was proposed there was no good method for representing structured data in an ASCII data stream. XML is now available and seem to be the coming wave. I also know that most of the new standards that will come out over the next year will be based around XML (and protocol specific HTTP commands). By ensuring that we are in the centre of these standards we will be able to leverage many common tools that will emerge to support and manage these protocols. There will definitely be down-sides so we need to debate this issue - not least the investment that some of us have already made in building using the current spec. I think that somebody from MS will be in Hawaii. Paul Moore From ipp-owner@pwg.org Fri Jan 9 16:30:04 1998 Delivery-Date: Fri, 09 Jan 1998 16:30:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA17521 for ; Fri, 9 Jan 1998 16:30:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18402 for ; Fri, 9 Jan 1998 16:32:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25989 for ; Fri, 9 Jan 1998 16:30:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 16:26:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24806 for ipp-outgoing; Fri, 9 Jan 1998 16:03:25 -0500 (EST) Date: Fri, 9 Jan 1998 13:03:12 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801092103.NAA01739@woden.eng.sun.com> To: ipp@pwg.org, paulmo@microsoft.com Subject: Re: IPP> Delay of IPP ratification X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I agree with Paul that we should spend some time looking at XML before we commit to the current protocol. XML is becoming an important protocol. Bob Herriot > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > From: Paul Moore > To: "'ipp@pwg.org'" > Subject: IPP> Delay of IPP ratification > Date: Fri, 9 Jan 1998 10:21:33 -0800 > X-Mailer: Internet Mail Service (5.5.1960.3) > Sender: ipp-owner@pwg.org > Content-Length: 942 > X-Lines: 19 > > This is a formal request that we delay the finalization of the IPP spec > until we have looked at the possibility of using XML as the protocol format. > > I know this is revisiting an old issue but we need to make sure we do the > right thing. When the current format was proposed there was no good method > for representing structured data in an ASCII data stream. XML is now > available and seem to be the coming wave. I also know that most of the new > standards that will come out over the next year will be based around XML > (and protocol specific HTTP commands). By ensuring that we are in the centre > of these standards we will be able to leverage many common tools that will > emerge to support and manage these protocols. > > There will definitely be down-sides so we need to debate this issue - not > least the investment that some of us have already made in building using the > current spec. > > I think that somebody from MS will be in Hawaii. > > Paul Moore > From ipp-owner@pwg.org Fri Jan 9 17:27:12 1998 Delivery-Date: Fri, 09 Jan 1998 17:27:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA18352 for ; Fri, 9 Jan 1998 17:27:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA18637 for ; Fri, 9 Jan 1998 17:29:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27115 for ; Fri, 9 Jan 1998 17:27:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 17:21:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26520 for ipp-outgoing; Fri, 9 Jan 1998 17:07:03 -0500 (EST) Message-ID: <34B69F3F.7F2EAC2E@underscore.com> Date: Fri, 09 Jan 1998 17:05:51 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot , paulmo@microsoft.com CC: ipp@pwg.org Subject: Re: IPP> Delay of IPP ratification References: <199801092103.NAA01739@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob and Paul, Care to elucidate on the merits and applicability of XML to the IPP model? Any known/expected problems in mapping? Any particular benefits over alternative approaches? Perhaps most importantly, exactly *why* should XML even be considered in the first place? Bob says that "XML is becoming an important protocol." We can all think of lots of emerging protocols that may be viewed as important, but are they applicable to network printing? How and why is XML applicable to a network printing protocol? Please understand that I am not casting any kind of early vote against XML here. Just trying to figure out why XML has suddenly entered the fray. ...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 -- ---------------------------------------------------------------------- Robert Herriot wrote: > > I agree with Paul that we should spend some time looking at XML before > we commit to the current protocol. XML is becoming an important protocol. > > Bob Herriot > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > From: Paul Moore > > To: "'ipp@pwg.org'" > > Subject: IPP> Delay of IPP ratification > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > X-Mailer: Internet Mail Service (5.5.1960.3) > > Sender: ipp-owner@pwg.org > > Content-Length: 942 > > X-Lines: 19 > > > > This is a formal request that we delay the finalization of the IPP spec > > until we have looked at the possibility of using XML as the protocol format. > > > > I know this is revisiting an old issue but we need to make sure we do the > > right thing. When the current format was proposed there was no good method > > for representing structured data in an ASCII data stream. XML is now > > available and seem to be the coming wave. I also know that most of the new > > standards that will come out over the next year will be based around XML > > (and protocol specific HTTP commands). By ensuring that we are in the centre > > of these standards we will be able to leverage many common tools that will > > emerge to support and manage these protocols. > > > > There will definitely be down-sides so we need to debate this issue - not > > least the investment that some of us have already made in building using the > > current spec. > > > > I think that somebody from MS will be in Hawaii. > > > > Paul Moore > > From ipp-owner@pwg.org Fri Jan 9 17:45:27 1998 Delivery-Date: Fri, 09 Jan 1998 17:45:27 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA18582 for ; Fri, 9 Jan 1998 17:45:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA18710 for ; Fri, 9 Jan 1998 17:48:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27774 for ; Fri, 9 Jan 1998 17:45:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 17:41:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27001 for ipp-outgoing; Fri, 9 Jan 1998 17:25:30 -0500 (EST) Message-Id: <3.0.1.32.19980109142055.00bc07f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 Jan 1998 14:20:55 PST To: Paul Moore , "'ipp@pwg.org'" From: Tom Hastings Subject: Re: IPP> Delay of IPP ratification [How big is an XML interpreter?] In-Reply-To: <5CEA8663F24DD111A96100805FFE6587C084B7@red-msg-51.dns.micr osoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I agree that we should take the time to consider XML, and I also agree with the other commenters that we need to do this expediously. One (of many) concerns that need to be discussed about using XML is the increased size of actual printing devices that support IPP. HTTP implementations are down to 20-30 K of code so using HTTP was not seen as an undue burden. What is the increased size to support an XML interpreter? One of the advantages of our binary IPP encoding is that it was light weight enough that volume desktop printers could implement it (and implementations are under way by a number of vendors). Therefore, the same IPP protocol (with the binary encoding) is a job submission protocol that can be used between clients and servers, between clients and spooling devices, and between servers and non-spooling devices. This is a great improvement over DPA where DPA has only been implemented by clients and servers; no non-spooling devices are supporting DPA. It also greatly simplifies server implementations when the protocol they receive is the same as they send, so that a server can just forward jobs to devices after spooling, rather than having to perform complex job submission protocol mappings. It would be a shame if IPP became too expensive to implement in non-spooling devices. Tom At 10:21 01/09/1998 PST, Paul Moore wrote: >This is a formal request that we delay the finalization of the IPP spec >until we have looked at the possibility of using XML as the protocol format. > >I know this is revisiting an old issue but we need to make sure we do the >right thing. When the current format was proposed there was no good method >for representing structured data in an ASCII data stream. XML is now >available and seem to be the coming wave. I also know that most of the new >standards that will come out over the next year will be based around XML >(and protocol specific HTTP commands). By ensuring that we are in the centre >of these standards we will be able to leverage many common tools that will >emerge to support and manage these protocols. > >There will definitely be down-sides so we need to debate this issue - not >least the investment that some of us have already made in building using the >current spec. > >I think that somebody from MS will be in Hawaii. > >Paul Moore > > From ipp-owner@pwg.org Fri Jan 9 20:33:10 1998 Delivery-Date: Fri, 09 Jan 1998 20:33:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA19977 for ; Fri, 9 Jan 1998 20:32:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19087 for ; Fri, 9 Jan 1998 20:35:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA29453 for ; Fri, 9 Jan 1998 20:32:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 20:14:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28624 for ipp-outgoing; Fri, 9 Jan 1998 19:27:18 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 09 Jan 1998 17:25:57 -0700 From: Scott Isaacson To: hastings@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> MOD - Fix Section 2.4 Object Identify with multiple PrinterURIs Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org FYI I had promised to get the new model document done by today, Friday (1/9), however, as has been pointed out by these messages from Tom and Bob, there is more extensive editing here (more than I thought). I will be delayed by a few days..... Which just goes to show that a little tweek can take up a lot of time these days... Scott >>> Robert Herriot 01/09 3:51 PM >>> You email reminds me of another ambiguously defined attribute. If a printer has several URI's, we have already said that the job attribute containing printer should be the printer uri that is "useful" for the client and may be different from the one to which the job was submitted. But with GetJobs, what is printer-uri part of the job-uri for each job if the job-uri consists of the printer uri and a job-identifier? Is the printer-uri part the original printer-uri to which the job was submitted or the one that would come back with 'containing-printer". I favor the latter. Bob Herriot > From ipp-owner@pwg.org Fri Jan 9 08:51:59 1998 > > At the telecon last Wednesday, we agreed to change the Printer object's > single-valued "printer-uri" attribute to a multi-valued > "printer-uri-supported" attribute. And keep the single-valued "printer-uri" > operation attribute for use in operation requests and responses. > > This note looks at the first section affected by this change to show > the impact. I think this is a good change, but it does require a lot > of careful re-work of the wording. Here is an attempt: > > Now Printer objects can be identified by one or more URIs, but jobs remain > with a single URI. However, each Printer object is still uniquely > identified by each of its URIs, if it has more than one URI. > > We also need to be careful to distinguish between the concept of a Printer URI > and the "printer-uri" operation attribute. The former is always two > separate words (with Printer and URI capitalized) and the latter is > a single hyphenated word with double quotes and all lower case. > > We need to fix section 2.4 and other parts of the document accordingly. > > Also we have to be careful, since the Printer object now has the renamed > multi-valued: "printer-uri-supported" attribute. It no longer has the > same name as the single-valued "printer-uri" operation attribute. So we have > to be careful to update the document each time we mention "printer-uri" > to make sure that is is refering to the "printer-uri" operation attribute > or the "printer-uri-supported" Printer object attribute. In some places, > we might be even talking about both, and so need to change the single > mention of "printer-uri" attribute to "printer-uri" operation attribute > and "printer-uri-supported" Printer attribute. > > For example of the changes, here is section 2.4 on object identity > with possible changes (we can't talk about the "printer-uri" operation > attribute yet, since operations are described later): > > >2.4 Object Identity > > > >All Printer and Job objects are identified by an identifier so that they > >can be persistently and unambiguously referenced. The IPP/1.0 model > >requires that these identifiers be Uniform Resource Identifiers (URIs) > >[RFC1630]. Often, the URI is a URL [RFC1738] [RFC1808]. > > I suggest adding to the end of the paragraph above: > > A Printer object MAY have one or more identifies that uniquely identify > the Printer object, depending on implementation. These Printer URIs > are contained in the Printer object's potentially multi-valued > "printer-uri-supported" attribute. Job objects SHALL have > only one unique identifier. This Job URI is contained in the Job object's > "job-uri" attribute. > > > > >IPP/1.0 does not specify how the URI is obtained, but it is RECOMMENDED > >that a Printer object is registered in a directory service which end users > >and programs can interrogate. Section 16 defines a generic schema for > >Printer object entries in the directory service. > > > >Allowing Job objects to have URIs allows for flexibility and scalability. > >In some implementations, the Printer object might create Jobs that are > >processed in the same local environment as the Printer object itself. In > >this case, the Job URI might just be a composition of the Printer's URI and > >some unique component for the Job object, such as the unique 32-bit > >positive integer mentioned later in this paragraph. In other > >implementations, the Printer object might be a central clearing-house for > >validating all Job object creation requests, and the Job object itself > >might be created in some environment that is remote from the Printer > >object. In this case, the Job object's URI may have no relationship at all > >to the Printer object's URI. However, many existing printing systems have > >local models or interface constraints that force Job objects to be > >identified using only a 32-bit positive integer rather than a URI. This > >numeric Job ID is only unique within the context of the Printer object to > >which the create request was originally submitted. In order to allow both > >types of client access to Jobs (either by Job URI or by numeric Job ID), > >when the Printer object successfully processes a create request and creates > >a new Job, the Printer object SHALL generate both a Job URI and a Job ID > >for the new Job object. This requirement allows all clients to access > >Printer objects and Job objects no matter the local constraints imposed on > >the client implementation. > > In order to fix the paragraph above, we need to introduce the concept that > a create operation specifies a single Printer URI, without introducing the > concept of operation attributes yet. I suggest adding a preceding paragraph: > > When a job is submitted to the Printer object, the client MUST supply a > single Printer URI which is one of the URIs that uniquely identify that > Printer object and is one of the values in that Printer object's > "printer-uri-supported" attribute. > > Then the long paragraph above can be fixed by replacing > "Printer's URI" and "Printer object's URI" with "Printer URI supplied > by the client when submitting the job" yielding: > > Allowing Job objects to have URIs allows for flexibility and scalability. > In some implementations, the Printer object might create Jobs that are > processed in the same local environment as the Printer object itself. In > this case, the Job URI might just be a composition of the > Printer URI supplied by the client when submitting the job > and some unique component for the Job object, such as the unique 32-bit > positive integer mentioned later in this paragraph. In other > implementations, the Printer object might be a central clearing-house for > validating all Job object creation requests, and the Job object itself > might be created in some environment that is remote from the Printer > object. In this case, the Job object's URI may have no relationship at all > to the > Printer URI supplied by the client when submitting the job. > However, many existing printing systems have > local models or interface constraints that force Job objects to be > identified using only a 32-bit positive integer rather than a URI. This > numeric Job ID is only unique within the context of the Printer object to > which the create request was originally submitted. In order to allow both > types of client access to Jobs (either by Job URI or by numeric Job ID), > when the Printer object successfully processes a create request and creates > a new Job, the Printer object SHALL generate both a Job URI and a Job ID > for the new Job object. This requirement allows all clients to access > Printer objects and Job objects no matter the local constraints imposed on > the client implementation. > > > > > >In addition to a unique identifier, Printer objects and Job objects have > >names. An object name need not be unique across all instances of all > >objects. A Printer object's name is chosen and set by an administrator > >through some mechanism outside the scope of IPP/1.0. A Job object's name > >is optionally chosen and supplied by the IPP client submitting the job. If > >the client does not supply a Job object name, the Printer object generates > >a name for the new Job object. In all cases, the name only has local > >meaning; the name is not constrained to be unique. > > Probably just replace "a unique identifier" with "unique identifiers" > in the first sentence in the paragraph above. > > > > >To summarize: > > > >- Each Printer object is uniquely identified with a URI. The Printer's > >"printer-uri" attribute contains the URI. > > Change the paragraph to: > > - Each Printer object is identified by one or more unique URIs. The > Printer's multi-valued "printer-uri-supported" attribute contains these URIs. > > > > >- Each Job object is uniquely identified with a URI. The Job's "job-uri" > >attribute contains the URI. > > > >- Each Job object is also uniquely identified with a combination of the URI > >of the Printer object to which the create request was originally submitted > >along with a Job ID (a 32-bit, positive integer) that is unique within the > >context of that Printer object. The Printer object's "printer-uri" > >contains the Printer URI. The Job object's "job-id" attribute contains the > >numeric Job ID. > > In order to fix this paragraph, we need to introduce the concept that > a create operation specifies a single Printer URI, without introducing the > concept of operation attributes yet. Also we can introduce the > "containing-printer-uri" attribute, since it is a connection between > the Job object and the Printer object. I suggest re-writing the paragraph > as: > > - When a job is submitted, the client MUST supply a single Printer URI > which is one of the URIs that uniquely identify the Printer object and > is one of the values in the Printer's "printer-uri-supported" attribute. > Each Job object is also uniquely identified with a combination of the > Printer URI supplied in the original create request along with a Job ID > (a 32-bit, positive integer) that is unique within the context of that > Printer object. The Printer object's "containing-printer-uri" contains > the Printer URI supplied in the create request. The Job object's "job-id" > attribute contains the numeric Job ID. > > > > > >- Each Printer object has a name (which is not necessarily unique). The > >administrator chooses and sets this name through some mechanism outside the > >scope of IPP/1.0 itself. The Printer object's "printer-name" attribute > >contains the name. > > > >- Each Job object has a name (which is not necessarily unique). The client > >optionally supplies this name in the create request. If the client does > >not supply this name, the Printer object generates a name for the Job > >object. The Job object's "job-name" attribute contains the name. > > > > From ipp-owner@pwg.org Fri Jan 9 20:50:04 1998 Delivery-Date: Fri, 09 Jan 1998 20:50:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA20065 for ; Fri, 9 Jan 1998 20:50:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19114 for ; Fri, 9 Jan 1998 20:52:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA00322 for ; Fri, 9 Jan 1998 20:49:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 20:32:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28073 for ipp-outgoing; Fri, 9 Jan 1998 18:35:40 -0500 (EST) Date: Fri, 9 Jan 1998 15:34:53 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801092334.PAA01881@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO new protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have just downloaded the latest version of the protocol document to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. The documents are: ipp-pro-980109.doc MS Word Version 6 with no revisions ipp-pro-980109-rev.doc MS Word Version 6 with revisions ipp-pro-980109.txt text with no revisions, same as draft-ietf-ipp-protocol-05.txt submitted to IETF today. This is the version that will go to the IESG if we reject XML and stay with the current protocol. From ipp-owner@pwg.org Fri Jan 9 21:05:34 1998 Delivery-Date: Fri, 09 Jan 1998 21:05:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA20153 for ; Fri, 9 Jan 1998 21:05:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA19137 for ; Fri, 9 Jan 1998 21:08:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA01131 for ; Fri, 9 Jan 1998 21:05:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 20:44:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28442 for ipp-outgoing; Fri, 9 Jan 1998 19:11:44 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 09 Jan 1998 17:08:16 -0700 From: Scott Isaacson To: paulmo@microsoft.com, ipp@pwg.org Cc: moore@cs.utk.edu, MMACKAY@novell.com, Harald.T.Alvestrand@uninett.no Subject: Re: IPP> Delay of IPP ratification Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Paul, There has to be some process in any standards body working group. We had final call for the working group close about a month ago and since then we have been working issues raised during final call - not new issues. Granted, the IESG has not had final call and really any issues are still open as long as we follow that process, it is just that this should have come up ealier. Keith has commented that he expected some comments during the larger final call time frame. Having said that, I am an technologist at heart and so I am always interested in the best technical solution. Best technologies to not always a standard make. The current protocol document is in the form that it is in because of the valid Microsoft and HP proposals that were made 9 months ago. As I recall the problem wasn't structured data in an ascii protocol, it was using a binary protocol rather than an ascii one for lower overhead in processing and performance reasons. I am convinced that the current protocol spec is not broken and that what we have will work (since many of us have already been doing prototyping). There would have to be a compelling reason to change now. Just becuase there are other working groups doing it, it not compelling to me. Just becuase it is a "new wave" is not compelling to me. Here is my major point: You do, however, raise vaild points about XML. It is a growing thing. It is a valid candidate. The WebDAV WG has found it be useful. But, one of our early goals for IPP was "speed to market" (so to speak) so that we could come to consensus before some new technology came over us an swallowed us up and we had to start over with the new technology. We are just on the verge here - we have a gold-master candidate and we are about ready to ship product. Do we "ship the product" with what we have fought for a year over and finally come to consensus on (paying the price with people's and company's time and resources) or to we hold up the product and wait to integrate in the next new feature? The classic question that we all face every day. I personally feel is that it is too late in the process for infusion of new things. This protocol mapping issue was discussed in Memphis (4/97) and Munich(8/97) with full understanding and consensus on the mailing list throughout the whole period. There were NO issues raised about this on the mailing list during final call. There were NO issues raised in Washington. It is too late. We need to ship. We are not broken. We do not NEED to integrate with the up and coming wave of anything or we will never ship, we will always be chasing. Having said all that, I would be willing to consider the following: Take the time to review a FULL proposal on an XML mapping for IPP on top of HTTP POSTs as new encoding rules for version 1.0 of the new "application/ipp" MIME media type if the following conditions are true: 1. That you (or someone) can contribute resources to deliver a full proposal, distributed to the working group (via the DL) prior to the face-to-face meeting on 1/21-22/98. 2. The proposal is limited to a data representation and encoding of the current Model and Semantics. We are not touching the model and semantics. There will be no revisiting the proposed use of new HTTP domain-specific methods. We SHALL NOT (can you tell I have been an editor too long!) not revisit the issue of POST vs new HTTP methods. 3. The working group can reach consensus (at the meeting, via a toll free phone call, on the DL) that there is a way to proceed with the XML mapping that will yield closure to all issues (given the limited scope of #2) in a matter of weeks, not months. 4. The area directors comment and approve of the proposed direction before the 1/21 meeting. I hope that these assumptions were in the intent of your email in the first place. I am a little worried about the use of the parenthetical phrase you added "(and protocol specific HTTP commands)". Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Paul Moore 01/09 11:21 AM >>> This is a formal request that we delay the finalization of the IPP spec until we have looked at the possibility of using XML as the protocol format. I know this is revisiting an old issue but we need to make sure we do the right thing. When the current format was proposed there was no good method for representing structured data in an ASCII data stream. XML is now available and seem to be the coming wave. I also know that most of the new standards that will come out over the next year will be based around XML (and protocol specific HTTP commands). By ensuring that we are in the centre of these standards we will be able to leverage many common tools that will emerge to support and manage these protocols. There will definitely be down-sides so we need to debate this issue - not least the investment that some of us have already made in building using the current spec. I think that somebody from MS will be in Hawaii. Paul Moore From ipp-owner@pwg.org Fri Jan 9 21:29:52 1998 Delivery-Date: Fri, 09 Jan 1998 21:29:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA20261 for ; Fri, 9 Jan 1998 21:29:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA19167 for ; Fri, 9 Jan 1998 21:32:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA01912 for ; Fri, 9 Jan 1998 21:29:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 21:15:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00323 for ipp-outgoing; Fri, 9 Jan 1998 20:49:53 -0500 (EST) Message-Id: <3.0.1.32.19980109174503.00fc2700@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 Jan 1998 17:45:03 PST To: Harry Lewis From: Tom Hastings Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value Cc: In-Reply-To: <5030300016645235000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 15:28 01/09/1998 PST, Harry Lewis wrote: >Tom, > >>It is overridden by the PDL, as long as the PDL not 'text/plain' or >>any document that has the orientation instructions embedded in the >PDL. > >I think you mean ... any document that DOESN'T have the orientation >instruction in the PDL... right?? Yes. > >Maybe I haven't made myself clear that what seems out of place to me is the >opposition of the following... > >Section 2.2, pg. 15 >"job-templet" attributes... include job processing instructions... intended to >override... embedded... document data. > >AND > >4.2.10... the definition of Orientation (a job-templet attribute) which clearly >calls out PDL override. > > An object or attribute who's DEFINITION says the PDL will override does not >belong in this category, in my opinion! (Or the category is ill defined or >described). > >In retrospect, just changing the name to include "plain-text" is probably not >the best solution since the problem pertains to >ANY form of data sent to the printer which is not encapsulated in a PDL (ex. >image). I agree with you. The "orientation" attribute really has the semantics of an IPP "orientation-default" attribute because it only takes effect if the document data does not have an instruction embedded in it. Currently client don't submit "xxx-default" attributes in IPP, though we had about 9 such attributes in DPA that had the semantics of only taking effect if the document content had no corresponding instruction. Those 9 DPA attributes are (in DPA we put "default" first): default-medium default-input-tray default-font default-resources (electronic form, bit map, etc. that is in the printer library) default-character-set default-character-mapping default-printer-resolution In fact, the IPP "document-natural-language" operation attribute is similar to the IPP "orientation" (being renamed to "orientation-requested") job template attribute, in that it only applies to documents that need it. So another approach would be to move the "orientation-requested" attribute from the Job Template group to become an operation attribute for Print-Job, Validate-Job, Print-URI, Send-Document, and Send-URI, just like we have: "document-format" and "compression". Operation attributes are a grab bag of attributes, while Job Template attributes have more regular semantics as you point out. Tom > >Harry Lewis - IBM Printing Systems > > > > >hastings@cp10.es.xerox.coM on 01/09/98 11:06:27 AM >Please respond to hastings@cp10.es.xerox.coM @ internet >To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus >cc: >Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value > > >At 07:37 01/09/1998 PST, Harry Lewis wrote: >>I tried to send this yesterday but there was a problem... >> >>Harry Lewis - IBM Printing Systems >> >> >>---------------------- Forwarded by Harry Lewis/Boulder/IBM on 01/09/98 >08:22 AM >> --------------------------- >> >> >>Harry Lewis >>01/08/98 04:43 PM >>To: ipp@pwg.org @ internet >>cc: >>From: Harry Lewis/Boulder/IBM @ IBMUS >>Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value >> >>Since job-template attributes are intended to override embedded print stream >>instructions, I'm confused by 4.2.10 orientation-requested (type2 enum) >which, >>by its definition, indicates the opposite (this attribute WILL be >overridden by >>the PDL as a matter of course, if I understand correctly). > >It is overriden by the PDL, as long as the PDL not 'text/plain' or >any document that has the orientation instructions embedded in the PDL. > >> >>If we're just trying to address "plain-text" with this attribute, then >maybe it >>should be called "plain-text-default-orientation"? > >It maybe good to include "plain-text" in the name. However, I don't >think we need to include "default", since for plain text it isn't the >default, its what the client is asking the Printer to do and an IPP >printer that supports "plain-text-orientation" MUST be able to handle >whatever values the "plain-text-orientation-supported" attribute contains. > >Alternatively, we haven't (yet) considered the client being able to >submit "xxx-default" attributes. In this case, if the attribute >were "orientation-default" that the client supplies, then any PDL >that embeds orientation would override and any PDL that doesn't >contain an orientation, such as 'text/plain', would be affected by >the "orientation-default" attribute. > >> >>Otherwise, this particular attribute appears to go against the grain with >>respect to the intent of job-template attributes. I think it is unique in >this >>sense which could be why we are struggling with the definition. > >Good observation. I agree. > >> >>Harry Lewis - IBM Printing Systems >> >> >> >> >>ipp-owner@pwg.org on 01/08/98 10:04:56 AM >>Please respond to ipp-owner@pwg.org @ internet >>To: hastings@cp10.es.xerox.com @ internet, ipp@pwg.org @ internet >>cc: >>Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value >> >> >>I suggest the following wording for the paragraphs 4.2.10 that Tom wrote >>and I enclose below: >> >>My wording: >>----------------------------------------------- >>For documents whose document-format does not explicitly specify the >>orientation (e.g. text/plain), this attribute specifies the >>client-requested orientation of the content of the print-stream pages >>when they are printed. For documents whose document-format does explicitly >>specify the orientation (e.g. PostScript), this attribute has no meaning -- >>it neither alters the orientation nor specifies the existing orientation. >>----------------------------------------------- >>Tom's wording: >> >>> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 >>> Proposed new text: >>> >>> 4.2.10 orientation-requested (type2 enum) >>> >>> This attribute specifies the orientation of the content of the print-stream >>> pages to be printed. In most cases, the orientation of the content is >>> specified within the document format generated by the device driver at >>> print time. However, some document formats (such as 'text/plain') do not >>> support the notion of page orientation, and it is possible to bind the >>> orientation after the document content has been generated. This attribute >>> provides an end user with the means to specify orientation for such >>> documents when the IPP Printer performs the formatting. >>> >> >> >> >> >> >> >> >> >> > > > > From ipp-owner@pwg.org Fri Jan 9 22:43:47 1998 Delivery-Date: Fri, 09 Jan 1998 22:43:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22388 for ; Fri, 9 Jan 1998 22:43:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19324 for ; Fri, 9 Jan 1998 22:46:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA03694 for ; Fri, 9 Jan 1998 22:43:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 22:21:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27929 for ipp-outgoing; Fri, 9 Jan 1998 18:05:00 -0500 (EST) Message-Id: <3.0.1.32.19980109150240.00b939c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 Jan 1998 15:02:40 PST To: Paul Moore , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> Delay of IPP ratification In-Reply-To: <5CEA8663F24DD111A96100805FFE6587C084B7@red-msg-51.dns.micr osoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 10:21 AM 1/9/98 PST, Paul Moore wrote: >This is a formal request that we delay the finalization of the IPP spec >until we have looked at the possibility of using XML as the protocol format. > >I know this is revisiting an old issue but we need to make sure we do the >right thing. When the current format was proposed there was no good method >for representing structured data in an ASCII data stream. XML is now >available and seem to be the coming wave. I also know that most of the new >standards that will come out over the next year will be based around XML >(and protocol specific HTTP commands). By ensuring that we are in the centre >of these standards we will be able to leverage many common tools that will >emerge to support and manage these protocols. > >There will definitely be down-sides so we need to debate this issue - not >least the investment that some of us have already made in building using the >current spec. > >I think that somebody from MS will be in Hawaii. > >Paul Moore > Paul, This kind of thing should not really happen. We have been through all our formal steps to get agreements within the IPP WG and seemed to have full agreement up to this message. Having said that, we certainly also do not want to end up with people implementing different flavours of IPP that do not interoperate, or we have missed our goal as a standards group. If we were to even consider looking at an alternative proposal at this 12th hour in the project, I expect to see some dedicated resource commitment from MS experts to rapidly come up with a detailed proposal on how all the current protocol functions could be expressed in the alternative proposal. Are you prepared to make such a commitment, or else we close the discussion right here? I think that a first draft from you within the next two weeks would be expected. I will wait a couple of days to allow people on the DL to respond to your message and then take it from there. I urge the members of the DL to come back with your views on this subject ASAP. Regards, Carl-Uno Manros In my role as IPP Co-chair Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 9 22:43:48 1998 Delivery-Date: Fri, 09 Jan 1998 22:43:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22393 for ; Fri, 9 Jan 1998 22:43:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19326 for ; Fri, 9 Jan 1998 22:46:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA03695 for ; Fri, 9 Jan 1998 22:43:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 22:22:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28023 for ipp-outgoing; Fri, 9 Jan 1998 18:24:06 -0500 (EST) From: Harry Lewis To: Cc: Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value Message-ID: <5030300016645235000002L052*@MHS> Date: Fri, 9 Jan 1998 18:28:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id WAA22393 Tom, >It is overridden by the PDL, as long as the PDL not 'text/plain' or >any document that has the orientation instructions embedded in the >PDL. I think you mean ... any document that DOESN'T have the orientation instruction in the PDL... right?? Maybe I haven't made myself clear that what seems out of place to me is the opposition of the following... Section 2.2, pg. 15 "job-templet" attributes... include job processing instructions... intended to override... embedded... document data. AND 4.2.10... the definition of Orientation (a job-templet attribute) which clearly calls out PDL override. An object or attribute who's DEFINITION says the PDL will override does not belong in this category, in my opinion! (Or the category is ill defined or described). In retrospect, just changing the name to include "plain-text" is probably not the best solution since the problem pertains to ANY form of data sent to the printer which is not encapsulated in a PDL (ex. image). Harry Lewis - IBM Printing Systems hastings@cp10.es.xerox.coM on 01/09/98 11:06:27 AM Please respond to hastings@cp10.es.xerox.coM @ internet To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value At 07:37 01/09/1998 PST, Harry Lewis wrote: >I tried to send this yesterday but there was a problem... > >Harry Lewis - IBM Printing Systems > > >---------------------- Forwarded by Harry Lewis/Boulder/IBM on 01/09/98 08:22 AM > --------------------------- > > >Harry Lewis >01/08/98 04:43 PM >To: ipp@pwg.org @ internet >cc: >From: Harry Lewis/Boulder/IBM @ IBMUS >Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value > >Since job-template attributes are intended to override embedded print stream >instructions, I'm confused by 4.2.10 orientation-requested (type2 enum) which, >by its definition, indicates the opposite (this attribute WILL be overridden by >the PDL as a matter of course, if I understand correctly). It is overriden by the PDL, as long as the PDL not 'text/plain' or any document that has the orientation instructions embedded in the PDL. > >If we're just trying to address "plain-text" with this attribute, then maybe it >should be called "plain-text-default-orientation"? It maybe good to include "plain-text" in the name. However, I don't think we need to include "default", since for plain text it isn't the default, its what the client is asking the Printer to do and an IPP printer that supports "plain-text-orientation" MUST be able to handle whatever values the "plain-text-orientation-supported" attribute contains. Alternatively, we haven't (yet) considered the client being able to submit "xxx-default" attributes. In this case, if the attribute were "orientation-default" that the client supplies, then any PDL that embeds orientation would override and any PDL that doesn't contain an orientation, such as 'text/plain', would be affected by the "orientation-default" attribute. > >Otherwise, this particular attribute appears to go against the grain with >respect to the intent of job-template attributes. I think it is unique in this >sense which could be why we are struggling with the definition. Good observation. I agree. > >Harry Lewis - IBM Printing Systems > > > > >ipp-owner@pwg.org on 01/08/98 10:04:56 AM >Please respond to ipp-owner@pwg.org @ internet >To: hastings@cp10.es.xerox.com @ internet, ipp@pwg.org @ internet >cc: >Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value > > >I suggest the following wording for the paragraphs 4.2.10 that Tom wrote >and I enclose below: > >My wording: >----------------------------------------------- >For documents whose document-format does not explicitly specify the >orientation (e.g. text/plain), this attribute specifies the >client-requested orientation of the content of the print-stream pages >when they are printed. For documents whose document-format does explicitly >specify the orientation (e.g. PostScript), this attribute has no meaning -- >it neither alters the orientation nor specifies the existing orientation. >----------------------------------------------- >Tom's wording: > >> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 >> Proposed new text: >> >> 4.2.10 orientation-requested (type2 enum) >> >> This attribute specifies the orientation of the content of the print-stream >> pages to be printed. In most cases, the orientation of the content is >> specified within the document format generated by the device driver at >> print time. However, some document formats (such as 'text/plain') do not >> support the notion of page orientation, and it is possible to bind the >> orientation after the document content has been generated. This attribute >> provides an end user with the means to specify orientation for such >> documents when the IPP Printer performs the formatting. >> > > > > > > > > > From ipp-owner@pwg.org Fri Jan 9 23:01:38 1998 Delivery-Date: Fri, 09 Jan 1998 23:01:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA24754 for ; Fri, 9 Jan 1998 23:01:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19361 for ; Fri, 9 Jan 1998 23:04:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA04605 for ; Fri, 9 Jan 1998 23:01:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 22:46:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02407 for ipp-outgoing; Fri, 9 Jan 1998 21:49:55 -0500 (EST) Message-Id: <1.5.4.32.19980110014956.006f5ef4@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: Fri, 09 Jan 1998 17:49:56 -0800 To: Robert.Herriot@Eng.Sun.COM (Robert Herriot) From: Carl-Uno Manros Subject: Re: IPP>PRO new protocol document Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 03:34 PM 1/9/98 -0800, you wrote: > >I have just downloaded the latest version of the protocol document to: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. > >The documents are: > > ipp-pro-980109.doc MS Word Version 6 with no revisions > ipp-pro-980109-rev.doc MS Word Version 6 with revisions > ipp-pro-980109.txt text with no revisions, same as > draft-ietf-ipp-protocol-05.txt submitted > to IETF today. > > >This is the version that will go to the IESG if we reject XML and >stay with the current protocol. > Bob, I think there is no reason to NOT send it in to the IETF now, whatever happenes with a new proposal. Carl-Uno From ipp-owner@pwg.org Fri Jan 9 23:10:45 1998 Delivery-Date: Fri, 09 Jan 1998 23:10:46 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27488 for ; Fri, 9 Jan 1998 23:10:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19389 for ; Fri, 9 Jan 1998 23:13:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA05166 for ; Fri, 9 Jan 1998 23:10:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 22:55:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02465 for ipp-outgoing; Fri, 9 Jan 1998 22:04:47 -0500 (EST) Message-Id: <1.5.4.32.19980110020141.00709f24@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: Fri, 09 Jan 1998 18:01:41 -0800 To: Scott Isaacson From: Carl-Uno Manros Subject: Re: IPP> Delay of IPP ratification Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 05:08 PM 1/9/98 -0700, you wrote: >Paul, > >There has to be some process in any standards body working group. We had >final call for the working group close about a month ago and since then we >have been working issues raised during final call - not new issues. >Granted, the IESG has not had final call and really any issues are still >open as long as we follow that process, it is just that this should have >come up ealier. Keith has commented that he expected some comments during >the larger final call time frame. --- snip, snip --- > >Having said all that, I would be willing to consider the following: > >Take the time to review a FULL proposal on an XML mapping for IPP on top of >HTTP POSTs as new encoding rules for version 1.0 of the new >"application/ipp" MIME media type if the following conditions are true: > >1. That you (or someone) can contribute resources to deliver a full >proposal, distributed to the working group (via the DL) prior to the >face-to-face meeting on 1/21-22/98. > --- snip , snip --- Scott, Thanks for your comments. One thing you got wrong were the dates for the next PWG IPP meeting. The meeting is actually on Januari 28 and 29. As I asked Paul in a previous message, can he have a draft for us by January 23, which would give him two weeks to write it and a couple of days for us to read it and get comments on the DL before the meeting. Carl-Uno From ipp-owner@pwg.org Fri Jan 9 23:27:33 1998 Delivery-Date: Fri, 09 Jan 1998 23:27:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27561 for ; Fri, 9 Jan 1998 23:27:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19423 for ; Fri, 9 Jan 1998 23:30:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA06888 for ; Fri, 9 Jan 1998 23:27:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 23:07:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27869 for ipp-outgoing; Fri, 9 Jan 1998 17:51:31 -0500 (EST) Date: Fri, 9 Jan 1998 14:51:18 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801092251.OAA01813@woden.eng.sun.com> To: SISAACSON@novell.com, ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Fix Section 2.4 Object Identify with multiple Printer URIs X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org You email reminds me of another ambiguously defined attribute. If a printer has several URI's, we have already said that the job attribute containing printer should be the printer uri that is "useful" for the client and may be different from the one to which the job was submitted. But with GetJobs, what is printer-uri part of the job-uri for each job if the job-uri consists of the printer uri and a job-identifier? Is the printer-uri part the original printer-uri to which the job was submitted or the one that would come back with 'containing-printer". I favor the latter. Bob Herriot > From ipp-owner@pwg.org Fri Jan 9 08:51:59 1998 > > At the telecon last Wednesday, we agreed to change the Printer object's > single-valued "printer-uri" attribute to a multi-valued > "printer-uri-supported" attribute. And keep the single-valued "printer-uri" > operation attribute for use in operation requests and responses. > > This note looks at the first section affected by this change to show > the impact. I think this is a good change, but it does require a lot > of careful re-work of the wording. Here is an attempt: > > Now Printer objects can be identified by one or more URIs, but jobs remain > with a single URI. However, each Printer object is still uniquely > identified by each of its URIs, if it has more than one URI. > > We also need to be careful to distinguish between the concept of a Printer URI > and the "printer-uri" operation attribute. The former is always two > separate words (with Printer and URI capitalized) and the latter is > a single hyphenated word with double quotes and all lower case. > > We need to fix section 2.4 and other parts of the document accordingly. > > Also we have to be careful, since the Printer object now has the renamed > multi-valued: "printer-uri-supported" attribute. It no longer has the > same name as the single-valued "printer-uri" operation attribute. So we have > to be careful to update the document each time we mention "printer-uri" > to make sure that is is refering to the "printer-uri" operation attribute > or the "printer-uri-supported" Printer object attribute. In some places, > we might be even talking about both, and so need to change the single > mention of "printer-uri" attribute to "printer-uri" operation attribute > and "printer-uri-supported" Printer attribute. > > For example of the changes, here is section 2.4 on object identity > with possible changes (we can't talk about the "printer-uri" operation > attribute yet, since operations are described later): > > >2.4 Object Identity > > > >All Printer and Job objects are identified by an identifier so that they > >can be persistently and unambiguously referenced. The IPP/1.0 model > >requires that these identifiers be Uniform Resource Identifiers (URIs) > >[RFC1630]. Often, the URI is a URL [RFC1738] [RFC1808]. > > I suggest adding to the end of the paragraph above: > > A Printer object MAY have one or more identifies that uniquely identify > the Printer object, depending on implementation. These Printer URIs > are contained in the Printer object's potentially multi-valued > "printer-uri-supported" attribute. Job objects SHALL have > only one unique identifier. This Job URI is contained in the Job object's > "job-uri" attribute. > > > > >IPP/1.0 does not specify how the URI is obtained, but it is RECOMMENDED > >that a Printer object is registered in a directory service which end users > >and programs can interrogate. Section 16 defines a generic schema for > >Printer object entries in the directory service. > > > >Allowing Job objects to have URIs allows for flexibility and scalability. > >In some implementations, the Printer object might create Jobs that are > >processed in the same local environment as the Printer object itself. In > >this case, the Job URI might just be a composition of the Printer's URI and > >some unique component for the Job object, such as the unique 32-bit > >positive integer mentioned later in this paragraph. In other > >implementations, the Printer object might be a central clearing-house for > >validating all Job object creation requests, and the Job object itself > >might be created in some environment that is remote from the Printer > >object. In this case, the Job object's URI may have no relationship at all > >to the Printer object's URI. However, many existing printing systems have > >local models or interface constraints that force Job objects to be > >identified using only a 32-bit positive integer rather than a URI. This > >numeric Job ID is only unique within the context of the Printer object to > >which the create request was originally submitted. In order to allow both > >types of client access to Jobs (either by Job URI or by numeric Job ID), > >when the Printer object successfully processes a create request and creates > >a new Job, the Printer object SHALL generate both a Job URI and a Job ID > >for the new Job object. This requirement allows all clients to access > >Printer objects and Job objects no matter the local constraints imposed on > >the client implementation. > > In order to fix the paragraph above, we need to introduce the concept that > a create operation specifies a single Printer URI, without introducing the > concept of operation attributes yet. I suggest adding a preceding paragraph: > > When a job is submitted to the Printer object, the client MUST supply a > single Printer URI which is one of the URIs that uniquely identify that > Printer object and is one of the values in that Printer object's > "printer-uri-supported" attribute. > > Then the long paragraph above can be fixed by replacing > "Printer's URI" and "Printer object's URI" with "Printer URI supplied > by the client when submitting the job" yielding: > > Allowing Job objects to have URIs allows for flexibility and scalability. > In some implementations, the Printer object might create Jobs that are > processed in the same local environment as the Printer object itself. In > this case, the Job URI might just be a composition of the > Printer URI supplied by the client when submitting the job > and some unique component for the Job object, such as the unique 32-bit > positive integer mentioned later in this paragraph. In other > implementations, the Printer object might be a central clearing-house for > validating all Job object creation requests, and the Job object itself > might be created in some environment that is remote from the Printer > object. In this case, the Job object's URI may have no relationship at all > to the > Printer URI supplied by the client when submitting the job. > However, many existing printing systems have > local models or interface constraints that force Job objects to be > identified using only a 32-bit positive integer rather than a URI. This > numeric Job ID is only unique within the context of the Printer object to > which the create request was originally submitted. In order to allow both > types of client access to Jobs (either by Job URI or by numeric Job ID), > when the Printer object successfully processes a create request and creates > a new Job, the Printer object SHALL generate both a Job URI and a Job ID > for the new Job object. This requirement allows all clients to access > Printer objects and Job objects no matter the local constraints imposed on > the client implementation. > > > > > >In addition to a unique identifier, Printer objects and Job objects have > >names. An object name need not be unique across all instances of all > >objects. A Printer object's name is chosen and set by an administrator > >through some mechanism outside the scope of IPP/1.0. A Job object's name > >is optionally chosen and supplied by the IPP client submitting the job. If > >the client does not supply a Job object name, the Printer object generates > >a name for the new Job object. In all cases, the name only has local > >meaning; the name is not constrained to be unique. > > Probably just replace "a unique identifier" with "unique identifiers" > in the first sentence in the paragraph above. > > > > >To summarize: > > > >- Each Printer object is uniquely identified with a URI. The Printer's > >"printer-uri" attribute contains the URI. > > Change the paragraph to: > > - Each Printer object is identified by one or more unique URIs. The > Printer's multi-valued "printer-uri-supported" attribute contains these URIs. > > > > >- Each Job object is uniquely identified with a URI. The Job's "job-uri" > >attribute contains the URI. > > > >- Each Job object is also uniquely identified with a combination of the URI > >of the Printer object to which the create request was originally submitted > >along with a Job ID (a 32-bit, positive integer) that is unique within the > >context of that Printer object. The Printer object's "printer-uri" > >contains the Printer URI. The Job object's "job-id" attribute contains the > >numeric Job ID. > > In order to fix this paragraph, we need to introduce the concept that > a create operation specifies a single Printer URI, without introducing the > concept of operation attributes yet. Also we can introduce the > "containing-printer-uri" attribute, since it is a connection between > the Job object and the Printer object. I suggest re-writing the paragraph > as: > > - When a job is submitted, the client MUST supply a single Printer URI > which is one of the URIs that uniquely identify the Printer object and > is one of the values in the Printer's "printer-uri-supported" attribute. > Each Job object is also uniquely identified with a combination of the > Printer URI supplied in the original create request along with a Job ID > (a 32-bit, positive integer) that is unique within the context of that > Printer object. The Printer object's "containing-printer-uri" contains > the Printer URI supplied in the create request. The Job object's "job-id" > attribute contains the numeric Job ID. > > > > > >- Each Printer object has a name (which is not necessarily unique). The > >administrator chooses and sets this name through some mechanism outside the > >scope of IPP/1.0 itself. The Printer object's "printer-name" attribute > >contains the name. > > > >- Each Job object has a name (which is not necessarily unique). The client > >optionally supplies this name in the create request. If the client does > >not supply this name, the Printer object generates a name for the Job > >object. The Job object's "job-name" attribute contains the name. > > > > From ipp-owner@pwg.org Fri Jan 9 23:30:07 1998 Delivery-Date: Fri, 09 Jan 1998 23:30:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27585 for ; Fri, 9 Jan 1998 23:30:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19435 for ; Fri, 9 Jan 1998 23:32:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA07268 for ; Fri, 9 Jan 1998 23:30:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 23:11:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27968 for ipp-outgoing; Fri, 9 Jan 1998 18:10:06 -0500 (EST) Date: Fri, 9 Jan 1998 15:08:39 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801092308.PAA01825@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, paulmo@microsoft.com, jkm@underscore.com Subject: Re: IPP> Delay of IPP ratification Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Jay, I cannot give you any more details at this time because I haven't thought about it enough. At this time, I don't know whether XML is a great idea or a terrible idea. But XML is an important enough emerging standard that we should not dismiss it without examining what the IPP protocol would look like in XML and what its benefits would be. Because the time is short, we need to make a decision quickly. We also need enough details from XML experts, such as those at Microsoft, to make an informed decision. Bob Herriot > From jkm@underscore.com Fri Jan 9 14:06:25 1998 > > Bob and Paul, > > Care to elucidate on the merits and applicability of XML to the IPP > model? Any known/expected problems in mapping? Any particular > benefits over alternative approaches? > > Perhaps most importantly, exactly *why* should XML even be > considered in the first place? > > Bob says that "XML is becoming an important protocol." We can all > think of lots of emerging protocols that may be viewed as important, > but are they applicable to network printing? How and why is XML > applicable to a network printing protocol? > > Please understand that I am not casting any kind of early vote > against XML here. Just trying to figure out why XML has suddenly > entered the fray. > > ...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 -- > ---------------------------------------------------------------------- > > > Robert Herriot wrote: > > > > I agree with Paul that we should spend some time looking at XML before > > we commit to the current protocol. XML is becoming an important protocol. > > > > Bob Herriot > > > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > > From: Paul Moore > > > To: "'ipp@pwg.org'" > > > Subject: IPP> Delay of IPP ratification > > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > > X-Mailer: Internet Mail Service (5.5.1960.3) > > > Sender: ipp-owner@pwg.org > > > Content-Length: 942 > > > X-Lines: 19 > > > > > > This is a formal request that we delay the finalization of the IPP spec > > > until we have looked at the possibility of using XML as the protocol format. > > > > > > I know this is revisiting an old issue but we need to make sure we do the > > > right thing. When the current format was proposed there was no good method > > > for representing structured data in an ASCII data stream. XML is now > > > available and seem to be the coming wave. I also know that most of the new > > > standards that will come out over the next year will be based around XML > > > (and protocol specific HTTP commands). By ensuring that we are in the centre > > > of these standards we will be able to leverage many common tools that will > > > emerge to support and manage these protocols. > > > > > > There will definitely be down-sides so we need to debate this issue - not > > > least the investment that some of us have already made in building using the > > > current spec. > > > > > > I think that somebody from MS will be in Hawaii. > > > > > > Paul Moore > > > > From ipp-owner@pwg.org Fri Jan 9 23:36:47 1998 Delivery-Date: Fri, 09 Jan 1998 23:36:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27911 for ; Fri, 9 Jan 1998 23:36:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19443 for ; Fri, 9 Jan 1998 23:39:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08024 for ; Fri, 9 Jan 1998 23:36:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 23:18:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28118 for ipp-outgoing; Fri, 9 Jan 1998 18:43:25 -0500 (EST) Date: Fri, 9 Jan 1998 15:37:53 -0800 (Pacific Standard Time) From: Ron Bergman To: ipp@pwg.org Subject: Re: IPP> Delay of IPP ratification In-Reply-To: <34B69F3F.7F2EAC2E@underscore.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I would like to echo some of the points presented by Jay. I thought that XML was a presentation layer protocol developed as the next generation HTML. Does XML include functionality beyond the presentation layer? If not, why would XML be any different than PostScript, PCL or HTML? Can anyone provide the URL to the current XML specification or tutorial for those persons (such as myself) who are not very knowledgeable regarding XML? I would like to be somewhat prepared if this does become a discussion topic in Maui. Ron Bergman Dataproducts Corp. On Fri, 9 Jan 1998, Jay Martin wrote: > Bob and Paul, > > Care to elucidate on the merits and applicability of XML to the IPP > model? Any known/expected problems in mapping? Any particular > benefits over alternative approaches? > > Perhaps most importantly, exactly *why* should XML even be > considered in the first place? > > Bob says that "XML is becoming an important protocol." We can all > think of lots of emerging protocols that may be viewed as important, > but are they applicable to network printing? How and why is XML > applicable to a network printing protocol? > > Please understand that I am not casting any kind of early vote > against XML here. Just trying to figure out why XML has suddenly > entered the fray. > > ...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 -- > ---------------------------------------------------------------------- > > > Robert Herriot wrote: > > > > I agree with Paul that we should spend some time looking at XML before > > we commit to the current protocol. XML is becoming an important protocol. > > > > Bob Herriot > > > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > > From: Paul Moore > > > To: "'ipp@pwg.org'" > > > Subject: IPP> Delay of IPP ratification > > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > > X-Mailer: Internet Mail Service (5.5.1960.3) > > > Sender: ipp-owner@pwg.org > > > Content-Length: 942 > > > X-Lines: 19 > > > > > > This is a formal request that we delay the finalization of the IPP spec > > > until we have looked at the possibility of using XML as the protocol format. > > > > > > I know this is revisiting an old issue but we need to make sure we do the > > > right thing. When the current format was proposed there was no good method > > > for representing structured data in an ASCII data stream. XML is now > > > available and seem to be the coming wave. I also know that most of the new > > > standards that will come out over the next year will be based around XML > > > (and protocol specific HTTP commands). By ensuring that we are in the centre > > > of these standards we will be able to leverage many common tools that will > > > emerge to support and manage these protocols. > > > > > > There will definitely be down-sides so we need to debate this issue - not > > > least the investment that some of us have already made in building using the > > > current spec. > > > > > > I think that somebody from MS will be in Hawaii. > > > > > > Paul Moore > > > > From ipp-owner@pwg.org Fri Jan 9 23:38:28 1998 Delivery-Date: Fri, 09 Jan 1998 23:38:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27922 for ; Fri, 9 Jan 1998 23:38:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19446 for ; Fri, 9 Jan 1998 23:41:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08187 for ; Fri, 9 Jan 1998 23:38:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 23:20:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27941 for ipp-outgoing; Fri, 9 Jan 1998 18:06:12 -0500 (EST) Message-Id: <3.0.1.32.19980109150136.00c0c990@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 9 Jan 1998 15:01:36 PST To: Harry Lewis , From: Tom Hastings Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value In-Reply-To: <5030300016633811000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 07:37 01/09/1998 PST, Harry Lewis wrote: >I tried to send this yesterday but there was a problem... > >Harry Lewis - IBM Printing Systems > > >---------------------- Forwarded by Harry Lewis/Boulder/IBM on 01/09/98 08:22 AM > --------------------------- > > >Harry Lewis >01/08/98 04:43 PM >To: ipp@pwg.org @ internet >cc: >From: Harry Lewis/Boulder/IBM @ IBMUS >Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value > >Since job-template attributes are intended to override embedded print stream >instructions, I'm confused by 4.2.10 orientation-requested (type2 enum) which, >by its definition, indicates the opposite (this attribute WILL be overridden by >the PDL as a matter of course, if I understand correctly). It is overriden by the PDL, as long as the PDL not 'text/plain' or any document that has the orientation instructions embedded in the PDL. > >If we're just trying to address "plain-text" with this attribute, then maybe it >should be called "plain-text-default-orientation"? It maybe good to include "plain-text" in the name. However, I don't think we need to include "default", since for plain text it isn't the default, its what the client is asking the Printer to do and an IPP printer that supports "plain-text-orientation" MUST be able to handle whatever values the "plain-text-orientation-supported" attribute contains. Alternatively, we haven't (yet) considered the client being able to submit "xxx-default" attributes. In this case, if the attribute were "orientation-default" that the client supplies, then any PDL that embeds orientation would override and any PDL that doesn't contain an orientation, such as 'text/plain', would be affected by the "orientation-default" attribute. > >Otherwise, this particular attribute appears to go against the grain with >respect to the intent of job-template attributes. I think it is unique in this >sense which could be why we are struggling with the definition. Good observation. I agree. > >Harry Lewis - IBM Printing Systems > > > > >ipp-owner@pwg.org on 01/08/98 10:04:56 AM >Please respond to ipp-owner@pwg.org @ internet >To: hastings@cp10.es.xerox.com @ internet, ipp@pwg.org @ internet >cc: >Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value > > >I suggest the following wording for the paragraphs 4.2.10 that Tom wrote >and I enclose below: > >My wording: >----------------------------------------------- >For documents whose document-format does not explicitly specify the >orientation (e.g. text/plain), this attribute specifies the >client-requested orientation of the content of the print-stream pages >when they are printed. For documents whose document-format does explicitly >specify the orientation (e.g. PostScript), this attribute has no meaning -- >it neither alters the orientation nor specifies the existing orientation. >----------------------------------------------- >Tom's wording: > >> From hastings@cp10.es.xerox.com Wed Jan 7 18:21:58 1998 >> Proposed new text: >> >> 4.2.10 orientation-requested (type2 enum) >> >> This attribute specifies the orientation of the content of the print-stream >> pages to be printed. In most cases, the orientation of the content is >> specified within the document format generated by the device driver at >> print time. However, some document formats (such as 'text/plain') do not >> support the notion of page orientation, and it is possible to bind the >> orientation after the document content has been generated. This attribute >> provides an end user with the means to specify orientation for such >> documents when the IPP Printer performs the formatting. >> > > > > > > > > > From ipp-owner@pwg.org Fri Jan 9 23:39:19 1998 Delivery-Date: Fri, 09 Jan 1998 23:39:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27927 for ; Fri, 9 Jan 1998 23:39:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19456 for ; Fri, 9 Jan 1998 23:42:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08252 for ; Fri, 9 Jan 1998 23:39:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 Jan 1998 23:20:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27894 for ipp-outgoing; Fri, 9 Jan 1998 17:54:38 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2BC361C@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'Jay Martin'" , Robert Herriot , Paul Moore , Yaron Goland , "'masinter@parc.xerox.com'" Cc: ipp@pwg.org Subject: RE: IPP> Delay of IPP ratification Date: Fri, 9 Jan 1998 14:53:49 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I think that the current IPP does not adequately address security concerns, and that the landscape wrt XML has changed such that it should be reconsidered. At this point our efforts are not to conclusively move IPP to XML, but to open it for consideration. XML is becoming a widely accepted way of expressing arbitrary data types, schemas, or property attributes. As it stands IPP is a new binary protocol specifically for printing. Any firewall or proxy that wishes to securely support it will have to have IPP specific features coded into it. In the future if other Internet protocols continue this trend, proxies and firewalls will need continual update for each protocol. At first glance XML appears to offer a standard way of expressing the functionality of IPP in a standard way. While an administrator might need to configure his firewall or proxy to specifically look for IPP verbs or XML schemas, it doesnt require the proxy product to be re-coded or altered. It also shouldnt require CGI, NSAPI, or ISAPI coding either. Our point is that we should investigate this as a possibility. You might respond by saying that "we already looked at XML". I would respond to that by saying that the landscape has changed. XML has progressed a lot, and it is gaining widespread acceptance in many efforts as a schema definition method. Therefore it is worthy to consider again with the new facts at hand. In addition to the XML issue, I also beleive that using POST is not optimal. I think that printing as a function is not something that firewalls and proxies would want to allow just because they allow HTTP. Rather then depending on HTTP to carry IPP through the "problem" of firewalls and proxies, proceeding on the current path is actually circumventing security policies without the consent of the administrators. Something that can work with existing proxies, but only after being explicitly configured or allowed (in most proxies) is more appropriate for the print functionality. As a firewall administrator it is up to me what funtionality I permit through my firewall and as it stands now IPP tricks me into thinking that Im allowing HTTP when Im really exposing printers to potentially unwanted load and resource consumption. If we need to change IPP to fit future needs and interoperability, we should do so. If we hold off on IESG last call, we can have frank technical discussions on how to improve IPP. If IPP moves forward to IESG last call without considering these options, by which we mean working group discussion for a period of time, I beleive that IPP present a less than optimal solution. Given the choice of spending extra time to get it right and holding off on moving to IESG, or standing up during IESG last call to oppose the IETF standardization of IPP, I would prefer the first. (wait and fix it) On the other hand, if IPP moves IESG last call as is, I beleive that we will stand up in opposition. -- Josh Cohen Program Manager - Internet Technologies > -----Original Message----- > From: Jay Martin [mailto:jkm@underscore.com] > Sent: Friday, January 09, 1998 2:06 PM > To: Robert Herriot; Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> Delay of IPP ratification > > > Bob and Paul, > > Care to elucidate on the merits and applicability of XML to the IPP > model? Any known/expected problems in mapping? Any particular > benefits over alternative approaches? > > Perhaps most importantly, exactly *why* should XML even be > considered in the first place? > > Bob says that "XML is becoming an important protocol." We can all > think of lots of emerging protocols that may be viewed as important, > but are they applicable to network printing? How and why is XML > applicable to a network printing protocol? > > Please understand that I am not casting any kind of early vote > against XML here. Just trying to figure out why XML has suddenly > entered the fray. > > ...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 -- > ---------------------------------------------------------------------- > > > Robert Herriot wrote: > > > > I agree with Paul that we should spend some time looking at XML before > > we commit to the current protocol. XML is becoming an important protocol. > > > > Bob Herriot > > > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > > From: Paul Moore > > > To: "'ipp@pwg.org'" > > > Subject: IPP> Delay of IPP ratification > > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > > X-Mailer: Internet Mail Service (5.5.1960.3) > > > Sender: ipp-owner@pwg.org > > > Content-Length: 942 > > > X-Lines: 19 > > > > > > This is a formal request that we delay the finalization of the IPP spec > > > until we have looked at the possibility of using XML as the > protocol format. > > > > > > I know this is revisiting an old issue but we need to make sure we do the > > > right thing. When the current format was proposed there was no good method > > > for representing structured data in an ASCII data stream. XML is now > > > available and seem to be the coming wave. I also know that most of the new > > > standards that will come out over the next year will be based around XML > > > (and protocol specific HTTP commands). By ensuring that we are in > the centre > > > of these standards we will be able to leverage many common tools that will > > > emerge to support and manage these protocols. > > > > > > There will definitely be down-sides so we need to debate this issue - not > > > least the investment that some of us have already made in > building using the > > > current spec. > > > > > > I think that somebody from MS will be in Hawaii. > > > > > > Paul Moore > > > > From ipp-owner@pwg.org Sat Jan 10 00:13:47 1998 Delivery-Date: Sat, 10 Jan 1998 00:13:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA28117 for ; Sat, 10 Jan 1998 00:13:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA19474 for ; Sat, 10 Jan 1998 00:16:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA09539 for ; Sat, 10 Jan 1998 00:13:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 10 Jan 1998 00:06:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08135 for ipp-outgoing; Fri, 9 Jan 1998 23:37:51 -0500 (EST) Date: Fri, 9 Jan 1998 20:37:25 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801100437.UAA02738@woden.eng.sun.com> To: ipp@pwg.org, rbergma@dpc.com Subject: Re: IPP> Delay of IPP ratification X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Try www.w3.org/TR The following document describes XML: http://www.w3.org/TR/PR-xml (8 Dec 1997) The following document describes XSL which are style sheets for XML. I'm not sure if this is important for us. http://www.w3.org/TR/NOTE-XSL-970910 > From ipp-owner@pwg.org Fri Jan 9 20:25:25 1998 > Date: Fri, 9 Jan 1998 15:37:53 -0800 (Pacific Standard Time) > From: Ron Bergman > To: ipp@pwg.org > Subject: Re: IPP> Delay of IPP ratification > In-Reply-To: <34B69F3F.7F2EAC2E@underscore.com> > X-X-Sender: rbergma@newmai.dpc.com > MIME-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 87 > > I would like to echo some of the points presented by Jay. > > I thought that XML was a presentation layer protocol developed as the next > generation HTML. Does XML include functionality beyond the presentation > layer? > > If not, why would XML be any different than PostScript, PCL or HTML? > > Can anyone provide the URL to the current XML specification or tutorial > for those persons (such as myself) who are not very knowledgeable > regarding XML? I would like to be somewhat prepared if this does become a > discussion topic in Maui. > > Ron Bergman > Dataproducts Corp. > > > > On Fri, 9 Jan 1998, Jay Martin wrote: > > > Bob and Paul, > > > > Care to elucidate on the merits and applicability of XML to the IPP > > model? Any known/expected problems in mapping? Any particular > > benefits over alternative approaches? > > > > Perhaps most importantly, exactly *why* should XML even be > > considered in the first place? > > > > Bob says that "XML is becoming an important protocol." We can all > > think of lots of emerging protocols that may be viewed as important, > > but are they applicable to network printing? How and why is XML > > applicable to a network printing protocol? > > > > Please understand that I am not casting any kind of early vote > > against XML here. Just trying to figure out why XML has suddenly > > entered the fray. > > > > ...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 -- > > ---------------------------------------------------------------------- > > > > > > Robert Herriot wrote: > > > > > > I agree with Paul that we should spend some time looking at XML before > > > we commit to the current protocol. XML is becoming an important protocol. > > > > > > Bob Herriot > > > > > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > > > From: Paul Moore > > > > To: "'ipp@pwg.org'" > > > > Subject: IPP> Delay of IPP ratification > > > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > > > X-Mailer: Internet Mail Service (5.5.1960.3) > > > > Sender: ipp-owner@pwg.org > > > > Content-Length: 942 > > > > X-Lines: 19 > > > > > > > > This is a formal request that we delay the finalization of the IPP spec > > > > until we have looked at the possibility of using XML as the protocol format. > > > > > > > > I know this is revisiting an old issue but we need to make sure we do the > > > > right thing. When the current format was proposed there was no good method > > > > for representing structured data in an ASCII data stream. XML is now > > > > available and seem to be the coming wave. I also know that most of the new > > > > standards that will come out over the next year will be based around XML > > > > (and protocol specific HTTP commands). By ensuring that we are in the centre > > > > of these standards we will be able to leverage many common tools that will > > > > emerge to support and manage these protocols. > > > > > > > > There will definitely be down-sides so we need to debate this issue - not > > > > least the investment that some of us have already made in building using the > > > > current spec. > > > > > > > > I think that somebody from MS will be in Hawaii. > > > > > > > > Paul Moore > > > > > > > > From ipp-owner@pwg.org Sat Jan 10 00:13:48 1998 Delivery-Date: Sat, 10 Jan 1998 00:13:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA28121 for ; Sat, 10 Jan 1998 00:13:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA19475 for ; Sat, 10 Jan 1998 00:16:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA09535 for ; Sat, 10 Jan 1998 00:13:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 10 Jan 1998 00:06:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07240 for ipp-outgoing; Fri, 9 Jan 1998 23:29:47 -0500 (EST) Date: Fri, 9 Jan 1998 20:29:00 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801100429.UAA02731@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, carl@manros.com Subject: Re: IPP>PRO new protocol document Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have already sent the protocol document as my text below ipp-pro-980109.txt indicates. > From carl@manros.com Fri Jan 9 18:49:22 1998 > X-Sender: cumanros@pop3.holonet.net > X-Mailer: Windows Eudora Light Version 1.5.4 (32) > Mime-Version: 1.0 > Date: Fri, 09 Jan 1998 17:49:56 -0800 > To: Robert.Herriot@Eng (Robert Herriot) > From: Carl-Uno Manros > Subject: Re: IPP>PRO new protocol document > Cc: ipp@pwg.org > X-Lines: 26 > > At 03:34 PM 1/9/98 -0800, you wrote: > > > >I have just downloaded the latest version of the protocol document to: > > > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. > > > >The documents are: > > > > ipp-pro-980109.doc MS Word Version 6 with no revisions > > ipp-pro-980109-rev.doc MS Word Version 6 with revisions > > ipp-pro-980109.txt text with no revisions, same as > > draft-ietf-ipp-protocol-05.txt submitted > > to IETF today. > > > > > >This is the version that will go to the IESG if we reject XML and > >stay with the current protocol. > > > > Bob, > > I think there is no reason to NOT send it in to the IETF now, > whatever happenes with a new proposal. > > Carl-Uno > > From ipp-owner@pwg.org Sat Jan 10 13:18:07 1998 Delivery-Date: Sat, 10 Jan 1998 13:18:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA00946 for ; Sat, 10 Jan 1998 13:18:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA20062 for ; Sat, 10 Jan 1998 13:20:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11912 for ; Sat, 10 Jan 1998 13:18:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 10 Jan 1998 13:08:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11318 for ipp-outgoing; Sat, 10 Jan 1998 12:54:14 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Josh Cohen'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Delay of IPP ratification Date: Sat, 10 Jan 1998 09:51:15 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org If a corporate entity wants to protect internal printing resources, which I agree are valuable (consumables, time, etc...) then the current IPP documents support the protection of these resources via authentication. I would propose that this authentication be done with TLS, but HTTP-specific autnentication might also be considered. What you have outlined as the ability to open up something between "wide-open", and "authenticated-access" I'm not sure would be used by entities attempting to protect internal printing resources. If I open my printing resources to the internet, then I want to know "who" is using the resource. IPP has provided a transport-independent protocol (TLS/SSL3) to accomplish this. And I believe most current web servers support SSL3, which is configurable to interoperate with TLS. If there is a security concern with the use of SSL3/TLS, then perhaps we should be discussing this, and not changing the entire nature of the protocol encoding. Randy > -----Original Message----- > From: Josh Cohen [SMTP:joshco@microsoft.com] > Sent: Friday, January 09, 1998 2:54 PM > To: 'Jay Martin'; Robert Herriot; Paul Moore; Yaron Goland; > 'masinter@parc.xerox.com' > Cc: ipp@pwg.org > Subject: RE: IPP> Delay of IPP ratification > > I think that the current IPP does not adequately address > security concerns, and that the landscape wrt XML has > changed such that it should be reconsidered. > > At this point our efforts are not to conclusively move > IPP to XML, but to open it for consideration. > XML is becoming a widely accepted way of expressing > arbitrary data types, schemas, or property attributes. > > As it stands IPP is a new binary protocol specifically > for printing. Any firewall or proxy that wishes to > securely support it will have to have IPP specific features > coded into it. In the future if other Internet protocols > continue this trend, proxies and firewalls will need > continual update for each protocol. > > At first glance XML appears to offer a standard way of > expressing the functionality of IPP in a standard way. > While an administrator might need to configure his > firewall or proxy to specifically look for IPP > verbs or XML schemas, it doesnt require the proxy product > to be re-coded or altered. It also shouldnt require > CGI, NSAPI, or ISAPI coding either. > > Our point is that we should investigate this as a > possibility. You might respond by saying that > "we already looked at XML". I would respond > to that by saying that the landscape has changed. > XML has progressed a lot, and it is gaining > widespread acceptance in many efforts as a > schema definition method. Therefore it is worthy > to consider again with the new facts at hand. > > In addition to the XML issue, I also beleive that > using POST is not optimal. I think that printing > as a function is not something that firewalls and proxies > would want to allow just because they allow HTTP. > Rather then depending on HTTP to carry IPP through > the "problem" of firewalls and proxies, proceeding > on the current path is actually circumventing security > policies without the consent of the administrators. > Something that can work with existing proxies, but > only after being explicitly configured or allowed > (in most proxies) is more appropriate for the print > functionality. > > As a firewall administrator it is up to me what > funtionality I permit through my firewall and as it > stands now IPP tricks me into thinking that Im > allowing HTTP when Im really exposing printers to > potentially unwanted load and resource consumption. > > > If we need to change IPP to fit future needs and > interoperability, we should do so. > > If we hold off on IESG last call, we can have frank > technical discussions on how to improve IPP. > > If IPP moves forward to IESG last call without > considering these options, by which we mean working > group discussion for a period of time, I beleive > that IPP present a less than optimal solution. > Given the choice of spending extra time to get it > right and holding off on moving to IESG, or > standing up during IESG last call to oppose the > IETF standardization of IPP, I would prefer the first. > (wait and fix it) > > On the other hand, if IPP moves IESG last call as is, > I beleive that we will stand up in opposition. > > -- > Josh Cohen > Program Manager - Internet Technologies > > > -----Original Message----- > > From: Jay Martin [mailto:jkm@underscore.com] > > Sent: Friday, January 09, 1998 2:06 PM > > To: Robert Herriot; Paul Moore > > Cc: ipp@pwg.org > > Subject: Re: IPP> Delay of IPP ratification > > > > > > Bob and Paul, > > > > Care to elucidate on the merits and applicability of XML to the IPP > > model? Any known/expected problems in mapping? Any particular > > benefits over alternative approaches? > > > > Perhaps most importantly, exactly *why* should XML even be > > considered in the first place? > > > > Bob says that "XML is becoming an important protocol." We can all > > think of lots of emerging protocols that may be viewed as important, > > but are they applicable to network printing? How and why is XML > > applicable to a network printing protocol? > > > > Please understand that I am not casting any kind of early vote > > against XML here. Just trying to figure out why XML has suddenly > > entered the fray. > > > > ...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 > -- > > > ---------------------------------------------------------------------- > > > > > > Robert Herriot wrote: > > > > > > I agree with Paul that we should spend some time looking at XML > before > > > we commit to the current protocol. XML is becoming an important > protocol. > > > > > > Bob Herriot > > > > > > > From ipp-owner@pwg.org Fri Jan 9 10:42:58 1998 > > > > From: Paul Moore > > > > To: "'ipp@pwg.org'" > > > > Subject: IPP> Delay of IPP ratification > > > > Date: Fri, 9 Jan 1998 10:21:33 -0800 > > > > X-Mailer: Internet Mail Service (5.5.1960.3) > > > > Sender: ipp-owner@pwg.org > > > > Content-Length: 942 > > > > X-Lines: 19 > > > > > > > > This is a formal request that we delay the finalization of the > IPP > spec > > > > until we have looked at the possibility of using XML as the > > protocol format. > > > > > > > > I know this is revisiting an old issue but we need to make sure > we do > the > > > > right thing. When the current format was proposed there was no > good > method > > > > for representing structured data in an ASCII data stream. XML is > now > > > > available and seem to be the coming wave. I also know that most > of the > new > > > > standards that will come out over the next year will be based > around > XML > > > > (and protocol specific HTTP commands). By ensuring that we are > in > > the centre > > > > of these standards we will be able to leverage many common tools > that > will > > > > emerge to support and manage these protocols. > > > > > > > > There will definitely be down-sides so we need to debate this > issue - > not > > > > least the investment that some of us have already made in > > building using the > > > > current spec. > > > > > > > > I think that somebody from MS will be in Hawaii. > > > > > > > > Paul Moore > > > > > > From ipp-owner@pwg.org Sat Jan 10 14:10:42 1998 Delivery-Date: Sat, 10 Jan 1998 14:10:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA01088 for ; Sat, 10 Jan 1998 14:10:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA20124 for ; Sat, 10 Jan 1998 14:13:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12655 for ; Sat, 10 Jan 1998 14:10:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 10 Jan 1998 14:05:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12061 for ipp-outgoing; Sat, 10 Jan 1998 13:51:03 -0500 (EST) Message-Id: <1.5.4.32.19980110174704.007016a8@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, 10 Jan 1998 09:47:04 -0800 To: Josh Cohen , "'Jay Martin'" , Robert Herriot , Paul Moore , Yaron Goland , "'masinter@parc.xerox.com'" From: Carl-Uno Manros Subject: RE: IPP> Delay of IPP ratification Cc: ipp@pwg.org Sender: ipp-owner@pwg.org At 02:53 PM 1/9/98 -0800, Josh Cohen wrote: >I think that the current IPP does not adequately address >security concerns, and that the landscape wrt XML has >changed such that it should be reconsidered. > Josh, You are basing all your reasoning around the firewall issue. Are you aware that we actually also specifiy the use of TLS for people who want to secure their printers? This is REAL security compared to firewalls. Also, your reasoning seems to be based on the assumption that everything runs over a common Web server that supports both Web services and printing. I think that you will find that IPP print servers and embedded IPP servers in printers will more commonly have their own dedicated HTTP servers, which makes it easy for a firewall to filter them. We have been over these issues in detail for the past year. Don't think that you are coming along telling us something new. Hence, I think you need to widen your horizons quite a lot, rather than concentrating all your thinking around your own favorite NT scenario. Carl-Uno From ipp-owner@pwg.org Sat Jan 10 19:11:30 1998 Delivery-Date: Sat, 10 Jan 1998 19:11:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA01984 for ; Sat, 10 Jan 1998 19:11:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20414 for ; Sat, 10 Jan 1998 19:14:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA13687 for ; Sat, 10 Jan 1998 19:11:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 10 Jan 1998 19:05:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA13104 for ipp-outgoing; Sat, 10 Jan 1998 18:50:38 -0500 (EST) Date: Sat, 10 Jan 1998 15:55:12 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801102355.AA22973@snorkel.eso.mc.xerox.com> To: Robert.Herriot@Eng.Sun.COM, carl@manros.com, jkm@underscore.com, joshco@microsoft.com, masinter@parc.xerox.com, paulmo@microsoft.com, yarong@microsoft.com Subject: RE: IPP> Delay of IPP ratification Cc: imcdonal@eso.mc.xerox.com, ipp@pwg.org Sender: ipp-owner@pwg.org Hi folks, Saturday (10 January 1998) I'm not very sympathetic to this "12th hour" request for an XML rewrite of the IPP Protocol spec...I'd like to comment on some hidden effects of Paul Moore's request. At present the IPP message ('application/ipp') is free-standing - while a few attributes are mapped into HTTP/1.1 header fields, one is allowed (by the IPP Model) to wrap all IPP attributes (including "operation-id") in the IPP message. So 'application/ipp' can be moved equally well via interactive (HTTP/1.1) or store-and-forward (SMTP) protocols. Josh and Paul are opposed to using HTTP Post to convey IPP messages, but their rationale is faulty. While firewalls shouldn't have to examine the content of every incoming HTTP message, they now routinely examine various HTTP header fields (for security and other site-policy reasons), and 'Content-Type' of 'application/ipp' couldn't be plainer! Adding new HTTP verbs for IPP will just make mappings of IPP to other protocols harder in the future, which works against ubiquity. My two cents, - Ira McDonald (High North, outside consultant at Xerox) From ipp-owner@pwg.org Mon Jan 12 08:57:01 1998 Delivery-Date: Mon, 12 Jan 1998 08:57:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16217 for ; Mon, 12 Jan 1998 08:56:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02192 for ; Mon, 12 Jan 1998 08:59:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA18685 for ; Mon, 12 Jan 1998 08:56:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 08:47:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA18092 for ipp-outgoing; Mon, 12 Jan 1998 08:33:18 -0500 (EST) From: Roger K Debry To: Cc: , , , , , Subject: RE: IPP> Delay of IPP ratification Message-ID: <5030100016023014000002L042*@MHS> Date: Mon, 12 Jan 1998 08:32:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA16217 Josh, I suggest you need to substantiate your claims on security! The group has worked very hard to insure, through the use of TLS, that an administrator can protect his or her print resources. Frankly, I think Microsoft should be terribly embarrased to veto the standards proposal at the last minute, based on incorrect information. After all, Microsoft has purported to be an active participant in the development of IPP. -- Josh Cohen Program Manager - Internet Technologies From ipp-owner@pwg.org Mon Jan 12 09:39:33 1998 Delivery-Date: Mon, 12 Jan 1998 09:39:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16819 for ; Mon, 12 Jan 1998 09:39:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02402 for ; Mon, 12 Jan 1998 09:42:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA19370 for ; Mon, 12 Jan 1998 09:39:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 09:31:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA18794 for ipp-outgoing; Mon, 12 Jan 1998 09:17:16 -0500 (EST) From: Roger K Debry To: Subject: IPP> Microsoft's XML pages Message-ID: <5030100016024621000002L012*@MHS> Date: Mon, 12 Jan 1998 09:17:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA16819 Check out http://www.microsoft.com/xml to find out more about XML, and how Microsoft will use it. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Mon Jan 12 11:54:05 1998 Delivery-Date: Mon, 12 Jan 1998 11:54:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18406 for ; Mon, 12 Jan 1998 11:54:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02899 for ; Mon, 12 Jan 1998 11:56:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20868 for ; Mon, 12 Jan 1998 11:54:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 11:39:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19683 for ipp-outgoing; Mon, 12 Jan 1998 11:09:58 -0500 (EST) Mime-Version: 1.0 Date: Mon, 12 Jan 1998 11:16:16 -0500 Message-ID: <00038619.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re: IPP> Delay of IPP ratification 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 ______________________________ Reply Separator _________________________________ Subject: IPP> Delay of IPP ratification Author: Paul Moore at INTERNET Date: 1/9/98 10:21 AM Paul: Would you please enumerate the standards that you are referencing in your statement below? Philip Thambidurai Paul Moore stated: > ... ... > I also know that most of the new > standards that will come out over the next year will be based around XML > (and protocol specific HTTP commands). By ensuring that we are in the centre > of these standards we will be able to leverage many common tools that will > emerge to support and manage these protocols. > ... From ipp-owner@pwg.org Mon Jan 12 11:54:15 1998 Delivery-Date: Mon, 12 Jan 1998 11:54:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18412 for ; Mon, 12 Jan 1998 11:54:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02902 for ; Mon, 12 Jan 1998 11:56:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20886 for ; Mon, 12 Jan 1998 11:54:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 11:38:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19710 for ipp-outgoing; Mon, 12 Jan 1998 11:11:53 -0500 (EST) Message-Id: <1.5.4.32.19980112150905.0075a468@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Jan 1998 07:09:05 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - How to learn about XML Sender: ipp-owner@pwg.org Hi, I just checked out my local bookstore on XML books over the weekend. I found two, hot off the press: - "Presenting XML" by Richard Light ISBN 1-5721-334-6 - $24.99 - "XML Complete" by Steven Holzner ISBN 0-07-913702-4 (with CD-ROM) $44.95 Prices may vary a bit I suppose. The first of these two spends more time on "Why XML", comparing it to SGML and HTML, while the second delves directly into teaching you "How to write" XML, and has more details and examples. I haven't actually got very far in reading any of them yet, but both should give you a quick impression about the capabilities of XML, if you want to go beyond what you find for free on the Internet. One Internet resource that I found is: http://www.chrystal.com/ which has some tutorial material and also points to a number of other free Internet sites for information on XML. Good reading, Carl-Uno From ipp-owner@pwg.org Mon Jan 12 12:43:56 1998 Delivery-Date: Mon, 12 Jan 1998 12:43:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19722 for ; Mon, 12 Jan 1998 12:43:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03223 for ; Mon, 12 Jan 1998 12:46:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21706 for ; Mon, 12 Jan 1998 12:43:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 12:37:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21124 for ipp-outgoing; Mon, 12 Jan 1998 12:22:56 -0500 (EST) Message-Id: <3.0.1.32.19980112091644.0106ce20@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 09:16:44 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Remove last 4 attr from Job Template table Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The Dec 19 version still has the four attributes in the Job Template table that the rest of the document has moved to be operation attributes: "compression", "job-k-octets", "job-impressions", "job-media-sheets". Tom From ipp-owner@pwg.org Mon Jan 12 13:23:12 1998 Delivery-Date: Mon, 12 Jan 1998 13:23:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20286 for ; Mon, 12 Jan 1998 13:23:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03390 for ; Mon, 12 Jan 1998 13:25:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA22426 for ; Mon, 12 Jan 1998 13:22:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 13:12:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21819 for ipp-outgoing; Mon, 12 Jan 1998 12:57:44 -0500 (EST) Message-Id: <3.0.1.32.19980112095305.00fa6aa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 09:53:05 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> Move "orientation-requested" from J.T. to Operation attribute group? Cc: Bob Pentecost , "Rick, DECprint engineer without portfolio, DTN 297-8350 (1-508-467-) MRO1-2/K20 23-Sep-1997 1834 -0400" , David Kellerman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org 1. So should we move "orientation-requested" from being a Job Template attribute to being an operation attribute, since it applies only to documents that don't have orientation embedded in the document and is not requesting to override the document? Job Template attributes are intended to be requests to override what is in the document data (as Harry Lewis points out). If we do make it an operation attribute on Print-Job, Validate-Job, Print-URI, Send-Document, and Send-URI, we also need to move the corresponding "orientation-requested-default" and "orientation-requested-supported" to the Printer object's Printer Description group. (NOTE: such movement will be the fifth attribute that we have moved from the Job Template attributes group to the Operation attributes and Printer Description attributes group (the other 4 being: "compression", "job-k-octets", "job-impressions", and "job-media-sheets".) 2a. Should we rename the operation attribute from "orientation-requested" to "orientation-default", since it is not a request to override the PDL data, but only to be used if the PDL data does not contain an orientation instruction. BTW, I think that this attribute can apply to other PDLs, than 'text/plain' which can NEVER contain an orientation instruction. However, I suspect that other PDLs, such as PCL and DEC-PPL3, can have an OPTIONAL orientation embedded instruction. (Hence the cc list). When a document is being printed in which the optional instruction was omitted, the "orientation-default" attribute could be used to control the orienation. Therefore, the semantics are exactly those of any "xxx-default" attribute, except that this attribute is being supplied by the client, instead of the Printer object. If we do rename the atribute, then the corresponding Printer Description attributes would become: "orientation-default-default" and "orientation-default-suppoted". 2b. Or could we say that the Printer Description attribute is really the same as the operation attribute, since they have the same semantics and so call the Printer Description attributes: "orientation-default" and "orientation-default-supported"? We currently have the "job-name" as an operation attribute which is the same as the "job-name" Job description attribute, so having an attribute with the same name in these two different groups would be the same idea for the "orientation-default" operation attribute. We've agreed that we can't have the same name for an attribute in the Job Template attribute group and any other group. Comments? Tom From ipp-owner@pwg.org Mon Jan 12 13:35:31 1998 Delivery-Date: Mon, 12 Jan 1998 13:35:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20444 for ; Mon, 12 Jan 1998 13:35:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03457 for ; Mon, 12 Jan 1998 13:38:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23061 for ; Mon, 12 Jan 1998 13:35:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 13:31:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21865 for ipp-outgoing; Mon, 12 Jan 1998 13:12:08 -0500 (EST) Message-Id: <3.0.1.32.19980112100727.0106fa80@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 10:07:27 PST To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), SISAACSON@novell.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Fix Section 2.4 Object Identify with multiple Printer URIs In-Reply-To: <199801092251.OAA01813@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 14:51 01/09/1998 PST, Robert Herriot wrote: >You email reminds me of another ambiguously defined attribute. > >If a printer has several URI's, we have already said that the job >attribute containing printer should be the printer uri that is "useful" >for the client and may be different from the one to which the job was >submitted. > >But with GetJobs, what is printer-uri part of the job-uri for each job >if the job-uri consists of the printer uri and a job-identifier? Is >the printer-uri part the original printer-uri to which the job was >submitted or the one that would come back with 'containing-printer". I >favor the latter. I agree. In other words, the "job-uri" attribute that comes back in any response is one that the client receiving the response could use in a Get-Job-Attributes operation, i.e., it has the same security URI capabilities as the one that the client supplied in the request that is returning the "job-uri" (if the implementation uses different URI schemes for different security access). This same statement needs to be made for the "containing-printer-uri" job attribute as well. In other words, the "containing-printer-uri" attribute that comes back in any response is one that the client receiving the response could use in a Get-Printer-Attributes operation, i.e., it has the same security URI capabilities as the one that the client supplied in the request that is returning the "job-uri" (if the implementation uses different URI schemes for different security access). NOTE: All this discussion makes it even more desirable for an IPP object implementor to use the same URI for TLS and non-TLS, to avoid having to generate URIs on the fly for a response for the "job-uri" and "containing-printer-uri". BTW, this above detail may be too much detail to put into section 2.4 on object identity. It may best be put into the description of the "job-uri" and "containing-printer-uri" attributes. Tom > >Bob Herriot >> From ipp-owner@pwg.org Fri Jan 9 08:51:59 1998 >> >> At the telecon last Wednesday, we agreed to change the Printer object's >> single-valued "printer-uri" attribute to a multi-valued >> "printer-uri-supported" attribute. And keep the single-valued "printer-uri" >> operation attribute for use in operation requests and responses. >> >> This note looks at the first section affected by this change to show >> the impact. I think this is a good change, but it does require a lot >> of careful re-work of the wording. Here is an attempt: >> >> Now Printer objects can be identified by one or more URIs, but jobs remain >> with a single URI. However, each Printer object is still uniquely >> identified by each of its URIs, if it has more than one URI. >> >> We also need to be careful to distinguish between the concept of a Printer URI >> and the "printer-uri" operation attribute. The former is always two >> separate words (with Printer and URI capitalized) and the latter is >> a single hyphenated word with double quotes and all lower case. >> >> We need to fix section 2.4 and other parts of the document accordingly. >> >> Also we have to be careful, since the Printer object now has the renamed >> multi-valued: "printer-uri-supported" attribute. It no longer has the >> same name as the single-valued "printer-uri" operation attribute. So we have >> to be careful to update the document each time we mention "printer-uri" >> to make sure that is is refering to the "printer-uri" operation attribute >> or the "printer-uri-supported" Printer object attribute. In some places, >> we might be even talking about both, and so need to change the single >> mention of "printer-uri" attribute to "printer-uri" operation attribute >> and "printer-uri-supported" Printer attribute. >> >> For example of the changes, here is section 2.4 on object identity >> with possible changes (we can't talk about the "printer-uri" operation >> attribute yet, since operations are described later): >> >> >2.4 Object Identity >> > >> >All Printer and Job objects are identified by an identifier so that they >> >can be persistently and unambiguously referenced. The IPP/1.0 model >> >requires that these identifiers be Uniform Resource Identifiers (URIs) >> >[RFC1630]. Often, the URI is a URL [RFC1738] [RFC1808]. >> >> I suggest adding to the end of the paragraph above: >> >> A Printer object MAY have one or more identifies that uniquely identify >> the Printer object, depending on implementation. These Printer URIs >> are contained in the Printer object's potentially multi-valued >> "printer-uri-supported" attribute. Job objects SHALL have >> only one unique identifier. This Job URI is contained in the Job object's >> "job-uri" attribute. >> >> > >> >IPP/1.0 does not specify how the URI is obtained, but it is RECOMMENDED >> >that a Printer object is registered in a directory service which end users >> >and programs can interrogate. Section 16 defines a generic schema for >> >Printer object entries in the directory service. >> > >> >Allowing Job objects to have URIs allows for flexibility and scalability. >> >In some implementations, the Printer object might create Jobs that are >> >processed in the same local environment as the Printer object itself. In >> >this case, the Job URI might just be a composition of the Printer's URI and >> >some unique component for the Job object, such as the unique 32-bit >> >positive integer mentioned later in this paragraph. In other >> >implementations, the Printer object might be a central clearing-house for >> >validating all Job object creation requests, and the Job object itself >> >might be created in some environment that is remote from the Printer >> >object. In this case, the Job object's URI may have no relationship at all >> >to the Printer object's URI. However, many existing printing systems have >> >local models or interface constraints that force Job objects to be >> >identified using only a 32-bit positive integer rather than a URI. This >> >numeric Job ID is only unique within the context of the Printer object to >> >which the create request was originally submitted. In order to allow both >> >types of client access to Jobs (either by Job URI or by numeric Job ID), >> >when the Printer object successfully processes a create request and creates >> >a new Job, the Printer object SHALL generate both a Job URI and a Job ID >> >for the new Job object. This requirement allows all clients to access >> >Printer objects and Job objects no matter the local constraints imposed on >> >the client implementation. >> >> In order to fix the paragraph above, we need to introduce the concept that >> a create operation specifies a single Printer URI, without introducing the >> concept of operation attributes yet. I suggest adding a preceding paragraph: >> >> When a job is submitted to the Printer object, the client MUST supply a >> single Printer URI which is one of the URIs that uniquely identify that >> Printer object and is one of the values in that Printer object's >> "printer-uri-supported" attribute. >> >> Then the long paragraph above can be fixed by replacing >> "Printer's URI" and "Printer object's URI" with "Printer URI supplied >> by the client when submitting the job" yielding: >> >> Allowing Job objects to have URIs allows for flexibility and scalability. >> In some implementations, the Printer object might create Jobs that are >> processed in the same local environment as the Printer object itself. In >> this case, the Job URI might just be a composition of the >> Printer URI supplied by the client when submitting the job >> and some unique component for the Job object, such as the unique 32-bit >> positive integer mentioned later in this paragraph. In other >> implementations, the Printer object might be a central clearing-house for >> validating all Job object creation requests, and the Job object itself >> might be created in some environment that is remote from the Printer >> object. In this case, the Job object's URI may have no relationship at all >> to the >> Printer URI supplied by the client when submitting the job. >> However, many existing printing systems have >> local models or interface constraints that force Job objects to be >> identified using only a 32-bit positive integer rather than a URI. This >> numeric Job ID is only unique within the context of the Printer object to >> which the create request was originally submitted. In order to allow both >> types of client access to Jobs (either by Job URI or by numeric Job ID), >> when the Printer object successfully processes a create request and creates >> a new Job, the Printer object SHALL generate both a Job URI and a Job ID >> for the new Job object. This requirement allows all clients to access >> Printer objects and Job objects no matter the local constraints imposed on >> the client implementation. >> >> >> > >> >In addition to a unique identifier, Printer objects and Job objects have >> >names. An object name need not be unique across all instances of all >> >objects. A Printer object's name is chosen and set by an administrator >> >through some mechanism outside the scope of IPP/1.0. A Job object's name >> >is optionally chosen and supplied by the IPP client submitting the job. If >> >the client does not supply a Job object name, the Printer object generates >> >a name for the new Job object. In all cases, the name only has local >> >meaning; the name is not constrained to be unique. >> >> Probably just replace "a unique identifier" with "unique identifiers" >> in the first sentence in the paragraph above. >> >> > >> >To summarize: >> > >> >- Each Printer object is uniquely identified with a URI. The Printer's >> >"printer-uri" attribute contains the URI. >> >> Change the paragraph to: >> >> - Each Printer object is identified by one or more unique URIs. The >> Printer's multi-valued "printer-uri-supported" attribute contains these URIs. >> >> > >> >- Each Job object is uniquely identified with a URI. The Job's "job-uri" >> >attribute contains the URI. >> > >> >- Each Job object is also uniquely identified with a combination of the URI >> >of the Printer object to which the create request was originally submitted >> >along with a Job ID (a 32-bit, positive integer) that is unique within the >> >context of that Printer object. The Printer object's "printer-uri" >> >contains the Printer URI. The Job object's "job-id" attribute contains the >> >numeric Job ID. >> >> In order to fix this paragraph, we need to introduce the concept that >> a create operation specifies a single Printer URI, without introducing the >> concept of operation attributes yet. Also we can introduce the >> "containing-printer-uri" attribute, since it is a connection between >> the Job object and the Printer object. I suggest re-writing the paragraph >> as: >> >> - When a job is submitted, the client MUST supply a single Printer URI >> which is one of the URIs that uniquely identify the Printer object and >> is one of the values in the Printer's "printer-uri-supported" attribute. >> Each Job object is also uniquely identified with a combination of the >> Printer URI supplied in the original create request along with a Job ID >> (a 32-bit, positive integer) that is unique within the context of that >> Printer object. The Printer object's "containing-printer-uri" contains >> the Printer URI supplied in the create request. The Job object's "job-id" >> attribute contains the numeric Job ID. >> >> >> > >> >- Each Printer object has a name (which is not necessarily unique). The >> >administrator chooses and sets this name through some mechanism outside the >> >scope of IPP/1.0 itself. The Printer object's "printer-name" attribute >> >contains the name. >> > >> >- Each Job object has a name (which is not necessarily unique). The client >> >optionally supplies this name in the create request. If the client does >> >not supply this name, the Printer object generates a name for the Job >> >object. The Job object's "job-name" attribute contains the name. >> > >> >> > > From ipp-owner@pwg.org Mon Jan 12 15:26:01 1998 Delivery-Date: Mon, 12 Jan 1998 15:26:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21402 for ; Mon, 12 Jan 1998 15:26:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA03883 for ; Mon, 12 Jan 1998 15:28:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24436 for ; Mon, 12 Jan 1998 15:25:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 15:17:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23422 for ipp-outgoing; Mon, 12 Jan 1998 15:01:21 -0500 (EST) Message-Id: <3.0.1.32.19980112113930.01074750@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 11:39:30 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO new protocol document [.pdf files uploaded] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've uploaded the corresonding .pdf files: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109.pdf The rev file has red revision marks which should print as black on B/W printers (I checked this box in the MS-WORD version 6 compatibility options menu). We should use the line numbers in the file with no revision marks for any e-mail discussion. Tom >Date: Fri, 9 Jan 1998 15:34:53 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO new protocol document >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I have just downloaded the latest version of the protocol document to: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. > >The documents are: > > ipp-pro-980109.doc MS Word Version 6 with no revisions > ipp-pro-980109-rev.doc MS Word Version 6 with revisions > ipp-pro-980109.txt text with no revisions, same as > draft-ietf-ipp-protocol-05.txt submitted > to IETF today. > > >This is the version that will go to the IESG if we reject XML and >stay with the current protocol. > > From ipp-owner@pwg.org Mon Jan 12 16:45:59 1998 Delivery-Date: Mon, 12 Jan 1998 16:45:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22100 for ; Mon, 12 Jan 1998 16:45:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04214 for ; Mon, 12 Jan 1998 16:48:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25786 for ; Mon, 12 Jan 1998 16:45:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 16:33:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24736 for ipp-outgoing; Mon, 12 Jan 1998 16:19:13 -0500 (EST) Message-ID: <34BA88AF.4F88E6BC@us.ibm.com> Date: Mon, 12 Jan 1998 14:18:42 -0700 From: Carl Kugler X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP Mail Archive: Re: IPP>MOD add another issue [encoding of CompoundValue] Content-Type: multipart/mixed; boundary="------------03F1D2F48D1D31E99F75DE1F" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------03F1D2F48D1D31E99F75DE1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Although compoundValue can be made to work, its complexity will lead to > bugs. Also its type is determined by looking at all of the tags of > values that it contains. This suggests that we should look for a > simpler-to-implement option. > > The most obvious solution is to add two new types text-language and > name-language which are the langauge constrained versions of text and > name. > Since we still have 'compound-attribute' in the protocol, couldn't we represent 'textWithLanguage' and 'nameWithLanguage' using that mechanism? (The 'textWithLanguage' attribute syntax is a compound attribute syntax, represented as an OCTET_STRING consisting of 4 fields: a) a SIGNED-SHORT which is the number of octets in the following field b) a value of type natural-language, c) a SIGNED-SHORT which is the number of octets in the following field, d) a value of type text. The length of a textWithLanguage value SHALL be 4 + the value of field a + the value of field c.). I'm finding all these embedded lengths to be a pain to implement, and it seems redundant with the logic we already have for compound-attribute. -Carl Kugler ======================Original message========================= > Re: IPP>MOD add another issue [encoding of CompoundValue] > > Robert Herriot (Robert.Herriot@Eng.Sun.COM) > Tue, 25 Nov 1997 18:54:45 -0800 > > * Messages sorted by: [ date ][ thread ][ subject ][ author ] > * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues" > * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC" > > I will try to explain the issue by giving more detail. > > The compoundValue has an integer value which specifies the number of > following values that compose the compound value. There are two > obvious ways to implement compoundValue in a general way: > > 1) recurse looking for additional values until the correct number > is found or until a non-null attribute name is found or a delimiter > tag is found. The latter two conditions are errors. This method > works, but is tricky the "nested" values are really at the same > level as other values in the protocol. > > 2) continue picking up values, but make a note that a compoundValue > is being built. In this case, there must be a check when a > non-null name is encountered, and when a delimiter tag is found > for the error of a compoundValue is still being built. > At first glance, this seems simpler, but it is easy to forget the > checks mentioned above. > > Although compoundValue can be made to work, its complexity will lead to > bugs. Also its type is determined by looking at all of the tags of > values that it contains. This suggests that we should look for a > simpler-to-implement option. > > The most obvious solution is to add two new types text-language and > name-language which are the langauge constrained versions of text and > name. Attributes with text and name values could also have a value of > type text-language or name-language. Tom and others have suggested > that language and text/name be separated by a single-quote character. > It would work, but is not in the spirit of the current protocol which > uses lengths instead of delimiting characters. So I suggest the value > be . The length > of the text/name string is length of the value minus ( language-length > + 2). > > This solution is easier to parse because the components are contained > with a single value. > > If we believe that tags are in short supply and that we don't want to > allocate two values for such obscure types, we could create a tag type > of "typed-octets" where the first byte of the value contains the > sub-tag value which in our case would be either text-language or > name-language. We could also have 2 bytes for the sub-tag rather than > 1. > > > From hastings@cp10.es.xerox.com Mon Nov 24 10:46:48 1997 > > > > As long as you've re-opened this issue, I'd like to add several > > other alternatives into the mix. (A committee is better able to > > pick between alternatives, than to design one on the fly). > > > > On the other hand, it may be better to live with the current scheme > > than to try to pick a new one. > > > > At 19:48 11/21/1997 PST, Robert Herriot wrote: > > > > > >As I am implementing the CompoundValue, I am finding problems that make > > >me think it should be changed. It requires too much special-casing and > > >in its current form it will introduce bugs where the value of the > > >CompoundValue exceeds the number of remaining attributes for the > > >attribute name or attribute group. To avoid those bugs, checks have to > > >be made in several places. > > > > Please explain this problem more. > > > > > > > >I suggest we reexamine the other possible solutions, one simple with > > >no room for extension, the other with room for extension. > > > > > > a) add two new value types: text-language and name-language each of which > > > is a single value in the protocol but which consists of 4 subfields: > > > a text/name length field, a text/name field, a language length field, > > > and a language field, . > > > > > > b) add a single new type: compound-value which consists of a single value > > > in the protocol but which consists of a value-tag field followed by > > > any number of groups-of-three subfields. Each group-of-three > > > consists of a value tag, a value length and a value. The text-language > > > solution of a) is represented by a text-language tag, a text tag, a > > > text length, a text value, a natural-language-tag, a natural-language > > > length and a natural-language value. > > > > > >I prefer b) because it offers room for extension and an implementation can > > >determine if it supports the compound value by examining the initial > > >tag in the compoundValue. > > > > Here are my additional alternatives: > > > > > > c) Amplify the 'text' and 'name' attribute syntaxes to allow a second > > natural language override value to precede the actual value which indicates > > the language of the immediately following value. The attribute syntax of > > the first value, when present, is: 'naturalLanguage' as defined in the > > current spec. > > > > Advantages: simple > > > > Disadvantages: a single-valued attribute sometimes has two values, making > > the validation of single-valued attributes more adhoc. Also counting > > attribute values is more adhoc. > > > > > > d) have two data types for each of 'text' and 'name': > > 'text' (same as current) and 'taggedText' > > 'name' (same as current) and 'taggedName' > > > > The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging > > in the beginning of the data (but for language only, not charset) > > to indicate natural language override: > > > > en'... > > en-us'... > > > > to indicate English and U.S. English > > > > Those attributes which currently have 'text' and 'name' would > > be changed to require support of both 'text' and 'taggedText' > > and 'name' and 'taggedName' > > > > For example: > > > > job-name (name | taggedName) > > > > Advantages: most request/response instances would not need to use the > > taggedText and taggedName in most interchanges. > > > > Disadvantages: clients and IPP objects would still have to support both > > forms. > > > > > > e) Change the spec for 'text' and 'name' to always require the RFC 2184 > > natural language prefix (but not charset). > > > > Advantages: simple, natural language tag is always stored with the data. > > Only one protocol value for each attribute value. > > > > Disadvantages: tag has to be skipped over when processing or displaying > > the data. > > > > > > f) Same as e) except include the charset tag as well, so in full compliance > > with RFC 2184 (same as we had in the Model document after the Atlanta > > meeting). Example: > > > > us-ascii'en'... > > utf-8'en-us'... > > > > Advantages: simple, charset and natural language tag is always stored > > with the data. Only one protocol value for each attribute value. > > IPP object doesn't need to charset convert data to a single charset. > > > > Disadvantage: tags have to be skipped over when processing or displaying > > the data. > > > > > > g) Add the dictionary attribute syntax that we postponed. > > > > Advantages: It is even more general than your alternative b) and is > > something we have agreed is something we want. I'd hate to see us > > put in something that is half a dictionary. I think that the dictionary > > also fixes the length checking problem that the current CompoundValue > > has, correct? > > > > Disadvantages: None. > > > > Tom > > > > > > > > > > * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues" > * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC" http://www.pwg.org/hypermail/ipp/2831.html --------------03F1D2F48D1D31E99F75DE1F Content-Type: text/html; charset=us-ascii; name="2831.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2831.html" Content-Base: "http://www.pwg.org/hypermail/ipp/2831. html" IPP Mail Archive: Re: IPP>MOD add another issue [encoding of CompoundValue]

Re: IPP>MOD add another issue [encoding of CompoundValue]

Robert Herriot (Robert.Herriot@Eng.Sun.COM)
Tue, 25 Nov 1997 18:54:45 -0800

I will try to explain the issue by giving more detail.

The compoundValue has an integer value which specifies the number of
following values that compose the compound value. There are two
obvious ways to implement compoundValue in a general way:

1) recurse looking for additional values until the correct number
is found or until a non-null attribute name is found or a delimiter
tag is found. The latter two conditions are errors. This method
works, but is tricky the "nested" values are really at the same
level as other values in the protocol.

2) continue picking up values, but make a note that a compoundValue
is being built. In this case, there must be a check when a
non-null name is encountered, and when a delimiter tag is found
for the error of a compoundValue is still being built.
At first glance, this seems simpler, but it is easy to forget the
checks mentioned above.

Although compoundValue can be made to work, its complexity will lead to
bugs. Also its type is determined by looking at all of the tags of
values that it contains. This suggests that we should look for a
simpler-to-implement option.

The most obvious solution is to add two new types text-language and
name-language which are the langauge constrained versions of text and
name. Attributes with text and name values could also have a value of
type text-language or name-language. Tom and others have suggested
that language and text/name be separated by a single-quote character.
It would work, but is not in the spirit of the current protocol which
uses lengths instead of delimiting characters. So I suggest the value
be <language length> <language string> <text/name string>. The length
of the text/name string is length of the value minus ( language-length
+ 2).

This solution is easier to parse because the components are contained
with a single value.

If we believe that tags are in short supply and that we don't want to
allocate two values for such obscure types, we could create a tag type
of "typed-octets" where the first byte of the value contains the
sub-tag value which in our case would be either text-language or
name-language. We could also have 2 bytes for the sub-tag rather than
1.

> From hastings@cp10.es.xerox.com Mon Nov 24 10:46:48 1997
>
> As long as you've re-opened this issue, I'd like to add several
> other alternatives into the mix. (A committee is better able to
> pick between alternatives, than to design one on the fly).
>
> On the other hand, it may be better to live with the current scheme
> than to try to pick a new one.
>
> At 19:48 11/21/1997 PST, Robert Herriot wrote:
> >
> >As I am implementing the CompoundValue, I am finding problems that make
> >me think it should be changed. It requires too much special-casing and
> >in its current form it will introduce bugs where the value of the
> >CompoundValue exceeds the number of remaining attributes for the
> >attribute name or attribute group. To avoid those bugs, checks have to
> >be made in several places.
>
> Please explain this problem more.
>
> >
> >I suggest we reexamine the other possible solutions, one simple with
> >no room for extension, the other with room for extension.
> >
> > a) add two new value types: text-language and name-language each of which
> > is a single value in the protocol but which consists of 4 subfields:
> > a text/name length field, a text/name field, a language length field,
> > and a language field, .
> >
> > b) add a single new type: compound-value which consists of a single value
> > in the protocol but which consists of a value-tag field followed by
> > any number of groups-of-three subfields. Each group-of-three
> > consists of a value tag, a value length and a value. The text-language
> > solution of a) is represented by a text-language tag, a text tag, a
> > text length, a text value, a natural-language-tag, a natural-language
> > length and a natural-language value.
> >
> >I prefer b) because it offers room for extension and an implementation can
> >determine if it supports the compound value by examining the initial
> >tag in the compoundValue.
>
> Here are my additional alternatives:
>
>
> c) Amplify the 'text' and 'name' attribute syntaxes to allow a second
> natural language override value to precede the actual value which indicates
> the language of the immediately following value. The attribute syntax of
> the first value, when present, is: 'naturalLanguage' as defined in the
> current spec.
>
> Advantages: simple
>
> Disadvantages: a single-valued attribute sometimes has two values, making
> the validation of single-valued attributes more adhoc. Also counting
> attribute values is more adhoc.
>
>
> d) have two data types for each of 'text' and 'name':
> 'text' (same as current) and 'taggedText'
> 'name' (same as current) and 'taggedName'
>
> The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging
> in the beginning of the data (but for language only, not charset)
> to indicate natural language override:
>
> en'...
> en-us'...
>
> to indicate English and U.S. English
>
> Those attributes which currently have 'text' and 'name' would
> be changed to require support of both 'text' and 'taggedText'
> and 'name' and 'taggedName'
>
> For example:
>
> job-name (name | taggedName)
>
> Advantages: most request/response instances would not need to use the
> taggedText and taggedName in most interchanges.
>
> Disadvantages: clients and IPP objects would still have to support both
> forms.
>
>
> e) Change the spec for 'text' and 'name' to always require the RFC 2184
> natural language prefix (but not charset).
>
> Advantages: simple, natural language tag is always stored with the data.
> Only one protocol value for each attribute value.
>
> Disadvantages: tag has to be skipped over when processing or displaying
> the data.
>
>
> f) Same as e) except include the charset tag as well, so in full compliance
> with RFC 2184 (same as we had in the Model document after the Atlanta
> meeting). Example:
>
> us-ascii'en'...
> utf-8'en-us'...
>
> Advantages: simple, charset and natural language tag is always stored
> with the data. Only one protocol value for each attribute value.
> IPP object doesn't need to charset convert data to a single charset.
>
> Disadvantage: tags have to be skipped over when processing or displaying
> the data.
>
>
> g) Add the dictionary attribute syntax that we postponed.
>
> Advantages: It is even more general than your alternative b) and is
> something we have agreed is something we want. I'd hate to see us
> put in something that is half a dictionary. I think that the dictionary
> also fixes the length checking problem that the current CompoundValue
> has, correct?
>
> Disadvantages: None.
>
> Tom
>
>
>
>

--------------03F1D2F48D1D31E99F75DE1F-- From ipp-owner@pwg.org Mon Jan 12 17:25:44 1998 Delivery-Date: Mon, 12 Jan 1998 17:25:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA22824 for ; Mon, 12 Jan 1998 17:25:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04425 for ; Mon, 12 Jan 1998 17:26:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27144 for ; Mon, 12 Jan 1998 17:23:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 17:10:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25458 for ipp-outgoing; Mon, 12 Jan 1998 16:41:09 -0500 (EST) Message-Id: <3.0.1.32.19980112133922.0143e310@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 13:39:22 PST To: ipp@pwg.org From: Chen Chen (by way of Carl-Uno Manros ) Subject: IPP> ADM - Robin Cover's XML Home Page Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org You may find this XML web page very useful for XML beginners. http://www.sil.org/sgml/xml.html Chen From ipp-owner@pwg.org Mon Jan 12 17:28:41 1998 Delivery-Date: Mon, 12 Jan 1998 17:28:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA22863 for ; Mon, 12 Jan 1998 17:28:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04458 for ; Mon, 12 Jan 1998 17:31:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27427 for ; Mon, 12 Jan 1998 17:28:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 17:18:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26116 for ipp-outgoing; Mon, 12 Jan 1998 16:54:37 -0500 (EST) Date: Mon, 12 Jan 1998 13:54:15 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801122154.NAA04036@woden.eng.sun.com> To: ipp@pwg.org, kugler@us.ibm.com Subject: Re: IPP Mail Archive: Re: IPP>MOD add another issue [encoding of CompoundValue] X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I found it rather easy to implement when I did it. Only field c) is redundant, but I found the implementation simpler when each value was preceded by a length because I already had code that picked up a length n and then the value as the next n bytes. It is then easy to check later that the sum of these bytes equals the value length of the whole compound value. Bob Herriot > From ipp-owner@pwg.org Mon Jan 12 13:35:48 1998 > Date: Mon, 12 Jan 1998 14:18:42 -0700 > From: Carl Kugler > X-Mailer: Mozilla 4.03 [en] (WinNT; I) > MIME-Version: 1.0 > To: ipp@pwg.org > Subject: IPP Mail Archive: Re: IPP>MOD add another issue [encoding of CompoundValue] > Content-Type: multipart/mixed; boundary="------------03F1D2F48D1D31E99F75DE1F" > Sender: ipp-owner@pwg.org > Content-Length: 19754 > X-Lines: 425 > > > Although compoundValue can be made to work, its complexity will lead to > > bugs. Also its type is determined by looking at all of the tags of > > values that it contains. This suggests that we should look for a > > simpler-to-implement option. > > > > The most obvious solution is to add two new types text-language and > > name-language which are the langauge constrained versions of text and > > name. > > > Since we still have 'compound-attribute' in the protocol, couldn't we represent > 'textWithLanguage' and 'nameWithLanguage' using that mechanism? > > (The 'textWithLanguage' attribute syntax is a compound attribute syntax, represented as an > OCTET_STRING consisting of 4 fields: a) a SIGNED-SHORT which is the number of octets in the > following field b) a value of type natural-language, c) a SIGNED-SHORT which is the number > of octets in the following field, d) a value of type text. The length of a > textWithLanguage value SHALL be 4 + the value of field a + the value of field c.). > > I'm finding all these embedded lengths to be a pain to implement, and it seems redundant with > the logic we already have for compound-attribute. > > -Carl Kugler > > ======================Original message========================= > > > Re: IPP>MOD add another issue [encoding of CompoundValue] > > > > Robert Herriot (Robert.Herriot@Eng.Sun.COM) > > Tue, 25 Nov 1997 18:54:45 -0800 > > > > * Messages sorted by: [ date ][ thread ][ subject ][ author ] > > * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues" > > * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC" > > > > I will try to explain the issue by giving more detail. > > > > The compoundValue has an integer value which specifies the number of > > following values that compose the compound value. There are two > > obvious ways to implement compoundValue in a general way: > > > > 1) recurse looking for additional values until the correct number > > is found or until a non-null attribute name is found or a delimiter > > tag is found. The latter two conditions are errors. This method > > works, but is tricky the "nested" values are really at the same > > level as other values in the protocol. > > > > 2) continue picking up values, but make a note that a compoundValue > > is being built. In this case, there must be a check when a > > non-null name is encountered, and when a delimiter tag is found > > for the error of a compoundValue is still being built. > > At first glance, this seems simpler, but it is easy to forget the > > checks mentioned above. > > > > Although compoundValue can be made to work, its complexity will lead to > > bugs. Also its type is determined by looking at all of the tags of > > values that it contains. This suggests that we should look for a > > simpler-to-implement option. > > > > The most obvious solution is to add two new types text-language and > > name-language which are the langauge constrained versions of text and > > name. Attributes with text and name values could also have a value of > > type text-language or name-language. Tom and others have suggested > > that language and text/name be separated by a single-quote character. > > It would work, but is not in the spirit of the current protocol which > > uses lengths instead of delimiting characters. So I suggest the value > > be . The length > > of the text/name string is length of the value minus ( language-length > > + 2). > > > > This solution is easier to parse because the components are contained > > with a single value. > > > > If we believe that tags are in short supply and that we don't want to > > allocate two values for such obscure types, we could create a tag type > > of "typed-octets" where the first byte of the value contains the > > sub-tag value which in our case would be either text-language or > > name-language. We could also have 2 bytes for the sub-tag rather than > > 1. > > > > > From hastings@cp10.es.xerox.com Mon Nov 24 10:46:48 1997 > > > > > > As long as you've re-opened this issue, I'd like to add several > > > other alternatives into the mix. (A committee is better able to > > > pick between alternatives, than to design one on the fly). > > > > > > On the other hand, it may be better to live with the current scheme > > > than to try to pick a new one. > > > > > > At 19:48 11/21/1997 PST, Robert Herriot wrote: > > > > > > > >As I am implementing the CompoundValue, I am finding problems that make > > > >me think it should be changed. It requires too much special-casing and > > > >in its current form it will introduce bugs where the value of the > > > >CompoundValue exceeds the number of remaining attributes for the > > > >attribute name or attribute group. To avoid those bugs, checks have to > > > >be made in several places. > > > > > > Please explain this problem more. > > > > > > > > > > >I suggest we reexamine the other possible solutions, one simple with > > > >no room for extension, the other with room for extension. > > > > > > > > a) add two new value types: text-language and name-language each of which > > > > is a single value in the protocol but which consists of 4 subfields: > > > > a text/name length field, a text/name field, a language length field, > > > > and a language field, . > > > > > > > > b) add a single new type: compound-value which consists of a single value > > > > in the protocol but which consists of a value-tag field followed by > > > > any number of groups-of-three subfields. Each group-of-three > > > > consists of a value tag, a value length and a value. The text-language > > > > solution of a) is represented by a text-language tag, a text tag, a > > > > text length, a text value, a natural-language-tag, a natural-language > > > > length and a natural-language value. > > > > > > > >I prefer b) because it offers room for extension and an implementation can > > > >determine if it supports the compound value by examining the initial > > > >tag in the compoundValue. > > > > > > Here are my additional alternatives: > > > > > > > > > c) Amplify the 'text' and 'name' attribute syntaxes to allow a second > > > natural language override value to precede the actual value which indicates > > > the language of the immediately following value. The attribute syntax of > > > the first value, when present, is: 'naturalLanguage' as defined in the > > > current spec. > > > > > > Advantages: simple > > > > > > Disadvantages: a single-valued attribute sometimes has two values, making > > > the validation of single-valued attributes more adhoc. Also counting > > > attribute values is more adhoc. > > > > > > > > > d) have two data types for each of 'text' and 'name': > > > 'text' (same as current) and 'taggedText' > > > 'name' (same as current) and 'taggedName' > > > > > > The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging > > > in the beginning of the data (but for language only, not charset) > > > to indicate natural language override: > > > > > > en'... > > > en-us'... > > > > > > to indicate English and U.S. English > > > > > > Those attributes which currently have 'text' and 'name' would > > > be changed to require support of both 'text' and 'taggedText' > > > and 'name' and 'taggedName' > > > > > > For example: > > > > > > job-name (name | taggedName) > > > > > > Advantages: most request/response instances would not need to use the > > > taggedText and taggedName in most interchanges. > > > > > > Disadvantages: clients and IPP objects would still have to support both > > > forms. > > > > > > > > > e) Change the spec for 'text' and 'name' to always require the RFC 2184 > > > natural language prefix (but not charset). > > > > > > Advantages: simple, natural language tag is always stored with the data. > > > Only one protocol value for each attribute value. > > > > > > Disadvantages: tag has to be skipped over when processing or displaying > > > the data. > > > > > > > > > f) Same as e) except include the charset tag as well, so in full compliance > > > with RFC 2184 (same as we had in the Model document after the Atlanta > > > meeting). Example: > > > > > > us-ascii'en'... > > > utf-8'en-us'... > > > > > > Advantages: simple, charset and natural language tag is always stored > > > with the data. Only one protocol value for each attribute value. > > > IPP object doesn't need to charset convert data to a single charset. > > > > > > Disadvantage: tags have to be skipped over when processing or displaying > > > the data. > > > > > > > > > g) Add the dictionary attribute syntax that we postponed. > > > > > > Advantages: It is even more general than your alternative b) and is > > > something we have agreed is something we want. I'd hate to see us > > > put in something that is half a dictionary. I think that the dictionary > > > also fixes the length checking problem that the current CompoundValue > > > has, correct? > > > > > > Disadvantages: None. > > > > > > Tom > > > > > > > > > > > > > > > > * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues" > > * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC" > > > > http://www.pwg.org/hypermail/ipp/2831.html From ipp-owner@pwg.org Mon Jan 12 18:25:15 1998 Delivery-Date: Mon, 12 Jan 1998 18:25:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23229 for ; Mon, 12 Jan 1998 18:25:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA04624 for ; Mon, 12 Jan 1998 18:26:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA28481 for ; Mon, 12 Jan 1998 18:23:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 18:08:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27715 for ipp-outgoing; Mon, 12 Jan 1998 17:53:28 -0500 (EST) Message-Id: <3.0.1.32.19980112145013.00914900@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 14:50:13 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference - 980114 Cc: Paul Moore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Agenda for PWG IPP Phone Conference - 980114 And I was worried that we were starting to run out of subjects for our Wednesday IPP phone conferences. Not so! I would like to open the floor for comments on the Microsoft suggestion to investigate the use of XML and related stuff. I have spoken to Paul Moore and he will participate in order to collect any questions that we have at this stage. It also seems to be a few more details that have come up on the Model document. I would like us to go over those as well to make sure that there are no further lingering issues with that. The dial-in information is the same as last weeek: Call-in: 1-423-523-7162 Access: 190148 Time: 4PM EST (1PM PST) Duration: Max 2.5 hours Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 12 21:39:02 1998 Delivery-Date: Mon, 12 Jan 1998 21:39:03 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24311 for ; Mon, 12 Jan 1998 21:39:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05018 for ; Mon, 12 Jan 1998 21:41:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00319 for ; Mon, 12 Jan 1998 21:38:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 12 Jan 1998 21:30:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29609 for ipp-outgoing; Mon, 12 Jan 1998 21:15:09 -0500 (EST) Message-Id: <3.0.1.32.19980112181018.01078a10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 Jan 1998 18:10:18 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Suggested Requirements for XML to encode IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org To those developing XML encoding schemes for IPP: I have not had a chance to study XML at all. However, for those working on XML encoding proposals for representing IPP requests and responses, I thought it would be helpful to write down the requirements that we evolved in doing the current IPP Protocol Encoding to help those doing XCL proposals. Our current IPP protocol encoding is described in: . The 05 version has been forwarded to the internet-drafts DL and will be out shortely. It is currently available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109.pdf Strawman Requirements for encoding IPP protocol using XML 1. Do not need to change the IPP Model document at all, or only at least trivially. It has all of the semantics that we want to represent. 2. Need to be able to represent all of the attribute syntaxes (data types) that are in Section 4.1 of the Model document: text, textWithLanguage, name, nameWithLanguage, keyword, enum, uri, uriScheme, charset, naturalLanguage, mimeMediaType, octetString, boolean, integer, rangeOfInteger, dateTime, resolution, and 1setOf X (multi-valued attributes). 2a. A different, more natural to XML, method for overriding the natural language for 'text' and 'name' attributes than using the 'textWithLanguage' and 'nameWithLanguage' attribute syntaxes would be acceptable. 3. Keywords are used to identify attributes and attribute values and are specified in lower case US-ASCII and U.S. English and allow hyphen (-), dot (.) and underscore (_). 3a. Using keywords to identify attribute syntaxes would be desirable, though not currently done in our current IPP protocol. 4. Implementors must be able to add private keywords using private keyword syntax for which clash with other implementors' private keywords is not possible. 5. The PWG must be able to add additional attribute syntaxes following a registration procedure that includes PWG review. 6. Implementors must be able to include priviate attribute syntaxes in conforming interchange. 6a. It would be desirable if clashes with other implementor private attribute syntaxes could be guarranteed to be avoided - something that our current IPP encoding does not solve, since attribute syntaxes are encoded as integers without a registration scheme. Using keywords for attribute syntaxes would be a way to achieve such name clash avoidance. 7. Implementors must be able to add private enum values. 8. Attributes must be identified by keywords in US-ASCII and US-English. 9. Attributes must be able to be multi-valued. 10. Some attributes must be able to have more than one attribute syntax defined for them, such as 'keyword' and 'name' (or 'text' and 'textWithLanguage' if that mechanism is used for overriding natural language on an attribute value by attribute value basis). 11. An instance of a multi-valued attribute must be able to employ any of the attribute syntaxes defined for it. For example be able to mix 'keyword' and 'name' values. 12. Each value of an attribute needs to identify which attribute syntax it is using. 13. The 'text' and 'name' attribute syntaxes must be able to represent any ISO 10646 character, probably using utf-8 encoding. 14. The 'text' and 'name' attribute values must be representable in other charsets than utf-8. Possibly, some simple coding transformation may be required by the client for some charsets. There is no need for this to be done on an attribute by attribute basis. Only a sinlge request or a single response needs to be in a charset specified in the interchange. 15. It must be possible to group attributes in an interchange into several groups. For requests: Operation attributes and Job Template attributes For responses: Operation attributes, Job Attributes, Printer Attributes, Job Description Attributes, Printer Descriptions Attribute, Unsupported Attributes. 16. No syntactic distinction is needed between multi-valued attributes that are ordered, and ones that are not. The semantics specify which attributes are odererd and which are not (most are not). 17. Similarly, no syntactic distincation need be made between attribute groups that require certain attributes to be first and ones that do not. The semantics specify which attributes must come first in which groups. Most attribute can occur anywhere in the groups in which they are permitted. Comments? Tom From ipp-owner@pwg.org Tue Jan 13 13:37:25 1998 Delivery-Date: Tue, 13 Jan 1998 13:37:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09013 for ; Tue, 13 Jan 1998 13:37:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07477 for ; Tue, 13 Jan 1998 13:40:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06761 for ; Tue, 13 Jan 1998 13:37:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 13:16:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04276 for ipp-outgoing; Tue, 13 Jan 1998 12:06:19 -0500 (EST) From: Roger K Debry To: Subject: IPP> Microsoft proposal Message-ID: <5030100016099094000002L042*@MHS> Date: Tue, 13 Jan 1998 12:06:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09013 Most of the mail that I have seen posted here seems to support the groups consideration of the latest Microsoft proposal. Clearly, we all want the best technical solution that still meets our original goals of rapid deployment of IPP. By the same token, I hope that Microsoft plans to participate on a more regular basis in IPP meetings, and that as we all stop dead in our tracks to consider their proposal, that they will be willing to honestly and fairly consider the pros and cons raised during any discussions that take place on their proposal, and that they will abide by any agreements that come out of the meeting in Maui. I would consider any other action on their part to be predatory and counter to the spirit of the IETF standards process. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Jan 13 13:37:25 1998 Delivery-Date: Tue, 13 Jan 1998 13:37:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09015 for ; Tue, 13 Jan 1998 13:37:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07479 for ; Tue, 13 Jan 1998 13:40:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06762 for ; Tue, 13 Jan 1998 13:37:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 13:12:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04259 for ipp-outgoing; Tue, 13 Jan 1998 12:04:59 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP>MOD add another issue [encoding nameWithLanguage and Message-ID: <5030100016099005000002L052*@MHS> Date: Tue, 13 Jan 1998 12:04:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09015 > I found it rather easy to implement when I did it. Perhaps you had an implementation in mind when you wrote the spec. Ease of implementation depends on your internal representation for attributes, I suppose, and our representation has a legacy of more than a year of IPP evolution behind it. We can change it, but there's a large impact since attributes are so central to the implementation. > Only field c) is redundant I wasn't addressing redundancy in the data stream, although that's a good point, too. What I meant is that it's redundant to specify a unique compound attribute syntax for these two specific attributes (nameWithLanguage and textWithLanguage]) when we already have a general 'compound-attribute' syntax. -Carl ('Course none of this will matter when we switch to XML.) Robert.Herriot@Eng.Sun.COM on 01/12/98 09:55:35 AM Please respond to Robert.Herriot@Eng.Sun.COM @ internet To: Carl Kugler/Boulder/IBM@ibmus, ipp@pwg.org @ internet cc: Subject: Re: IPP Mail Archive: Re: IPP>MOD add another issue [encodin I found it rather easy to implement when I did it. Only field c) is redundant, but I found the implementation simpler when each value was preceded by a length because I already had code that picked up a length n and then the value as the next n bytes. It is then easy to check later that the sum of these bytes equals the value length of the whole compound value. Bob Herriot From ipp-owner@pwg.org Tue Jan 13 13:37:25 1998 Delivery-Date: Tue, 13 Jan 1998 13:37:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09021 for ; Tue, 13 Jan 1998 13:37:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07478 for ; Tue, 13 Jan 1998 13:40:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06764 for ; Tue, 13 Jan 1998 13:37:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 13:18:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04287 for ipp-outgoing; Tue, 13 Jan 1998 12:06:56 -0500 (EST) From: Roger K Debry To: Subject: IPP> Microsoft proposal Message-ID: <5030100016099119000002L092*@MHS> Date: Tue, 13 Jan 1998 12:06:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09021 Most of the mail that I have seen posted here seems to support the groups consideration of the latest Microsoft proposal. Clearly, we all want the best technical solution that still meets our original goals of rapid deployment of IPP. By the same token, I hope that Microsoft plans to participate on a more regular basis in IPP meetings, and that as we all stop dead in our tracks to consider their proposal, that they will be willing to honestly and fairly consider the pros and cons raised during any discussions that take place on their proposal, and that they will abide by any agreements that come out of the meeting in Maui. I would consider any other action on their part to be predatory and counter to the spirit of the IETF standards process. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Jan 13 13:37:27 1998 Delivery-Date: Tue, 13 Jan 1998 13:37:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09028 for ; Tue, 13 Jan 1998 13:37:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07483 for ; Tue, 13 Jan 1998 13:40:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06784 for ; Tue, 13 Jan 1998 13:37:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 13:21:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04327 for ipp-outgoing; Tue, 13 Jan 1998 12:16:52 -0500 (EST) Message-Id: <3.0.1.32.19980113091137.009ff5f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 13 Jan 1998 09:11:37 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Thoughts around use of XML Cc: hamilton@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org We already have an intensive internal discussion on the use of XML inside Xerox. I have copied out a few comments from one of our researchers at PARC, Dennis Hamilton. These might be food for thought for MS and others, who want to discuss the subject of using XML in IPP. Regards, Carl-Uno --- I would be surprised to see XML used to describe interfaces, though I suppose it could be. Basically, what I have seen of it in my limited encounters is that it is more like job or document metadata and references to things assume availability of distribution mechanisms that are not themselves described. (URL's and URI's are very popular in this context.) I agree that it doesn't appear to be efficient at communicating data structures among applications that can rely on a stronger agreement that has less redundancy in the transmitted data encodings because there is strong application agreement. In a way, that is exactly the sense in which XML is lighter-weight, plus it needs to be used at a not-too-fine-grained level. So delivering job parameters and providing descriptive status responses is perfect. It also fits into the idea of having a small delta between that and HTML or something a script could handle. One thing I am not sure about is what happens when scripts start being included as the values of XML attributes. That and the ability to refer to applets and components at the scripting / automation level may be something that is perhaps considered easier to migrate to. I don't have a thought about that, I just wonder if it is something that Microsoft is noticing as a possibility. Also, I wouldn't be surprised if script engines start supporting access to these babies. Your characterization of the difference between XML and a data stream designed for marshalling and efficient transmission fits my impression also. ------- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jan 13 13:43:14 1998 Delivery-Date: Tue, 13 Jan 1998 13:43:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09063 for ; Tue, 13 Jan 1998 13:43:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA07524 for ; Tue, 13 Jan 1998 13:46:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA07537 for ; Tue, 13 Jan 1998 13:43:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 13:37:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04374 for ipp-outgoing; Tue, 13 Jan 1998 12:31:31 -0500 (EST) Message-Id: <3.0.1.32.19980113092641.00a11100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 13 Jan 1998 09:26:41 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Updated requirements for XML encoding of IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've updated the Strawman Requirements for encoding IPP protocol using XML. Revision marks show the additions. I hope we can consider this document at the IPP telecon, Wednesday, 1/14/98, 1-3 pm PDT. The files are available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.txt Here is a copy of the .txt file: Subj: Strawman Requirements for encoding IPP protocol using XML Date: 01/13/98 Files: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.pdf .doc .txt Version: 0.1 To those developing XML encoding schemes for IPP: Here are the coding requirements that our current IPP Protocol document meets. A proposal for encoding IPP using XML should meet these requirements too. The current IPP protocol encoding specification is available as an Internet-Draft as: . The 05 version has been forwarded to the Internet-Drafts DL and will be out shortly. It is currently available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109.pdf The current IPP Model and Semantics specification is available as an Internet-Draft as: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.pdf Several requirements have alternative requirements listed immediately following, with an "a" appended. We need to decide which requirement should be the one we want to have. The term "recipient" is used to indicate both a client and an IPP object, since an IPP object receives requests from a client and a client received responses from an IPP object. Strawman Requirements for encoding IPP protocol using XML The encoding of IPP in XML shall meet the following requirements: 1.Do not need to change the IPP Model document at all, or only at least trivially. It has all of the semantics that we want to represent. 2.Be registered as a MIME media type, that can be transmitted with any transport, such as SMTP, rather than being restricted to HTTP 1.1, i.e., be registered with Intended usage: COMMON. 3.Be able to represent all of the IPP operations: Print-Job, Print- URI, Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs, Send-Document, Cancel-Job, and Get-Job-Attributes. See section 4.2 to 4.4 of the Model document. Each operation has a defined request format and a defined response format, consisting of groups of attributes. 4.In addition, the Print-Job and Send-Document requests have appended document data which must be easily separable by the recipient. 5.The appended document must be able to be any text or binary document format, including an XML document itself. 6.Also the Send-Document request must be able to be sent with no document (if this is a problem for XML, we could add a new operation, say, Close-Job, to close a multi-document job without sending a document). 1 7.It must be possible for any version of a recipient to detect that request or response is a later or earlier version for all future versions. 8.Need to be able to represent all of the attribute syntaxes (data types) that are in Section 4.1 of the Model document: 'text', 'textWithLanguage', 'name', 'nameWithLanguage', 'keyword', 'enum', 'uri', 'uriScheme', 'charset', 'naturalLanguage', 'mimeMediaType', 'octetString', 'boolean', 'integer', 'rangeOfInteger', 'dateTime', 'resolution', and '1setOf X' (multi-valued attributes). A 'dictionary' value is reserved for the future. 8a. A different, more natural to XML, method for overriding the natural language for .text. and .name. attributes than using the .textWithLanguage. and .nameWithLanguage. attribute syntaxes would be acceptable. 8b. A different, more natural to XML, method for grouping a bunch of attributes as the value of an attribute would be acceptable to having a 'dictionary' attribute syntax. 9.Keywords are used to identify attributes and attribute values and are specified in lower case US-ASCII and U.S. English and allow hyphen (-), dot (.) and underscore (_). 9a. Using keywords to identify attribute syntaxes would be desirable, though not currently done in our current IPP protocol. 10.Implementers must be able to add private keywords using private keyword syntax for which clash with other implementers. private keywords is not possible. Implication: a recipient must be able ignore any attributes (and values) not recognized and/or supported and continue parsing a request or response. 11.The PWG must be able to add additional attribute syntaxes following a registration procedure that includes PWG review. Implication: a recipient must be able ignore any attributes (and values) not recognized and/or supported and continue parsing a request or response. 12.Implementers must be able to include private attribute syntaxes in conforming interchange. Implication: a recipient must be able ignore any attribute syntaxes not supported and continue parsing a request or response. 10a. It would be desirable if clashes with other implement private attribute syntaxes could be guaranteed to be avoided - something that our current IPP encoding does not solve, since attribute syntaxes are encoded as integers without a registration scheme. Using keywords for attribute syntaxes would be a way to achieve such name clash avoidance. 13.Implementers must be able to add private enum values. 14.Attributes must be identified by keywords in US-ASCII and US- English. 15.Some attribute syntaxes must be able to be defined to be a value that contains several distinct specific data types in a specific order, like a C struct. Currently, each such value must be present, there is no need for values to be optional in such a structure. 2 16.Attributes must be able to be multi-valued, i.e., to have multipl instances of the value. 17.The syntax specification must be able to indicate which attribute are permitted to be multi-values, and which must be single valued. 18.Any attribute must be able to have "out-of-band" values, i.e., values that can be used with any attribute and attribute syntax. Currently, we have the following "out-of-band" values: 'unsupported', 'unknown', 'no-value', with 'default' reserved for the future. 19.Some attributes must be able to have more than one attribute syntax defined for them, such as .keyword. and .name. (or .text. and .textWithLanguage. if that mechanism is used for overriding natural language on an attribute value by attribute value basis). 20.An instance of a multi-valued attribute must be able to employ any of the attribute syntaxes defined for it. For example be able to mix .keyword. and .name. values. 21.Each value of an attribute needs to identify which attribute syntax it is using. 22.The .text. and .name. attribute syntaxes must be able to represent any ISO 10646 character, probably using utf-8 encoding. 23.The .text. and .name. attribute values must be representable in other charsets than utf-8. Possibly, some simple coding transformation may be required by the client for some charsets. There is no need for this to be done on an attribute by attribute basis. Only a single request or a single response needs to be in a charset specified in the interchange. 24.It must be possible to group attributes in an interchange into several groups. For requests: Operation attributes and Job Template attributes. For responses: Operation attributes, Job Attributes, Printer Attributes, Job Description Attributes, Printer Descriptions Attribute, Unsupported Attributes. 25.Attribute groups must be identified as to which group. 26.The syntax definition should restrict the order of occurrence of attribute groups. 27.The recipient should be able to ignore entire attribute groups that are not recognized and/or supported. 28.No syntactic distinction is needed between multi-valued attributes that are ordered, and ones that are not. The semantics specify which attributes are ordered and which are not (most are not). 29.Similarly, no syntactic distinction need be made between attribute groups that require certain attributes to be first and ones that do not. The semantics specify which attributes must come first in which groups. Most attribute can occur anywhere in the groups in which they are permitted. 3 From ipp-owner@pwg.org Tue Jan 13 15:36:54 1998 Delivery-Date: Tue, 13 Jan 1998 15:36:54 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA10439 for ; Tue, 13 Jan 1998 15:36:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08072 for ; Tue, 13 Jan 1998 15:39:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA08253 for ; Tue, 13 Jan 1998 15:36:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 15:32:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA07690 for ipp-outgoing; Tue, 13 Jan 1998 15:17:55 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> PRO - Updated requirements for XML encoding of IPP Message-ID: <5030100016109972000002L022*@MHS> Date: Tue, 13 Jan 1998 15:17:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA10439 >5.The appended document must be able to be any text or binary document > format, including an XML document itself. I think this is important (and I don't see how large binary objects can be sent within XML). >2.Be registered as a MIME media type, that can be transmitted with any > transport, such as SMTP, rather than being restricted to HTTP 1.1, > i.e., be registered with Intended usage: COMMON. I'd like to add: "All IPP operations shall be mappable to the HTTP/1.1 POST method." -Carl Kugler From ipp-owner@pwg.org Tue Jan 13 19:37:47 1998 Delivery-Date: Tue, 13 Jan 1998 19:37:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA13071 for ; Tue, 13 Jan 1998 19:37:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA08900 for ; Tue, 13 Jan 1998 19:40:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09067 for ; Tue, 13 Jan 1998 19:37:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 19:33:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08510 for ipp-outgoing; Tue, 13 Jan 1998 19:18:37 -0500 (EST) Message-ID: <19980114001821.4488.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> IBM IPP client Content-Type: text/plain Date: Tue, 13 Jan 1998 16:18:21 PST Sender: ipp-owner@pwg.org Hi, I installed JDK 1.1.3 on a HPUX 10.20 system, and then tried running IBM IPP client (1.1). I selected a local file, gave a fictitous URL just to observe how the client behaves, and clicked on "Submit Print Job". I received the following error: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Compiled Code) at ibm.boulder.penn.ipp.IPPPrinter.printJob(Compiled Code) at ibm.boulder.penn.ipp.IPPMainFrame.submitPrintJob(Compiled Code) at ibm.boulder.penn.ipp.IPPMainFrame.actionPerformed(Compiled Code) at java.awt.MenuItem.processActionEvent(MenuItem.java:434) at java.awt.MenuItem.processEvent(MenuItem.java:398) .......... Did anybody else come across this error? Any pointer will be highly appreciated. PB purub@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Tue Jan 13 20:25:14 1998 Delivery-Date: Tue, 13 Jan 1998 20:25:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA13404 for ; Tue, 13 Jan 1998 20:25:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA08993 for ; Tue, 13 Jan 1998 20:28:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA09717 for ; Tue, 13 Jan 1998 20:25:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 13 Jan 1998 20:20:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09173 for ipp-outgoing; Tue, 13 Jan 1998 20:06:12 -0500 (EST) Message-Id: <199801140106.UAA09168@lists.underscore.com> Date: Tue, 13 Jan 98 18:01:02 MST From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext:5 - 5661" To: ipp@pwg.org Subject: IPP> IPP > IBM Client Prototype Sender: ipp-owner@pwg.org Puru, The client prototype attempts to connect to an IPP Server before performing any data stream writes. As a result, in your case, you get an exception that we have not provided an error dialog for. Unfortunately the client does not do anything unless it is interacting with an IPP Server. Steve From ipp-owner@pwg.org Wed Jan 14 10:14:31 1998 Delivery-Date: Wed, 14 Jan 1998 10:14:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27110 for ; Wed, 14 Jan 1998 10:14:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10376 for ; Wed, 14 Jan 1998 10:17:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA11294 for ; Wed, 14 Jan 1998 10:14:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 10:03:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA10715 for ipp-outgoing; Wed, 14 Jan 1998 09:49:09 -0500 (EST) Message-Id: <199801141448.JAA26052@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-05.txt Date: Wed, 14 Jan 1998 09:48:14 -0500 Sender: ipp-owner@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-05.txt Pages : 31 Date : 13-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19980113150041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113150041.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jan 14 10:32:13 1998 Delivery-Date: Wed, 14 Jan 1998 10:40:04 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA27635 for ietf-123-outbound.10@ietf.org; Wed, 14 Jan 1998 10:32:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26052; Wed, 14 Jan 1998 09:48:14 -0500 (EST) Message-Id: <199801141448.JAA26052@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-05.txt Date: Wed, 14 Jan 1998 09:48:14 -0500 Sender: cclark@cnri.reston.va.us --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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-05.txt Pages : 31 Date : 13-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19980113150041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113150041.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Jan 14 13:27:41 1998 Delivery-Date: Wed, 14 Jan 1998 13:27:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA02499 for ; Wed, 14 Jan 1998 13:26:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11277 for ; Wed, 14 Jan 1998 13:29:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13317 for ; Wed, 14 Jan 1998 13:26:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 13:20:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12733 for ipp-outgoing; Wed, 14 Jan 1998 13:05:43 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 14 Jan 1998 11:04:04 -0700 From: Scott Isaacson To: hastings@cp10.es.xerox.com, ipp@pwg.org Cc: bpenteco@boi.hp.com, landau@hannah.ENET.dec.com, davek@nls.com Subject: Re: IPP> Move "orientation-requested" from J.T. to Operation attributegroup? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I changed "orientation" to "orientation-requested" but I did not make "orientation-requested" an operation attribute. It behaves just like a Job Template attribute for unformatted jobs (validation against supported, default value, client supplied desired outcome, etc.) But I did put in more words about how it does not apply to already formatted document content and so it can never really conflict with what is in the document data - it simply does not apply in those cases. I added that a client SHOULD NOT supply an "orientation-requested" attribute for already formatted document content - if it does, the Printer object will not use it. ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Wed Jan 14 14:30:43 1998 Delivery-Date: Wed, 14 Jan 1998 14:30:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA03669 for ; Wed, 14 Jan 1998 14:30:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11520 for ; Wed, 14 Jan 1998 14:33:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14011 for ; Wed, 14 Jan 1998 14:30:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 14:21:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13414 for ipp-outgoing; Wed, 14 Jan 1998 13:57:44 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 14 Jan 1998 11:56:49 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new 980109 model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have posted: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109-rev.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109.txt Comments only one line-numbered ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980109.pdf please. The following is the change log: 1. Minor editing changes in the Introduction 2. Fixed the description of the group of "job-description" attributes 3. Under 2.4, added new paragraphs on - one or more URI per printer object ("printer-uri-supported") - possibly different security mechanisms per URI ("uri-security-supported") - client supplies one URI in "printer-uri" operation attribute - Job only has one URI (ever) 4. Edited section on directory service entry and reference to 16 5. Named and clarified "operation-id", "status-code", "version-number", and "request-id" attributes Added a new level 2 section to 3.0 on "operation-id" and "request-id" 6. Fixed up the section on "Operation Targets" to account for multi-valued "printer-uri-supported" 7. For version numbers, clarified that if an IPP object gets a request in an unsupported version number, the IPP object returns the CLOSEST supported version number 8. Added missing "compression-supported", "job-k-octets-supported", "job-impressions-supported", and "job-media-sheets-supported" 9. Made "compression" operation attribute (supplied by client) a document level attribute (not a Job level attribute) Added it to Send-Document and Send-URI, removed it from Job Description attributes 10 In Print-Job response, clarified job-uri and job-id 11. Clarified that on a query, and IPP object MAY always respond with a subset of supported attributes and or values depending on security policy in place 12. Fixed ambiguity over possible Send-URI with no URI reference 13. Clarified "out-of-band" values and usage 14. Removed un-needed entries in Job Template table (4.2) for "compression ", "job-k-octets ", "job-impressions ", and "job-media-sheets " 15. "orientation" changed to "orientation-requested" new language to show that it is a special case Job Template attribute. Added "reverse-portrait" Moved enums to start at 3 Clarified that all IPP enums start at 3 for SNMP MIB alignment purposes 16. Added new section on IANA considerations (referenced IANA Consideration I-D) 17. Added ref for GZIP 18. Clarified "containing-printer-uri" 19. Removed "printer-tls-uri", added "uri-security-supported", and fixed up "printer-uri-supported". Gave an example for multiple URIs with different security mechanisms 20. Made sure all "pdl-override-supported" were not "pdl-override" (fixed an inconsistency) 21. Changed MUST to SHOULD in 5.4 on conformance requirement for clients to support TLS 22 Fixed up references to IPP I-Ds 23. Fixed some minor formatting bugs 24. Added Bob's note to case f) in 8.3 (gateway use of user name) 25. Fixed ambiguity in 8,5 on IPP TLS profile 26. Added note on why developers should subscribe to the DL 27. Fixed number 2 in the description of what 'not-attempted' means for "pdl-override-supported" Number 2 used to mean something more like 'attempted' 28. Added a new level 3 header in 15.3 to show validation of request-id (in range 1:MAX) 29. Added a new level 3 header in 15.4 to show check for "printer-is-accepting-jobs" 30. Fixed up 16 to show new generic directory schema changes corresponding to "printer-uri-supported" and "uri-security-supported" changes There is still a problem with "printer-uri", "printer-uri-supported", "job-id", and "containing-printer-uri" - I will send a separate email. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Wed Jan 14 14:35:44 1998 Delivery-Date: Wed, 14 Jan 1998 14:35:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA03767 for ; Wed, 14 Jan 1998 14:35:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11547 for ; Wed, 14 Jan 1998 14:38:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14618 for ; Wed, 14 Jan 1998 14:35:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 14:30:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13434 for ipp-outgoing; Wed, 14 Jan 1998 14:04:43 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 14 Jan 1998 12:04:00 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - Problem with job ID and containing printer URI Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org We still have a problem with printer-uri, job-uri, job-id, and containing-printer-uri. Some statements of fact 1. The client supplied "printer-uri" in a create request MUST be one of the URIs in "printer-uri-supported" 2. For each new Job object, the Printer object generates both a "job-id" and a "job-uri". 3. If the client has a only a Job URI the client can query the Job to get the containing printer URI 4. We DO NOT return the "containing printer URI" in the create response, but we do return the Job URI and the Job ID. Since we do not return the containing printer URI, we are assuming that the containing printer URI MUST BE the same as the client supplied Printer URI. Here is the question: Should the Printer object generate the "containing-printer-uri" for a new Job object or should the Printer object use the client supplied "printer-uri"?? Or stated another way: Should the "printer-uri" that a client uses on a create request be the "containing-printer-uri" or should the Printer object choose the value for "containing-printer-uri" which might be different than the client supplied printer URI in the create request? Some poeple have suggested that we should allow flexibility and allow the containing printer URI to be different than the original printer to which the create request was supplied. However, this would mandate: - ALWAYS returning a "containing-printer-uri" whenever the "job-id" is returned (create response, get Jobs query, query Job). We would never allow a client to get ONLY a job id. It MUST always get both since the client might query a Printer URI for a Job and then it might have to use a different Printer URI to query the job using the Job ID, so both must ALWAYS be returned. - The Job ID has no meaning in the the context of the Printer object being queried, only in the "contianing-printer-uri" Printer This seems convoluted. We have this flexibility in the Job URI (where it should be). We only introduced the Job ID for support for existing APIs. I am sure that these APIs to not support a Job ID coming back for a different printer than the one to which the job is being submitted. I think that the answer to the above should be: 1. The client supplied printer-uri should be the containing-printer-uri always! A client can always go back to Printer object to which the job was submitted and use the job-id. 2. If a client is querying a Printer for Jobs, the Printer only returns job ids for jobs that are associated with that Pritner URI 3. Leave the flexibility of Job identifiers that are independent of Printer URIs to the "job-uri" attribute not the "job-id"attribute. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Wed Jan 14 15:39:38 1998 Delivery-Date: Wed, 14 Jan 1998 15:39:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA04848 for ; Wed, 14 Jan 1998 15:39:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11852 for ; Wed, 14 Jan 1998 15:42:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA15481 for ; Wed, 14 Jan 1998 15:39:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 15:27:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14779 for ipp-outgoing; Wed, 14 Jan 1998 15:02:04 -0500 (EST) Message-Id: <199801142002.MAA32012@rbi.rbi.com> Subject: IPP>Apparent conflicts clarification Date: Wed, 14 Jan 98 12:02:03 -0800 x-sender: bgalten@rbi.rbi.com x-mailer: Claris Emailer 2.0, March 15, 1997 From: Brendan Galten To: "IPP Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: ipp-owner@pwg.org There are a couple of items that I was hoping somebody could clarify for me. The first is an apparent conflict between the protocol and model documents. Here is a synopsis: On page 133 of the model document, in section 15.3.3.1 is the paragraph: "If an IPP object receives a request with (1) required attribute groups missing, or (2) the attributes groups are out of order, or (3) the groups are repeated, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code." However, the protocol document states on page 5 that: A receiver of a request SHALL be able to process as equivalent empty attribute groups: a) an xxx-attributes-tag with an empty xxx-attribute-sequence, b) an expected but missing xxx-attributes-tag. Perhaps I am not reading the documents correctly, but case "b" in the protocol rule appears to conflict with case "1" in the model rule. Please let me know if and how I am interpreting this incorrectly. Also, on page 130 of the model document note 3 states: "The Unsupported Attributes Group is present only if the client included some Operation and/or Job Template attributes that the printer doesn't support whether a success or an error return." It would seem that the "error return" case would contain either 0 or a subset of all Unsupported Attributes. Either an error case can occur before any or all Unsupported Attributes were found. The question is, is there any significance to the Unsupported Attributes list that is returned given that the list could be incomplete? Should the only attribute in the list be the offending attribute, if found? If an unrecoverable error occurred then there is no way to complete the list. Perhaps, if my thinking is correct, note 3 could exclude Unsupported Attributes in the error case. Again please let me know if my understanding of the document is correct. Any help would be appreciated. Thanks, Brendan Galten Brendan Galten RBI Software Systems 510-204-9980 bgalten@rbi.com From ipp-owner@pwg.org Wed Jan 14 15:47:23 1998 Delivery-Date: Wed, 14 Jan 1998 15:47:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA04965 for ; Wed, 14 Jan 1998 15:47:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11892 for ; Wed, 14 Jan 1998 15:50:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16041 for ; Wed, 14 Jan 1998 15:47:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 15:37:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14796 for ipp-outgoing; Wed, 14 Jan 1998 15:07:53 -0500 (EST) Date: Wed, 14 Jan 1998 12:07:22 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801142007.MAA05343@woden.eng.sun.com> To: ipp@pwg.org, SISAACSON@novell.com Subject: Re: IPP> MOD - Problem with job ID and containing printer URI X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I think that you are making different assumptions than I am about the containing-printer-uri. I have assumed that if a client submits a job J to printer P and then queries the job id of J returned by the printJob operation for its containing-printer-uri, it should get back P. But in any case, it can still perform a Get-Jobs to P and see the job J in the list. So there is no need for PrintJob to return containing-printer-uri because it is the printer to which the PrintJob was submitted. If someone who is not the owner of J queries J, then the P returned may be different because of security issues. Thus containing-printer-uri is a computed attribute whose value can differ for each query. That's my view of it. I hope that others have the same understanding. Bob Herriot > From ipp-owner@pwg.org Wed Jan 14 11:32:51 1998 > X-Mailer: Novell GroupWise 4.1 > Date: Wed, 14 Jan 1998 12:04:00 -0700 > From: Scott Isaacson > To: ipp@pwg.org > Subject: IPP> MOD - Problem with job ID and containing printer URI > Mime-Version: 1.0 > Content-Disposition: inline > Sender: ipp-owner@pwg.org > X-Lines: 99 > > > We still have a problem with printer-uri, job-uri, job-id, and > containing-printer-uri. Some statements of fact > > 1. The client supplied "printer-uri" in a create request MUST be one of the > URIs in "printer-uri-supported" > 2. For each new Job object, the Printer object generates both a "job-id" and > a "job-uri". > 3. If the client has a only a Job URI the client can query the Job to get > the containing printer URI > 4. We DO NOT return the "containing printer URI" in the create response, but > we do return the Job URI and the Job ID. Since we do not return the > containing printer URI, we are assuming that the containing printer URI MUST > BE the same as the client supplied Printer URI. > > Here is the question: > > Should the Printer object generate the "containing-printer-uri" for a new > Job object or should the Printer object use the client supplied > "printer-uri"?? > > Or stated another way: > > Should the "printer-uri" that a client uses on a create request be the > "containing-printer-uri" or should the Printer object choose the value for > "containing-printer-uri" which might be different than the client supplied > printer URI in the create request? > > Some poeple have suggested that we should allow flexibility and allow the > containing printer URI to be different than the original printer to which > the create request was supplied. However, this would mandate: > > - ALWAYS returning a "containing-printer-uri" whenever the "job-id" is > returned (create response, get Jobs query, query Job). We would never allow > a client to get ONLY a job id. It MUST always get both since the client > might query a Printer URI for a Job and then it might have to use a > different Printer URI to query the job using the Job ID, so both must ALWAYS > be returned. > - The Job ID has no meaning in the the context of the Printer object being > queried, only in the "contianing-printer-uri" Printer > > This seems convoluted. We have this flexibility in the Job URI (where it > should be). We only introduced the Job ID for support for existing APIs. I > am sure that these APIs to not support a Job ID coming back for a different > printer than the one to which the job is being submitted. > > I think that the answer to the above should be: > > 1. The client supplied printer-uri should be the containing-printer-uri > always! A client > can always go back to Printer object to which the job was submitted and use > the job-id. > 2. If a client is querying a Printer for Jobs, the Printer only returns job > ids for jobs that are associated with that Pritner URI > 3. Leave the flexibility of Job identifiers that are independent of Printer > URIs to the "job-uri" attribute not the "job-id"attribute. > > Scott > > > > ************************************************************ > Scott A. Isaacson > Corporate Architect > Novell Inc., M/S PRV-C-121 > 122 E 1700 S, Provo, UT 84606 > voice: (801) 861-7366, (800) 453-1267 x17366 > fax: (801) 861-2517 > email: sisaacson@novell.com > web: http://www.novell.com > ************************************************************ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Wed Jan 14 16:12:29 1998 Delivery-Date: Wed, 14 Jan 1998 16:12:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA05410 for ; Wed, 14 Jan 1998 16:11:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA11988 for ; Wed, 14 Jan 1998 16:14:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA16695 for ; Wed, 14 Jan 1998 16:11:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 16:03:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14973 for ipp-outgoing; Wed, 14 Jan 1998 15:29:59 -0500 (EST) Message-ID: <01BD20F0.485DF940.bpenteco@boi.hp.com> From: Bob Pentecost To: "'PWG-ipp'" Cc: "'Hastings, Tom (PWG)'" Subject: IPP> RE: Move "orientation-requested" from J.T. to Operation attribute group? Date: Wed, 14 Jan 1998 08:19:50 -0700 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 Here's a reply I had sent to Tom. Tom's assessment of how PCL works is correct. Bob Pentecost HP -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] Sent: Tuesday, January 13, 1998 8:34 AM To: Bob Pentecost Cc: THast@cp10.es.xerox.com Subject: RE: Move "orientation-requested" from J.T. to Operation attribute group? Bob, Ok if I forward this to the IPP DL? I think that you are saying that the "orientation-requested" (or whatever we call it), could be useful for submitting PCL documents, especially by reference, if the orientation command had been (mistakenly) omitted from the PCL for some reason. Correct? A second reason for using the attribute might be that the default for some printer isn't what the user wants. Suppose the user has convenient access to a printer that defaults to B size media with landscape orientation. The user wants to print a simple portrait PCL file that doesn't have an embedded portrait orientation instruction. This "orientation-requested" attribute would allow the user to make sure that the Printer object's "orientation-requested-default" did not take effect. I just want to make sure that we write the description so that this attribute could be used with PCL (and any other PDL where the orientation instruction is optional in the data). Ok if I copy your reply and this replay to the IPP DL? Or maybe you would prefer to forward it yourself? Thanks, Tom At 13:47 01/12/1998 PST, you wrote: >Tom, > >You're right, PCL can optionally contain a command to change the orientation. >If the PCL command is not present, the orientation will be the default as set >through the printer's control panel or as specified with the PJL settings that >precede the job. > >Bob > > >-----Original Message----- >From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] >Sent: Monday, January 12, 1998 10:53 AM >To: ipp@pwg.org >Cc: Bob Pentecost; Rick, DECprint engineer without portfolio, DTN 297-8350 >(1-508-467-) MRO1-2/K20 23-Sep-1997 1834 -0400; David Kellerman >Subject: Move "orientation-requested" from J.T. to Operation attribute group? > >1. So should we move "orientation-requested" from being a Job Template >attribute to being an operation attribute, since it applies only to >documents that don't have orientation embedded in the document >and is not requesting to override the document? > >Job Template attributes are intended to be requests to override what >is in the document data (as Harry Lewis points out). > >If we do make it an operation attribute on Print-Job, Validate-Job, >Print-URI, Send-Document, and Send-URI, we also need to move >the corresponding "orientation-requested-default" and >"orientation-requested-supported" to the Printer object's Printer >Description group. > >(NOTE: such movement will be the fifth attribute that we have moved >from the Job Template attributes group to the Operation attributes >and Printer Description attributes group (the other 4 being: "compression", >"job-k-octets", "job-impressions", and "job-media-sheets".) > > >2a. Should we rename the operation attribute from "orientation-requested" >to "orientation-default", since it is not a request to override the PDL >data, but only to be used if the PDL data does not contain an orientation >instruction. > >BTW, I think that this attribute can apply to other PDLs, than 'text/plain' >which can NEVER contain an orientation instruction. However, I suspect >that other PDLs, such as PCL and DEC-PPL3, can have an OPTIONAL >orientation embedded instruction. (Hence the cc list). When a document >is being printed in which the optional instruction was omitted, the >"orientation-default" attribute could be used to control the orienation. >Therefore, the semantics are exactly those of any "xxx-default" attribute, >except that this attribute is being supplied by the client, instead of >the Printer object. > >If we do rename the atribute, then the corresponding Printer Description >attributes would become: "orientation-default-default" and >"orientation-default-suppoted". > > >2b. Or could we say that the Printer Description attribute is really the >same as the operation attribute, since they have the same semantics >and so call the Printer Description attributes: > > "orientation-default" and "orientation-default-supported"? > >We currently have the "job-name" as an operation attribute which is >the same as the "job-name" Job description attribute, so having an >attribute with the same name in these two different groups would >be the same idea for the "orientation-default" operation attribute. > >We've agreed that we can't have the same name for an attribute in the >Job Template attribute group and any other group. > >Comments? > >Tom > > > From ipp-owner@pwg.org Wed Jan 14 16:17:11 1998 Delivery-Date: Wed, 14 Jan 1998 16:17:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA05556 for ; Wed, 14 Jan 1998 16:17:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12020 for ; Wed, 14 Jan 1998 16:19:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA17308 for ; Wed, 14 Jan 1998 16:17:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 16:13:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15976 for ipp-outgoing; Wed, 14 Jan 1998 15:45:49 -0500 (EST) Date: Wed, 14 Jan 1998 12:45:20 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801142045.MAA05385@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO A simple XML example for today's teleconference X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Here is a simple example for us to use in today's teleconference. It encodes a PrintJob operations into XML. There are many ways to do this. This is one idea that is roughly correct but not exactly what I might propose a few days from now. Note: '' mark the beginning and end of comments and the '<' and '>' mark the beginning and end of 'elements' which provide the structuring. I will make liberal use of comments below each line to explain what is meant above. NOTE: THIS EXAMPLE IS TO PRESENT IDEAS FOR DISCUSSION. DO NOT TAKE THIS AS A PROPOSAL. POST /printer/killtree HTTP/1.1 Content-Type = text/xml Content-Length = ??? mein Stoff Wolfgang 50 300 300 inch From ipp-owner@pwg.org Wed Jan 14 19:10:56 1998 Delivery-Date: Wed, 14 Jan 1998 19:10:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA10066 for ; Wed, 14 Jan 1998 19:10:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12722 for ; Wed, 14 Jan 1998 19:13:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18060 for ; Wed, 14 Jan 1998 19:10:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 19:06:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17516 for ipp-outgoing; Wed, 14 Jan 1998 18:51:22 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 14 Jan 1998 16:50:38 -0700 From: Scott Isaacson To: ipp@pwg.org, bgalten@rbi.com Subject: Re: IPP>Apparent conflicts clarification Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org >>> Brendan Galten 01/14 1:02 PM >>> > There are a couple of items that I was hoping somebody could clarify for > me. The first is an apparent conflict between the protocol and model > documents. Here is a synopsis: > On page 133 of the model document, in section 15.3.3.1 is the > paragraph: > > "If an IPP object receives a request with (1) required > attribute groups missing, or > (2) the attributes groups are out of order, or (3) the groups > are repeated, the IPP > object REJECTS the request and RETURNS the > 'client-error-bad-request' status code." > > However, the protocol document states on page 5 that: > > A receiver of a request SHALL be able to process as equivalent > empty attribute > groups: > > a) an xxx-attributes-tag with an empty >xxx-attribute-sequence, > > b) an expected but missing xxx-attributes-tag. > > >Perhaps I am not reading the documents correctly, but case "b" in the >protocol rule appears to conflict with case "1" in the model rule. >Please let me know if and how I am interpreting this incorrectly. Notice that case 1) in the Model Document describes a "required" (or expected) group that is missing. A required group coming from the client is one that contains a MANDATORY (for a client to supply) attribute. The protocol document defines what "missing" means: it is either case a) (a tag but no attributes) or b) (no tag and therefore no attributes). So, in either case if a required group (a group containing a MANDATORY to supply attribute) is missing (not there at all or there but empty) then a 'client-error-bad-request' status code is returned. I don't see a conflict. > Also, on page 130 of the model document note 3 states: > > "The Unsupported Attributes Group is present only if the client >included some > Operation and/or Job Template attributes that the printer >doesn't support whether > a success or an error return." >It would seem that the "error return" case would contain either 0 or a >subset of all Unsupported Attributes. Either an error case can occur >before any or all Unsupported Attributes were found. The question is, is >there any significance to the Unsupported Attributes list that is >returned given that the list could be incomplete? Should the only >attribute in the list be the offending attribute, if found? If an >unrecoverable error occurred then there is no way to complete the list. >Perhaps, if my thinking is correct, note 3 could exclude Unsupported >Attributes in the error case. > Again please let me know if my understanding of the document is >correct. Any help would be appreciated. If the response status code is any error other than 'client-error-attributes-or-values-not-supported', then the requester can assume that the IPP object did not get to processing Job Template attributes against what is supported and so a subsequent request that fixed any other problem might still have one or more unsupported attributes. If the response is 'client-error-attributes-or-values-not-supported', the client can still only be sure that the returned list of unsupported attributes is only some not necessarily all unsupported attributes. We used to have a statement like "if any unsupported attribute is returned then all SHOULD be returned", but we never had a SHALL. I think that now, that statement is not explicit but is actually embodied in the steps outlined in section 15.3. If the response status code is one of the "successful status-ok-but-xxx" cases, the list of unsupported attributes can be assumed to be the full set since the successful status code indicates that all validation and all checks have been done and the IPP object thinks that it can do what it is being asked to do. There still might be errors, but they would not affect what is or is not supported. Short answer: a list of unsupported attributes returned (on an error status code) is not guaranteed to be the full set of unsupported attributes. > Thanks, >Brendan Galten > >Brendan Galten >RBI Software Systems >510-204-9980 >bgalten@rbi.com ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Wed Jan 14 19:50:56 1998 Delivery-Date: Wed, 14 Jan 1998 19:50:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA10622 for ; Wed, 14 Jan 1998 19:50:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12831 for ; Wed, 14 Jan 1998 19:53:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18766 for ; Wed, 14 Jan 1998 19:50:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 19:46:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18186 for ipp-outgoing; Wed, 14 Jan 1998 19:31:20 -0500 (EST) Date: Wed, 14 Jan 1998 16:27:46 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801150027.QAA05602@woden.eng.sun.com> To: bpenteco@boi.hp.com Subject: Re: IPP> RE: Move "orientation-requested" from J.T. to Operation attribute group? Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org If a PCL document is formatted for landscape but has no command saying landscape and the printer default is portrait, does the text get oriented as if the page were portrait with lines running off the edge of the paper? Bob Herriot > From: Bob Pentecost > >Tom, > > > >You're right, PCL can optionally contain a command to change the > orientation. > >If the PCL command is not present, the orientation will be the default as > set > >through the printer's control panel or as specified with the PJL settings > that > >precede the job. > > > >Bob From jmp-owner@pwg.org Wed Jan 14 20:38:35 1998 Delivery-Date: Wed, 14 Jan 1998 20:38:35 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA11309 for ; Wed, 14 Jan 1998 20:38:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12909 for ; Wed, 14 Jan 1998 20:41:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19747 for ; Wed, 14 Jan 1998 20:38:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 20:32:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18895 for jmp-outgoing; Wed, 14 Jan 1998 20:26:57 -0500 (EST) From: don@lexmark.com Message-Id: <199801150126.AA09514@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, sense@pwg.org, p1394@pwg.org, pmp@pwg.org, fin@pwg.org Date: Wed, 14 Jan 1998 17:14:49 -0500 Subject: JMP> PWG Meeting Agenda - Final Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From pmp-owner@pwg.org Wed Jan 14 20:40:47 1998 Delivery-Date: Wed, 14 Jan 1998 20:40:47 -0500 Return-Path: pmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA11333 for ; Wed, 14 Jan 1998 20:40:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12918 for ; Wed, 14 Jan 1998 20:43:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20009 for ; Wed, 14 Jan 1998 20:40:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 20:33:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18862 for pmp-outgoing; Wed, 14 Jan 1998 20:26:25 -0500 (EST) From: don@lexmark.com Message-Id: <199801150126.AA09514@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, sense@pwg.org, p1394@pwg.org, pmp@pwg.org, fin@pwg.org Date: Wed, 14 Jan 1998 17:14:49 -0500 Subject: PMP> PWG Meeting Agenda - Final Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: pmp-owner@pwg.org Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From pwg-owner@pwg.org Wed Jan 14 20:44:56 1998 Delivery-Date: Wed, 14 Jan 1998 20:44:56 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA11367 for ; Wed, 14 Jan 1998 20:44:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA12928 for ; Wed, 14 Jan 1998 20:47:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20319 for ; Wed, 14 Jan 1998 20:44:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 20:37:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18929 for pwg-outgoing; Wed, 14 Jan 1998 20:27:33 -0500 (EST) From: don@lexmark.com Message-Id: <199801150126.AA09514@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, sense@pwg.org, p1394@pwg.org, pmp@pwg.org, fin@pwg.org Date: Wed, 14 Jan 1998 17:14:49 -0500 Subject: PWG> PWG Meeting Agenda - Final Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Jan 14 20:58:51 1998 Delivery-Date: Wed, 14 Jan 1998 20:58:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA11554 for ; Wed, 14 Jan 1998 20:58:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12950 for ; Wed, 14 Jan 1998 21:01:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20936 for ; Wed, 14 Jan 1998 20:58:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 14 Jan 1998 20:54:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18912 for ipp-outgoing; Wed, 14 Jan 1998 20:27:11 -0500 (EST) From: don@lexmark.com Message-Id: <199801150126.AA09514@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org, sense@pwg.org, p1394@pwg.org, pmp@pwg.org, fin@pwg.org Date: Wed, 14 Jan 1998 17:14:49 -0500 Subject: IPP> PWG Meeting Agenda - Final Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Thu Jan 15 15:29:27 1998 Delivery-Date: Thu, 15 Jan 1998 15:29:28 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA08850 for ; Thu, 15 Jan 1998 15:29:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA16142 for ; Thu, 15 Jan 1998 15:32:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA25122 for ; Thu, 15 Jan 1998 15:29:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 15 Jan 1998 15:19:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24533 for ipp-outgoing; Thu, 15 Jan 1998 15:04:31 -0500 (EST) From: Carl Kugler To: Cc: Subject: IPP> Re: IPP > TES> IBM Client Prototype Message-ID: <5030100016217588000002L082*@MHS> Date: Thu, 15 Jan 1998 15:04:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA08850 Puru- As Steve says below, the IPP Client is useless without an IPP Server. However, one can make a "pretend" IPP server by using a driver to serve binary trace files such as ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012B00.trc (See http://www.pwg.org/hypermail/ipp/2911.html for a description of the trace repository.) This is one of the techniques we plan to use for interoperability testing. Here is some example Java 1.1 code for a simple driver: // Server which listens on port 80 and transmits a file called "response" // after accepting a connection. Records data read from client in // file called "request". import java.io.*; import java.net.*; public class driver { class reader implements Runnable // Reads from socket, writes to file { Socket readsock; reader(Socket sock) { readsock = sock; } public void run() { try { byte b[] = new byte[32768]; int len = 0; InputStream in = readsock.getInputStream(); FileOutputStream fout = new FileOutputStream("request"); while ((len = in.read(b)) > 0) fout.write(b, 0, len); } catch (Exception e) { e.printStackTrace(); } } } class writer implements Runnable // Reads from file, writes to socket { Socket writesock; writer(Socket sock) { writesock = sock; } public void run() { try { byte b[] = new byte[32768]; int len = 0; OutputStream out = writesock.getOutputStream(); FileInputStream fin = new FileInputStream("response"); while ((len = fin.read(b)) > 0) out.write(b, 0, len); System.err.println("Sent response."); } catch (Exception e) { e.printStackTrace(); } } } driver() throws IOException { ServerSocket listener = new ServerSocket(80); Socket serverSock = listener.accept(); System.err.println("Accepted connection."); Thread t1 = new Thread(new reader(serverSock)); Thread t2 = new Thread(new writer(serverSock)); t1.start(); t2.start(); } public static void main(String argv[]) throws IOException { new driver(); } } // Carl Kugler // IBM ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/15/98 10:18 AM --------------------------- ipp-owner@pwg.org on 01/13/98 01:22:53 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> IPP > IBM Client Prototype Puru, The client prototype attempts to connect to an IPP Server before performing any data stream writes. As a result, in your case, you get an exception that we have not provided an error dialog for. Unfortunately the client does not do anything unless it is interacting with an IPP Server. Steve From ipp-owner@pwg.org Thu Jan 15 17:25:19 1998 Delivery-Date: Thu, 15 Jan 1998 17:25:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA11112 for ; Thu, 15 Jan 1998 17:24:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA16824 for ; Thu, 15 Jan 1998 17:27:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26478 for ; Thu, 15 Jan 1998 17:24:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 15 Jan 1998 17:20:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25915 for ipp-outgoing; Thu, 15 Jan 1998 17:05:25 -0500 (EST) Message-ID: <01BD21C6.ECF40C20.bpenteco@boi.hp.com> From: Bob Pentecost To: "'Robert Herriot'" Cc: "ipp@pwg.org" Subject: RE: IPP> RE: Move "orientation-requested" from J.T. to Operation attribute group? Date: Thu, 15 Jan 1998 14:32:27 -0700 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 Yes, if a PCL document is formatted for landscape but has no command saying landscape and the printer default is portrait, the text does get oriented as portrait, with lines running off the edge of the paper. Bob Pentecost HP -----Original Message----- From: Robert Herriot [SMTP:Robert.Herriot@Eng.Sun.COM] Sent: Wednesday, January 14, 1998 5:28 PM To: bpenteco@boi.hp.com Cc: ipp@pwg.org Subject: Re: IPP> RE: Move "orientation-requested" from J.T. to Operation attribute group? If a PCL document is formatted for landscape but has no command saying landscape and the printer default is portrait, does the text get oriented as if the page were portrait with lines running off the edge of the paper? Bob Herriot > From: Bob Pentecost > >Tom, > > > >You're right, PCL can optionally contain a command to change the > orientation. > >If the PCL command is not present, the orientation will be the default as > set > >through the printer's control panel or as specified with the PJL settings > that > >precede the job. > > > >Bob From ipp-owner@pwg.org Thu Jan 15 22:16:23 1998 Delivery-Date: Thu, 15 Jan 1998 22:16:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA14697 for ; Thu, 15 Jan 1998 22:16:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA17483 for ; Thu, 15 Jan 1998 22:19:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA28216 for ; Thu, 15 Jan 1998 22:16:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 15 Jan 1998 22:11:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27623 for ipp-outgoing; Thu, 15 Jan 1998 21:56:03 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 15 Jan 1998 19:54:35 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new 970116 model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I have posted: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980116-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980116-rev.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980116.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980116.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980116.txt The only changes are: 1. Fixed up Printer object URI problem (containing-printer-uri => job-printer-uri) 2. Fixed up "orientation-request" problem 3. Clean up bad cross-references 4. Very minor edits Rev marks are againts 980109. This is going to the IETF as draft-ietf-ipp-model-09.txt Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From adm Fri Jan 16 14:15:01 1998 Delivery-Date: Fri, 16 Jan 1998 14:27:10 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA02890 for ietf-123-outbound.10@ietf.org; Fri, 16 Jan 1998 14:12:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA02860; Fri, 16 Jan 1998 14:11:35 -0500 (EST) Message-Id: <199801161911.OAA02860@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-05.txt Date: Fri, 16 Jan 1998 14:11:30 -0500 Sender: cclark@cnri.reston.va.us --NextPart Note: This announcement is being re-sent on the order of authorship. 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-05.txt Pages : 31 Date : 13-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19980116140010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980116140010.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jan 16 14:38:44 1998 Delivery-Date: Fri, 16 Jan 1998 14:38:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA03347 for ; Fri, 16 Jan 1998 14:38:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19684 for ; Fri, 16 Jan 1998 14:41:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00301 for ; Fri, 16 Jan 1998 14:38:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 16 Jan 1998 14:23:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29269 for ipp-outgoing; Fri, 16 Jan 1998 14:02:06 -0500 (EST) Message-Id: <3.0.1.32.19980116105933.0098cce0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 16 Jan 1998 10:59:33 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 Cc: paulmo@microsoft.com, lstein@fapo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference - 980114 Attending: Carl-Uno Manros Don Wright Scott Isaacson Bob Herriot Tom Hastings Paul Moore Peter Zehler Ron Bergman Keith Carter Swen Johnson Carl Kugler Steve Gebert Jim Walker Harry Lewis Randy Turner Ira Mcdonald Xavier Riley One more gentleman from Novell (who's name I couldn't read afterwards!) The main agenda point was to discuss Paul Moore's suggestion to examine the use of XML to carry the protocol information which is currently in the application/ipp MIME type. Paul explained that the Microsoft Web Architecture team wanted to examine the potential use of XML in IPP in order to align our protocol solution with other standardization projects such as WEBDAV, which have already jumped onto the XML bandwagon. He offered to have a strawman proposal ready for presentation at the PWG IPP meeting in Maui on January 28th. Paul would show up for the meeting and also bring along a Microsoft Web/XML expert. It was agreed that this was a reasonable way to proceed for now, but it was also clear that the group had not yet bought into this approach. A number of comments were offered: Tom Hastings has written up a small document listing the requirements for a new protocol mapping, which has been distrubuted to the DL. Paul Moore promissed to make sure that that list was studied in writing up the new proposal. Bob Herriot said that he had already stated his own analysis to try to determine if a mapping to XML was feasible. Some initial ideas have already been sent to the DL. He had identified a couple of issues, the most important one seems to be how we get the document data in - can they form part of the XML structure or do they have to be in a separate file? Bob will try to verify any XML issues that come up with Sun experts that are active in the XML project. Peter Zehler wanted to get better information about the extra footprint that an XML parser would take up in a small printer, compared to our current solution. It was also pointed out that the W3C has not yet ratified XML as an official Recommendation; voting closes on January 20th. Scott Isaacson pointed out that the Microsoft idea about also introducing new HTTP methods was a separate subject that should be discussed independently from the XML discussion. It seemed to be little or no interest in the group to go over that subject again, which has been extensively discussed during last year. Paul More undertook to not only provide the new draft solution, but also to come up with some convincing rationale for why we should consider the change. It was also requested to set up a phone conference into the Maui meeting for people who are unable to attend. Carl-Uno will organize that in collaboration with Larry Stein who is making the conference arrangements for Maui. The phone conference will be held on January 28th, 1 - 3 pm local time (which is 3 - 5 pm PST and 6 - 8 pm EST), mark your calendars. So far, 20 people had signed up to be present in Maui on January 28th. I few more might come due to this agenda change. Paul Moore will make sure that the Microsoft input is available on the IPP DL on the day before the meeting. On the IPP meeting agenda we will now reserve the time from 10:30 am to at most 5 pm on the 28th for discussion of the prosed new protocol mapping, which means that we will shorten the time previously planned to discuss possible future extensions to IPP. Some, or all, of that discussion will be moved to the following day, during which we will also discuss interoperability testing. The rest of the phone conference was devoted to some detailed comments about the Model & Semantics document. Scott Isaacson will document the final results of those discussions in the latest draft, which has actually already been distributed to the DL carrying the date January 16th. This draft is NOT expected to change further. Next week's phone conference will review any new information that has come up on the DL in the meantime. --- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 16 14:40:18 1998 Delivery-Date: Fri, 16 Jan 1998 14:40:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA03408 for ; Fri, 16 Jan 1998 14:40:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19688 for ; Fri, 16 Jan 1998 14:43:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00509 for ; Fri, 16 Jan 1998 14:40:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 16 Jan 1998 14:33:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29291 for ipp-outgoing; Fri, 16 Jan 1998 14:11:55 -0500 (EST) Message-Id: <199801161911.OAA02860@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-05.txt Date: Fri, 16 Jan 1998 14:11:30 -0500 Sender: ipp-owner@pwg.org --NextPart Note: This announcement is being re-sent on the order of authorship. 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-05.txt Pages : 31 Date : 13-Jan-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19980116140010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980116140010.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jan 16 15:40:07 1998 Delivery-Date: Fri, 16 Jan 1998 15:40:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA04260 for ; Fri, 16 Jan 1998 15:40:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19983 for ; Fri, 16 Jan 1998 15:42:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01206 for ; Fri, 16 Jan 1998 15:39:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 16 Jan 1998 15:33:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00639 for ipp-outgoing; Fri, 16 Jan 1998 15:18:09 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 16 Jan 1998 13:17:05 -0700 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, ipp@pwg.org Cc: lstein@fapo.com, paulmo@microsoft.com Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org I forgot that I was supposed to write up the Model and Semantics dicsussion and post the results. As Carl-Uno has pointed out, I already posted the actual document and the changes can be read following the revision marks, however to summarize on the DL: 1. The "containing-printer-uri" name was changed to "job-printer-uri" There was a discussion about making it hard (always one value and only one value) or soft (any one of the possibly many URIs for the Printer object depending on the URI used in the query to get the attribute). It was decided to make it "hard". In other words: It is popultated by the Printer object that creates the Job and t is the URI of the printer object that created the job. If the Printer object that creates the Job has more than one URI, it is the one URI that was used by the client when issuing the create request. The client always uses the creating Printer URI along with the "job-id" when targeting a Job object via the Job ID. If the client (or any other client) queries the Printer objec with a different URI, the "job-printer-uri" is still (hard not soft) the URI that was used for creation, not the URI that is being used for the query. It is possible that some implementations might allow a client to query the job using the Job ID and any one of the URIs for the Printer object that created the Job, however the spec is silent on such a feature (left up to the implementation). It was noted that the Job ID is only in the IPP model for existing system API and model constraints, it is not an elegant part of the new IPP model. In those existing systems, there is really no concept of a "soft" printer associated with the Job. The job was createad with a Printer in mind and it always stays associated with that Printer, not some other more or less secure access channel to that printer. 2. "orientation-requested" stays a J.T. attribute. The model already notes that any JT attribute may or may not be supported based on the context of the document format. Language was added to "orientation-requested" to make very clear that it is "what is wanted" not "a description of what is" and that it is expected the Printer objects support "orientation-requested" for some document formats (text/plain) and not others (application/postscript). As Carl-Uno stated, the -09 version just delivered to the IETF resolves ALL issues and problems raised during the final call period and it is expected that the -09 document will be the document sent to the IESG. As soon as it is announced, are you, Carl-Uno, going to notify the IESG? We have 100% consensus that any of the latest mess about XML will have NO impact on the model. Scott >>> Carl-Uno Manros 01/16 11:59 AM >>> Minutes from PWG IPP Phone Conference - 980114 Attending: Carl-Uno Manros Don Wright Scott Isaacson Bob Herriot Tom Hastings Paul Moore Peter Zehler Ron Bergman Keith Carter Swen Johnson Carl Kugler Steve Gebert Jim Walker Harry Lewis Randy Turner Ira Mcdonald Xavier Riley One more gentleman from Novell (who's name I couldn't read afterwards!) The main agenda point was to discuss Paul Moore's suggestion to examine the use of XML to carry the protocol information which is currently in the application/ipp MIME type. Paul explained that the Microsoft Web Architecture team wanted to examine the potential use of XML in IPP in order to align our protocol solution with other standardization projects such as WEBDAV, which have already jumped onto the XML bandwagon. He offered to have a strawman proposal ready for presentation at the PWG IPP meeting in Maui on January 28th. Paul would show up for the meeting and also bring along a Microsoft Web/XML expert. It was agreed that this was a reasonable way to proceed for now, but it was also clear that the group had not yet bought into this approach. A number of comments were offered: Tom Hastings has written up a small document listing the requirements for a new protocol mapping, which has been distrubuted to the DL. Paul Moore promissed to make sure that that list was studied in writing up the new proposal. Bob Herriot said that he had already stated his own analysis to try to determine if a mapping to XML was feasible. Some initial ideas have already been sent to the DL. He had identified a couple of issues, the most important one seems to be how we get the document data in - can they form part of the XML structure or do they have to be in a separate file? Bob will try to verify any XML issues that come up with Sun experts that are active in the XML project. Peter Zehler wanted to get better information about the extra footprint that an XML parser would take up in a small printer, compared to our current solution. It was also pointed out that the W3C has not yet ratified XML as an official Recommendation; voting closes on January 20th. Scott Isaacson pointed out that the Microsoft idea about also introducing new HTTP methods was a separate subject that should be discussed independently from the XML discussion. It seemed to be little or no interest in the group to go over that subject again, which has been extensively discussed during last year. Paul More undertook to not only provide the new draft solution, but also to come up with some convincing rationale for why we should consider the change. It was also requested to set up a phone conference into the Maui meeting for people who are unable to attend. Carl-Uno will organize that in collaboration with Larry Stein who is making the conference arrangements for Maui. The phone conference will be held on January 28th, 1 - 3 pm local time (which is 3 - 5 pm PST and 6 - 8 pm EST), mark your calendars. So far, 20 people had signed up to be present in Maui on January 28th. I few more might come due to this agenda change. Paul Moore will make sure that the Microsoft input is available on the IPP DL on the day before the meeting. On the IPP meeting agenda we will now reserve the time from 10:30 am to at most 5 pm on the 28th for discussion of the prosed new protocol mapping, which means that we will shorten the time previously planned to discuss possible future extensions to IPP. Some, or all, of that discussion will be moved to the following day, during which we will also discuss interoperability testing. The rest of the phone conference was devoted to some detailed comments about the Model & Semantics document. Scott Isaacson will document the final results of those discussions in the latest draft, which has actually already been distributed to the DL carrying the date January 16th. This draft is NOT expected to change further. Next week's phone conference will review any new information that has come up on the DL in the meantime. --- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 16 16:29:18 1998 Delivery-Date: Fri, 16 Jan 1998 16:29:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA04856 for ; Fri, 16 Jan 1998 16:29:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20409 for ; Fri, 16 Jan 1998 16:32:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01890 for ; Fri, 16 Jan 1998 16:29:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 16 Jan 1998 16:24:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA01329 for ipp-outgoing; Fri, 16 Jan 1998 16:09:54 -0500 (EST) Message-Id: <3.0.1.32.19980116130725.00b194d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 16 Jan 1998 13:07:25 PST To: Scott Isaacson , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 Cc: Harald.Alvestrand@maxware.no, moore@cs.utk.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:17 PM 1/16/98 PST, Scott Isaacson wrote: >I forgot that I was supposed to write up the Model and Semantics dicsussion >and post the results. As Carl-Uno has pointed out, I already posted the >actual document and the changes can be read following the revision marks, >however to summarize on the DL: > ---snip, snip ---- >As Carl-Uno stated, the -09 version just delivered to the IETF resolves ALL >issues and problems raised during the final call period and it is expected >that the -09 document will be the document sent to the IESG. > >As soon as it is announced, are you, Carl-Uno, going to notify the IESG? We >have 100% consensus that any of the latest mess about XML will have NO >impact on the model. > >Scott Scott, As much as I would like to, I don't think it makes a lot of sense to send the Model document to the IESG before we also have full agreement around the Protocol document - after all the IETF is in the business of standardizing protocols. I am copying Harald and Keith Moore on this message to get their clarification on that. BTW, please note that Harald has a new email address, see above. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 16 19:09:37 1998 Delivery-Date: Fri, 16 Jan 1998 19:09:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA06831 for ; Fri, 16 Jan 1998 19:09:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21134 for ; Fri, 16 Jan 1998 19:11:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA03059 for ; Fri, 16 Jan 1998 19:08:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 16 Jan 1998 19:03:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02483 for ipp-outgoing; Fri, 16 Jan 1998 18:48:56 -0500 (EST) Message-Id: <3.0.1.32.19980116154627.00bb2690@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 16 Jan 1998 15:46:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP in Maui - Participants Cc: lstein@fapo.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_885023187==_" Sender: ipp-owner@pwg.org --=====================_885023187==_ Content-Type: text/plain; charset="us-ascii" Attached is an Excel file listing the people who have registed for Maui so far. We have 22 people for Wednesday January 28th, and 17 for Thursday January 29th. (Larry, you may not have Josh Cohen and Paul Moore from MS on your list yet). Sorry, no ASCII version of this PWG document. Carl-Uno --=====================_885023187==_ Content-Type: application/octet-stream; name="Maui.xls"; x-mac-type="584C5334"; x-mac-creator="5843454C" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Maui.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAHAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAABsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CAgAAAUFADMTygfhAAAAwQACAAAAvwAAAKQABgABABAPAADAAAAA4gAAAFwANgADQ1NHICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbAAUAAQAAAABCAAIA 5AQ9AQYAAAABAAIA6gACAP//nAACAA4AGQACAAAAEgACAAAAEwACAAAAPQASAOAB8ABYL6AjOAAA AAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABANoAAgAAADEAFADIAAAA/3+QAQAAAAAAAwVB cmlhbDEAFADIAAAA/3+QAQAAAAAAAwVBcmlhbDEAFADIAAAA/3+QAQAAAAAAAwVBcmlhbDEAFADI AAAA/3+QAQAAAAAAAwVBcmlhbDEAHgDwAAEA/3+8AgAAAAAAAw9UaW1lcyBOZXcgUm9tYW4xABQA 8AAAAP9/kAEAAAACAAMFQXJpYWwxABQAGAEBAP9/vAIAAAAAAAMFQXJpYWweBBoABQAXIiQiIywj IzBfKTtcKCIkIiMsIyMwXCkeBB8ABgAcIiQiIywjIzBfKTtbUmVkXVwoIiQiIywjIzBcKR4EIAAH AB0iJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJQAIACIiJCIjLCMjMC4wMF8pO1tSZWRd XCgiJCIjLCMjMC4wMFwpHgQ1ACoAMl8oIiQiKiAjLCMjMF8pO18oIiQiKiBcKCMsIyMwXCk7Xygi JCIqICItIl8pO18oQF8pHgQsACkAKV8oKiAjLCMjMF8pO18oKiBcKCMsIyMwXCk7XygqICItIl8p O18oQF8pHgQ9ACwAOl8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIq ICItIj8/Xyk7XyhAXykeBDQAKwAxXygqICMsIyMwLjAwXyk7XygqIFwoIywjIzAuMDBcKTtfKCog Ii0iPz9fKTtfKEBfKR4EBgCkAAMwLjDgABAAAAAAAPX/IADAIAAAAAAAAOAAEAABAAAA9f8g9MAg AAAAAAAA4AAQAAEAAAD1/yD0wCAAAAAAAADgABAAAgAAAPX/IPTAIAAAAAAAAOAAEAACAAAA9f8g 9MAgAAAAAAAA4AAQAAAAAAD1/yD0wCAAAAAAAADgABAAAAAAAPX/IPTAIAAAAAAAAOAAEAAAAAAA 9f8g9MAgAAAAAAAA4AAQAAAAAAD1/yD0wCAAAAAAAADgABAAAAAAAPX/IPTAIAAAAAAAAOAAEAAA AAAA9f8g9MAgAAAAAAAA4AAQAAAAAAD1/yD0wCAAAAAAAADgABAAAAAAAPX/IPTAIAAAAAAAAOAA EAAAAAAA9f8g9MAgAAAAAAAA4AAQAAAAAAD1/yD0wCAAAAAAAADgABAAAAAAAAEAIADAIAAAAAAA AOAAEAABACsA9f8g+MAgAAAAAAAA4AAQAAEAKQD1/yD4wCAAAAAAAADgABAAAQAsAPX/IPjAIAAA AAAAAOAAEAABACoA9f8g+MAgAAAAAAAA4AAQAAEACQD1/yD4wCAAAAAAAADgABAAAAAAAAEAIhDA IAAAAAAAAOAAEAAFAAAAAQAiGMAgAAAAAAAA4AAQAAUApAABACIcwCAAAAAAAADgABAABQABAAEA IhzAIAAAAAAAAOAAEAAFAAAAAQAgCMAgAAAAAAAA4AAQAAYAAAABACAIwCAAAAAAAADgABAABgAA AAEAIhjAIAAAAAAAAOAAEAAHAAAAAQAgCMAgAAAAAAAAkwIEABCAA/+TAgQAEYAG/5MCBAASgAT/ kwIEABOAB/+TAgQAAIAA/5MCBAAUgAX/kgDiADgAAAAAAP///wD/AAAAAP8AAAAA/wD//wAA/wD/ AAD//wCAAAAAAIAAAAAAgACAgAAAgACAAACAgADAwMAAgICAAJmZ/wCZM2YA///MAMz//wBmAGYA /4CAAABmzADMzP8AAACAAP8A/wD//wAAAP//AIAAgACAAAAAAICAAAAA/wAAzP8AzP//AMz/zAD/ /5kAmcz/AP+ZzADMmf8A4+PjADNm/wAzzMwAmcwAAP/MAAD/mQAA/2YAAGZmmQCWlpYAADNmADOZ ZgAAMwAAMzMAAJkzAACZM2YAMzOZADMzMwCFAA0AjgYAAAAABlNoZWV0MYUADQA2EgAAAAAGU2hl ZXQyhQANACMTAAAAAAZTaGVldDMKAAAACQgIAAAFEAAzE8oHCwIQAAAAAAAAAB8AnAgAAJ0RAAAN AAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIA AQCAAAgAAAAAAAAAAAAlAgQAAAD/AIwABAABAAEAgQACAMEFFAAAABUAAACDAAIAAACEAAIAAABN AFIBAABcXFgtRVMtRVNBRS1DU0ctRlMzXFdJTEVZX1EA////AAEEAAScALQAE18BAAIAAQDqCm8I WwABAA8ALAECAAEAAAADAAAATGV0dGVyAAEAAMIIAToNAAAAAgAAAAAAAADAwMAAEAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklWoBAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAkioLAP8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACh ACIAAQBbAAEAAQAEAAAALAEAAAAAAAAAAOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAMAtgwPAAAA AAAAAgoAAAAfAAAABAAAAAgCEAAAAAAABAD/AAAAEgAAAYkACAIQAAEAAAAEAGgBAAAAAAABAAAI AhAAAgAAAAQA/wAAAAAAAAEAAAgCEAADAAAABAA7AQAAAAAAAQAACAIQAAQAAAAEADsBAAAKMQAB CgEIAhAABQAAAAQAOwEAAAG3AAEKAQgCEAAGAAAABAA7AQAAegEAARRACAIQAAcAAAAEACwBAABF UAABAAAIAhAACAAAAAQALAEAAAAAAAEUQAgCEAAJAAAABAAsAQAAAAAAAQAACAIQAAoAAAAEACwB AAAAAAABAAAIAhAACwAAAAQALAEAAAAAAAEAAAgCEAAMAAAABAAsAQAAiQAAAQAACAIQAA0AAAAE ACwBAAAAAAABAAAIAhAADgAAAAQALAEAAAAAAAEAAAgCEAAPAAAABAAsAQAAAAAAAQAACAIQABAA AAAEACwBAAAAAAABAAAIAhAAEQAAAAQALAEAAAAAAAEAAAgCEAASAAAABAAsAQAAAAAAAQAACAIQ ABMAAAAEACwBAAAAAAABAAAIAhAAFAAAAAQALAEAAAAAAAEAAAgCEAAVAAAABAAsAQAAAAAAAQAA CAIQABYAAAAEACwBAAB6AQABEgAIAhAAFwAAAAQALAEAAAAAAAEAAAgCEAAYAAAABAAsAQAAegEA AQAACAIQABkAAAAEACwBAAAAAAABAAAIAhAAGgAAAAQALAEAAAAAAAGJAAgCEAAbAAAABAAsAQAA AAAAAQAACAIQABwAAAAEACwBAAAAAAABAAAIAhAAHQAAAAQALAEAAAAAAAEAAAgCEAAeAAAABAA7 AQAAAAAAAQAAvgAKAAAAAgAVABUAAwAEAiAAAQAAABwAGABSZWdpc3RlZCBmb3IgSVBQIGluIE1h dWm+AAoAAQACABUAFQADAL4ACgACAAIAFQAVAAMABAIMAAMAAAAWAAQATGFzdAQCDQADAAEAFgAF AEZpcnN0BAILAAMAAgAWAAMAV2VkBAIMAAMAAwAWAAQAVGh1cr4ACgAEAAAAFgAWAAEABAIPAAQA AgAWAAcAUFdHL0lQUAQCCwAEAAMAFwADAElQUL4ACgAFAAAAFgAWAAEAvQASAAUAAgAYAAAAPEAY AAAAPUADAL4ADgAGAAAAFgAWABgAGAADAAQCDwAHAAAAGgAHAEJlcmdtYW4EAgsABwABABoAAwBS b269ABIABwACABsAAADwPxsAAADwPwMABAINAAgAAAAaAAUAQ29oZW4EAgwACAABABoABABKb3No fgIKAAgAAgAbAAAA8D8BAgYACAADABsABAINAAkAAAAaAAUARG9tYW4EAgwACQABABoABABEYXZl fgIKAAkAAgAbAAAA8D8BAgYACQADABsABAIOAAoAAAAaAAYARmFycmVsBAILAAoAAQAaAAMATGVl vQASAAoAAgAbAAAA8D8bAAAA8D8DAAQCEAALAAAAGgAIAEhhc3RpbmdzBAILAAsAAQAaAAMAVG9t vQASAAsAAgAbAAAA8D8bAAAA8D8DAAQCDwAMAAAAGgAHAEhlcnJpb3QEAgsADAABABoAAwBCb2K9 ABIADAACABsAAADwPxsAAADwPwMABAIOAA0AAAAaAAYASGlyYXRhBAIQAA0AAQAaAAgAS2F6dWhp cm9+AgoADQACABsAAADwPwECBgANAAMAGwAEAg0ADgAAABoABQBIb2xzdAQCDgAOAAEAGgAGAEhl bnJpa70AEgAOAAIAGwAAAPA/GwAAAPA/AwAEAg0ADwAAABoABQBLdW50egQCDQAPAAEAGgAFAERh dmlkvQASAA8AAgAbAAAA8D8bAAAA8D8DAAQCDwAQAAAAGgAHAExlY2xhaXIEAgwAEAABABoABABH cmVnfgIKABAAAgAbAAAA8D8BAgYAEAADABsABAINABEAAAAaAAUATGV3aXMEAg0AEQABABoABQBI YXJyeb0AEgARAAIAGwAAAPA/GwAAAPA/AwAEAg4AEgAAABoABgBNYW5yb3MEAhAAEgABABoACABD YXJsLVVub70AEgASAAIAGwAAAPA/GwAAAPA/AwAEAg0AEwAAABoABQBNb29yZQQCDAATAAEAGgAE AFBhdWx+AgoAEwACABsAAADwPwECBgATAAMAGwAEAg4AFAAAABoABgBOYWthbm8EAhAAFAABABoA CABZYXN1aGlrb70AEgAUAAIAGwAAAPA/GwAAAPA/AwAEAhEAFQAAABoACQBQZW50ZWNvc3QEAgsA FQABABoAAwBCb2K9ABIAFQACABsAAADwPxsAAADwPwMABAINABYAAAAaAAUAUmlsZXkEAg4AFgAB ABoABgBYYXZpZXK9ABIAFgACABsAAADwPxsAAADwPwMABAIOABcAAAAaAAYAUm93bGV5BAIOABcA AQAaAAYAU3R1YXJ0vQASABcAAgAbAAAA8D8bAAAA8D8DAAQCDwAYAAAAGgAHAFNhbm5pbm8EAg4A GAABABoABgBSb2Jlcm+9ABIAGAACABsAAADwPxsAAADwPwMABAIOABkAAAAaAAYAVHVybmVyBAIN ABkAAQAaAAUAUmFuZHm9ABIAGQACABsAAADwPxsAAADwPwMABAIOABoAAAAaAAYAVWNoaW5vBAIP ABoAAQAaAAcAQXRzdXNoab0AEgAaAAIAGwAAAPA/GwAAAPA/AwAEAg4AGwAAABoABgBXcmlnaHQE AgsAGwABABoAAwBEb269ABIAGwACABsAAADwPxsAAADwPwMABAIOABwAAAAaAAYAWmVobGVyBAIN ABwAAQAaAAUAUGV0ZXK9ABIAHAACABsAAADwPxsAAADwPwMAvgAOAB0AAAAaABoAGwAbAAMABAIV AB4AAAAZAA0AVG90YWwgUGVyIERheQECBgAeAAEAGQAGABsAHgACABYAAAAAAAAANkAIAHIgRP0F AAEeAAIAvAQVAB4AHgACAwACCwAt6f/+/wAAGRDxAAYAGwAeAAMAFgAAAAAAAAAxQAgAHgAC/gUA AR4AAgDXAEIA3QgAAFgCDgAyAA4AQAAwACQAEgA4ADkAOQA3ADkAOAA+ADkAOAA7ADgAPAA5ADwA OgA5ADoAOwA5ADsANwA5ABIAPgIKALYGAAAAAAAAAACgAAQAAwAEAB0ADwADEQAJAAAAAQARABEA CQmrACIAIADw/////////////////////////////////////////woAAAAJCAgAAAUQADMTygcL AgwAAAAAAAAAAADqEgAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEA KgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCMAAQAAQABAIEAAgDBBBQAAAAV AAAAgwACAAAAhAACAAAAoQAiAAAAAQABAAEAAQAEAQAJCQAAAAAAAADgPwAAAAAAAOA/TWFVAAIA CAAAAgoAAAAAAAAAAAEAAD4CCgC2AAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAAoAAAAJCAgA AAUQADMTygcLAgwAAAAAAAAAAADXEwAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJN YlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCMAAQAAQABAIEA AgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAAAQABAAEAAQAEAAAAAAAAAAAAAADgPwAAAAAA AOA/TWFVAAIACAAAAgoAAAAAAAAAAAEAAD4CCgC2AAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAA AAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAA AAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAoAAAAAcAAAABAAAAQAAAAAQAAABI AAAACAAAAFwAAAASAAAAaAAAAAsAAACAAAAADAAAAIwAAAATAAAAmAAAAAIAAADkBAAAHgAAAAwA AABMYXJyeSBTdGVpbgAeAAAABAAAAENTRwAeAAAAEAAAAE1pY3Jvc29mdCBFeGNlbABAAAAAgOTD U9QivQFAAAAAgFsofzcdvQEDAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAA AAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAALwAAAAGAAAAAQAAADgAAAAPAAAAQAAAAAsAAABg AAAAEAAAAGgAAAANAAAAcAAAAAwAAACZAAAAAgAAAOQEAAAeAAAAFgAAAFdhcnAgTmluZSBFbmdp bmVlcmluZwAAQQsAAAAAAAAACwAAAAAAAAAeEAAAAwAAAAcAAABTaGVldDEABwAAAFNoZWV0MgAH AAAAU2hlZXQzAAwQAAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAA/v///wwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAD+////FAAAABUAAAAW AAAAFwAAABgAAAAZAAAAGgAAAP7////9/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAADwAFAABAAA APAAPADwAAYAwAFIAPAABgDAAQAA8D8CQNABAADwPwJA0AEWAAUB//////////8CAAAAEAgCAAAA AADAAAAAAAAARgAAAAAAAPAAAAAAAAAA8AAAAAAA/v///wAAAAAAAPAAQgBvAG8AawAAAAAAAADw AFAABAAAAPAACADwAAYAwAEUAPAABgDAAQAA8D8CQNABAADwPwJA0AEAAAAAAADwAAoAAgH///// //////////8AAAAAAADwAAAAAAAAAPAAAAAAAAAA8AAAAAAAAADwAAAAAAAAAAAAEBQAAAAA8AAF AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAABA0AEAAAAAAADwAAAA AAAAAPAAKAACAQEAAAADAAAA/////wAAAAAAAPAAAAAAAAAA8AAAAAAAAADwAAAAAAAAAPAAAAAA AAsAAAAAEAAAAADwAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAA8AA4AAIB////////////////AAAAAAAA8AAAAAAAAADwAAAAAAAA APAAAAAAAAAA8AAAAAAAEwAAAAAQAAAAAPAA --=====================_885023187==_ Content-Type: text/plain; charset="us-ascii" Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com --=====================_885023187==_-- From ipp-owner@pwg.org Sat Jan 17 12:05:53 1998 Delivery-Date: Sat, 17 Jan 1998 12:06:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17688 for ; Sat, 17 Jan 1998 12:05:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA22148 for ; Sat, 17 Jan 1998 12:07:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA05832 for ; Sat, 17 Jan 1998 12:04:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 17 Jan 1998 11:55:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05242 for ipp-outgoing; Sat, 17 Jan 1998 11:40:30 -0500 (EST) Message-ID: <34C0DEE0.AB72A588@parc.xerox.com> Date: Sat, 17 Jan 1998 08:40:00 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org, paulmo@microsoft.com, lstein@fapo.com Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 References: <3.0.1.32.19980116105933.0098cce0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org If you use XML for the protocol mapping and yet want to get file data in, you might consider a protocol mapping which separates the print data stream from the print protocol using MIME multipart, e.g., "multipart/related" where the print protocol elements are in an XML data structure, and the binary data streams are encoded appropriately just with their MIME media designations (application/postscript, etc.). Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Mon Jan 19 10:12:37 1998 Delivery-Date: Mon, 19 Jan 1998 10:12:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16007 for ; Mon, 19 Jan 1998 10:12:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02515 for ; Mon, 19 Jan 1998 10:15:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09198 for ; Mon, 19 Jan 1998 10:12:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 10:00:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08590 for ipp-outgoing; Mon, 19 Jan 1998 09:46:01 -0500 (EST) Message-Id: <199801191445.JAA14994@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-09.txt Date: Mon, 19 Jan 1998 09:45:37 -0500 Sender: ipp-owner@pwg.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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-09.txt Pages : 179 Date : 16-Jan-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-09.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-09.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: <19980116161436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980116161436.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon Jan 19 10:02:16 1998 Delivery-Date: Mon, 19 Jan 1998 10:16:02 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA15668 for ietf-123-outbound.10@ietf.org; Mon, 19 Jan 1998 10:02:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA14994; Mon, 19 Jan 1998 09:45:37 -0500 (EST) Message-Id: <199801191445.JAA14994@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-09.txt Date: Mon, 19 Jan 1998 09:45:37 -0500 Sender: cclark@cnri.reston.va.us --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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-09.txt Pages : 179 Date : 16-Jan-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-09.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-09.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: <19980116161436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980116161436.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Jan 19 10:27:36 1998 Delivery-Date: Mon, 19 Jan 1998 10:27:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16422 for ; Mon, 19 Jan 1998 10:27:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02591 for ; Mon, 19 Jan 1998 10:30:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09825 for ; Mon, 19 Jan 1998 10:27:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 10:23:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA08870 for ipp-outgoing; Mon, 19 Jan 1998 10:05:45 -0500 (EST) Message-Id: <34C36AFA.DAB69E89@dazel.com> Date: Mon, 19 Jan 1998 09:02:18 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Larry Masinter Cc: Carl-Uno Manros , ipp@pwg.org, paulmo@microsoft.com, lstein@fapo.com Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 References: <3.0.1.32.19980116105933.0098cce0@garfield> <34C0DEE0.AB72A588@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Larry Masinter wrote: > > If you use XML for the protocol mapping and yet want to get > file data in, you might consider a protocol mapping which separates > the print data stream from the print protocol using MIME > multipart, e.g., "multipart/related" where the print protocol > elements are in an XML data structure, and the binary data streams > are encoded appropriately just with their MIME media designations > (application/postscript, etc.). This seemed like a nice approach to me as well. In fact, I so much as raised it as a suggestion at the last IPP conference call (only I being a MIME neophyte suggested "multipart/mixed"; your suggestion sounds a lot better to me). However, my suggestion was immediately shouted down, as "this issue had already been discussed in the past, and a decision made". Well, as we are re-visiting the protocol encoding at this point, I would like to have this decision re-considered as well. It seems like a multipart MIME message, with the protocol and data in separate parts would be a natural solution. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Mon Jan 19 12:13:49 1998 Delivery-Date: Mon, 19 Jan 1998 12:13:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19033 for ; Mon, 19 Jan 1998 12:13:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03084 for ; Mon, 19 Jan 1998 12:16:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10614 for ; Mon, 19 Jan 1998 12:13:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 12:07:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10051 for ipp-outgoing; Mon, 19 Jan 1998 11:52:26 -0500 (EST) Message-Id: <3.0.1.32.19980119084910.00ad8100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 19 Jan 1998 08:49:10 PST To: walker@dazel.com, Larry Masinter From: Carl-Uno Manros Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 Cc: ipp@pwg.org, paulmo@microsoft.com In-Reply-To: <34C36AFA.DAB69E89@dazel.com> References: <3.0.1.32.19980116105933.0098cce0@garfield> <34C0DEE0.AB72A588@parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 07:02 AM 1/19/98 PST, James Walker wrote: >This seemed like a nice approach to me as well. In fact, I so much >as raised it as a suggestion at the last IPP conference call (only >I being a MIME neophyte suggested "multipart/mixed"; your suggestion >sounds a lot better to me). However, my suggestion was immediately >shouted down, as "this issue had already been discussed in the past, >and a decision made". > Jim, This is not my recollection from the phone conference. I believe that I also brought up this alternative, when Bob Herriot indicated that he saw a problem with including the document data within an XML body. I think that the more important issue is whether we find consensus that going down the XML lane at all makes sense at this stage. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jan 19 13:16:07 1998 Delivery-Date: Mon, 19 Jan 1998 13:16:08 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20042 for ; Mon, 19 Jan 1998 13:16:07 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03387 for ; Mon, 19 Jan 1998 13:18:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11518 for ; Mon, 19 Jan 1998 13:16:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 13:06:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10711 for ipp-outgoing; Mon, 19 Jan 1998 12:42:44 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587C08511@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Cc: Josh Cohen Subject: IPP> xml etc. Date: Mon, 19 Jan 1998 09:35:43 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org [excuse the delay] 2 MS people will attend Hawaii meeting (me and Josh cohen) We will attempt to have a preminary document available before the next teleconf. We will have a fuller document available before Hawaii. The consensus within MS was that, since there is already a separation between model/semantics and protocol, the remapping should be relatively painless. Specific technical points:- XML parser: There should be no problem in making a parser in < 50k. We have both java and c code that we might be able to share with people. A subset is possible - it looks like the final XML spec will allow for that. Application/ipp: The immediate feeling was that instead of application/ipp we would use multi-part. This was after 10 seconds of detailed analysis of the issue :-). The PDL would be carried as a separate opaque BLOB as it is today. POST vs other Methods: The other MS folks were surprised about the objection. They said that they thought all current servers were capable of extra methods (certainly NS and Apache). They had not heard the objection from Novell in the DAV group so they had assumed that the NW web server was equally capable. Why use non_POST: Firewalls was the main issue - it gives good granularity for an admin (I explained the group's feeling about firewall debates). There are other reasons for it which we did not have time to cover. We will present the reasons for and against both the XML and different method usage in Hawaii. Hope this all helps Paul Moore From ipp-owner@pwg.org Mon Jan 19 13:23:20 1998 Delivery-Date: Mon, 19 Jan 1998 13:23:21 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20251 for ; Mon, 19 Jan 1998 13:23:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03422 for ; Mon, 19 Jan 1998 13:26:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12342 for ; Mon, 19 Jan 1998 13:23:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 13:18:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10733 for ipp-outgoing; Mon, 19 Jan 1998 12:50:04 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587C08514@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Larry Masinter'" , Carl-Uno Manros Cc: ipp@pwg.org, lstein@fapo.com Subject: RE: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114 Date: Mon, 19 Jan 1998 09:38:07 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org we had come to the same conclusion > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Saturday, January 17, 1998 8:40 AM > To: Carl-Uno Manros > Cc: ipp@pwg.org; Paul Moore; lstein@fapo.com > Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - > 980114 > > If you use XML for the protocol mapping and yet want to get > file data in, you might consider a protocol mapping which separates > the print data stream from the print protocol using MIME > multipart, e.g., "multipart/related" where the print protocol > elements are in an XML data structure, and the binary data streams > are encoded appropriately just with their MIME media designations > (application/postscript, etc.). > > Larry > -- > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Mon Jan 19 19:27:59 1998 Delivery-Date: Mon, 19 Jan 1998 19:27:59 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24796 for ; Mon, 19 Jan 1998 19:27:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA04766 for ; Mon, 19 Jan 1998 19:30:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA13314 for ; Mon, 19 Jan 1998 19:27:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 19:22:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12739 for ipp-outgoing; Mon, 19 Jan 1998 19:07:33 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 Message-ID: <5030100016354617000003L073*@MHS> Date: Mon, 19 Jan 1998 19:07:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA24796 The weakness with the MIME way is that it's either unsafe or slow -- either you arbitrarily pick a boundary string and hope that it doesn't appear in the binary data, or you prescan the data to make sure. Content-length avoids those problems. ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/19/98 10:37 AM --------------------------- ipp-owner@pwg.org on 01/19/98 03:25:14 AM Please respond to walker@dazel.com @ internet To: masinter@parc.xerox.com @ internet cc: lstein@fapo.com @ internet, paulmo@microsoft.com @ internet, ipp@pwg.org @ internet, cmanros@cp10.es.xerox.com @ internet Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 Larry Masinter wrote: > > If you use XML for the protocol mapping and yet want to get > file data in, you might consider a protocol mapping which separates > the print data stream from the print protocol using MIME > multipart, e.g., "multipart/related" where the print protocol > elements are in an XML data structure, and the binary data streams > are encoded appropriately just with their MIME media designations > (application/postscript, etc.). This seemed like a nice approach to me as well. In fact, I so much as raised it as a suggestion at the last IPP conference call (only I being a MIME neophyte suggested "multipart/mixed"; your suggestion sounds a lot better to me). However, my suggestion was immediately shouted down, as "this issue had already been discussed in the past, and a decision made". Well, as we are re-visiting the protocol encoding at this point, I would like to have this decision re-considered as well. It seems like a multipart MIME message, with the protocol and data in separate parts would be a natural solution. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Mon Jan 19 21:13:49 1998 Delivery-Date: Mon, 19 Jan 1998 21:13:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA26276 for ; Mon, 19 Jan 1998 21:13:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA04927 for ; Mon, 19 Jan 1998 21:16:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA14028 for ; Mon, 19 Jan 1998 21:13:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 19 Jan 1998 21:08:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA13453 for ipp-outgoing; Mon, 19 Jan 1998 20:53:19 -0500 (EST) Message-Id: <3.0.1.32.19980119175016.00997760@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 19 Jan 1998 17:50:16 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference - 980121 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Agenda for PWG IPP Phone Conference - 980114 As we have got final drafts on all our initially planned documents, the only remaining subject for discussion is the request from Paul Moore to re-open the protocol mapping for discussion. Paul has signaled that he will try to have some initial input for our Wednesday phone conference. Assuming that this happens, we will talk about Paul's and anybody else's new input on that subject. The dial-in information is the same as last weeek: Call-in: 1-423-523-7162 Access: 190148 Time: 4PM EST (1PM PST) Duration: Max 2.5 hours Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jan 20 06:22:15 1998 Delivery-Date: Tue, 20 Jan 1998 06:22:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA05757 for ; Tue, 20 Jan 1998 06:22:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA05508 for ; Tue, 20 Jan 1998 06:24:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA16648 for ; Tue, 20 Jan 1998 06:22:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 05:52:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA15827 for ipp-outgoing; Tue, 20 Jan 1998 05:37:38 -0500 (EST) Date: Tue, 20 Jan 1998 02:34:12 -0800 (PST) From: Ned Freed Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 In-reply-to: "Your message dated Mon, 19 Jan 1998 19:07:33 -0500" <5030100016354617000003L073*@MHS> To: Carl Kugler Cc: ipp@pwg.org Message-id: <01ISL15CYHSW94DRQQ@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org > The weakness with the MIME way is that it's either unsafe or slow -- either you > arbitrarily pick a boundary string and hope that it doesn't appear in the > binary data, or you prescan the data to make sure. Content-length avoids those > problems. Actually, the fact of the matter is that it doesn't have to be either -- it is quite easy to generate boundaries which in practice are so statistically unlikely to ever appear in the message text that the chances of, say message corruption as a result of undetected network errors are many orders of magnitude greater. Ned From ipp-owner@pwg.org Tue Jan 20 07:20:13 1998 Delivery-Date: Tue, 20 Jan 1998 07:20:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA05992 for ; Tue, 20 Jan 1998 07:20:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA05550 for ; Tue, 20 Jan 1998 07:22:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA17697 for ; Tue, 20 Jan 1998 07:20:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 07:10:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA17124 for ipp-outgoing; Tue, 20 Jan 1998 06:55:43 -0500 (EST) Message-ID: <34C4434A.D8F6EA94@parc.xerox.com> Date: Mon, 19 Jan 1998 22:25:14 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 References: <5030100016354617000003L073*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl Kugler wrote: > > The weakness with the MIME way is that it's either unsafe or slow -- either you > arbitrarily pick a boundary string and hope that it doesn't appear in the > binary data, or you prescan the data to make sure. Content-length avoids those > problems. > This is the standard argument, but: In practice, content-length is less safe than multipart boundaries, and usually slower: you have no way of guaranteeing that the content won't change even if you *think* it is static, and if the content is dynamically generated, you have to buffer the entire content before issuing the content-length. Of course, there are alternatives, e.g., a well known termination string and a content encoding that guarantees the content doesn't contain the termination string, or chunked encoding. Larry -- http://www.parc.xerox.com/masinter From jmp-owner@pwg.org Tue Jan 20 12:19:11 1998 Delivery-Date: Tue, 20 Jan 1998 12:19:12 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA08949 for ; Tue, 20 Jan 1998 12:19:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA06670 for ; Tue, 20 Jan 1998 12:21:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18419 for ; Tue, 20 Jan 1998 12:19:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 12:15:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18095 for jmp-outgoing; Tue, 20 Jan 1998 12:12:01 -0500 (EST) Message-Id: <3.0.1.32.19980120090707.010f3ae0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Jan 1998 09:07:07 PST To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> FWD: Protocol Action: IETF Policy on Character Sets and Languages to BCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org >Date: Tue, 20 Jan 1998 08:34:19 PST >From: The IESG >Subject: Protocol Action: IETF Policy on Character Sets and Languages to BCP >Sender: scoya@cnri.reston.va.us >To: IETF-Announce:;;@sigurd.innosoft.com@cp10.es.xerox.coM >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-charsets@innosoft.com > > > >The IESG has approved publication of the following Internet-Drafts: > > o IETF Policy on Character Sets and Languages > for publication as a BCP. > > o IANA Charset Registration Procedure > for publication as a BCP. > > > o UTF-8, a transformation format of ISO 10646 > for publication as a Proposed Standard. > >The IESG contact person is Keith Moore. > > >Technical Summary > > This set of documents specifies a consistent, useful policy for the > IETF with regard to the use of character sets and language > information in IETF standards. > > In particular, it specifies that protocols MUST be able to use > the UTF-8 charset in human-readable text strings (support for > other charsets is optional), and MUST be able to provide language > tags for such text, in order to be successfully submitted to IETF > standards processes without approval of a variance procedure. > >Working Group Summary > > The policy has been reviewed at a special BOF at the Munich IETF > and in numerous working groups; there seems to be rough consensus > on the policy as stated. > > No objections were raised during IETF Last Call. > >Protocol Quality > > These documents have been reviewed for the IESG by Keith Moore. > > >NOTE TO RFC EDITOR: >draft-yergeau-utf8-rev-01.txt contains an instance of MUST (all caps). >The IESG requests this word be lower case. > > > From pwg-owner@pwg.org Tue Jan 20 12:26:00 1998 Delivery-Date: Tue, 20 Jan 1998 12:26:01 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09038 for ; Tue, 20 Jan 1998 12:26:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA06734 for ; Tue, 20 Jan 1998 12:28:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18670 for ; Tue, 20 Jan 1998 12:25:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 12:15:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18088 for pwg-outgoing; Tue, 20 Jan 1998 12:11:54 -0500 (EST) Message-Id: <3.0.1.32.19980120090707.010f3ae0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Jan 1998 09:07:07 PST To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: PWG> FWD: Protocol Action: IETF Policy on Character Sets and Languages to BCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org >Date: Tue, 20 Jan 1998 08:34:19 PST >From: The IESG >Subject: Protocol Action: IETF Policy on Character Sets and Languages to BCP >Sender: scoya@cnri.reston.va.us >To: IETF-Announce:;;@sigurd.innosoft.com@cp10.es.xerox.coM >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-charsets@innosoft.com > > > >The IESG has approved publication of the following Internet-Drafts: > > o IETF Policy on Character Sets and Languages > for publication as a BCP. > > o IANA Charset Registration Procedure > for publication as a BCP. > > > o UTF-8, a transformation format of ISO 10646 > for publication as a Proposed Standard. > >The IESG contact person is Keith Moore. > > >Technical Summary > > This set of documents specifies a consistent, useful policy for the > IETF with regard to the use of character sets and language > information in IETF standards. > > In particular, it specifies that protocols MUST be able to use > the UTF-8 charset in human-readable text strings (support for > other charsets is optional), and MUST be able to provide language > tags for such text, in order to be successfully submitted to IETF > standards processes without approval of a variance procedure. > >Working Group Summary > > The policy has been reviewed at a special BOF at the Munich IETF > and in numerous working groups; there seems to be rough consensus > on the policy as stated. > > No objections were raised during IETF Last Call. > >Protocol Quality > > These documents have been reviewed for the IESG by Keith Moore. > > >NOTE TO RFC EDITOR: >draft-yergeau-utf8-rev-01.txt contains an instance of MUST (all caps). >The IESG requests this word be lower case. > > > From ipp-owner@pwg.org Tue Jan 20 12:52:41 1998 Delivery-Date: Tue, 20 Jan 1998 12:52:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09503 for ; Tue, 20 Jan 1998 12:52:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA06862 for ; Tue, 20 Jan 1998 12:55:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA19487 for ; Tue, 20 Jan 1998 12:52:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 12:44:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18080 for ipp-outgoing; Tue, 20 Jan 1998 12:11:48 -0500 (EST) Message-Id: <3.0.1.32.19980120090707.010f3ae0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Jan 1998 09:07:07 PST To: pwg@pwg.org, ipp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> FWD: Protocol Action: IETF Policy on Character Sets and Languages to BCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >Date: Tue, 20 Jan 1998 08:34:19 PST >From: The IESG >Subject: Protocol Action: IETF Policy on Character Sets and Languages to BCP >Sender: scoya@cnri.reston.va.us >To: IETF-Announce:;;@sigurd.innosoft.com@cp10.es.xerox.coM >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-charsets@innosoft.com > > > >The IESG has approved publication of the following Internet-Drafts: > > o IETF Policy on Character Sets and Languages > for publication as a BCP. > > o IANA Charset Registration Procedure > for publication as a BCP. > > > o UTF-8, a transformation format of ISO 10646 > for publication as a Proposed Standard. > >The IESG contact person is Keith Moore. > > >Technical Summary > > This set of documents specifies a consistent, useful policy for the > IETF with regard to the use of character sets and language > information in IETF standards. > > In particular, it specifies that protocols MUST be able to use > the UTF-8 charset in human-readable text strings (support for > other charsets is optional), and MUST be able to provide language > tags for such text, in order to be successfully submitted to IETF > standards processes without approval of a variance procedure. > >Working Group Summary > > The policy has been reviewed at a special BOF at the Munich IETF > and in numerous working groups; there seems to be rough consensus > on the policy as stated. > > No objections were raised during IETF Last Call. > >Protocol Quality > > These documents have been reviewed for the IESG by Keith Moore. > > >NOTE TO RFC EDITOR: >draft-yergeau-utf8-rev-01.txt contains an instance of MUST (all caps). >The IESG requests this word be lower case. > > > From ipp-owner@pwg.org Tue Jan 20 12:57:39 1998 Delivery-Date: Tue, 20 Jan 1998 12:57:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09624 for ; Tue, 20 Jan 1998 12:57:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA06892 for ; Tue, 20 Jan 1998 13:00:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA20147 for ; Tue, 20 Jan 1998 12:57:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 12:50:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18556 for ipp-outgoing; Tue, 20 Jan 1998 12:22:18 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 Message-ID: <5030100016410458000002L082*@MHS> Date: Tue, 20 Jan 1998 12:22:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA09624 I had to see for myself so I've tried to work out some rough numbers. Assumptions: 1) The boundary delimiter has the maximum legal length of 70 characters. 2) The boundary delimiter and the encapsulated data are generated by random, uncorrelated processes. 3) The encapsulated data is a string of 8-bit octets 4) The encapsulated data is more than 70 octets long. Let N be the number of octets in the encapsulated data. The number of substrings of length 70 in the encapsulated data is N - 70 - 1 or N - 71. A substring matches the boundary delimiter with probability (1 / 256) ^ 70, since there are 256 possibilities for each character and all characters have to match, in order. The expected number of matches is therefore (N - 71) * (1/256) ^ 70 or (N - 71) / (256 ^ 70). So, for example, transferring 1 GB files, you'd expect (1E9 - 71) / (256 ** 70) or 2.6E-160 failures per submission, which works out to a failure rate of 1 in 3.77E+159 trials. Of course, the failure rate is lower for smaller files; 1 in 3.77E+162 for 1 MB files. If we challenge assumption 3 and say we're transferring 1 GB 7bit ASCII files, then the failure rate increases to 1 in 1.85E+138. In conclusion, I'd have to agree that this probability is insignificant (if my assumptions are valid and I've done the math right). -Carl ipp-owner@pwg.org on 01/19/98 10:58:54 PM Please respond to ipp-owner@pwg.org @ internet To: Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org @ internet Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011 > The weakness with the MIME way is that it's either unsafe or slow -- either you > arbitrarily pick a boundary string and hope that it doesn't appear in the > binary data, or you prescan the data to make sure. Content-length avoids those > problems. Actually, the fact of the matter is that it doesn't have to be either -- it is quite easy to generate boundaries which in practice are so statistically unlikely to ever appear in the message text that the chances of, say message corruption as a result of undetected network errors are many orders of magnitude greater. Ned From ipp-owner@pwg.org Tue Jan 20 15:41:04 1998 Delivery-Date: Tue, 20 Jan 1998 15:41:04 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA11430 for ; Tue, 20 Jan 1998 15:41:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA07457 for ; Tue, 20 Jan 1998 15:43:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA21233 for ; Tue, 20 Jan 1998 15:40:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 15:35:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20662 for ipp-outgoing; Tue, 20 Jan 1998 15:20:13 -0500 (EST) Date: Tue, 20 Jan 1998 12:19:28 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801202019.MAA03875@woden.eng.sun.com> To: ipp@pwg.org, paulmo@microsoft.com Subject: Re: IPP> xml etc. Cc: joshco@microsoft.com X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org > > XML parser: There should be no problem in making a parser in < 50k. We have > both java and c code that we might be able to share with people. A subset is > possible - it looks like the final XML spec will allow for that. I cannot find such language in the December 8 1997 version. Can you tell us more about the rules for subsets. What subset are you proposing? It seems to me that most of XML could be eliminated for IPP, e.g. parameter entities and (normal) entities except for < and &. Even DTD's are unnecessary if a printer hard codes the single DTD that it supports. Once all of this is tossed out, there isn't much left to parse. > POST vs other Methods: The other MS folks were surprised about the > objection. They said that they thought all current servers were capable of > extra methods (certainly NS and Apache). They had not heard the objection > from Novell in the DAV group so they had assumed that the NW web server was > equally capable. Unfortunately, the Sun Web server doesn't support extension of methods. From ipp-owner@pwg.org Tue Jan 20 20:27:28 1998 Delivery-Date: Tue, 20 Jan 1998 20:27:29 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA13243 for ; Tue, 20 Jan 1998 20:27:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA08387 for ; Tue, 20 Jan 1998 20:30:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA22317 for ; Tue, 20 Jan 1998 20:27:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 20:21:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21733 for ipp-outgoing; Tue, 20 Jan 1998 20:06:32 -0500 (EST) Message-Id: <3.0.1.32.19980120170158.0107d940@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Jan 1998 17:01:58 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - How much IPP request validation can an XML parser do? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org One advantage that XML might offer is that an XML parser might be able to perform some amount of request validation, instead of having each implementation having to hard code in the validation. If this were possible, then interoperability would be increased by using XML, since all implementations would be using the same DTD. Questions that would be helpful for the XML proponents to answer: 1. So how many of the steps in the Model section 15.3 and 15.4 could be naturally performed by an XML parser, given a DTD for IPP? E.g., presence of required attribute groups, order of attribute groups, presence of required attributes in required attribute groups, attribute syntax is correct for each supplied attribute, etc. 2. Could an actual implementation take the standard IPP DTD and edit out the optional features (operations, attributes, and attribute values) that the implementation has chosen not to support, and thereby getting further validation of an IPP operation request? 3. Could an actual implementation take the standard IPP DTD and edit in the extensions that the implementation has chosen to support, and thereby get validation for such extensions in an IPP operation request? Tom From ipp-owner@pwg.org Tue Jan 20 20:59:44 1998 Delivery-Date: Tue, 20 Jan 1998 20:59:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA13465 for ; Tue, 20 Jan 1998 20:59:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA08444 for ; Tue, 20 Jan 1998 21:02:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA22988 for ; Tue, 20 Jan 1998 20:59:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 20 Jan 1998 20:55:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA22418 for ipp-outgoing; Tue, 20 Jan 1998 20:40:31 -0500 (EST) Message-Id: <3.0.1.32.19980120173825.0098d9a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Jan 1998 17:38:25 PST To: Paul Moore , Josh Cohen From: Carl-Uno Manros Subject: Re: IPP> xml etc. Cc: IPP@pwg.org In-Reply-To: <5CEA8663F24DD111A96100805FFE6587C08511@red-msg-51.dns.micr osoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 09:35 AM 1/19/98 PST, Paul Moore wrote: > >Specific technical points:- > >XML parser: There should be no problem in making a parser in < 50k. We have >both java and c code that we might be able to share with people. A subset is >possible - it looks like the final XML spec will allow for that. > Paul, Here is my take on the paragraph above: 1) The current W3C XML proposal does not contain a way to define subsets. 2) The voting on the XML proposal closes today. The release date as an official W3C spec will depend on the votes and comments received from W3C members. 3) If W3C members have commented that they want to get a way of defining subsets in XML, the specs need to be enhanced and the ratification of it will be delayed for at least a few months. So, either the XML specs will go ahead as is without the subset feature, or you will not have an XML spec to reference until later. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jan 21 12:36:05 1998 Delivery-Date: Wed, 21 Jan 1998 12:36:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA26335 for ; Wed, 21 Jan 1998 12:36:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10403 for ; Wed, 21 Jan 1998 12:38:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24647 for ; Wed, 21 Jan 1998 12:36:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 21 Jan 1998 12:26:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24083 for ipp-outgoing; Wed, 21 Jan 1998 12:11:39 -0500 (EST) Message-Id: <3.0.1.32.19980121090706.01193ca0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 Jan 1998 09:07:06 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> A few typos in 980116 Model document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I read the revision marked version and came up with a small number of typos. Also one small issue about why the 'unknown' job state was removed from the list of 'not-completed' jobs returned by Get-Jobs. See point 5 below. Only typo number 8 is significant, because it doesn't indicate that the syntax of the "printer-uri-supported" is multi-valued (though the text is pretty clear and the table entry is 1setOf). The table of contents will be automatically updated to be correct when the header is fixed. We should decide whether these are worth fixing or not. (Page and line numbers are for the .pdf file without revision marks.) 1. page 17, section 2.4, lines 584-585, the sentence: The entry in the directory that represents the IPP Printer object includes the possibly many URIs for that Printer object values of one its attributes. At least delete the last five words: "values of one its attributes" Perhaps also change "the possibly many" to "one or more" to give: The entry in the directory that represents the IPP Printer object includes one or more URIs for that Printer object. 2. Page 17, section 2.4, lines 591-596: I like the example, but think that each use of URI should have "Job" or "Printer" put in front of it, since the paragraph switches from one to the other and back several times: For example, consider a Printer object that supports both a communication channel secured by the use of SSL3 (using an "https" schemed URI) and another open communication channel that is not secured with SSL3 (using an simple "http" schemed URI). If a client were to submit a job using the secure URI, the Printer object would assign the new Job object a secure URI as well. If a client were to submit a job using the open-channel URI, the Printer would assign the new Job object an open-channel URI. Giving: For example, consider a Printer object that supports both a communication channel secured by the use of SSL3 (using an "https" schemed Printer URI) and another open communication channel that is not secured with SSL3 (using an simple "http" schemed Printer URI). If a client were to submit a job using the secure Printer URI, the Printer object would assign the new Job object a secure Job URI as well. If a client were to submit a job using the open-channel Printer URI, the Printer would assign the new Job object an open-channel Job URI. 3. Page 18, section 2.4, line 633: add "a" in front of "Job ID in: Each Job object is also identified with Job ID which is a 32-bit, positive integer. giving: Each Job object is also identified with a Job ID which is a 32-bit, positive integer. 4. Page 35, section 3.2.1.2, line 1235, change "generated" to "generate" in: which URI was used in the Print-Job Request to generated the new URI so that the new URI references the correct access channel. to give: which URI was used in the Print-Job Request to generate the new URI so that the new URI references the correct access channel. 5. Page 41, section 3.2.6.1, the 'unknown' (out-of-band) value was removed from the list of jobs that the Get-Jobs operation returns when the client supplies 'not-completed' or (omits the "which-jobs" operation attribute). I think that 'unknown' should be put back in, possibly with an indication of out-of-band, since it isn't in the sets of states described in the "job-state" section. So change lines 1459-1460, from: 'not-completed': This includes any Job object whose state is 'pending', 'processing', 'processing-stopped', or 'pending-held'. to: 'not-completed': This includes any Job object whose state is 'pending', 'processing', 'processing-stopped', 'pending-held', or 'unknown' (which is an out-of-band value, see the beginning of section 4.1). and lines 1522-1525 from: - If the client requests all 'not-completed' Jobs (Jobs in the 'pending', 'processing', 'pending-held', and 'processing-stopped' states), then Jobs are returned in relative chronological order of expected time to complete (based on whatever scheduling algorithm is configured for the Printer object). to: - If the client requests all 'not-completed' Jobs (Jobs in the 'pending', 'processing', 'pending-held', 'processing-stopped', and 'unknown' states), then Jobs are returned in relative chronological order of expected time to complete (based on whatever scheduling algorithm is configured for the Printer object). 6. Page 70, section 4.2.10, line 2420, replace "shsort" with "short" 7. Page 73, section 4.3.1, line 2529, change: This can guaranteed because ... to: This can be guaranteed because ... 8. Page 85, section 4.4.1, line 2946, add "1setOf" to the syntax of the "printer-uri-supported" attribute in the header to give: 4.4.1 printer-uri-supported (1setOf uri) 9. Page 85, section 4.4.1, line 2950-2951, add "of" in: See the next section for a description "uri-security-supported" which is the MANDATORY companion attribute to this "printer-uri-supported" attribute. to: See the next section for a description of "uri-security-supported" which is the MANDATORY companion attribute to this "printer-uri-supported" attribute. or better: See the next section for a description of the "uri-security-supported" attribute which is a companion to this "printer-uri-supported" attribute. 10. Page 153, section 15.4.3, line 5195, change "Orientation-requested" to "orientation-requested". Tom From ipp-owner@pwg.org Wed Jan 21 14:36:28 1998 Delivery-Date: Wed, 21 Jan 1998 14:36:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA27138 for ; Wed, 21 Jan 1998 14:36:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA10821 for ; Wed, 21 Jan 1998 14:39:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA25351 for ; Wed, 21 Jan 1998 14:36:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 21 Jan 1998 14:30:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA24796 for ipp-outgoing; Wed, 21 Jan 1998 14:15:40 -0500 (EST) Message-Id: <3.0.1.32.19980121111318.00c1aa50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 Jan 1998 11:13:18 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Phone Conference into PWG IPP Meeting - 980128 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, I have now set up the details for the phone conference during next week's IPP meeting in Maui: Time: 3:00 - 5:00 pm PST (6:00 - 8:00 pm EST) (1:00 - 3:00 pm local) Numbers: 1-800-857-5607 1-212-547-0240 (if somebody wants to dial in from outside the US) Password: cmanros During this session, we will discuss a Microsoft proposal for a different protocol mapping. Look out for an input document from Paul Moore the day before the phone conference. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Thu Jan 22 01:41:06 1998 Delivery-Date: Thu, 22 Jan 1998 01:41:06 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA08167 for ; Thu, 22 Jan 1998 01:41:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA12493 for ; Thu, 22 Jan 1998 01:43:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA27391 for ; Thu, 22 Jan 1998 01:41:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 22 Jan 1998 01:38:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA27084 for jmp-outgoing; Thu, 22 Jan 1998 01:34:56 -0500 (EST) From: don@lexmark.com Message-Id: <199801220634.AA16323@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, JMP@pwg.org, fin@pwg.org Date: Thu, 22 Jan 1998 00:55:34 -0500 Subject: JMP> PWG> Meeting Charges Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: jmp-owner@pwg.org fyi.... Don ---------------------- Forwarded by Don Wright on 01/22/98 12:55 AM --------------------------- From: lstein%fapo.com@interlock.lexmark.com on 01/21/98 02:58 PM PST To: p1394%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: PWG> Meeting Charges Aloha All, The meeting charge for the January PWG meetings will be $36.00 per person per meeting day. This includes the room rental, AV equipment, power strips, food and beverage. Hopefully, to make things easier, Warp Nine will process all the meeting charges through our card service. This way we don't have to have the hotel involved at all. Yes Don, we will provide receipts if requested. Please print out this email, fill in the questions and bring it to the meeting. Checks made out to Warp Nine or cash made out to Larry is fine also. Thanks, Larry ________________________________________________________________ January PWG Meeting Charges # of Meetings Charge 1 day $36 2 days $72 3 days $108 4 days $144 5 days $180 Name: Company: Phone Number: Card Type: Visa MasterCard American Express Card number: Expiration date: Total Meeting Days: Total Meeting Charge: Name on Card (if different): Street address or PO box no. credit card is billed to: Zip code credit card is billed to: Receipt requested? Yes No Fax number for receipt: Signature: *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-owner@pwg.org Thu Jan 22 01:59:53 1998 Delivery-Date: Thu, 22 Jan 1998 01:59:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA08215 for ; Thu, 22 Jan 1998 01:59:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA12518 for ; Thu, 22 Jan 1998 02:02:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA27985 for ; Thu, 22 Jan 1998 01:59:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 22 Jan 1998 01:55:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA27092 for ipp-outgoing; Thu, 22 Jan 1998 01:35:03 -0500 (EST) From: don@lexmark.com Message-Id: <199801220634.AA16323@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, JMP@pwg.org, fin@pwg.org Date: Thu, 22 Jan 1998 00:55:34 -0500 Subject: IPP> PWG> Meeting Charges Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org fyi.... Don ---------------------- Forwarded by Don Wright on 01/22/98 12:55 AM --------------------------- From: lstein%fapo.com@interlock.lexmark.com on 01/21/98 02:58 PM PST To: p1394%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: PWG> Meeting Charges Aloha All, The meeting charge for the January PWG meetings will be $36.00 per person per meeting day. This includes the room rental, AV equipment, power strips, food and beverage. Hopefully, to make things easier, Warp Nine will process all the meeting charges through our card service. This way we don't have to have the hotel involved at all. Yes Don, we will provide receipts if requested. Please print out this email, fill in the questions and bring it to the meeting. Checks made out to Warp Nine or cash made out to Larry is fine also. Thanks, Larry ________________________________________________________________ January PWG Meeting Charges # of Meetings Charge 1 day $36 2 days $72 3 days $108 4 days $144 5 days $180 Name: Company: Phone Number: Card Type: Visa MasterCard American Express Card number: Expiration date: Total Meeting Days: Total Meeting Charge: Name on Card (if different): Street address or PO box no. credit card is billed to: Zip code credit card is billed to: Receipt requested? Yes No Fax number for receipt: Signature: *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-owner@pwg.org Thu Jan 22 17:24:17 1998 Delivery-Date: Thu, 22 Jan 1998 17:24:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17967 for ; Thu, 22 Jan 1998 17:24:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15933 for ; Thu, 22 Jan 1998 17:26:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00144 for ; Thu, 22 Jan 1998 17:24:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 22 Jan 1998 17:13:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29540 for ipp-outgoing; Thu, 22 Jan 1998 16:58:32 -0500 (EST) Message-Id: <3.0.1.32.19980122135540.00bbf210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 Jan 1998 13:55:40 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Confeence - 980121 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Confeence - 980121 For a start these are not really minutes, but tries to capture some of the pre-discussion for the main discussion of Paul Moore's proposal to be presented at the PWG IPP meeting next week. Attending: Paul Moore Josh Cohen Xavier Riley Peter Zehler Lee Farrell Carl Kugler Steve Gebert Tom Hastings Carl-Uno Manros Ira Mcdonald Jay Martin Bob Herriot Ron Bergman Scott Isaacson Swen Johnson Most of the discussion was a series of questions to Paul and Josh about their upcoming proposal. This included a number of questions such as: - Extra overhead of XML in comparison to current solution? - Stability of XML? - Will XML DTDs be used? If so, on what level? How generic? - Will XML be able to do more or less than our current solution? - What advantages would extra HTTP method(s) bring? - Will the new proposal be detailed and specific enough to make a comparison? - What are the disadvantages compared to our current solution? - How much extra time will it take to finalize the IPP specs if we have to re-write the protocol specification? - Paul and Josh assured everybody that they will make their utmost to get a good proposal together for discussion next week, including rationales for the choices in the proposal and compared to our current solution. The proposal text and any presentation material will be made to the IPP DL the day before the face-to-face meeting on January 28th, so that people who will join the discussion over the phone conference (see separate message) have a chance to read up on it beforehand. ---- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jan 22 18:40:45 1998 Delivery-Date: Thu, 22 Jan 1998 18:40:45 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18706 for ; Thu, 22 Jan 1998 18:40:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16204 for ; Thu, 22 Jan 1998 18:43:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01440 for ; Thu, 22 Jan 1998 18:40:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 22 Jan 1998 18:36:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00889 for ipp-outgoing; Thu, 22 Jan 1998 18:21:15 -0500 (EST) Message-Id: <3.0.1.32.19980122151846.00a11380@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 Jan 1998 15:18:46 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Support for UTF16 Cc: paulmo@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, I picked this up from a message just sent by Yaron Goland from Microsoft to the WEBDAV group. ---- As far as character sets go, XML requires that all XML parsers implement UTF8/16, DAV requires XML, therefore all implementers of DAV must support UTF8/16. ---- Does this put yet another requirement on IPP implementations, if we choose to use XML? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 23 12:55:50 1998 Delivery-Date: Fri, 23 Jan 1998 12:55:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03280 for ; Fri, 23 Jan 1998 12:55:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA18585 for ; Fri, 23 Jan 1998 12:58:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA05494 for ; Fri, 23 Jan 1998 12:55:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 12:45:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04839 for ipp-outgoing; Fri, 23 Jan 1998 12:30:10 -0500 (EST) Message-Id: <3.0.1.32.19980123092734.00c12cd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 23 Jan 1998 09:27:34 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Technical Overview of IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, Back in October, I wrote an article about IPP for the French publication "Document numerique", which was published in December. They have now made the text available on the web at: http://www.editions-hermes.fr/ap_revu.htm When you get to this page, select "Hermes" and "Document numerique" to get the text. It is not quite up-to-date, and certainly does not mention XML :-}, but most of it still makes sense. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 23 13:15:41 1998 Delivery-Date: Fri, 23 Jan 1998 13:15:41 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA03416 for ; Fri, 23 Jan 1998 13:15:40 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18689 for ; Fri, 23 Jan 1998 13:18:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06742 for ; Fri, 23 Jan 1998 13:15:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 13:11:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05055 for ipp-outgoing; Fri, 23 Jan 1998 12:47:18 -0500 (EST) From: don@lexmark.com Message-Id: <199801231746.AA19407@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: cmanros@cp10.es.xerox.com Cc: Ipp@pwg.org Date: Fri, 23 Jan 1998 12:46:08 -0500 Subject: Re: IPP> PRO - Support for UTF16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Yes, we would be required to support both UTF8 and UTF16 in just the way XML requires if we want to be able to say the IPP uses XML. If we only want to say that IPP uses XML-like syntax than we could stray from that position. Should we decide to use XML, I don't think half a loaf is the right way to go. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: paulmo%microsoft.com@interlock.lexmark.com (bcc: Don Wright) bcc: Don Wright Subject: IPP> PRO - Support for UTF16 FYI, I picked this up from a message just sent by Yaron Goland from Microsoft to the WEBDAV group. ---- As far as character sets go, XML requires that all XML parsers implement UTF8/16, DAV requires XML, therefore all implementers of DAV must support UTF8/16. ---- Does this put yet another requirement on IPP implementations, if we choose to use XML? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 23 16:00:12 1998 Delivery-Date: Fri, 23 Jan 1998 16:00:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA05224 for ; Fri, 23 Jan 1998 16:00:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA19518 for ; Fri, 23 Jan 1998 16:02:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07910 for ; Fri, 23 Jan 1998 16:00:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 15:54:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA07333 for ipp-outgoing; Fri, 23 Jan 1998 15:38:53 -0500 (EST) Message-Id: <3.0.1.32.19980123123557.00bb6590@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 23 Jan 1998 12:35:57 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Document numerique article on IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I found that it was not so easy to actually download the article from the location in France, so I have now uploaded a copy of it in .pdf format to our FTP server. The address is: ftp://ftp.pwg.org/pub/pwg/ipp/press-reports/IPP-tut.pdf Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 23 20:49:41 1998 Delivery-Date: Fri, 23 Jan 1998 20:49:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA07288 for ; Fri, 23 Jan 1998 20:49:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA20340 for ; Fri, 23 Jan 1998 20:52:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA10272 for ; Fri, 23 Jan 1998 20:49:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 20:45:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09461 for ipp-outgoing; Fri, 23 Jan 1998 20:27:44 -0500 (EST) Date: Fri, 23 Jan 1998 20:10:00 -0500 (EST) Message-Id: <199801240110.UAA02954@ns.owlseye.com> From: owl@owlseye.com To: ipp@pwg.org Reply-To: owl@owlseye.com Subject: IPP> OK to send e-mail? Sender: ipp-owner@pwg.org OK to send an e-mail to ipp@pwg.org? From ipp-owner@pwg.org Fri Jan 23 23:28:57 1998 Delivery-Date: Fri, 23 Jan 1998 23:28:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA14633 for ; Fri, 23 Jan 1998 23:28:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA20580 for ; Fri, 23 Jan 1998 23:31:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11286 for ; Fri, 23 Jan 1998 23:28:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 23:18:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10679 for ipp-outgoing; Fri, 23 Jan 1998 23:01:42 -0500 (EST) Date: Fri, 23 Jan 1998 20:01:14 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801240401.UAA06906@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO Analysis of XML as IPP Protocol X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I have downloaded a document in which I analyze how the IPP protocol would be mapped to XML. The documents are at ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO ipp-xml-980123.doc MS Word 97 ipp-xml-980123-6.doc MS Word version 6 ipp-xml-980123.prn PostScript I hope to talk through these ideas next week. Bob Herriot From ipp-owner@pwg.org Fri Jan 23 23:39:57 1998 Delivery-Date: Fri, 23 Jan 1998 23:39:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA14982 for ; Fri, 23 Jan 1998 23:39:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA20599 for ; Fri, 23 Jan 1998 23:42:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11913 for ; Fri, 23 Jan 1998 23:39:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 23 Jan 1998 23:35:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10703 for ipp-outgoing; Fri, 23 Jan 1998 23:15:01 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D08F1@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> XML DTD and schema example Date: Fri, 23 Jan 1998 20:14:50 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Another example XML DTD and schema.. comments to follow shortly --- Josh Cohen Program Manager - Internet Technologies begin 600 ipp2.xml M06X@97AA;7!L92!P2!$ M5$0N#0H-"E!224Y4("]V:6,R,"]D;W0M;6%T2UD871A/"]D871A;&EN:U5223X-"CPA+2T@=&AI2UD871A#0IC;VYE;G0M;&5N M9W1H.B`_/PT*#0I;8F5G:6YN:6YG(&]F(&)I;F%R>2!C;VYT96YT70T*+BXN M#0I;96YD:6YG(&]F(&)I;F%R>2!C;VYT96YT70T*+2UB:6=R86YD;VU-1#5S >=')I;F7!E("@C4$-$051!*3X-"CPA+2T@7!E('!R:6YT+6IO8BP@<75E; Sat, 24 Jan 1998 00:41:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA20663 for ; Sat, 24 Jan 1998 00:44:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA12634 for ; Sat, 24 Jan 1998 00:41:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 24 Jan 1998 00:37:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA12071 for ipp-outgoing; Sat, 24 Jan 1998 00:22:27 -0500 (EST) Date: Fri, 23 Jan 1998 21:21:58 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199801240521.VAA07065@woden.eng.sun.com> To: ipp@pwg.org, joshco@microsoft.com Subject: Re: IPP> XML DTD and schema example X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org I just read through your XML example and I wonder why you don't use the "encoding" XML attribute in the "; Sat, 24 Jan 1998 03:11:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA20810 for ; Sat, 24 Jan 1998 03:13:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA14246 for ; Sat, 24 Jan 1998 03:10:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 24 Jan 1998 03:03:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA13110 for ipp-outgoing; Sat, 24 Jan 1998 02:33:42 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D08F7@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> non uu XML scheme Date: Fri, 23 Jan 1998 23:33:34 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org An example print-job XML schema based on my DTD. PRINT /vic20/dot-matrix HTTP/1.1 Content-type: multipart/related ; boundary="--bigrandomMD5string";type="text/xml" --bigrandomMD5string Content-type: text/xml 1.0 print-job http://colorprinter en en mailto:Josh@microsoft.com Josh Cohen Please use XML! application/Atari_ST_GEMWrite CID:foobar-my-data --bigrandomMD5string content-type: application/Atari_ST_GEMWrite content-id:foobar-my-data conent-length: ?? [beginning of binary content] ... [ending of binary content] --bigrandomMD5string-- [--end of message --] --- Josh Cohen Program Manager - Internet Technologies From ipp-owner@pwg.org Sat Jan 24 03:11:12 1998 Delivery-Date: Sat, 24 Jan 1998 03:11:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA15860 for ; Sat, 24 Jan 1998 03:11:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA20813 for ; Sat, 24 Jan 1998 03:13:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA14272 for ; Sat, 24 Jan 1998 03:11:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 24 Jan 1998 03:02:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA13121 for ipp-outgoing; Sat, 24 Jan 1998 02:35:11 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D08F8@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> non uu DTD Date: Fri, 23 Jan 1998 23:35:05 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Here is a suggested DTD for an IPP message.. I recommend that it be used in the spec for the definition but not for on the wire validation. This will easily allow arbitrary new headers to be inserted by clients and servers --- Josh Cohen Program Manager - Internet Technologies From ipp-owner@pwg.org Sat Jan 24 17:25:38 1998 Delivery-Date: Sat, 24 Jan 1998 17:25:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19122 for ; Sat, 24 Jan 1998 17:25:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21646 for ; Sat, 24 Jan 1998 17:28:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16024 for ; Sat, 24 Jan 1998 17:25:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 24 Jan 1998 17:17:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15443 for ipp-outgoing; Sat, 24 Jan 1998 17:02:39 -0500 (EST) Date: Sat, 24 Jan 1998 14:07:49 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801242207.AA27372@snorkel.eso.mc.xerox.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org, joshco@microsoft.com Subject: Re: IPP> XML DTD and schema example Sender: ipp-owner@pwg.org Hi Bob, I agree that the initial '; Sat, 24 Jan 1998 18:16:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21659 for ; Sat, 24 Jan 1998 18:19:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16685 for ; Sat, 24 Jan 1998 18:16:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 24 Jan 1998 18:12:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16117 for ipp-outgoing; Sat, 24 Jan 1998 17:57:15 -0500 (EST) From: don@lexmark.com Message-Id: <199801242257.AA23532@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Sat, 24 Jan 1998 17:52:04 -0500 Subject: IPP> Re: PWG> PWG OID Structure Proposals [the case for a flat structure] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Tom Hastings said: >Actually, we have been trying to write something down for two months >already and changing it every time. I am afraid that this will continue. The only writing I've seen is e-mails. I haven't seen an actual compilation using different structures. >What advantages did it give you? Distributed name space management with some logic to it. Adapters are next to adapters, printer are next to printers, etc. I don't have adapter MIBs in between printers, in between stuff I can't talk about. >How many OIDs have you assigned? hundreds I'm tired of arguing about this. Go ahead with a flat space and paint yourselves in a corner later. Perhaps we can claim PWG OIDs are secure -- "security by confusion." I reserve the right to say "I told you so." Don From ipp-owner@pwg.org Mon Jan 26 18:16:22 1998 Delivery-Date: Mon, 26 Jan 1998 18:16:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA21564 for ; Mon, 26 Jan 1998 18:16:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA04859 for ; Mon, 26 Jan 1998 18:19:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21232 for ; Mon, 26 Jan 1998 18:16:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 26 Jan 1998 18:08:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20647 for ipp-outgoing; Mon, 26 Jan 1998 17:53:13 -0500 (EST) Message-Id: <3.0.1.32.19980126140422.00f9de30@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 26 Jan 1998 14:04:22 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO Analysis of XML as IPP Protocol [.pdf file posted] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've posted the corresponding PDF file at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-xml-980123-6.pdf Tom >Date: Fri, 23 Jan 1998 20:01:14 PST >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org >Subject: IPP>PRO Analysis of XML as IPP Protocol >X-Sun-Charset: US-ASCII >Sender: ipp-owner@pwg.org > > >I have downloaded a document in which I analyze how the IPP protocol would >be mapped to XML. > >The documents are at > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > > ipp-xml-980123.doc MS Word 97 > ipp-xml-980123-6.doc MS Word version 6 > ipp-xml-980123.prn PostScript > >I hope to talk through these ideas next week. > >Bob Herriot > > From ipp-owner@pwg.org Mon Jan 26 20:36:39 1998 Delivery-Date: Mon, 26 Jan 1998 20:36:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA23126 for ; Mon, 26 Jan 1998 20:36:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05251 for ; Mon, 26 Jan 1998 20:39:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA21952 for ; Mon, 26 Jan 1998 20:36:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 26 Jan 1998 20:30:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21390 for ipp-outgoing; Mon, 26 Jan 1998 20:15:15 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D0930@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> FW: POST vs. New Methods Date: Mon, 26 Jan 1998 16:21:15 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org An interesting datapoint about new methods vs overloading POST. -----Original Message----- From: Judith Slein [mailto:slein@wrc.xerox.com] Sent: Wednesday, January 21, 1998 1:12 PM To: http-ng-pdg@w3.org Subject: POST vs. New Methods Larry Masinter suggested that I forward this information to the HTTP-NG mailing list, feeling that it is relevant to discussions you have had recently. It's a summary of a discussion that occurred on the WebDAV mailing list about 15 months ago, about the merits of extending HTTP with new methods vs. relying on POST with new mime types. WebDAV did start out with a specification using POST, but decided to change its approach to introduce new methods. Issues raised on the WebDAV mailing list: 1. How do proxies / security gateways behave with POST with a new entity-body vs. new methods? Need to do a survey. 2. Separate methods are certain not to introduce new constraints on HTTP, whereas using POST might do so. 3. Separate methods are cleaner for existing servers to deal with. Using POST might cause unpredictable results from existing servers. (a controversial claim) 4. Using separate methods stays closer to the simple OO model of the Web, where operations are defined on resources. 5. It depends on your model of a web server. You can view a web server as a collection of objects, with methods defined on them, a la object-oriented programming. Or you can view a web server as a collection of agents (computational entities), of which some serve documents, while others perform activities like "copy" or "server diff." In fact, there may be many agents capable of performing an activity, and a single agent may be capable of handling more than one type of activity. On the OO view of HTTP, an HTTP message is directed to an object (the Request-URI), which handles the method in the request message. On the agent view of HTTP, an HTTP message is directed to an agent (or a default HTTP agent), which then handles either the HTTP/1.1 style message or processes the command specified in the MIME type of the request message. The advantage of the Agent view is the range of capability of the agents isn't hardwired, and there may be many agents, with slightly different characteristcs, all active simultaneously in the same server. The advantages of the Object Oriented view stem from the fixed set of methods: this fixed set is understood better by existing Web technology (e.g., caches), and can be used to implement a simple access control scheme (method x user --> ACL). 6. Separate methods are simpler and cleaner for server vendors to implement. (Some server implementors felt very strongly about this.) 7. It's easier to modify media types if we want to make changes later than it is to modify method definitions. (a controversial claim) 8. Access control today is based on methods, not on media types. (claim by an Apache implementor) 9. Media type should not carry any semantics beyond "this is the format of the content of the message body" 10. We should preserve the ability to use different media types to do the same thing. 11. The existing Web framework is built around methods. If we are talking about extensions to HTTP/1.x, then you would expect those extensions to follow the framework of HTTP. If you care about the existing implementation base and the advantages provided by HTTP's generic interface, you will stay within the existing framework. 12. Look at PEP and what it recommends for how to extend HTTP. Decide whether we think PEP will succeed. From ipp-owner@pwg.org Tue Jan 27 01:59:25 1998 Delivery-Date: Tue, 27 Jan 1998 01:59:25 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA01835 for ; Tue, 27 Jan 1998 01:59:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA05767 for ; Tue, 27 Jan 1998 02:02:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA23212 for ; Tue, 27 Jan 1998 01:59:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 27 Jan 1998 01:51:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA22613 for ipp-outgoing; Tue, 27 Jan 1998 01:35:17 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 26 Jan 1998 23:34:06 -0700 From: "Scott Isaacson" To: joshco@microsoft.com, ipp@pwg.org Subject: Re: IPP> FW: POST vs. New Methods Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id BAA01835 >>> Josh Cohen 01/26 5:21 PM >>> >1. How do proxies / security gateways behave with POST with a new >entity-body vs. new methods? Need to do a survey. This seems to come up again and again and seems like most everybody has decided that "the firewall" or "the proxy" argument can be successfully debated either way. The IPP WG did an "informal survey" over that past year that showed no influencing factors pushing the decision in either direction. A good survey would be very useful. >2. Separate methods are certain not to introduce new constraints on HTTP, >whereas using POST might do so. This conclusion seems backwards to me. With new methods a new HTTP version must be defined or a an extension mechanism (PEP) must be defined on how to extend it. With POST, no such action is necessary. >3. Separate methods are cleaner for existing servers to deal with. Using >POST might cause unpredictable results from existing servers. (a >controversial claim) Again this claim seems backwards to me, note the controversial claim >4. Using separate methods stays closer to the simple OO model of the Web, >where operations are defined on resources. I agree with the fact that separate methods stay closer to a simple OO model, but what is the "OO model of the Web"? There definitely is not consensus on this. In the working group moving to IIOP/RMI/DCOM has always been "shot down" pretty quickly. If we do this as OO, we need some better stability first. Note: The OMG Printing Facility is OO and that IDL shows a %100 mapping to IPP. So let's use IIOP not HTTP and the whole discussion about new methods vs POST is moot. >5. It depends on your model of a web server. You can view a web server as >a collection of objects, with methods defined on them, a la object-oriented >programming. Or you can view a web server as a collection >of agents (computational entities), of which some serve documents, while >others perform activities like "copy" or "server diff." In fact, there may >be many agents capable of performing an activity, and a single agent may be >capable of handling more than one type of activity. On the OO view of HTTP, >an HTTP message is directed to an object (the >Request-URI), which handles the method in the request message. On the agent >view of HTTP, an HTTP message is directed to an agent (or a default HTTP >agent), which then handles either the HTTP/1.1 style message or processes >the command specified in the MIME type of the request message. The >advantage of the Agent view is the range of capability of the agents isn't >hardwired, and there may be many agents, with slightly different >characteristcs, all active simultaneously in the same server. The >advantages of the Object Oriented view stem from the fixed set of methods: >this fixed set is understood better by existing Web technology (e.g., >caches), and can be used to implement a simple access control scheme >(method x user --> ACL). Again, I agree with this. However, I have been pushed back when I bring up the OO discussion within the IPP WG. The decisions have been made to not be so OO pure at this point in time. >6. Separate methods are simpler and cleaner for server vendors to >implement. (Some server implementors felt very strongly about this.) Where any of the server implementors involved the embedded web server guys? Again, sounds like a controversial claim. >7. It's easier to modify media types if we want to make changes later than >it is to modify method definitions. (a controversial claim) So, this argues for POST right? >8. Access control today is based on methods, not on media types. (claim by >an Apache implementor) >9. Media type should not carry any semantics beyond "this is the format of >the content of the message body" I believe this statement to be true, but I don't understand this statement in this context. Does is argue for or against new methods or POST? >10. We should preserve the ability to use different media types to do the >same thing. What does this statement mean? Does it mean we need to use different media types "application/postscript" and "application/pcl" (or whaterver the right media type is for PCL) to do the same thing, in this case identify the format of printer-ready data? Again, I believe this statement to be true, but I don't understand this statement in this context. Does is argue for or against new methods or POST? >11. The existing Web framework is built around methods. If we are talking >about extensions to HTTP/1.x, then you would expect those extensions to >follow the framework of HTTP. If you care about the existing >implementation base and the advantages provided by HTTP's generic >interface, you will stay within the existing framework. The IPP WG discussions between 12/96 and 5/97 stablized on the latter: "If you care about the existing implementation base and the advantages provided by HTTP's generic interface, you will stay within the existing framework." Discussion was held, decisions were made, and consensus was declared and it has stayed that way for the past 6 months. It has been considered to many to be a "barrier to success" to "force" infrastructure development to support IPP when the same functionality could be realized with no dependency on new infrastructure. Some say supporting new methods on existing web servers is just as easy as supporing a POST, however, it is obvious that that is not the case across the board. One of the key goals of IPP was and is to be succsessful with with existing infrastructure so that the solutions could be deployed and accepted on its functionality with no barrier to success. To be perfectly honest, look at all the changes from HTTP/1.0 to HTTP/1.1 - those changes were due to implementation lessons and deployment on a wide scale. If we wait for IPP due to implementattion dependencies or adoption on a wide scale which is slow due to waiting for a developing infrastructure, we will never find out how to move IPP/1.0 to IPP/1.1 and beyond. >12. Look at PEP and what it recommends for how to extend HTTP. Decide >whether we think PEP will succeed. This issue is why I think the conclusion to #2 above is flawed. In order to extend HTTP/1.1 there must be an extension mechanism. Period. Is it obviously clear to all EXACTLY how to extend HTTP/1.1 with no new development? Yes - by using POST. A final note: I believe that WebDAVs approach to using new methods is great for WebDAV since, from my observations, the implementors of WebDAV will be web server developers. The implementors of IPP are not necessarily web server developers. In short on the server side, I see almost 100% overlap between Web server (HTTP/1.1) developers and WebDAV developers and almost no overlap between IPP developers and web server developers (either accross companies or accross divisions within companies). So it makes sense to me to tie together WebDAV and HTTP but it doesn't make as much sense to me to tie IPP into HTTP with new methods. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Tue Jan 27 15:42:29 1998 Delivery-Date: Tue, 27 Jan 1998 15:42:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13741 for ; Tue, 27 Jan 1998 15:42:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08330 for ; Tue, 27 Jan 1998 15:45:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24794 for ; Tue, 27 Jan 1998 15:42:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 27 Jan 1998 15:33:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24236 for ipp-outgoing; Tue, 27 Jan 1998 15:17:41 -0500 (EST) From: Roger K Debry To: Subject: IPP> FW: POST vs. New Methods Message-ID: <5030100016744039000002L092*@MHS> Date: Tue, 27 Jan 1998 15:17:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA13741 My comments in <> Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Larry Masinter suggested that I forward this information to the HTTP-NG mailing list, feeling that it is relevant to discussions you have had recently. It's a summary of a discussion that occurred on the WebDAV mailing list about 15 months ago, about the merits of extending HTTP with new methods vs. relying on POST with new mime types. WebDAV did start out with a specification using POST, but decided to change its approach to introduce new methods. Issues raised on the WebDAV mailing list: 1. How do proxies / security gateways behave with POST with a new entity-body vs. new methods? Need to do a survey. <> Was a survey ever done??? 2. Separate methods are certain not to introduce new constraints on HTTP, whereas using POST might do so. <> Any explanation behind this? Its certainly not obvious, since <> the data in a POST is opaque to the HTTP server and a new <> method is not! 3. Separate methods are cleaner for existing servers to deal with. Using POST might cause unpredictable results from existing servers. (a controversial claim) <> Surely this is in jest. Servers are built to hand off the <> data in a POST to an application. If existing servers don't <> handle new methods what happens? Probably unpredictable. 4. Using separate methods stays closer to the simple OO model of the Web, where operations are defined on resources. <> Only if the server itself is going to operate on the data. <> If not, then the simplest OO model seems to be to just pass the data <> thru. Now the data passed through is clean and the back-end <> application knows the contents of the message and the operation with <> no dependency on the server. If a new method is defined, the <> the interface is not clean, since the method is defined to the <> server, but processing of the method is really handled by a <> back-end application 5. It depends on your model of a web server. You can view a web server as a collection of objects, with methods defined on them, a la object-oriented programming. Or you can view a web server as a collection of agents (computational entities), of which some serve documents, while others perform activities like "copy" or "server diff." In fact, there may be many agents capable of performing an activity, and a single agent may be capable of handling more than one type of activity. On the OO view of HTTP, an HTTP message is directed to an object (the Request-URI), which handles the method in the request message. On the agent view of HTTP, an HTTP message is directed to an agent (or a default HTTP agent), which then handles either the HTTP/1.1 style message or processes the command specified in the MIME type of the request message. The advantage of the Agent view is the range of capability of the agents isn't hardwired, and there may be many agents, with slightly different characteristcs, all active simultaneously in the same server. The advantages of the Object Oriented view stem from the fixed set of methods: this fixed set is understood better by existing Web technology (e.g., caches), and can be used to implement a simple access control scheme (method x user --> ACL). 6. Separate methods are simpler and cleaner for server vendors to implement. (Some server implementors felt very strongly about this.) <> AGain, this depends on whether or not we are talking about <> functions to be performed in the server or functions done by <> back-end application outside of the server. Since I don't <> believe that printing will be a web server function, POST is <> probably cleaner. 7. It's easier to modify media types if we want to make changes later than it is to modify method definitions. (a controversial claim) 8. Access control today is based on methods, not on media types. (claim by an Apache implementor) 9. Media type should not carry any semantics beyond "this is the format of the content of the message body" 10. We should preserve the ability to use different media types to do the same thing. 11. The existing Web framework is built around methods. If we are talking about extensions to HTTP/1.x, then you would expect those extensions to follow the framework of HTTP. If you care about the existing implementation base and the advantages provided by HTTP's generic interface, you will stay within the existing framework. <> I claim that this is only true for operations that are <> expected to be processed in the Web Server itself, as opposed <> to a back end. If we take this claim at face value, then we <> would define HTTP methods for **EVERY** operation that goes <> through a server to a back end data base, transaction system, <> etc. Would we expect there to be a "PAY" method when using the <> web to send a payment transaction to an e-business back end? Would <> you expect a "QUERY DB" method when using the web to access a <> data base? 12. Look at PEP and what it recommends for how to extend HTTP. Decide whether we think PEP will succeed. From ipp-owner@pwg.org Wed Jan 28 08:56:12 1998 Delivery-Date: Wed, 28 Jan 1998 08:56:12 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA28536 for ; Wed, 28 Jan 1998 08:56:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA10607 for ; Wed, 28 Jan 1998 08:58:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA26646 for ; Wed, 28 Jan 1998 08:56:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 08:44:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA26060 for ipp-outgoing; Wed, 28 Jan 1998 08:29:02 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D095B@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> ipppreso.ppt Date: Wed, 28 Jan 1998 05:28:40 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Hi, Here is a powerpoint presentation of the slides paul and myself will be using at wednesday's session. If your joining us via teleconference, you can use these to follow along. If you dont have powerpoint97, I apologize for not making these slides available in another format. Unfortunately, I wasnt able to install the internet assistant to save as HTML prior to departing for the meeting.. Josh <> begin 600 ipppreso.ppt MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M````/@``````````$```_O___P````#^____`````#T```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________\/`.@#SQL```$`Z0,H````@!8``.`0``#/$``` M&!<```4````*```````````````!`````````0\`\@.(`0``+P#(#PP````P M`-(/!``````````/`-4'Y```````MP]$````5`!I`&T`90!S`"``3@!E`'<` M(`!2`&\`;0!A`&X```"@B&(`H(AB`,B&8@"W\0(P[(9B``@```#LAF(`R?(" M,```!!(0`+ M\1`````$```(`0``"`(```CW```0'P#P#QP``````/,#%`````(````````` M`````````(``````#P#0!XL````/`/H#9P``````_@,#``````$```#]`S0` M```@````9````"````!D````^(9B`,GR`C#PAF(`"````(H/```2!@``U/O_ M_ZS___\!````<`#[`P@`````````<`@``'``^P,(`````0```$`+```?`/\# M%`````(```0,```````````````"````/P#9#PP``````-H/!```````)0`/ M`/`/*!@`````\P,4`````P`````````"``````$``````````)\/!``````` M`````*@/&@```$E04"!03\-36%P<&EN9R!D971A:6QS#71I;6EN9R`H,2XP(&]R(&QA=&5R*0U5 M0``H0](````(P```````````"L````!```````?````````````$0````$` M`````",`````````*P`````````?`````````!$```````````#S`Q0````$ M``````````(````!`0``````````GP\$````````````J`\.````3F]N(%!/ M4U0@+2!W:'D0`)\/!`````$``````*`/7`$``$D`10!4`$8`(`!0`'(`90!S M`',`=0!R`&4`#0!0`$\`4P!4`"``;P!V`&4`<@!L`&\`80!D`"``;P!B`',` M8P!U`'(`90!S`"``80!C`'0`:0!O`&X`#0!3`&D`;0!I`&P`80!R`"``9`!I M`',`8P!U`',`'1E0`@`%,`90!R`'8`90!R``T`30!I`&,`<@!O`',`;P!F`'0`(`!0`'(` M;P!X`'D`(`!3`&4`<@!V`&4`<@`-`$D`;@!K`'0`;P!M`&D`(`!0`'(`;P!X M`'D`(`!3`&4`<@!V`&4`<@`-`$8`:0!R`&4`=P!A`&P`;``@`$$`9`!M`&D` M;@!I`',`=`!R`&$`=`!O`'(``@``5`!H`&4`(`!C`&\`;0!I M`&X`9P`@`'<`80!V`&4`(`!F`&\`<@`@`',`=`!R`'4`8P!T`'4`<@!E`&0` M(`!D`&$`=`!A``T`5`!O`&\`;`!S`"``80!R`&4`(`!E`&$`0`@ M`&$`=@!A`&D`;`!A`&(`;`!E`"``80!N`&0`(`!B`&4`8P!O`&T`:0!N`&<` M(`!M`&\`<@!E`"``0!S`"P`(`!E`'0`8P```*$/4@```"0````` M```````P`````0``````0````````````'P````!```````D`````````"\` M``````(`%``!`````````$``````````?````````````/,#%`````@````` M`````@````4!``````````"?#P0```````````"H#PH```!834P@+2!7:&%T M$`"?#P0````!``````"H#ZT```!$5$0_#5EE'AX/@U.86UE(%-P86-E0!P`&D`;@!G`"``;P!R`"``=P!E`&$` M:P`@`'0`>0!P`&D`;@!G``T`0@!O`&(`&2!S`"``<`!R`&\`<`!O`',`80!L M`"``*`!S`'0`<@!O`&X`9P`I``T`4`!A`'4`;``O`$H`;P!S`&@`(``H`'<` M90!A`&L`*0`-`%``80!Y`&P`;P!A`&0`(``H`%``1`!,`"D`#0!M`'4`;`!T M`&D`<`!A`'(`=``@`&T`:0!M`&4```"A#U(````=````````````*0````$` M``````X````````````/`````0``````'0`````````8`````````!$````! M`````0`.``````````\```````````"J#QH```!4``````````H````!```` M`P`%````````````\P,4````"@`````````"````!P$``````````)\/!``` M`````````*@/"P```%A-3"`M(%=H96X_$`"?#P0````!``````"H#VT```!6 M97)S:6]N(#$N,`U834P@;F]T(')E861Y+"!S;VUE(&]F('5S(&%R92!D;VYE M#4-R96%T97,@;&5G86-Y#59E7!I;F<-3F\@;F%M92!S<&%C90``\P,4````#``````````"````"0$````` M`````)\/!````````````*@/"P```%A-3"!-87!P:6YG$`"?#P0````!```` M``"@#W@!``!2`&4`<0!U`&4``!A`&T`<`!L`&4`(``<($<`90!T`"``2@!O`&(`'0@#P0`````````#P`$\&P````2``KP"`````,(```@`@`` M0P`+\!@```"``*2>=@"_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0 M%``/#P`1\!```````,,+"`````$````.`'8`#P`-\`P``````)X/!`````$` M```/``3P2````!(`"O`(`````0@````,``"#``OP,````($!````"(,!!0`` M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@```` M____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8 M`````0````T.````````````@``````'````#P`,!(@!```/``+P@`$``$`` M"/`(`````P````,,```/``/P&`$```\`!/`H`````0`)\!`````````````` M`/____\``@```@`*\`@`````#```!0````\`!/!L````$@`*\`@````"#``` M(`(``$,`"_`8````@`"DSO0"OP$```$`_P$```$``0,"!``````0\`@```"` M`;`!T!10!`\`$?`0``````##"P@`````````#0#T`@\`#?`,``````">#P0` M````````#P`$\&P````2``KP"`````,,```@`@``0P`+\!@```"```3/]`*_ M`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0%``/#P`1\!```````,,+ M"`````$````.`/0"#P`-\`P``````)X/!`````$````/``3P2````!(`"O`( M`````0P````,``"#``OP,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\! M$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____``````"`@(`````` M``#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8`````0````T.```````` M````@``````'````#P`,!(@!```/``+P@`$``%``"/`(`````P````,0```/ M``/P&`$```\`!/`H`````0`)\!`````,````!``%``4`!``X`````@`*\`@` M````$```!0````\`!/!L````$@`*\`@````"$```(`(``$,`"_`8````@`#$ MS_0"OP$```$`_P$```$``0,"!``````0\`@```"``;`!T!10!`\`$?`0```` M``##"P@`````````#0#T`@\`#?`,``````">#P0`````````#P`$\&P````2 M``KP"`````,0```@`@``0P`+\!@```"``"30]`*_`0```0#_`0```0`!`P,$ M`````!#P"````.`$L`'0%``/#P`1\!```````,,+"`````$````.`/0"#P`- M\`P``````)X/!`````$````/``3P2````!(`"O`(`````1`````,``"#``OP M,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0`` M`#\#`0`!`!``\`<@````____``````"`@(````````#,F0`S,\P`S,S_`+*R ML@`/`.X#V`$```(`[P,8`````0````T.````````````@``````'````#P`, M!(@!```/``+P@`$``&``"/`(`````P````,4```/``/P&`$```\`!/`H```` M`0`)\!```````````````/____\``@```@`*\`@`````%```!0````\`!/!L M````$@`*\`@````"%```(`(``$,`"_`8````@`"$T/0"OP$```$`_P$```$` M`0,"!``````0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0`$ M`0\`#?`,``````">#P0`````````#P`$\&P````2``KP"`````,4```@`@`` M0P`+\!@```"``.30]`*_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0 M%``/#P`1\!```````,,+"`````$````.``0!#P`-\`P``````)X/!`````$` M```/``3P2````!(`"O`(`````10````,``"#``OP,````($!````"(,!!0`` M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@```` M____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8 M`````0````T.````````````@``````'````#P`,!(@!```/``+P@`$``'`` M"/`(`````P````,8```/``/P&`$```\`!/`H`````0`)\!````"D````2P(` M`.`!`````````@`*\`@`````&```!0````\`!/!L````$@`*\`@````"&``` M(`(``$,`"_`8````@`"DT?0"OP$```$`_P$```$``0,"!``````0\`@```"` M`;`!T!10!`\`$?`0``````##"P@`````````#0`$`0\`#?`,``````">#P0` M````````#P`$\&P````2``KP"`````,8```@`@``0P`+\!@```"```32]`*_ M`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0%``/#P`1\!```````,,+ M"`````$````.`),"#P`-\`P``````)X/!`````$````/``3P2````!(`"O`( M`````1@````,``"#``OP,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\! M$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____``````"`@(`````` M``#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8`````0````T.```````` M````@``````'````#P`,!(@!```/``+P@`$``(``"/`(`````P````,<```/ M``/P&`$```\`!/`H`````0`)\!`````_````I````'0"``#>`0```@`*\`@` M````'```!0````\`!/!L````$@`*\`@````"'```(`(``$,`"_`8````@``D MT_0"OP$```$`_P$```$``0,"!``````0\`@```"``;`!T!20`P\`$?`0```` M``##"P@`````````#0#V`@\`#?`,``````">#P0`````````#P`$\&P````2 M``KP"`````,<```@`@``0P`+\!@```"``(33]`*_`0```0#_`0```0`!`P,$ M`````!#P"````,`#L`'0%#`/#P`1\!```````,,+"`````$````.`/8"#P`- M\`P``````)X/!`````$````/``3P2````!(`"O`(`````1P````,``"#``OP M,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0`` M`#\#`0`!`!``\`<@````____``````"`@(````````#,F0`S,\P`S,S_`+*R ML@`/`.X#V`$```(`[P,8`````0````T.````````````@``````'````#P`, M!(@!```/``+P@`$``)``"/`(`````P````,@```/``/P&`$```\`!/`H```` M`0`)\!```````````````/____\``@```@`*\`@`````(```!0````\`!/!L M````$@`*\`@````"(```(`(``$,`"_`8````@`!$U/0"OP$```$`_P$```$` M`0,"!``````0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0#V M`@\`#?`,``````">#P0`````````#P`$\&P````2``KP"`````,@```@`@`` M0P`+\!@```"``*34]`*_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0 M%``/#P`1\!```````,,+"`````$````.`/8"#P`-\`P``````)X/!`````$` M```/``3P2````!(`"O`(`````2`````,``"#``OP,````($!````"(,!!0`` M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@```` M____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8 M`````0````T.````````````@``````'````#P`,!(@!```/``+P@`$``*`` M"/`(`````P````,D```/``/P&`$```\`!/`H`````0`)\!`````````````` M`````````````@`*\`@`````)```!0````\`!/!L````$@`*\`@````")``` M(`(``$,`"_`8````@``$U?0"OP$```$`_P$```$``0,"!``````0\`@```"` M`;`!T!10!`\`$?`0``````##"P@`````````#0#V`@\`#?`,``````">#P0` M````````#P`$\&P````2``KP"`````,D```@`@``0P`+\!@```"``&35]`*_ M`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0%``/#P`1\!```````,,+ M"`````$````.`/8"#P`-\`P``````)X/!`````$````/``3P2````!(`"O`( M`````20````,``"#``OP,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\! M$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____``````"`@(`````` M``#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8`````0````T.```````` M````@``````'````#P`,!(@!```/``+P@`$``+``"/`(`````P````,H```/ M``/P&`$```\`!/`H`````0`)\!```````````````````````````@`*\`@` M````*```!0````\`!/!L````$@`*\`@````"*```(`(``$,`"_`8````@`#$ MU?0"OP$```$`_P$```$``0,"!``````0\`@```"``;`!T!10!`\`$?`0```` M``##"P@`````````#0#V`@\`#?`,``````">#P0`````````#P`$\&P````2 M``KP"`````,H```@`@``0P`+\!@```"``"36]`*_`0```0#_`0```0`!`P,$ M`````!#P"````"`$L`'0%``/#P`1\!```````,,+"`````$````.`/8"#P`- M\`P``````)X/!`````$````/``3P2````!(`"O`(`````2@````,``"#``OP M,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0`` M`#\#`0`!`!``\`<@````____``````"`@(````````#,F0`S,\P`S,S_`+*R ML@`/`.X#V`$```(`[P,8`````0````T.````````````@``````'````#P`, M!(@!```/``+P@`$``,``"/`(`````P````,L```/``/P&`$```\`!/`H```` M`0`)\!```````````````/____\``@```@`*\`@`````+```!0````\`!/!L M````$@`*\`@````"+```(`(``$,`"_`8````@`#DUO0"OP$```$`_P$```$` M`0,"!``````0\`@```"``;`!T!10!`\`$?`0``````##"P@`````````#0#V M`@\`#?`,``````">#P0`````````#P`$\&P````2``KP"`````,L```@`@`` M0P`+\!@```"``$37]`*_`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0 M%``/#P`1\!```````,,+"`````$````.`/8"#P`-\`P``````)X/!`````$` M```/``3P2````!(`"O`(`````2P````,``"#``OP,````($!````"(,!!0`` M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@```` M____``````"`@(````````#,F0`S,\P`S,S_`+*RL@`/`.X#V`$```(`[P,8 M`````0````T.````````````@``````'````#P`,!(@!```/``+P@`$``-`` M"/`(`````P````,P```/``/P&`$```\`!/`H`````0`)\!`````````````` M`/____\``@```@`*\`@`````,```!0````\`!/!L````$@`*\`@````",``` M(`(``$,`"_`8````@`!T2?8"OP$```$`_P$```$``0,"!``````0\`@```"` M`;`!T!10!`\`$?`0``````##"P@`````````#0#V`@\`#?`,``````">#P0` M````````#P`$\&P````2``KP"`````,P```@`@``0P`+\!@```"``-1)]@*_ M`0```0#_`0```0`!`P,$`````!#P"````.`$L`'0%``/#P`1\!```````,,+ M"`````$````.`/8"#P`-\`P``````)X/!`````$````/``3P2````!(`"O`( M`````3`````,``"#``OP,````($!````"(,!!0``"),!CI^+`)0!WKUH`+\! M$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____``````"`@(`````` M``#,F0`S,\P`S,S_`+*RL@`/`.X#H@,```(`[P,8````!P````T````````` M````@``````'````#P`,!%(#```/``+P2@,``.``"/`(`````P````4\```/ M``/PX@(```\`!/`H`````0`)\!```````````````````````````@`*\`@` M````/```!0````\`!/!L````$@`*\`@````"/```(`(``$,`"_`8````@`!T M3/8"OP$```$`_P$```$``0,"!``````0\`@```"``;`!T!10!`\`$?`0```` M``##"P@`````````#0#V`@\`#?`,``````">#P0`````````#P`$\#8"``"B M#`KP"`````4\````"@``HP`+\#P```"``-1,]@*%``(```"'``8```"_``(` M`@"!`00```B#`0````B_`0``$`#``0$```C_`0``"``!`@(```@``!#P"``` M`%D$9@(:$=,,#P`-\,H!`````)\/!`````0``````*`/E@$``#P`/P!8`$T` M3``@`'8`90!R`',`:0!O`&X`/0`<(#$`+@`P`!T@/@`-`#P`4@!E`'$`=0!E M`',`=``^``T`(``\`$\`<`!E`'(`80!T`&D`;P!N`#X`4`!R`&D`;@!T`"`` M2@!O`&(`/``O`$\`<`!E`'(`80!T`&D`;P!N`#X`#0`@`#P`5@!E`'(`O6@`OP$2`!(`_P$` M``@`!`,)````/P,!``$`$`#P!R````#___\``````("`@````````,R9`#,S MS`#,S/\`LK*R``\`[@.T`P```@#O`Q@````'````#0````````````"````` M``<````/``P$9`,```\``O!<`P``\``(\`@````$````!$````\``_#T`@`` M#P`$\"@````!``GP$```````````````_____P`````"``KP"`````!````% M````#P`$\&P````2``KP"`````)````@`@``0P`+\!@```"``#1-]@*_`0`` M`0#_`0```0`!`P($`````!#P"````(`!L`'0%%`$#P`1\!```````,,+"``` M```````-`/8"#P`-\`P``````)X/!``````````/``3PM@$``*(,"O`(```` M`T`````*``"C``OP/````(``E$WV`H4``@```(<`!@```+\``@`"`($!!``` M"(,!````"+\!```0`,`!`0``"/\!```(``$"`@``"```$/`(````9@1&`7H. MH`H/``WP2@$`````GP\$````!```````J`_`````/%)E<75E``````"?#P0````$``````"J#PH````!`````0``````#P`$\$@````2 M``KP"`````%`````#```@P`+\#````"!`0````B#`04```B3`8Z?BP"4`=Z] M:`"_`1(`$@#_`0``"``$`PD````_`P$``0`0`/`'(````/___P``````@("` M````````S)D`,S/,`,S,_P"RLK(`#P#N`S8$```"`.\#&`````<````-```` M`````````(``````!P````\`#`3F`P``#P`"\-X#`````0CP"`````,````# M1```#P`#\'8#```/``3P*`````$`"?`0``````````````````````````(` M"O`(`````$0```4````/``3P;````!(`"O`(`````D0``"`"``!#``OP&``` M`(``5$[V`K\!```!`/\!```!``$#`@0`````$/`(````@`&P`=`44`0/`!'P M$```````PPL(``````````T`]@(/``WP#```````G@\$``````````\`!/#* M`@``H@P*\`@````#1`````H``*,`"_`\````@`"T3O8"A0`"````AP`&```` MOP`"``(`@0$$```(@P$````(OP$``!``P`$!```(_P$```@``0("```(```0 M\`@````$!48!VA&T#@\`#?!>`@````"?#P0````$``````"@#PH"```\`%(` M90!S`'``;P!N`',`90`^``T`(``\`',`=`!A`'0`=0!S`#X`,@`P`#``/``O M`',`=`!A`'0`=0!S`#X`#0`@`#P`3P!P`&4`<@!A`'0`:0!O`&X`/@!'`&4` M=`!*`&\`8@!S`#P`+P!/`'``90!R`&$`=`!I`&\`;@`^``T`(``\`%8`90!R M`',`:0!O`&X`/@`Q`"X`,``\`"\`=@!E`'(`#P0````!````#P`$\$@````2``KP"`````%, M````#```@P`+\#````"!`0````B#`04```B3`8Z?BP"4`=Z]:`"_`1(`$@#_ M`0``"``$`PD````_`P$``0`0`/`'(````/___P``````@("`````````S)D` M,S/,`,S,_P"RLK(`#P#N`]@!```"`.\#&`````$````-#@```````````(`` M````!P````\`#`2(`0``#P`"\(`!```@``CP"`````,````#4```#P`#\!@! M```/``3P*`````$`"?`0``````````````#_____``(```(`"O`(`````%`` M``4````/``3P;````!(`"O`(`````E```"`"``!#``OP&````(``1"9V`+\! M```!`/\!```!``$#`@0`````$/`(````@`&P`=`44`0/`!'P$```````PPL( M``````````T`=@`/``WP#```````G@\$``````````\`!/!L````$@`*\`@` M```#4```(`(``$,`"_`8````@`"D)G8`OP$```$`_P$```$``0,#!``````0 M\`@```#@!+`!T!0`#P\`$?`0``````##"P@````!````#@!V``\`#?`,```` M``">#P0````!````#P`$\$@````2``KP"`````%0````#```@P`+\#````"! M`0````B#`04```B3`8Z?BP"4`=Z]:`"_`1(`$@#_`0``"``$`PD````_`P$` M`0`0`/`'(````/___P``````@("`````````S)D`,S/,`,S,_P"RLK(```!R M%U`````!`-```````-<;``!4)```-"8``!0H``#T*0``U"L``+0M``"4+P`` M=#$``%0S```T-0``%#<``!``4`#T.```GCP``%I```"81```>$8`````]0\< M``````$``+P-``,`````6$@```$````4`````0!B```````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````/[_```$``(```````````````````````$```#@ MA9_R^4]H$*N1"``K)[/9,`````0+```+`````0```&`````"````:`````0` M``",````"````*`````)````M````!(```#`````"@```.`````,````[``` M``T```#X````#P````0!```1````#`$```(```#D!```'@```!L```!)4%`@ M4')O=&]C;VP@36]D:69I8V%T:6]N M````"P```&IO`!H`'0`0``\`-``>`!T`$``4`!``&@`: M`!``$0`=`!T`%P`$````+@$!``0````"`0(`!`````(!`@`$````+0$$``0` M```M`0$`!P```!L$@0)Y`]``2``$````+0$```0````M`0(`!0````D"```` M`@4````4`@`````5````^P+5_P```````)`!`````````!)4:6UE3\;`!,`$@`1``0` M```N`0$`!`````(!`@`%````"0(````"!0```!0"``````0````N`1@`!``` M``(!`0`(````,@IK`8(``0```)8`!````"X!`0`$`````@$"``4````)`@`` M``(%````%`(`````!````"X!&``$`````@$!`!X````R"FL!H``/````36%P M<&EN9R!D971A:6QS`"$`$0`2`!,`"@`3`!,`"0`3`!``"P`0``H`"P`.``0` M```N`0$`!`````(!`@`%````"0(````"!0```!0"``````0````N`1@`!``` M``(!`0`(````,@JA`8(``0```)8`!````"X!`0`$`````@$"``4````)`@`` M``(%````%`(`````!````"X!&``$`````@$!`"<````R"J$!H``5````=&EM M:6YG("@Q+C`@;W(@;&%T97(I``H`"P`=``H`$P`2``H`#``3``D`$P`)`!,` M#``*``H`$0`*`!``#0`,``0````N`0$`!`````(!`@`5````^P+5_P`````` M`)`!`````````!)4:6UE3\; M`!,`$@`1``0````N`0$`!`````(!`@`%````"0(````"!0```!0"``````0` M```N`1@`!`````(!`0`(````,@I*`H(``0```)8`!````"X!`0`$`````@$" M``4````)`@````(%````%`(`````!````"X!&``$`````@$!`!@````R"DH" MH``+````9W)A;G5L87)I='D`$P`,`!$`$@`3``H`$0`,``L`"@`3``0````N M`0$`!`````(!`@`$`````@$"``0````M`0$`!````"T!!``0````^P(0``<` M`````+P"``````$"`B)3>7-T96T`;@0````M`0,`!````/`!!0`/````)@8/ M`!0`5$Y04`0`#``````````````````)````)@8/``@`_____P$````#```` M``"&!@`````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````#^_P``!``"```````````````````````"```` M`M7-U9PN&Q"3EP@`*RSYKD0````%U7!E($UA<'!I;F<`$````$5X86UP;&4@4F5Q=65S=``3````17AA;7!L M92"31V5T($IO8G.4`!0```"31V5T+4IO8G.4(%)E````#0```%-L:61E(%1I=&QE0`````````````````````````````````````````````` M`````````````!8`!0'__________P,````0C8%DFT_/$8;J`*H`N2GH```` M``````````````````````#^____``````````!#`'4`<@!R`&4`;@!T`"`` M50!S`&4`<@`````````````````````````````````````````````````` M````&@`"`?_______________P`````````````````````````````````` M`````````````#4`````$`````````4`4P!U`&T`;0!A`'(`>0!)`&X`9@!O M`'(`;0!A`'0`:0!O`&X````````````````````````````````````H``(! M`0```/__________```````````````````````````````````````````` M````)0`````0````````4`!O`'<`90!R`%``;P!I`&X`=``@`$0`;P!C`'4` M;0!E`&X`=````````````````````````````````````"@``@$"````!``` M`/____\````````````````````````````````````````````````````` MU$@````````%`$0`;P!C`'4`;0!E`&X`=`!3`'4`;0!M`&$`<@!Y`$D`;@!F M`&\`<@!M`&$`=`!I`&\`;@``````````````.``"`?_______________P`` M`````````````````````````````````````````````"T`````$``````` M```````````````````````````````````````````````````````````` M````````````````````````````````________________```````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````#_______________\````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````/_______________P`````````````````````````````` 9``````````````````````````````````== ` end From ipp-owner@pwg.org Wed Jan 28 09:23:57 1998 Delivery-Date: Wed, 28 Jan 1998 09:23:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA28872 for ; Wed, 28 Jan 1998 09:23:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA10715 for ; Wed, 28 Jan 1998 09:26:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA27303 for ; Wed, 28 Jan 1998 09:23:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 09:18:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26729 for ipp-outgoing; Wed, 28 Jan 1998 09:03:11 -0500 (EST) Message-ID: <34CF3A83.B8C302A8@underscore.com> Date: Wed, 28 Jan 1998 09:02:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: joshco@microsoft.com Subject: Re: IPP> ipppreso.ppt Content-Type: multipart/mixed; boundary="------------10A7ED838CC9CC86AF125FB8" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------10A7ED838CC9CC86AF125FB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is an Acrobat (PDF) version of Josh Cohen's previously submitted PowerPoint presentation. I'll leave it up to Microsoft to upload both of these files on the PWG server if they feel it is appropriate. ...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 -- ---------------------------------------------------------------------- --------------10A7ED838CC9CC86AF125FB8 Content-Type: application/pdf; name="ipppreso.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ipppreso.pdf" JVBERi0xLjIgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9M WldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4gBozGwghQgG4yGAgGo0iJyMogMwNIRUBo xiYuHAgGg2G0gEAgKhEBsRlggg0IF5GiI0GcmlEZGAuGQzHI0k5UMYgFs5GQxGgyn53EAoJJ QKAgKByN50N5jN5sEBNN5kNJmNJjMJ0NJvNxzFMoNQNFo1G4uhYtHEClBEEExiIzGM2KkZFt tGE8kMooMRlFKFBcGQyGtnKlpGQ3EGElORFwxHI3Gs/oNDyowv9JpZVOcXLBNJggNNlOhlMJ kEBvMwgMWpMJyPIgOFSqlWNmMtI5oQ0vM+ud1mQgGQ4nU/vnDiFIwWR0GHxI23wNxPLyV0zg zGg34HRFB3NB5H/XFvZpAtil67nOGHQoFLxAy61o7Ay7U/7k5GCRsy6KchmGAchm6YmjCOA4 NSg4yDKOgwjSNizPw9L9PW9r5PeFyjvizTpMK+jquu9UQsm/y4oW6LOBgGIcMCKjDLENsGhA LgULyiI3jkEA2LCMo5C4FL0Bq5UMwCya7IYvMYr4vzARAyTDPqxb8MfE66JyyzFSkFwYBw77 ptEi6uDMM0gjKNw6BANsIDQrYQDoNAwjcqAnimKjruA9jhv44yIuS5abrU+D5MG6b6vuxr8v 24ruu+8L5vG8rzwtEz2KJP4W0NEDqPtEsMSyoUtvjSSghQM45TqOsfjkNI6Dy64io4gIDWVu ZHN0cmVhbQ1lbmRvYmoNOSAwIG9iag01MTYNZW5kb2JqDTQgMCBvYmoNPDwNL1R5cGUgL1Bh Z2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANPj4N L1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDggMCBSDT4+DWVuZG9iag0xMSAwIG9iag08 PA0vTGVuZ3RoIDEyIDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgR yM4gBozGwghQgG4yGAgGo0iJyMogMwNIRUBoyGgyFw0EA0Gw2Fw4EAgKhEBsRlwgg0IF5GiI 0GcnlJUjIwFwwGI4GU5MYgnkQG85O4gFBON5uEBQJ5TKggFogO5oPIplRqBotGI0GouoItHE ClREEEziIzGM4lUZFo3nozHMolVDiMqpIoLgyGQ1rRUrgyo95ldEsUQuxUvAuGY1G0ivVKJJ FKhGp8WOZzOsWwNcFuEqkksU5tFxud1oVEpFKvt/z8dwumxAxG45s2M2t13N7qFSEBvOxlOR sN5hMnBMRzMedMpzEBhMZ0NNN2Oho4t0lBs9UuQwumLvGtvl+wFb2Ws7s8GOEo93xAwGg5Gv kKZpNppNhhOQgMg0uYOrNuqpw0qcIggis67RO0sKFu61DwNU+DDL217zsE9LDLQoq6we3QWp 4GYZK+8gjDSiw7jCNg2BAIIhiYEAxqaOg5DfFoyDKM6LOfBbsu22kIvC1cKtc8zYtFDbahi+ r4BQIw6jcMgwjaMo3DpFY2Ky9DLAa9oaNKGIcpMoMxTKnCLIwjSOLZMgQIgtsPpYooaBu98Q KKG4YSaKi9hAJIoCg/w3ueNzru/IcKPI14ZNjEQcBmGbVxCkIYBs3qlDpGT+DLBcxNHN0IUR CbdSK8rYPRJLaREj1JvZSzFr2KY3yqEEDDnLEWDK5IxDCOaLwAzjnowN7+vwOA2DLKsruIOb Yy6gIA1lbmRzdHJlYW0NZW5kb2JqDTEyIDAgb2JqDTU1MA1lbmRvYmoNMTAgMCBvYmoNPDwN L1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2 IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDExIDAgUg0+Pg1lbmRvYmoN MTQgMCBvYmoNPDwNL0xlbmd0aCAxNSAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJl YW0NCoAMRBAoEcjOIAaMxsIIUIBuMhgIBqNIicjKIDMDSEVAaMhmNxdCxoNhsLhwIBAVCIDY jLRBBoQLyNERoM5NKCpGRgLhgMRuNJwYxBO4gN5PKTuIBQTjebhAUCeUyoIBaIDuaDCdBTKT UDRaMYoLqALRxApSRBBMoiMxjN5TGRbIBgMxzRypQojSKUXBkMhrWypXRkN6HOLROxmMJrQa pOxhg7MVKSKCeboubTKdDQbzIIMBXRaNJ5dLteJxk75Hs/LBcMRhC5TQhQUCkSScVNWLZtNb rjBRqRpucHVJGLhlhqpctJvtTf65HcJeZVQ+MNeHscbxhuNRrp6UUDKchATzh4ayaabqxzxL bQLPaZmIBkOONOLh7Yhx+x0tRfRs1a+vq6S0BanYYhsozfNo2wqBaJQniE4QZPq0KiOQr6xP y5j/QBCbjwG7KPJ+3whiCJwhiKJkHQhCUKLCu0CPwx8Nhk/7nwDD8LwMGgasi2QmCSqUViEK bchq+jjtC7r3rUhi2rsuDlN67Dfr65zAugwr3sc18fKUJ7NPCOYftWIqOICADWVuZHN0cmVh bQ1lbmRvYmoNMTUgMCBvYmoNNDE5DWVuZG9iag0xMyAwIG9iag08PA0vVHlwZSAvUGFnZQ0v UGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0+Pg0vUHJv Y1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMTQgMCBSDT4+DWVuZG9iag0xNyAwIG9iag08PA0v TGVuZ3RoIDE4IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4g BozGwghQgG4yGAgGo0iJyMogMwNIRUBoyGozFw4EA0Gw2kIgEBUIgNiMtEEGhAvI0RGkgkUp jIwFwxHMNlJjEE6moxhcpO4gFBFPB0MpyNxhNggKZ1OR2Mp5FMpNQNFoxGsmhYtHEClJEEEy iIzGMnnFcG4uGAzHM3KlAiNGpBcGUerJUrYyG9BlEqoM7HMTwdAFs6GAxHAywdHFBEN4gNxv OggN9WORsN5hMggKBPKZUvtbHIgFo0tY0wdmtAgGQ4F2QttdFw0iG2uuCvAovQyG2njoy2u+ wmMHI2GuJ1U6GIzGeB35OMp0OZjMJwi5QORvPB5qVNznEFt74+rnV0s243Qw3l2yN5vfDrXF 4935NwGlf5ydBkGKHvmFAmjSMbvjmN4zMy7zwPEKbyKa8z0Mg9TjrK1TWt2/8COC+y/PwyD9 LM6AbBo1KfsKGAchvFIqMkJI3DWOg3jaNIQOIw7cuREqdsaui7J2GyyRgpEHPC8aqwm+6uwE FywopDDCPdDkVP0yUPuJCsexWiEXyEGTWReyQjDSiw7qgqIgjJG43DSOY6DkMMajkObiOik4 WhmGseQy2MxMGjIWz6GETw637ghrPCRRJFYcRQ/64BjSkCOaN46szBYQIW0E3ThOU6DfOwQD iOqmjSMoyPMHKItWGk/MI2K1LYKlBreuK50RIzgL3Rb7sBLsAN0oresWncXOpXgnMqN4xDUM oxjoNI3jcOYQRqEAwssMqjja640DeMgWBANQ6zjbA7je4lXBm2jXQyFtcLlILkSyvYY3Y2qf N6FA0jcMg0jMMymjKNwxjK81511FVer24gio4gINZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9i ag02MzINZW5kb2JqDTE2IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jl c291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9D b250ZW50cyAxNyAwIFINPj4NZW5kb2JqDTIwIDAgb2JqDTw8DS9MZW5ndGggMjEgMCBSDS9G aWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADEQQKBHIziAGjMbCCFCAbjIYCAajSInI yiAzA0hFQGjIbwsaDYbC4cCAQFQiA2IysQQaEC8jREaDOSSYqRkYC4YDmdzYxiAWzkYDYaje bHcQCgsE0mUAQFc0HkfimTmoGi0YjccTUWjiBSciCCYREZjGayeMi0bzoZjmSyefxGT0gUFw ZDIa1QqVaPCC5Si/C4ZDMbjWfYGdjmjXOklQ0Rcxm82mk3Qc7mE7RczG85CA5nQ5HUxnQ6xY yCAyGE6GG9VYc0Cy2fAWOBjnZWmczytYe/3S7DIba2OjLBX6bWGc3cZYeg4IYYsqXQqG83mw 5iAwxYQGUwnM0mw89g7GHvmExGyLmE3acxGXI5PKiA25yLnM38IWjWt8sWzPirAsSYoYsy3p uq61hgtsCrio6kt+vKqo6oy/uQwS2hm5ichiGIZK+6KkiCMjxjc1YzjK643jMEDODSM7KDCN gQCCKYhiSJIQDgOQ3jgN45xg4SIhaGatho47AsHBagOSGwYQKug7jSOg0DeOo6BBKLrjINMf RE9USxO4TXv6s0iwA2gZP2my0zIiDlrg4zGLqu7gwiu7iwoxAahnNwqJ+5oYhqGEyw+FAiDS 043DfKwyjxLcrNe+cSDQ64wjO+8IhbOz+Io/7AKwFwaTa3kGzk4DhU1ODAKFJkMTfP6KVbQg kO6zzqsy071NPKA2Ri+w2MzK45jmOsThAO6LjQzAyjc/CRhxUU3t7BzlSAnQbz2w4UDpIDYJ ohcAKE58+LiwQahrb9CDKzI3BBKUqDONErPNKkrDyMtt0xVD+pzAqw0/UIYXHVLfTnU7iOXP ChBuG8PT8oQYpnUg3ROOgytOz7QtG0oyhY7A5DkMI8jnjt7jG4Qio4gIDWVuZHN0cmVhbQ1l bmRvYmoNMjEgMCBvYmoNNjYxDWVuZG9iag0xOSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFy ZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0+Pg0vUHJvY1Nl dCAyIDAgUg0+Pg0vQ29udGVudHMgMjAgMCBSDT4+DWVuZG9iag0yMyAwIG9iag08PA0vTGVu Z3RoIDI0IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4gBozG wghQgG4yGAgGo0iJyMogMwNIRUBoyHAwFw4EA0G44kIgEBUIgNiMtEEGhAvI0RGgzk8pjMgG A5GMLlJjEAtnQ2Gw0lBUO4gFBYJpMoIgK5oMJ0FMpNQNFoxHE2hYtGo3o5EEEyiIyo04rA1F wwotHoERlNJFBcGQyGtVKlXGVguEqoMgGI0s5UoAoIkqvFXGg5FwyEF9sVkhgxm5UjNZFwxG 8Nn9KH+JrEUxtBGeUkUpyMzgeM0+WrEgHIwktupV0GQ20F10eQx+ZGQzwdvzIwGutuRZMpzF kYN5yEBzOBloBiOp0EBuN/WOR1Nx0NJti52MJsNJkqZpN5u0Fek2OFs10eoseqj3x11eFw2i GOzt9uTbLuqyOr4sK/saHAcP4wilCwKYmNAGoZJO3jJNKyrLsozTOQWFDPwE96bJEFsLNa1K Ihi1ijsu2DZNawrbNxATdMc3jABovbaKEtYbBmGqjrkJw3uW7DrKmEA6DQNI5yO74yvW4rRx GrkCsks0VLTHbgsfH7arrAK8wHLb5J02IZtonTiLAuKlCCOg6DkNLqDo5IQOaEAijYMrwO6O cPTAHKghkxjBxM1cLteFzYtm/suLmusYzBGcxL8kFBLq2gUB40AYsoozeR0GCtRdAziQUuQ8 VQEDQOBCcCp0kszP6FwaBqndGjCHqBDEHoZB89YbJMowWvrEsDUVUb/S627cwlGlXMaHNLs7 TNN07SaxR0GVRUxVA8VWl0xrWHIbIFaYfB4MIfBiHgX3SHgxB8GV2XhdlNhwGz82vA1tQRbl UW/fVK2jBTC19D7S3w9wZ2DKj6PbK78P0GGCWVL69QJcIYJrLVKxQwcgDC8AQCmOAwjG5LQU BEa1UI+aysHDFZrbRk10dZcZWbgLfBtQDO1AGdbZqJ7qjKOQ2jeObrDLPM9jpJb0jYPLQCKj iAgNZW5kc3RyZWFtDWVuZG9iag0yNCAwIG9iag03MTYNZW5kb2JqDTIyIDAgb2JqDTw8DS9U eXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAw IFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAyMyAwIFINPj4NZW5kb2JqDTI5 IDAgb2JqDTw8DS9MZW5ndGggMzAgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFt DQqADEQQKBHIziAGjMbCCFCAbjIYCAajSInIyiAzA0hFQGjIZjUXDgQDQbDaQiAQFQiA2Iy0 QQaEC8jREaDOTymMjAXDAcjGFykxiAWzoYSUaSgqHcQCgsE0mCArmgwnQQFwUCmUmqOjIcye IykiCCiDGSUig1+k0sxm83HSsFStDeQQu0WGiDOG0CllwU2+tC0aYGhDiBWAQTKIjMYzcqRk WjedjMcyK9CguDIZDW/R0b2KkXYXDEcjXO3qiYQa0ilCgpnQ5WyDnQ8nA0m6Dm85CA7mUwms QbLabbNjmhDTF0fDYgQDIcC4ZUjHceIc/Taq95gbZvMc7PYahzvJ2alkI3mLNi2TDjp+LLZg ZZuiDkZcgqUHvjGuT+0ig5iA4NeOA3jmMI2Kq/jXNgvjzu257AJ0yiVKE6QYOo+ruv2y4ZOy rKtu4urDiMgTmO4nAGu+oqSvE74avm+jVigMI6jYF4lQENEDN23sFQ4FoaubBoaNS5KZoYxc IMcyAYMlCCzus9rMu0zsPp0GIZhg0sLPuGqPydGA8jYN4wjJAwoCIJkdrgBriMA47PxAiMRw q6IXBo9bqpS1cMw3NMGQu0ElIm8SdMwG8XKWNsZDoNI4DCOSqM2GKeQ9NydBqGIYyZC7VjaN I2jKzYio4gINZW5kc3RyZWFtDWVuZG9iag0zMCAwIG9iag00OTINZW5kb2JqDTI1IDAgb2Jq DTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMjYgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwN L0YwIDYgMCBSIA0vRjEgMjcgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMg MjkgMCBSDT4+DWVuZG9iag0zMiAwIG9iag08PA0vTGVuZ3RoIDMzIDAgUg0vRmlsdGVyIC9M WldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4gBozGwghQgG4yGAgGo0iJyMogMwNIRUBo yGw2Fw0EA0j4uHAgEBUIgNiMtEEGhAvI0RGgzk0oKkZGAuGMTgUpMYgFs7GIyHA5nB3EAoLB NJlCEBXNBlNw/FMpNQNFoxGw5FwyoQ4n8qEEyiIzGM3lMZFo3FwwGY5k9AEERlNKFBcGQyGt XKlZGQ3us4Il1ng5GciulDr9csF3pZWMpyOZpN5ugdvv1ZpAtGlpxVkswgo1fnFs0EQx5UoN 2Kl4vUezcdGWm12FnYwHOCxdEG43sd4ptPNxvOkvMphMh5FggOZvNsXN5mEB1OYgMMWEBky5 l2Ytvemz07udkrch1U41tJpexG2z8Ng2+GGA0HNjoOMGY4Gwz9gUCGiwwjoMrrjYMozjCMY8 u+GocPEGgasIsqZoYtLyrYty4Lk9TBsgvK9r6rCOsE+aiMQ0L8p2GTHP+yTKMszDahg77AqF CIXIWlLCrat64vK9cPtjES/xJDyyJ2GgcBvIClicMo7MnGrBM8kDVx5DUfw7EC+PhEsJxWz7 VxUngYtCvAnjqOTkDG6DojcMkBxiHTtjeEA0uO4o7tmIqOICDWVuZHN0cmVhbQ1lbmRvYmoN MzMgMCBvYmoNNDQ3DWVuZG9iag0zMSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDI2 IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANPj4NL1Byb2NTZXQgMiAw IFINPj4NL0NvbnRlbnRzIDMyIDAgUg0+Pg1lbmRvYmoNMzUgMCBvYmoNPDwNL0xlbmd0aCAz NiAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMRBAoEcjOIAaMxsIIUIBu MhgIBqNIicjKIDMDSEVAaMhwMRcNBANBsNhcOBAICoRAbEZcIINCBeRoiNBnJ5SVIyMBcMRy ORvOTGIBbPBiNxoNZydxAKCaUxAUDkbzgbzmYTYKZUagaLRiOBoLhlRBrQZURBBM4iM5BKJV GRaNxcMBmObcVKHEZVTBQXBkMhrWipXBlQb1KxBPBkMbLQqJihmOKVe6aUCkSScVBATTKdDQ bzJgq4LcLRJJYpzaLjc7rd7zS6bfsBoo7htTibnhRzjqLcxqMLMVL4WCaTBAbjed9ppKCLdP Y7PRLldLtjsPfNlga3tcTt8UOL/vMUMMnwqaRMQZjecpgZTMZYsbjHFzEdTpxzfMDqbjoaTa i47KwNIyDCOgyuW0rnBqFyFui1bqNc7rKL6v7tMG7jDtUnjyBq3aVLzBgZrY2AUCc/IsCmJk EOa57bwe1rrRI7LaNLDLcMAsDxLEj7oPMFAijYMr/v4OYWPwEAuBQ4gmC4rUCjoOQ0vrAw5x W0yTR61TpxhD8JR9Gbtxq7yep/Bq8Nw4AbzMvkTBAOcoDeNyDjoPI4DTOUrQVBkXS26suuu2 MKxo2zop4GbABnHQYBoj8STaNwwv/Nw4DC+baCKjiAgNZW5kc3RyZWFtDWVuZG9iag0zNiAw IG9iag00ODENZW5kb2JqDTM0IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMjYgMCBS DS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+ Pg0vQ29udGVudHMgMzUgMCBSDT4+DWVuZG9iag0zOCAwIG9iag08PA0vTGVuZ3RoIDM5IDAg Ug0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4gBozGwghQgG4yGAgG o0iJyMogMwNIRUBoyGwyFwyEA0Gw2Fw4EAgKhEBsRlwgg0IF5GiI0GcnlJUjIwFwwiEilRjE E8GAwGs5O4gFBYJpMEBNMJwOBpNxnFMqNQNFoxG1HFo4gUqIggmcRGYxnEqjItG89GY5lFBo dIpRcGQyGtXKlZGQ3udioYuhQ0nNCFs8GY4G1xKlJFBSMpxOplOZ0EBvOUwyhwN5uOcXMJzy 51OhlzJlNhlNplNx0vVZFt9EAtkkhnNjtluuGFv+Nut3vNYjt+iOAngxHI5sJUoWIG9gugoN 5w0xhOhpzogyRhNhpMxp02iNxlPGW1J21GvBo52Y0tGEwFlEAyHG2tVa98/3nF3wouyPPUu7 bP4saiBiG72LkngZBoGkEv69A5Dm7A3BYy44OuzsLMq6wyvUGKQBnBDGOa6K7KM9QWhq+qRN oo74pohi0MYta2hgt8SN+vEAuI27AhkGYaRyw4XBjESFpUxwlDeMQQCeMQ1DKMY6QtJcmiCO g6DkNIxNIygQNCEDUNU1g6DnFLZNokygJW2cbRw/cTOBHjewKkIZsS/bBJs+D+iCOQ5DCPLR C4FEPqMFyFwIwKuByGc4ySpQpjKOgnjM9QbqPRcFhzIDeSIGIYhq5bHC4q8wvGyoyjIEAxDY N4xjW2cxPQNyMMxFIYhwniFhaxIXT7O0gwbT7EBsh7os6i9YDGOtANYMcPOEIqOICA1lbmRz dHJlYW0NZW5kb2JqDTM5IDAgb2JqDTU1Ng1lbmRvYmoNMzcgMCBvYmoNPDwNL1R5cGUgL1Bh Z2UNL1BhcmVudCAyNiAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+ DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAzOCAwIFINPj4NZW5kb2JqDTQxIDAgb2Jq DTw8DS9MZW5ndGggNDIgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADEQQ KBHIziAGjMbCCFCAbjIYCAajSInIyiAzA0hFQGjIZDgXQsaDYbC4cCAQFQiA2Iy0QQaEC8jR EaDOTSgqRkYC4YjUYwKUmMQC2djEZDUczg7iAUEkoFCUnk4RcmmE4HA0m4zimUmoGi0YjMYi 4aUMcUCVCCZRGxTeUxkWjcXDAZjmT0EQRGU0sUFyPDWuFSvDIb3mcES8i4ZDYcUm8US5z7C3 umEQwnQyiwQG4wm3MiDMHg6Zo1mU8nc3nIyZoqlIk5rA14aDIaTe9WmdxQbWihbe+HU5Gk5m M0GXPbEG2EZYaU4jIDCPXcqUIUCzkC0ajWSycWjOQWXm4nFjPJ9OmcQwnI5mU6cgczuF7fET sajeHzihZCF5TqiDkBikrlvk8QbPK/Kdo+uylKYzg6OAMI2DYMKtDqMIzou5AZKMsjmNwxT6 uWvCdhnEIqL4EwQDaNLPNAqSLjCOYQOE64ZpGxShxtErnLkukFRFBa+r/DLCwHEb3sc8zIBo sLyr4JI3MxC45Ngrrkhg7cOvmngaBu8DzN8pgyjcOo2uQG6dpPIoXPq+7HvhIEqME5MAyyxM rro/EOr4MQ3jeNjkPrOsEIm3ihwQG4bSQvjNBaHzNzIMrgqEOY6OCrTrsIuTuRyw6hx4urpN 7IC/KPIdBJ4HLFzzBDlSAOUJwuEA3jModHUoOQ6jHByLBAO40joNAQB4Mw5DeNtHRQHg6DeH 1MMKFoaBqkNOriudQVXUchSqwlThgu0kN6sgbhwGdXDKOc/DqOg0jeN1ahBW9c12i9fWBYQ8 WRYQ82bKoW25aE6PDase1DPSmVIwFtyJTsRslPLny6GsgCnYyLs5FStRkOY5jrc73RwscvMQ tYQI/G63q/kKIRLUT+VIG0MhlG8Bsgn88TcxTF0UpgrjQPIQDJdrrwDldsZcjwZOunYYJ/Az Ep7aMgDoEEIDYEA1DeMWqDpSo0jFdVz3gOj06noaTaLH+jw1pS5hwHEvOprAxbMHG0PNHlyW yjz/X6ncuhtuGDBQH7kCKjiAgA1lbmRzdHJlYW0NZW5kb2JqDTQyIDAgb2JqDTc3OQ1lbmRv YmoNNDAgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAyNiAwIFINL1Jlc291cmNlcyA8 PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA0 MSAwIFINPj4NZW5kb2JqDTQ2IDAgb2JqDTw8DS9MZW5ndGggNDcgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqADEQQKBHIziAGjMbCCFCAbjIYCAajSInIyiAzA0hFQGjI aDEXDIQDQbDYXDgQCAqEQGxGXCCDQgXkaIjQZyeUlSMjAXDMZDIczkxiAWzygDcbzk7iAUEU 8GE2nA2RcpGU4nUynM6CmVGoGi0YjKQSIWjWBSoiCCZyIYjmcSqdi6w0IQRGVUsUDwflgmkw QHYynI5mk3m4elyfjOQDDER4fVwqV6Ii2PTm03mq1esnTH10GlQVUwQDwnnDAmE6YQ3D4oHI 0m46CAlG8xDwX6XT6nC53I5/QijRlbA4Pd4vbYDBareV7QaIebMxcvfaLRk6oGUfE08iDW6/ Y9DbG7r9Lm8DRmM3nA01kfDHbej1ezIczfykeEPCnQy7AfEMkiIHT0Ng/Y6BaNgwjEMo2Pe/ MCPI+rbDU2kHqY2yLM0rTpCKjiAgDWVuZHN0cmVhbQ1lbmRvYmoNNDcgMCBvYmoNMzI1DWVu ZG9iag00MyAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDI2IDAgUg0vUmVzb3VyY2Vz IDw8DS9Gb250IDw8DS9GMCA2IDAgUiANL0YyIDQ0IDAgUiANPj4NL1Byb2NTZXQgMiAwIFIN Pj4NL0NvbnRlbnRzIDQ2IDAgUg0+Pg1lbmRvYmoNNTIgMCBvYmoNPDwNL0xlbmd0aCA1MyAw IFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMRBAoEcjOIAaMxsIIUIBuMhgI BqNIicjKIDMDSEVAaMhiNhdCxoNpAOBAICoRAbEZYIINCBeRoiNBmLpNKIyMBdChrApQYxAL Z0MxmORzJyodxAKCKeDCbTgbIuKZQagbQhcNRgN6PP4GLhjRJ9SaWXBkMhmRzKdBASjeYjnV CpVhaNZ2NxjNypQIjKKUKLMMhpcrpYRlIaCNcPeiIIJiM4GOZtSJzYBlSKAKB4UjKcTqZTmd B9hJXQcFSMaKBAPCecDKcjCdDSbzcPrUdBbbrgPBfrdfsdntdIVBVS9WVtec+CPhiLhhvOQc uVtNHVQbxOMPNJp77KaXnM9oDoZTIQTodDkaTEdfHcetZ5N3dT1bnVxlitMNNRxtXsfQ9T2D K+irBiGqFvkpY1LeIY3jgNLQNIGIYPi/bNBe/z0vW8cBvsGz9Ba06UNSk4eQxAENwjAwQQQF EFDEJynjK0gcP1FjeRNDUBNJECKPzCrVhe0iGxY8DPtC8jzP/HL3Pq+EVwrDkQQ9H0RKW3ki vFDgio4gIA1lbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2JqDTQwNQ1lbmRvYmoNNDggMCBvYmoN PDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA0OSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0v RjAgNiAwIFIgDS9GMyA1MCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA1 MiAwIFINPj4NZW5kb2JqDTU1IDAgb2JqDTw8DS9MZW5ndGggNTYgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqADEQQKBHIziAGjMbCCFCAbjIYCAajSInIyiAzA0hFQGxA cC4ZCAaDYbC4cCAQFQiA2Iy0QQaEC8jREaDOTSgqRkWjAXDMcDGBSkxiCIyk7iAUFwZDIZkc ynQWko3mI5imUmoGzuejcaDmcUOeRQYUEqUek0saCApGU5nA3m45mWrFSsC0YjIaSAQC0bzy TykiCCZDOB3+c1meDCF0KiTizDy12233EfXOsREWjIYi7FyqiC7FY6kCAeHM6GE6HU5j6IDA eC/TajVZWrg0qCq94mJjWv58YbvRCjSE84GU5ag02/aXQG3evUXPVoYDgajfe9CzU46VKqZY GjfedDA9LeYwUa/icbkcrvZkYWnM5vO+PdDTylSwaDgUbRjwrOMObkjcHzNtcF47QBATlsuv bNM4nDAugsDgtINSpwW2zcOkkjrMYxMOQo0gxjeOA0rZAjXxHEsTu827cv0GyQw9GEZLK0bS DcMI2jKHwmjeNqlKWOYQCCOA4DYi4oRMl4yjGNLitfHMdwxFytLI/KyLM0gXwsMUqNxCTGv4 4QeS7L8XsUG0Ovw30QTGlERRJEzVhlFM5RY2sqt06jrv1Pk3pQHkpR4KAwjqNkghlIYzjqNI yIuOg3hANA3jkuIxDCMY1pfRw0jcM8ox1HkWw0nkrs/LL+y5C9STQ/c2OwpDXosyS4VG2oio 4gINZW5kc3RyZWFtDWVuZG9iag01NiAwIG9iag01MjINZW5kb2JqDTU0IDAgb2JqDTw8DS9U eXBlIC9QYWdlDS9QYXJlbnQgNDkgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYg MCBSIA0vRjMgNTAgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgNTUgMCBS DT4+DWVuZG9iag01OCAwIG9iag08PA0vTGVuZ3RoIDU5IDAgUg0vRmlsdGVyIC9MWldEZWNv ZGUgDT4+DXN0cmVhbQ0KgAxEECgRyM4gBozGwghQgG4yGAgGo0iJyMogMwNIRUBoyGw4Fw4E A0Gw2kIgEBUIgNiMtEEGhAvI0RGgzk8pjIwFwyHI0HMoKhjEERlJ3EAoJppOZjMpsNhhNxlN 51OYplJqBotGI3GIuhYtHEClJEEEyiIzrsinFZG4uGAzHNqoNHLgyGQ1qxUrAyG9DoFknQwH FxoFCnQ0HA3GlAowoJxvEB0PJwNJuM95rE/Fo0ruLsdlmYgGUgGVAjNaFw0iGllOGxl0uw2z EdGU7v2fwIyGNiueBHNb14oyWUywgMJkMhzEBuyEWMJsEB2551MuzFt222bnVysmo1Qw1m94 N1j2z7GlokqoYuGI0G8/1tHOZpNpwNhlOXW84g7W2z7vNWwrYPKq7aNs9LusC8CFvinQYhsi bgiSKAoOMOD7DSMYwjoNI3jcEA2qoOgQDnDinOi540jJDaLjSOjlRWOgwusGrSP4Ggar+0Cz rS0y2LcuC5NcosBrxAq+Nu9SdN0GDeKEFsHBinjgiwJomBAKYxjQMo2jCyLIDFFsPiqKgjLA /S+s2kzwu6tq3sJBrxrtIy9I6vsEPWGYawi+MoBcGYbhw8LGiGMI5ouJI3UPRUXDSOzqwKIq OICADWVuZHN0cmVhbQ1lbmRvYmoNNTkgMCBvYmoNNDc0DWVuZG9iag01NyAwIG9iag08PA0v VHlwZSAvUGFnZQ0vUGFyZW50IDQ5IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2 IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDU4IDAgUg0+Pg1lbmRvYmoN NjEgMCBvYmoNPDwNL0xlbmd0aCA2MiAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJl YW0NCoAMRBAoEcjOIAaMxsIIUIBuMhgIBqNIicjKIDMDSEVAaMhyNRcOBANBsNpCIBAVCIDY jLRBBoQLyNERoM5PKYyMBcMRmNxnKCoYxBEZSdxAKCGbzcYzYdTmaaUKZSagaLRiORwLoWLR xApSRBBMoiMxjNypGRaNxcMBnWKBQhQXBkMhrUipVBkN6HQLBOrpE7eIBbOhgMhjXipRhQWC aTBAaDCcxAZzCaTcZTIIDabzaZTcdDqbRAYTdmTTkjcb6MYbtVIiLRnWRpfKGLhlJYXKaFg7 WOBzs6LRzObzfmTGaDeaTHFzMbzkICSUChrarecFJNttLTa7bIt1e+DcbndanHb1RJVtRiNp JgZ1h9vQMUVaeboOUCkSScVBBljmOgyjCzI3jMEAoCeKb+DCNg2NUyTWPK17Yhc4D0r8ijvK CwT3hshrwjMywyueM45MqNwQQIEAxqUOg5DeNjRtKEAyjwOCLDmp6lP6NzqCoFT1BqGMMqE9 DFCCIYmDm6gWusFrsBk7S1LYtzvvEujqOs9CwNhCjusDKwZuovwahyn7vp0sgbhy+SjjCM0A OeOYyxwqEePLLiaypDSbBoGK9PCuQZNm6irpAhctPUG8OsC3irhyxDFCEMI5CFFNCMKrTwQs 2ySNzDTeNu382BQO40DTAAxDfSbMzlOiozujysyg2DZNpC4a0Ywi8wyxQ6DeEAyNOManMkNr LOc/scDrOcUQLGkbTnHM7LuBoio4gIANZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iag01NTkN ZW5kb2JqDTYwIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNDkgMCBSDS9SZXNvdXJj ZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVu dHMgNjEgMCBSDT4+DWVuZG9iag02IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9U cnVlVHlwZQ0vTmFtZSAvRjANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuDS9GaXJzdENoYXIg MzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjQ2IDMyOCA0MTAgNTA2IDUwNiA4MzUgNzgw IDE3OCAzMjggMzI4IDQ3OSA1NjEgMjQ2IDMyOCAyNDYgMjc0IA01MDYgNTA2IDUwNiA1MDYg NTA2IDUwNiA1MDYgNTA2IDUwNiA1MDYgMjc0IDI3NCA1NjEgNTYxIDU2MSA0NTIgDTkxNyA3 MjYgNjcxIDY3MSA3MjYgNjE2IDU2MSA3MjYgNzI2IDMxNSAzOTcgNzI2IDYxNiA4OTAgNzI2 IDcyNiANNTYxIDcyNiA2NzEgNTYxIDYxNiA3MjYgNzI2IDk0NSA3MjYgNzI2IDU4OSAzNTYg MjYwIDM0MiA0NjUgNTA2IA0zMjggNDM4IDUwNiA0MzggNTA2IDQyNCAzMjggNDc5IDUwNiAy NzQgMjg3IDQ5MyAyNzQgNzUzIDUwNiA0OTMgDTUwNiA1MDYgMzI4IDM4MyAyNzQgNTA2IDQ5 MyA3MjYgNTA2IDQ5MyA0NTIgNDc5IDE3OCA0NzkgNTM0IDc4MCANNzgwIDc4MCA1NjEgNTYx IDU2MSA1NjEgNTYxIDU2MSA1NjEgNTYxIDU2MSA1NjEgNTYxIDc4MCA3ODAgNzgwIA03ODAg NTYxIDU2MSA1NjEgNTYxIDU2MSA1NjEgNTYxIDU2MSA1NjEgNTYxIDU2MSA1NjEgNzgwIDc4 MCA1NjEgDTI0NiAzMjggNTA2IDUwNiA1MDYgNTA2IDE3OCA1MDYgMzQyIDc1MyAyNjAgNDc5 IDU2MSAzMjggNzUzIDUwNiANMzgzIDU0NyAzMDEgMjg3IDMyOCA1NzUgNDUyIDI0NiAzMTUg MzAxIDMxNSA0NzkgNzUzIDc1MyA3NTMgNDM4IA03MjYgNzI2IDcyNiA3MjYgNzI2IDcyNiA4 OTAgNjcxIDYxNiA2MTYgNjE2IDYxNiAzMjggMzI4IDMyOCAzMjggDTcyNiA3MjYgNzI2IDcy NiA3MjYgNzI2IDcyNiA1NjEgNzI2IDcyNiA3MjYgNzI2IDcyNiA3MjYgNTYxIDUwNiANNDM4 IDQzOCA0MzggNDM4IDQzOCA0MzggNjcxIDQzOCA0MzggNDM4IDQzOCA0MzggMjc0IDI3NCAy NzQgMjc0IA01MDYgNTA2IDUwNiA1MDYgNTA2IDUwNiA1MDYgNTQ3IDUwNiA1MDYgNTA2IDUw NiA1MDYgNTA2IDQ5MyA1MDYgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnRE ZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9iag03IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3Jp cHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4NL0ZsYWdzIDM0DS9Gb250QkJveCBbIC0y NTAgLTIxNiAxMTM0IDEwNDAgXQ0vTWlzc2luZ1dpZHRoIDM0Mg0vU3RlbVYgNzMNL1N0ZW1I IDczDS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgODkxDS9YSGVpZ2h0IDQ0Ng0vQXNjZW50 IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFkaW5nIDE0OQ0vTWF4V2lkdGggOTQ1DS9BdmdXaWR0 aCA0MDENPj4NZW5kb2JqDTI3IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVl VHlwZQ0vTmFtZSAvRjENL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGQNL0ZpcnN0Q2hh ciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTUgMzQwIDU1MyA1MTAgNTEwIDEwMjEg ODI5IDI3NiAzNDAgMzQwIDUxMCA1NzQgMjU1IDM0MCAyNTUgMjc2IA01MTAgNTEwIDUxMCA1 MTAgNTEwIDUxMCA1MTAgNTEwIDUxMCA1MTAgMzQwIDM0MCA1NzQgNTc0IDU3NCA1MTAgDTkz NiA3MjMgNjU5IDcyMyA3MjMgNjU5IDU5NSA3ODcgNzg3IDM4MyA1MTAgNzg3IDY1OSA5MzYg NzIzIDc4NyANNTk1IDc4NyA3MjMgNTUzIDY1OSA3MjMgNzIzIDEwMjEgNzIzIDcyMyA2NTkg MzQwIDI3NiAzNDAgNTc0IDUxMCANMzQwIDUxMCA1NTMgNDQ2IDU1MyA0NDYgMzQwIDUxMCA1 NTMgMjc2IDM0MCA1NzQgMjc2IDgyOSA1NTMgNTEwIA01NTMgNTUzIDQ0NiAzODMgMzQwIDU1 MyA0ODkgNzAyIDUxMCA0ODkgNDQ2IDQwNCAxOTEgNDA0IDUxMCA3ODcgDTc4NyA3ODcgNTc0 IDU3NCA1NzQgNTc0IDU3NCA1NzQgNTc0IDU3NCA1NzQgNTc0IDU3NCA3ODcgNzg3IDc4NyAN Nzg3IDU3NCA1NzQgNTc0IDU3NCA1NzQgNTc0IDU3NCA1NzQgNTc0IDU3NCA1NzQgNTc0IDc4 NyA3ODcgNTc0IA0yNTUgMzQwIDUxMCA1MTAgNTEwIDUxMCAxOTEgNTEwIDM2MSA3NDQgMjk3 IDUxMCA1NzQgMzQwIDc0NCA1MTAgDTQwNCA1NTMgMjk3IDI5NyAzNDAgNTc0IDUzMSAyNTUg MzQwIDI5NyAzNDAgNTEwIDc0NCA3NDQgNzQ0IDUxMCANNzIzIDcyMyA3MjMgNzIzIDcyMyA3 MjMgMTAwMCA3MjMgNjU5IDY1OSA2NTkgNjU5IDM4MyAzODMgMzgzIDM4MyANNzIzIDcyMyA3 ODcgNzg3IDc4NyA3ODcgNzg3IDU3NCA3ODcgNzIzIDcyMyA3MjMgNzIzIDcyMyA2MTcgNTUz IA01MTAgNTEwIDUxMCA1MTAgNTEwIDUxMCA3MjMgNDQ2IDQ0NiA0NDYgNDQ2IDQ0NiAyNzYg Mjc2IDI3NiAyNzYgDTUxMCA1NTMgNTEwIDUxMCA1MTAgNTEwIDUxMCA1NTMgNTEwIDU1MyA1 NTMgNTUzIDU1MyA1MTAgNTUzIDUxMCANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0v Rm9udERlc2NyaXB0b3IgMjggMCBSDT4+DWVuZG9iag0yOCAwIG9iag08PA0vVHlwZSAvRm9u dERlc2NyaXB0b3INL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuLEJvbGQNL0ZsYWdzIDE2NDE4 DS9Gb250QkJveCBbIC0yNTAgLTIxNiAxMjI1IDEwNDAgXQ0vTWlzc2luZ1dpZHRoIDM0MA0v U3RlbVYgMTM2DS9TdGVtSCAxMzYNL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA4OTENL1hI ZWlnaHQgNDQ2DS9Bc2NlbnQgODkxDS9EZXNjZW50IC0yMTYNL0xlYWRpbmcgMTQ5DS9NYXhX aWR0aCAxMDIxDS9BdmdXaWR0aCA0MjcNPj4NZW5kb2JqDTQ0IDAgb2JqDTw8DS9UeXBlIC9G b250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjINL0Jhc2VGb250IC9Db3VyaWVyTmV3 LEJvbGQNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg DTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANXQ0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZw0vRm9udERlc2NyaXB0b3IgNDUgMCBSDT4+DWVuZG9iag00NSAwIG9iag08 PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9Db3VyaWVyTmV3LEJvbGQNL0Zs YWdzIDE2NDE4DS9Gb250QkJveCBbIC0yNTAgLTMwMCA3MjcgMTAwMCBdDS9NaXNzaW5nV2lk dGggNjA2DS9TdGVtViAxOTENL1N0ZW1IIDE5MQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0 IDgzMw0vWEhlaWdodCA0MTcNL0FzY2VudCA4MzMNL0Rlc2NlbnQgLTMwMA0vTGVhZGluZyAx MzMNL01heFdpZHRoIDYwNg0vQXZnV2lkdGggNjAwDT4+DWVuZG9iag01MCAwIG9iag08PA0v VHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YzDS9CYXNlRm9udCAvQ291 cmllck5ldw0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANNjA2IDYwNiA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IA02MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYg NjA2IA02MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2 MDYgNjA2IDYwNiA2MDYgDTYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiANNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IA1dDS9FbmNvZGluZyAvV2lu QW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciA1MSAwIFINPj4NZW5kb2JqDTUxIDAgb2Jq DTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0NvdXJpZXJOZXcNL0ZsYWdz IDM0DS9Gb250QkJveCBbIC0yNTAgLTMwMCA3MjcgMTAwMCBdDS9NaXNzaW5nV2lkdGggNjA2 DS9TdGVtViAxMDkNL1N0ZW1IIDEwOQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDgzMw0v WEhlaWdodCA0MTcNL0FzY2VudCA4MzMNL0Rlc2NlbnQgLTMwMA0vTGVhZGluZyAxMzMNL01h eFdpZHRoIDYwNg0vQXZnV2lkdGggNjAwDT4+DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4 dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgMTAgMCBSIDEzIDAgUiAxNiAw IFIgMTkgMCBSIDIyIDAgUiBdDS9Db3VudCA2DS9UeXBlIC9QYWdlcw0vUGFyZW50IDYzIDAg Ug0+Pg1lbmRvYmoNMjYgMCBvYmoNPDwNL0tpZHMgWzI1IDAgUiAzMSAwIFIgMzQgMCBSIDM3 IDAgUiA0MCAwIFIgNDMgMCBSIF0NL0NvdW50IDYNL1R5cGUgL1BhZ2VzDS9QYXJlbnQgNjMg MCBSDT4+DWVuZG9iag00OSAwIG9iag08PA0vS2lkcyBbNDggMCBSIDU0IDAgUiA1NyAwIFIg NjAgMCBSIF0NL0NvdW50IDQNL1R5cGUgL1BhZ2VzDS9QYXJlbnQgNjMgMCBSDT4+DWVuZG9i ag02MyAwIG9iag08PA0vS2lkcyBbNSAwIFIgMjYgMCBSIDQ5IDAgUiBdDS9Db3VudCAxNg0v VHlwZSAvUGFnZXMNL01lZGlhQm94IFsgMCAwIDc5MiA2MTIgXQ0+Pg1lbmRvYmoNMSAwIG9i ag08PA0vQ3JlYXRvciAoKQ0vQ3JlYXRpb25EYXRlIChEOjE5OTgwMTI4MDg1NjMzKQ0vVGl0 bGUgKGlwcHByZXNvKQ0vQXV0aG9yIChqa20pDS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0 ZXIgMy4wMiBmb3IgV2luZG93cyBOVCkNL0tleXdvcmRzICgpDS9TdWJqZWN0ICgpDT4+DWVu ZG9iag0zIDAgb2JqDTw8DS9QYWdlcyA2MyAwIFINL1R5cGUgL0NhdGFsb2cNPj4NZW5kb2Jq DXhyZWYNMCA2NA0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMTc5MjIgMDAwMDAgbiANMDAw MDAxNzQ3NyAwMDAwMCBuIA0wMDAwMDE4MDk1IDAwMDAwIG4gDTAwMDAwMDA2MjggMDAwMDAg biANMDAwMDAxNzUwOCAwMDAwMCBuIA0wMDAwMDEyMDYyIDAwMDAwIG4gDTAwMDAwMTMxNDgg MDAwMDAgbiANMDAwMDAwMDAxOSAwMDAwMCBuIA0wMDAwMDAwNjA5IDAwMDAwIG4gDTAwMDAw MDEzOTIgMDAwMDAgbiANMDAwMDAwMDc0NiAwMDAwMCBuIA0wMDAwMDAxMzcyIDAwMDAwIG4g DTAwMDAwMDIwMjcgMDAwMDAgbiANMDAwMDAwMTUxMiAwMDAwMCBuIA0wMDAwMDAyMDA3IDAw MDAwIG4gDTAwMDAwMDI4NzUgMDAwMDAgbiANMDAwMDAwMjE0NyAwMDAwMCBuIA0wMDAwMDAy ODU1IDAwMDAwIG4gDTAwMDAwMDM3NTIgMDAwMDAgbiANMDAwMDAwMjk5NSAwMDAwMCBuIA0w MDAwMDAzNzMyIDAwMDAwIG4gDTAwMDAwMDQ2ODQgMDAwMDAgbiANMDAwMDAwMzg3MiAwMDAw MCBuIA0wMDAwMDA0NjY0IDAwMDAwIG4gDTAwMDAwMDUzOTIgMDAwMDAgbiANMDAwMDAxNzYx NiAwMDAwMCBuIA0wMDAwMDEzNDA4IDAwMDAwIG4gDTAwMDAwMTQ1MDQgMDAwMDAgbiANMDAw MDAwNDgwNCAwMDAwMCBuIA0wMDAwMDA1MzcyIDAwMDAwIG4gDTAwMDAwMDYwNjggMDAwMDAg biANMDAwMDAwNTUyNSAwMDAwMCBuIA0wMDAwMDA2MDQ4IDAwMDAwIG4gDTAwMDAwMDY3NjYg MDAwMDAgbiANMDAwMDAwNjE4OSAwMDAwMCBuIA0wMDAwMDA2NzQ2IDAwMDAwIG4gDTAwMDAw MDc1MzkgMDAwMDAgbiANMDAwMDAwNjg4NyAwMDAwMCBuIA0wMDAwMDA3NTE5IDAwMDAwIG4g DTAwMDAwMDg1MzUgMDAwMDAgbiANMDAwMDAwNzY2MCAwMDAwMCBuIA0wMDAwMDA4NTE1IDAw MDAwIG4gDTAwMDAwMDkwNzcgMDAwMDAgbiANMDAwMDAxNDc3NiAwMDAwMCBuIA0wMDAwMDE1 ODY2IDAwMDAwIG4gDTAwMDAwMDg2NTYgMDAwMDAgbiANMDAwMDAwOTA1NyAwMDAwMCBuIA0w MDAwMDA5NzExIDAwMDAwIG4gDTAwMDAwMTc3MjYgMDAwMDAgbiANMDAwMDAxNjEzMyAwMDAw MCBuIA0wMDAwMDE3MjE4IDAwMDAwIG4gDTAwMDAwMDkyMTAgMDAwMDAgbiANMDAwMDAwOTY5 MSAwMDAwMCBuIA0wMDAwMDEwNDYyIDAwMDAwIG4gDTAwMDAwMDk4NDQgMDAwMDAgbiANMDAw MDAxMDQ0MiAwMDAwMCBuIA0wMDAwMDExMTY1IDAwMDAwIG4gDTAwMDAwMTA1OTUgMDAwMDAg biANMDAwMDAxMTE0NSAwMDAwMCBuIA0wMDAwMDExOTQxIDAwMDAwIG4gDTAwMDAwMTEyODYg MDAwMDAgbiANMDAwMDAxMTkyMSAwMDAwMCBuIA0wMDAwMDE3ODIyIDAwMDAwIG4gDXRyYWls ZXINPDwNL1NpemUgNjQNL1Jvb3QgMyAwIFINL0luZm8gMSAwIFINL0lEIFs8ZTFjODRlZmJi OTkzODI0ZTExYjRkNGUzMWM5Yjg5YWE+PGUxYzg0ZWZiYjk5MzgyNGUxMWI0ZDRlMzFjOWI4 OWFhPl0NPj4Nc3RhcnR4cmVmDTE4MTQ1DSUlRU9GDQ== --------------10A7ED838CC9CC86AF125FB8-- From ipp-owner@pwg.org Wed Jan 28 09:47:42 1998 Delivery-Date: Wed, 28 Jan 1998 09:47:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA29240 for ; Wed, 28 Jan 1998 09:47:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA10814 for ; Wed, 28 Jan 1998 09:50:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA27948 for ; Wed, 28 Jan 1998 09:47:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 09:42:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA27401 for ipp-outgoing; Wed, 28 Jan 1998 09:27:37 -0500 (EST) Message-ID: <34CF4050.A2D28A70@underscore.com> Date: Wed, 28 Jan 1998 09:27:28 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: joshco@microsoft.com Subject: Re: IPP> ipppreso.ppt (EMBEDDED TEXT VERSION) References: <34CF3A83.B8C302A8@underscore.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ipp-owner@pwg.org Following is a hand-crafted version of Josh's PowerPoint presentation. Hopefully the translation was successful, but be forewarned. ;-) In the future, it would be best to stay in the all-text world if the information being conveyed is pure text, no? ...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 -- ---------------------------------------------------------------------- 1 - IPP Protocol Modifications * Use XML instead of binary protocol - why? - Mapping details - timing (1.0 or later) * Use different method than POST - why? - granularity 2 - Non POST - why * IETF Pressure * POST overload obscures action * Similar discussion in DAV * Firewall ACL control degrees * Fundamentally IPP doesn't care * Some installed base issues for implementers 3 - Non POST - what * One method "PRINT" * Per Operation - PRINT-JOB - CANCEL-JOB - LIST-JOBS * Others? 4 - External Survey * Do not overload POST - Netscape Proxy Server - Microsoft Proxy Server - Inktomi Proxy Server - Firewall Administrators * 5 out of 6 administrators queried * No objections to a new method, just two "indifference" 5 - XML - Why? * The coming wave for structured data - Tools are easily available and becoming more so * Advantages of original ASCII proposal without its disadvantages - Did not exist 9 months ago - Has solved and will solve issues we haven't even thought about yet - nested structure, arrays, etc 6 - XML - What * DTD? - Yes, for spec but not runtime validation * XSL? - No, not at this time * Attributes or Elements? - - 12 * Name Spaces - Outermost elements only 7 - XML What (cont) * Strong typing or weak typing - Bob's proposal (strong) - Paul/Josh (weak) * Payload (PDL) - multipart mime 8 - XML - When? * Version 1.0 - XML not ready, some of us are done - Creates legacy * Version 2.0 * Never * Our recommendation: do it now 9 - MS Proposal * PRINT Method * XML now * DTD for reference but no runtime validate * No XSL * Elements, no (XML) attributes * No strong typing * No name space 10 - XML Mapping * Request or response as outer element * operation qualifiers next level - version, option, state… * Job Object, Job Attributes as elements * Arrays (SetOf) as nested block - even for one occurrence 11 - IPP Type Mapping * Date, name, text, keyword, URI, urischeme, charset, naturallanguage & mime type as is * Integer, enum, bool, -> numeric string * range of -> structure with & * resolution -> structure with & * Some naming issues - Why don't all job attributes start "job" ? 12 - Example Request Print Job 1.0 My Print Job 1 CID:content-label 13 - Example "Get Jobs" Get-Jobs 1.0 jobCopies jobName 14 - "Get-Jobs" Response 200 GetJobs 1.0 1 Mom's Apple Pie recipe 2 Paul's guide to horseback riding 15 - Miscellaneous * No typing - typing adds no real value - simpler - IPP application must still validate its data * XML Schema to be in UTF-8 * Case Insensitive 16 - Conclusion * XML has gained momentum and is now a good choice for IPP * Using PRINT instead of POST allows a finer grain of control and expression in ACLs * "after session" BarBof whiteboard session to discuss minor issues of expression # # # # # From ipp-owner@pwg.org Wed Jan 28 10:40:57 1998 Delivery-Date: Wed, 28 Jan 1998 10:40:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA00869 for ; Wed, 28 Jan 1998 10:40:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA11034 for ; Wed, 28 Jan 1998 10:43:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA28608 for ; Wed, 28 Jan 1998 10:40:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 10:36:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA28058 for ipp-outgoing; Wed, 28 Jan 1998 10:20:54 -0500 (EST) From: Roger K Debry To: Subject: IPP> Microsoft Presentation Message-ID: <5030100016769319000002L092*@MHS> Date: Wed, 28 Jan 1998 10:20:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA00869 Well, many of you will not see this as you are sleeping in somplace in Maui. However, I want to respond to the Microsoft presentation with the IBM point of view so that it is clear going in to the meeting this afternoon. The Microsoft proposal addresses two issues: 1) Use a new method instead of POST 2) Use XML instead of the current protocol However, the major issue here is not, I believe, a technical one. It is a matter of timing, of process, and principle. Let me explain. A year ago as we started down the path of developing a new standard for printing on the Internet, we agreed to pursue that path which would allow us to deploy the standard as quickly as possible. This meant, for one thing, basing our work on existing, well established protocols, and products. We stopped dead in our tracks last spring to deal with Microsoft's SWP proposal and after much soul searching and negotiation, we reached a compromise that accomodated Microsoft's views and got the standard back on track. The Post vs. new method debate was not a Microsoft issue until just a few weeks ago. Nevertheless, We have argued the firewall and POST vs. new method over and over again, and our decisions to go with POST reviewed at every IETF meeting. Now here we are a month after the last call on the standard, with Microsoft once again asking us to stop and reset the standard. It is our belief that if we agree to this change, it will be at least 4-6 months before we are ready to do a last call again. This is evidenced by the many issues raised in Bob Herriot's fine analysis of mapping IPP to XML. This has some serious implications ... o Much of the prototyping work will have to be reset o The standard will be at least six months late in being approved o We lose credibility with the consultants and analysists we've talked to o We lose credibility with the IETF o We bind ourselves (I believe) too closely to one company's strategy and their view of how Browsers and the web play in the desktop. o We open the door for consideration of the NEXT cool technology to come along six months from now, or Microsoft's next O/S change. We can debate the technical issues ad nauseum (and probably will), but I believe we need to take a stand on what we have done and say "It is good enough". Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Jan 28 11:33:54 1998 Delivery-Date: Wed, 28 Jan 1998 11:33:56 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03203 for ; Wed, 28 Jan 1998 11:33:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA11290 for ; Wed, 28 Jan 1998 11:36:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA29255 for ; Wed, 28 Jan 1998 11:33:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 11:29:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28728 for ipp-outgoing; Wed, 28 Jan 1998 11:14:23 -0500 (EST) Message-ID: From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> Microsoft Presentation Date: Wed, 28 Jan 1998 11:11:56 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Gentlemen, I fully agree with Roger Debry's observations. The IPP started out with a very aggressive schedule, but did sacrifice that schedule to ensure that the approach was technically sound and that the concerns of all participants were heard. Indeed, the representatives of Microsoft were concerned with the delays that such considerations imposed. There is no compelling information in the new Microsoft presentation that suggests that the working group has not properly addressed its objectives and charter or that what has been developed will not work effectively. I would suggest that, looking from an embedded server point of view, which I believe will be the primary implementation mode, the proposed changes would complicate the implementation. I would also observe increasing apprehension that the IPP will get bogged down in standardsitis. I see the re-emergence of alternate internet printing schemes. Indeed, I now am starting to regret that I discouraged several such schemes. I think that this challenge to the IPP may delay the deployment to such an extent that it will be fatal. Enjoy Hawaii ! W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Roger K Debry [SMTP:rdebry@us.ibm.com] > Sent: Wednesday, January 28, 1998 10:21 AM > To: ipp@pwg.org > Subject: IPP> Microsoft Presentation > > > Well, many of you will not see this as you are sleeping in somplace in > Maui. > However, I want to respond to the Microsoft presentation with the IBM > point > of view so that it is clear going in to the meeting this afternoon. > > The Microsoft proposal addresses two issues: > > 1) Use a new method instead of POST > > 2) Use XML instead of the current protocol > > However, the major issue here is not, I believe, a technical one. > It is a matter of timing, of process, and principle. Let me explain. > > A year ago as we started down the path of developing a new > standard for printing on the Internet, we agreed to pursue that > path which would allow us to deploy the standard as quickly as > possible. This meant, for one thing, basing our work on existing, > well established protocols, and products. We stopped dead in our > tracks last spring to deal with Microsoft's SWP proposal and after > much soul searching and negotiation, we reached a compromise > that accomodated Microsoft's views and got the standard back on > track. The Post vs. new method debate was not a Microsoft issue > until just a few weeks ago. Nevertheless, We have argued the firewall > and POST vs. new method over and over again, and our decisions > to go with POST reviewed at every IETF meeting. > > Now here we are a month after the last call on the standard, with > Microsoft once again asking us to stop and reset the standard. > It is our belief that if we agree to this change, it will be at least > 4-6 > months before we are ready to do a last call again. This is evidenced > by the many issues raised in Bob Herriot's fine analysis of mapping > IPP to XML. This has some serious implications ... > > o Much of the prototyping work will have to be reset > o The standard will be at least six months late in being approved > o We lose credibility with the consultants and analysists we've talked > to > o We lose credibility with the IETF > o We bind ourselves (I believe) too closely to one company's > strategy and their view of how Browsers and the web play in the > desktop. > o We open the door for consideration of the NEXT cool technology to > come along six months from now, or Microsoft's next O/S change. > > We can debate the technical issues ad nauseum (and probably will), > but I believe we need to take a stand on what we have done and say > "It is good enough". > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Jan 28 13:09:43 1998 Delivery-Date: Wed, 28 Jan 1998 13:09:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA05652 for ; Wed, 28 Jan 1998 13:09:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11789 for ; Wed, 28 Jan 1998 13:12:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00029 for ; Wed, 28 Jan 1998 13:09:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 13:04:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29457 for ipp-outgoing; Wed, 28 Jan 1998 12:49:04 -0500 (EST) Date: Wed, 28 Jan 1998 09:54:09 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801281754.AA28277@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP> ipppreso.ppt (EMBEDDED TEXT VERSION) Cc: joshco@microsoft.com Sender: ipp-owner@pwg.org Hi Jay, Thanks, you saved me sending a low quality note to Josh about IETF working group rules. And now my two weeks of boning up on XML, XLL, XSL and various XML applications for this afternoon isn't wasted. Thanks very much, - Ira McDonald (High North, outside consultant at Xerox) From ipp-owner@pwg.org Wed Jan 28 23:43:22 1998 Delivery-Date: Wed, 28 Jan 1998 23:43:22 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA19198 for ; Wed, 28 Jan 1998 23:43:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA13771 for ; Wed, 28 Jan 1998 23:46:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA01612 for ; Wed, 28 Jan 1998 23:43:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 23:35:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA00557 for ipp-outgoing; Wed, 28 Jan 1998 23:06:50 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2014E547B@red-86-msg.dns.microsoft.com> From: Josh Cohen To: Jay Martin , ipp@pwg.org Subject: RE: IPP> ipppreso.ppt (EMBEDDED TEXT VERSION) Date: Wed, 28 Jan 1998 20:06:44 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org > -----Original Message----- > From: Jay Martin [mailto:jkm@underscore.com] > Sent: Wednesday, January 28, 1998 6:27 AM > To: ipp@pwg.org > Cc: Josh Cohen > Subject: Re: IPP> ipppreso.ppt (EMBEDDED TEXT VERSION) > > > Following is a hand-crafted version of Josh's PowerPoint presentation. > Hopefully the translation was successful, but be forewarned. ;-) > > In the future, it would be best to stay in the all-text world if > the information being conveyed is pure text, no? > I totally agree. I think that my message implied my recognition of that as well as apologies in advance. It is a worthy guideline to follow, but in this case, I was simply unable to follow it. Thank you for translating it. > ...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 -- > ---------------------------------------------------------------------- > > > 1 - IPP Protocol Modifications > * Use XML instead of binary protocol > - why? > - Mapping details > - timing (1.0 or later) > * Use different method than POST > - why? > - granularity > > 2 - Non POST - why > * IETF Pressure > * POST overload obscures action > * Similar discussion in DAV > * Firewall ACL control degrees > * Fundamentally IPP doesn't care > * Some installed base issues for implementers > > 3 - Non POST - what > * One method "PRINT" > * Per Operation > - PRINT-JOB > - CANCEL-JOB > - LIST-JOBS > * Others? > > 4 - External Survey > * Do not overload POST > - Netscape Proxy Server > - Microsoft Proxy Server > - Inktomi Proxy Server > - Firewall Administrators > * 5 out of 6 administrators queried > * No objections to a new method, just two "indifference" > > 5 - XML - Why? > * The coming wave for structured data > - Tools are easily available and becoming more so > * Advantages of original ASCII proposal without its disadvantages > - Did not exist 9 months ago > - Has solved and will solve issues we haven't even > thought about yet > - nested structure, arrays, etc > > 6 - XML - What > * DTD? > - Yes, for spec but not runtime validation > * XSL? > - No, not at this time > * Attributes or Elements? > - > - 12 > * Name Spaces > - Outermost elements only > > 7 - XML What (cont) > * Strong typing or weak typing > - Bob's proposal (strong) > - Paul/Josh (weak) > * Payload (PDL) > - multipart mime > > 8 - XML - When? > * Version 1.0 > - XML not ready, some of us are done > - Creates legacy > * Version 2.0 > * Never > * Our recommendation: do it now > > 9 - MS Proposal > * PRINT Method > * XML now > * DTD for reference but no runtime validate > * No XSL > * Elements, no (XML) attributes > * No strong typing > * No name space > > 10 - XML Mapping > * Request or response as outer element > * operation qualifiers next level > - version, option, state… > * Job Object, Job Attributes as elements > * Arrays (SetOf) as nested block - even for one occurrence > > 11 - IPP Type Mapping > * Date, name, text, keyword, URI, urischeme, charset, > naturallanguage & mime type as is > * Integer, enum, bool, -> numeric string > * range of -> structure with & > * resolution -> structure with & > * Some naming issues > - Why don't all job attributes start "job" ? > > 12 - Example Request > > > > Print Job > 1.0 > > My Print Job > 1 > CID:content-label > > > > 13 - Example "Get Jobs" > > > Get-Jobs > 1.0 > > jobCopies > jobName > > > > 14 - "Get-Jobs" Response > > > 200 > GetJobs > 1.0 > > 1 > Mom's Apple Pie recipe > > > 2 > Paul's guide to horseback riding > > > > 15 - Miscellaneous > * No typing > - typing adds no real value > - simpler > - IPP application must still validate its data > * XML Schema to be in UTF-8 > * Case Insensitive > > 16 - Conclusion > * XML has gained momentum and is now a good choice for IPP > * Using PRINT instead of POST allows a finer grain of control > and expression in ACLs > * "after session" BarBof whiteboard session to discuss minor > issues of expression > > > # # # # # > From ipp-owner@pwg.org Wed Jan 28 23:44:07 1998 Delivery-Date: Wed, 28 Jan 1998 23:44:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA19208 for ; Wed, 28 Jan 1998 23:44:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA13774 for ; Wed, 28 Jan 1998 23:46:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA01702 for ; Wed, 28 Jan 1998 23:44:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 28 Jan 1998 23:36:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA00546 for ipp-outgoing; Wed, 28 Jan 1998 23:06:13 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2014E5478@red-86-msg.dns.microsoft.com> From: Josh Cohen To: Roger K Debry , ipp@pwg.org Subject: RE: IPP> Microsoft Presentation Date: Wed, 28 Jan 1998 20:06:09 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I agree that the issues before us are more "process" than technical. > -----Original Message----- > From: Roger K Debry [mailto:rdebry@us.ibm.com] > Sent: Wednesday, January 28, 1998 7:21 AM > To: ipp@pwg.org > Subject: IPP> Microsoft Presentation > > > o Much of the prototyping work will have to be reset Granted, there is some work involved, however, we can cut out the more complicated binary parsing work and depend on XML parsing to simplify things. Keep in mind that as a guide, we are offering code. > o The standard will be at least six months late in being approved Maybe > o We lose credibility with the consultants and analysists > we've talked to > o We lose credibility with the IETF I totally disagree. You will gain credibility with the IETF. Your area director and other members of the community presently feel that the pwg has proceeded on its own and disregarded input given in the past. While we may be guilty of not pressing hard enough in the past, like everyone, we have limited resources. > o We bind ourselves (I believe) too closely to one company's > strategy and their view of how Browsers and the web play > in the desktop. We have not decided to make this "last minute" objection to make IPP fit into "our" model of the universe, as you imply. It was our standards group, (myself, yaron and others) who have pressed our printing group to reconsider. If there is anyone who is in danger of slipping a product or being pressured by business ship reasons to avoid a last minute change, it is us. > o We open the door for consideration of the NEXT cool technology to > come along six months from now, or Microsoft's next O/S change. Again, this has nothing to do with Microsoft's next OS world or the "next big thing". We are pursuing this because we really beleive it is the right thing to do. XML offers us a uniform way to model data in a portable manner. This functionality is something IPP needs. In the past, XML did not have the momentum it does now, and the IPP group rightfully decided to build its own way of doing that. I assert that the world around us has changed. While pwg invented a wheel to structure the data, the rest of the world really appears to be adopting XML as a standard way to do this. If we ignore that and say "well we already spent all this time building our own wheel", I fear that the world will be searching for a "more standard" or more interoperable (with other protocols) way of doing what IPP does. The worst case isnt slipping a few months. The worst case is that IPP is obsoleted the day it is released. That would truly make the work done on IPP a waste. > > We can debate the technical issues ad nauseum (and probably will), > but I believe we need to take a stand on what we have done and say > "It is good enough". "No, It isnt" :) > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > From ipp-owner@pwg.org Thu Jan 29 05:49:48 1998 Delivery-Date: Thu, 29 Jan 1998 05:49:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id FAA20937 for ; Thu, 29 Jan 1998 05:49:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA14170 for ; Thu, 29 Jan 1998 05:52:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA02957 for ; Thu, 29 Jan 1998 05:49:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 29 Jan 1998 05:44:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA02416 for ipp-outgoing; Thu, 29 Jan 1998 05:29:01 -0500 (EST) Message-Id: <3.0.1.32.19980129022412.010b8820@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 29 Jan 1998 02:24:12 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO Section 9.4 - Error in Print-URI Example Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Swen Johnson has noticed that the Print-URI Request example ends with the lines: 0x03 end-of-attributes end-of-attributes-tag %!PS... data instead of just: 0x03 end-of-attributes end-of-attributes-tag Tom >X-Sender: sjohnson@tralfaz >Date: Tue, 27 Jan 1998 18:37:36 -0800 >To: thastings@cp10.es.xerox.com >From: Swen Johnson >Subject: PRO Section 9.4 - Error in Print-URI Example >Cc: cmanros@cp10.es.xerox.com, xriley@cp10.es.xerox.com, > rick@cp10.es.xerox.com, sjohnson@cp10.es.xerox.com > >Tom, > >The last line of Section 9.6 - "Print-URI Request" shows document data >being sent with the request. > > >-- Swen > > > From ipp-owner@pwg.org Thu Jan 29 09:14:01 1998 Delivery-Date: Thu, 29 Jan 1998 09:14:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA22789 for ; Thu, 29 Jan 1998 09:14:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14518 for ; Thu, 29 Jan 1998 09:16:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA03740 for ; Thu, 29 Jan 1998 09:13:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 29 Jan 1998 09:03:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA03161 for ipp-outgoing; Thu, 29 Jan 1998 08:47:46 -0500 (EST) From: Roger K Debry To: Subject: RE: IPP> Microsoft Presentation Message-ID: <5030100016828802000002L022*@MHS> Date: Thu, 29 Jan 1998 08:47:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA22789 >While we may be guilty of not pressing >hard enough in the past, like everyone, >we have limited resources. I understand the resource issue, we all face the same problem. Unfortunately, you lose a lot of credibitlity with the IPP working group when the only time you show up at a meeting is to suggest a major change to the standard. From ipp-owner@pwg.org Thu Jan 29 22:03:44 1998 Delivery-Date: Thu, 29 Jan 1998 22:03:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA01427 for ; Thu, 29 Jan 1998 22:03:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA17312 for ; Thu, 29 Jan 1998 22:06:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA05215 for ; Thu, 29 Jan 1998 22:03:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 29 Jan 1998 21:58:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA04675 for ipp-outgoing; Thu, 29 Jan 1998 21:43:29 -0500 (EST) Message-Id: <3.0.1.32.19980129184030.00b37330@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 29 Jan 1998 18:40:30 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The PWG has just held a meeting on IPP. In that meeting which also had a phone conference, which together covered most of the active IPP participants, the subject of Paul Moore's and Josh Cohen's proposal to evaluate new alternatives for the protocol specification was discussed. Although the proposal found some support and to have some technical merit, it was clear that a considerable majority were not convinced that the solutions proposed would offer a better alternative to our current solution and preferred to go ahead with our current drafts without further delays. I therefore believe that we have enough consensus to proceed with our earlier plans to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards, and our remaining three drafts as Informational RFCs. I wish to see your reconfirmation of this consensus expressed on the IPP DL. I plan to send the drafts to the IESG next Friday on February 6th, 1998. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jan 29 23:46:49 1998 Delivery-Date: Thu, 29 Jan 1998 23:46:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08931 for ; Thu, 29 Jan 1998 23:46:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA17507 for ; Thu, 29 Jan 1998 23:49:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA06006 for ; Thu, 29 Jan 1998 23:46:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 29 Jan 1998 23:41:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA05396 for ipp-outgoing; Thu, 29 Jan 1998 23:26:04 -0500 (EST) From: "Rajesh Chawla" To: , "Carl-Uno Manros" Subject: Re: IPP> Consensus on sending our drafts to the IESG Date: Thu, 29 Jan 1998 23:21:48 -0500 Message-ID: <01bd2d36$94e28900$8dc245c6@rajesh.ari.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org >I therefore believe that we have enough consensus to proceed with our >earlier plans to send the IPP Model & Semantics and the Protocol >Specification drafts to the IESG with the recommendation as Proposed >Standards, and our remaining three drafts as Informational RFCs. > >I wish to see your reconfirmation of this consensus expressed on the IPP DL. I support the decision of sending the IPP Model & Semantics and the Protocol Specification drafts to the IESG. Regards, Rajesh ====================================================== Rajesh Chawla TR Computing Solutions (703) 787-2078 (Voice) 13622 Flintwood Place (703) 904-9689 (Fax) Herndon VA 20171 From ipp-owner@pwg.org Fri Jan 30 03:07:13 1998 Delivery-Date: Fri, 30 Jan 1998 03:07:13 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA09765 for ; Fri, 30 Jan 1998 03:07:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA17690 for ; Fri, 30 Jan 1998 03:09:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA07069 for ; Fri, 30 Jan 1998 03:07:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 03:03:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA06508 for ipp-outgoing; Fri, 30 Jan 1998 02:47:48 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> Consensus on sending our drafts to the IESG Message-ID: <5030300017340362000002L022*@MHS> Date: Fri, 30 Jan 1998 02:53:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id DAA09765 As requested, I reafirm my decision, as expressed at the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG without further delay. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri Jan 30 05:51:22 1998 Delivery-Date: Fri, 30 Jan 1998 05:51:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id FAA10450 for ; Fri, 30 Jan 1998 05:51:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA17899 for ; Fri, 30 Jan 1998 05:54:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA07788 for ; Fri, 30 Jan 1998 05:51:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 05:46:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA07236 for ipp-outgoing; Fri, 30 Jan 1998 05:31:14 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2015F1D79@red-86-msg.dns.microsoft.com> From: Josh Cohen To: Rajesh Chawla , ipp@pwg.org, Carl-Uno Manros Subject: RE: IPP> Consensus on sending our drafts to the IESG Date: Fri, 30 Jan 1998 02:31:02 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I do not agree that we have "consensus". To me, consensus means at least a majority in favor, and no "vehement" objections. I would go along with saying we have "rough consensus, with strong minority dissention". Carl, at the end of the debate, essentially a compromise was reached (at your suggestion), that this would be clearly indicated as we move forward to last call. I oppose last calling our current documents. However, we dont want to upset the process for no reason, so we agreed to go along with last call as long as the situation was correctly described as we move to last call. > -----Original Message----- > From: Rajesh Chawla [mailto:rajesh@trcs.com] > Sent: Thursday, January 29, 1998 8:22 PM > To: ipp@pwg.org; Carl-Uno Manros > Subject: Re: IPP> Consensus on sending our drafts to the IESG > > > >I therefore believe that we have enough consensus to proceed with our > >earlier plans to send the IPP Model & Semantics and the Protocol > >Specification drafts to the IESG with the recommendation as Proposed > >Standards, and our remaining three drafts as Informational RFCs. > > > >I wish to see your reconfirmation of this consensus > expressed on the IPP > DL. > > I support the decision of sending the IPP Model & Semantics > and the Protocol > Specification drafts to the IESG. > > Regards, > Rajesh > ====================================================== > Rajesh Chawla TR > Computing > Solutions > (703) 787-2078 (Voice) 13622 > Flintwood Place > (703) 904-9689 (Fax) > Herndon VA 20171 > > From ipp-owner@pwg.org Fri Jan 30 09:32:31 1998 Delivery-Date: Fri, 30 Jan 1998 09:32:31 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11548 for ; Fri, 30 Jan 1998 09:32:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA18282 for ; Fri, 30 Jan 1998 09:35:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA08869 for ; Fri, 30 Jan 1998 09:32:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 09:19:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA08080 for ipp-outgoing; Fri, 30 Jan 1998 08:57:12 -0500 (EST) From: Roger K Debry To: Subject: RE: IPP> Consensus on sending our drafts to the IESG Message-ID: <5030100016871244000002L042*@MHS> Date: Fri, 30 Jan 1998 08:56:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA11548 Based on the vote count, I strongly disagree with this! We have STRONG consensus, with a minority opinion. >I would go along with saying we have "rough consensus, with >strong minority dissention". From ipp-owner@pwg.org Fri Jan 30 09:35:25 1998 Delivery-Date: Fri, 30 Jan 1998 09:35:26 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11581 for ; Fri, 30 Jan 1998 09:35:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA18295 for ; Fri, 30 Jan 1998 09:38:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA09294 for ; Fri, 30 Jan 1998 09:35:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 09:30:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA08108 for ipp-outgoing; Fri, 30 Jan 1998 09:06:44 -0500 (EST) From: Keith Carter To: Subject: Re: IPP> Consensus on sending our drafts to the IESG Message-ID: <5040300011891391000002L012*@MHS> Date: Fri, 30 Jan 1998 09:04:24 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org As requested, I reafirm my decision, as expressed during the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards and the remaining three drafts as Informational RFCs without further delay. Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Jan 30 10:49:15 1998 Delivery-Date: Fri, 30 Jan 1998 10:49:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14273 for ; Fri, 30 Jan 1998 10:49:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA18704 for ; Fri, 30 Jan 1998 10:51:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10254 for ; Fri, 30 Jan 1998 10:49:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 10:40:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09409 for ipp-outgoing; Fri, 30 Jan 1998 10:12:30 -0500 (EST) Message-ID: <34D1ECF3.55A76666@underscore.com> Date: Fri, 30 Jan 1998 10:08:35 -0500 From: "Jeffrey D. Schnitzer" Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <3.0.1.32.19980129184030.00b37330@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The follow message from Roger Debry was misdirected to : Subject: Re: IPP> Consensus on sending our drafts to the IESG Date: Fri, 30 Jan 1998 09:00:23 -0500 From: Roger K Debry To: I agree with the majority here and believe that we should proceed with our plans to submit our work to the IESG as it stands. Roger K deBry Co-author of IPP Model and Semantics Document Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 Carl-Uno Manros wrote: > > The PWG has just held a meeting on IPP. In that meeting which also had a > phone conference, which together covered most of the active IPP > participants, the subject of Paul Moore's and Josh Cohen's proposal to > evaluate new alternatives for the protocol specification was discussed. > > Although the proposal found some support and to have some technical merit, > it was clear that a considerable majority were not convinced that the > solutions proposed would offer a better alternative to our current solution > and preferred to go ahead with our current drafts without further delays. > > I therefore believe that we have enough consensus to proceed with our > earlier plans to send the IPP Model & Semantics and the Protocol > Specification drafts to the IESG with the recommendation as Proposed > Standards, and our remaining three drafts as Informational RFCs. > > I wish to see your reconfirmation of this consensus expressed on the IPP DL. > > I plan to send the drafts to the IESG next Friday on February 6th, 1998. > > Regards, > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 30 10:55:33 1998 Delivery-Date: Fri, 30 Jan 1998 10:55:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14514 for ; Fri, 30 Jan 1998 10:55:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA18722 for ; Fri, 30 Jan 1998 10:58:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10672 for ; Fri, 30 Jan 1998 10:55:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 10:44:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09429 for ipp-outgoing; Fri, 30 Jan 1998 10:17:31 -0500 (EST) Content-return: allowed Date: Fri, 30 Jan 1998 07:10:35 PST From: "Caruso, Angelo " Subject: RE: IPP> Consensus on sending our drafts to the IESG To: "'Carl-Uno Manros'" , ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org Carl, Though I have been mostly silent over the last several months, I cast my vote in favor of submitting the current drafts to the IESG. Based on my understanding of the drafts, and the new proposal from Microsoft, I see no compelling technical reason why we should further delay IESG review of this work. Thanks, Angelo From ipp-owner@pwg.org Fri Jan 30 13:08:55 1998 Delivery-Date: Fri, 30 Jan 1998 13:08:55 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA17380 for ; Fri, 30 Jan 1998 13:08:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19317 for ; Fri, 30 Jan 1998 13:11:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11968 for ; Fri, 30 Jan 1998 13:08:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 12:49:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10764 for ipp-outgoing; Fri, 30 Jan 1998 11:02:31 -0500 (EST) From: Roger K Debry To: Subject: IPP> Vote on IESG last call submission Message-ID: <5030100016875747000002L072*@MHS> Date: Fri, 30 Jan 1998 11:01:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA17380 I vote that we proceed with our plans to submit the current Internet Drafts to the IESG, as planned. I see no compelling arguments to go with the Microsoft chnages. From ipp-owner@pwg.org Fri Jan 30 13:28:32 1998 Delivery-Date: Fri, 30 Jan 1998 13:28:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA17558 for ; Fri, 30 Jan 1998 13:28:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19406 for ; Fri, 30 Jan 1998 13:31:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13215 for ; Fri, 30 Jan 1998 13:28:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:07:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10839 for ipp-outgoing; Fri, 30 Jan 1998 11:21:36 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Consensus on sending our drafts to the IESG Message-ID: <5030100016876640000002L002*@MHS> Date: Fri, 30 Jan 1998 11:20:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA17558 As requested, I reafirm my decision, as expressed during the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards and the remaining three drafts as Informational RFCs without further delay. Carl Kugler - IBM Printing Systems From ipp-owner@pwg.org Fri Jan 30 13:36:36 1998 Delivery-Date: Fri, 30 Jan 1998 13:36:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA17617 for ; Fri, 30 Jan 1998 13:36:36 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19449 for ; Fri, 30 Jan 1998 13:39:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13810 for ; Fri, 30 Jan 1998 13:36:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:16:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11006 for ipp-outgoing; Fri, 30 Jan 1998 11:46:19 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 30 Jan 1998 09:44:41 -0700 From: "Scott Isaacson" To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA17617 I was unable to participate in the last few minutes of the telephone conference that was held on 1/28, but I was pleased to hear that we have clear consensus "to proceed with our earlier plans to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards, and our remaining three drafts as Informational RFCs." I fully endorse the position that we should proceed with forwarding these docs to the IESG for finall call and comment as they stand. In reviewing rfc2026 on the Internet Standards Process BCP, I get the impression that the goal is to be fair in balancing technical excellence with consensus. In this IPP WG case, there has been no compelling evidence that the current IPP I-Ds are lacking in technical excellence. However, I do feel that claims that a single voice if shouted loudly enough indicates a lack of consensus to be disruptive to the standards process. I believe that we have strong consensus. Period. I have been involved in this WG since late 1996. I am the editor and principal author of the Model and Semantics document. I have contributed to all of the other IPP I-Ds. I have seen proprosals raised, debated, modified, reworked, reviewed, analyzed, and finally embraced. I have seen a lot of give and take. I have seen WG meetings at the IETF where IETF attendees outside the WG have come and participated and provided feedback and opinion. I have seen the process work. In this latest case of "vehement opposition" I have not seen a lot of cooperation and give and take. Scott Isaacson ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Carl-Uno Manros 01/29 7:40 PM >>> The PWG has just held a meeting on IPP. In that meeting which also had a phone conference, which together covered most of the active IPP participants, the subject of Paul Moore's and Josh Cohen's proposal to evaluate new alternatives for the protocol specification was discussed. Although the proposal found some support and to have some technical merit, it was clear that a considerable majority were not convinced that the solutions proposed would offer a better alternative to our current solution and preferred to go ahead with our current drafts without further delays. I therefore believe that we have enough consensus to proceed with our earlier plans to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards, and our remaining three drafts as Informational RFCs. I wish to see your reconfirmation of this consensus expressed on the IPP DL. I plan to send the drafts to the IESG next Friday on February 6th, 1998. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 30 13:38:05 1998 Delivery-Date: Fri, 30 Jan 1998 13:38:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA17629 for ; Fri, 30 Jan 1998 13:38:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19464 for ; Fri, 30 Jan 1998 13:40:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13906 for ; Fri, 30 Jan 1998 13:37:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:18:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA11100 for ipp-outgoing; Fri, 30 Jan 1998 12:05:42 -0500 (EST) From: don@lexmark.com Message-Id: <199801301704.AA18442@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 30 Jan 1998 11:58:27 -0500 Subject: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I reaffirm my position that we send the existing documents to the IESG as is for last call. The XML proposal while technically interesting does not provide additional functionality. Because the current state of XML does not provide all the structured data types we need adoption could therefore lead to a divergence between an IPP XML implementation and the main XML efforts. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 01/30/98 11:55 AM --------------------------- From: cmanros%cp10.es.xerox.com@interlock.lexmark.com on 01/29/98 06:40 PM PST To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> Consensus on sending our drafts to the IESG The PWG has just held a meeting on IPP. In that meeting which also had a phone conference, which together covered most of the active IPP participants, the subject of Paul Moore's and Josh Cohen's proposal to evaluate new alternatives for the protocol specification was discussed. Although the proposal found some support and to have some technical merit, it was clear that a considerable majority were not convinced that the solutions proposed would offer a better alternative to our current solution and preferred to go ahead with our current drafts without further delays. I therefore believe that we have enough consensus to proceed with our earlier plans to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards, and our remaining three drafts as Informational RFCs. I wish to see your reconfirmation of this consensus expressed on the IPP DL. I plan to send the drafts to the IESG next Friday on February 6th, 1998. Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jan 30 14:06:56 1998 Delivery-Date: Fri, 30 Jan 1998 14:06:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17873 for ; Fri, 30 Jan 1998 14:06:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19589 for ; Fri, 30 Jan 1998 14:09:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15874 for ; Fri, 30 Jan 1998 14:06:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:51:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10450 for ipp-outgoing; Fri, 30 Jan 1998 10:51:06 -0500 (EST) Mime-Version: 1.0 Date: Fri, 30 Jan 1998 10:57:18 -0500 Message-ID: <0003C8FD.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: IPP> XML et al 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 vote for going with the existing specs, and to submit them to the IESG immediately. XML may well have its merits, but there is a process that we have followed towards the current protocol mapping. Although the current mapping may not be the best of all possible worlds, it is good enough. And, there is no telling what new schemes will be proposed six months from now, and six months after that ... Philip Thambidurai Okidata From ipp-owner@pwg.org Fri Jan 30 14:09:52 1998 Delivery-Date: Fri, 30 Jan 1998 14:09:53 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17893 for ; Fri, 30 Jan 1998 14:09:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19598 for ; Fri, 30 Jan 1998 14:12:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16227 for ; Fri, 30 Jan 1998 14:09:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:54:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10659 for ipp-outgoing; Fri, 30 Jan 1998 10:55:13 -0500 (EST) From: Steve Gebert To: Message-ID: <5030100016875374000002L042*@MHS> Date: Fri, 30 Jan 1998 10:54:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA17893 This is confirmation of my opinion expressed during the Maui meeting. I believe we should submit our work as it stands without further delay. Steve Gebert From ipp-owner@pwg.org Fri Jan 30 14:10:15 1998 Delivery-Date: Fri, 30 Jan 1998 14:10:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17902 for ; Fri, 30 Jan 1998 14:10:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19601 for ; Fri, 30 Jan 1998 14:12:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16289 for ; Fri, 30 Jan 1998 14:10:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:55:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10022 for ipp-outgoing; Fri, 30 Jan 1998 10:46:38 -0500 (EST) Message-ID: <34D1F5D1.14A17701@underscore.com> Date: Fri, 30 Jan 1998 10:46:25 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <5030300017340362000002L022*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry Lewis wrote: > As requested, I reafirm my decision, as expressed at the meeting in Maui, > to send the IPP Model & Semantics and the Protocol Specification drafts > to the IESG without further delay. Ditto for me, too. It's really a shame XML wasn't available earlier. It certainly has some merit. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Jan 30 14:11:52 1998 Delivery-Date: Fri, 30 Jan 1998 14:11:52 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17917 for ; Fri, 30 Jan 1998 14:11:51 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19604 for ; Fri, 30 Jan 1998 14:14:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16533 for ; Fri, 30 Jan 1998 14:11:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 13:57:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA10781 for ipp-outgoing; Fri, 30 Jan 1998 11:05:30 -0500 (EST) Message-ID: <34D1FA2C.83FE5CA1@underscore.com> Date: Fri, 30 Jan 1998 11:05:00 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Roger K Debry , Josh Cohen Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <5030100016871244000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger K Debry wrote: > Based on the vote count, I strongly disagree with this! We have STRONG > consensus, with a minority opinion. > > >I would go along with saying we have "rough consensus, with > >strong minority dissention". For the benefit of those not at the Maui meeting (nor dialed into the telecon), after a couple of XML presentations and discussions a vote was taken. In fact, TWO votes were taken: one based on "personal" (ie, one vote per person), and one for "company" (one vote per represented company). The results were: Personal: Send current draft to IESG: 20 (77%) Delay sending the current draft: 6 (13%) Company: Send current draft to IESG: 11 (78%) Delay sending the current draft: 3 (12%) As a result, Carl-Uno Manros declared that the IPP WG had "rough consensus" in favor of sending the current draft as-is to the IESG. Afterwards, Josh Cohen (Microsoft) raised significant objections to the use of the term "rough consensus"; he later echoed those comments on this DL: > I do not agree that we have "consensus". > To me, consensus means at least a majority in favor, > and no "vehement" objections. > I would go along with saying we have "rough consensus, with > strong minority dissention". Josh does seem to raise a good point that needs to be well understood by the PWG in the future, namely, exactly what does "rough consensus" mean? Is it purely subjective (based on the WG chairperson's perogative)? Or can it be objective (based on numerical analysis)? Perhaps our AD's can provide some brief insight on this topic, just so we don't get into this kind of problem in the future. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Jan 30 15:07:05 1998 Delivery-Date: Fri, 30 Jan 1998 15:07:05 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA18410 for ; Fri, 30 Jan 1998 15:07:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19827 for ; Fri, 30 Jan 1998 15:09:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA17576 for ; Fri, 30 Jan 1998 15:06:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 14:57:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16763 for ipp-outgoing; Fri, 30 Jan 1998 14:37:47 -0500 (EST) From: lpyoung@lexmark.com Message-Id: <199801301937.AA26907@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 30 Jan 1998 14:37:26 -0500 Subject: Re: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org After reviewing the XML proposal and reading the e-mail discussion, my belief is that the best route for the IPP working group is to submit the current internet drafts to the IESG for consideration as Proposed Standard. Lloyd ------------------------------------------------------------ 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 From ipp-owner@pwg.org Fri Jan 30 15:17:37 1998 Delivery-Date: Fri, 30 Jan 1998 15:17:37 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA18515 for ; Fri, 30 Jan 1998 15:17:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19890 for ; Fri, 30 Jan 1998 15:20:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA18204 for ; Fri, 30 Jan 1998 15:17:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 15:13:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16857 for ipp-outgoing; Fri, 30 Jan 1998 14:50:16 -0500 (EST) Message-ID: <34D22C9E.41586DF@us.ibm.com> Date: Fri, 30 Jan 1998 12:40:14 -0700 From: Carl Kugler X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> TES - sharing binary IPP trace files Content-Type: multipart/mixed; boundary="------------18DCE6EA6C6E08C09D15CCAD" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------18DCE6EA6C6E08C09D15CCAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Regarding the trace repository at ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces (described at http://www.pwg.org/hypermail/ipp/2911.html): These files: ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012A00.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00012B00.trc should be demoted; they are based on an obsolete version of the protocol. I'm sending Pete 4 new files to replace them: 00022A00.trc 00022A00.txt 00022B00.trc 00022B00.txt 00022A00.txt and 00022B00.txt are attached. We believe these to be compliant with the current version of the IPP specs, with no privacy or authentication applied. The .trc files are suitable for use with a driver like the one described in http://www.pwg.org/hypermail/ipp/3120.html -Carl Kugler --------------18DCE6EA6C6E08C09D15CCAD Content-Type: text/plain; charset=us-ascii; name="00022A00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="00022A00.txt" // a. the person posting the trace file: Carl Kugler // b. contact information for that person : kugler@us.ibm.com // c. the unique sequence number for the conversation (SSSS): 0002 // d. the name of the operation (O): PrintJob // d. whether it is a request or a response (R): request // e. the file name of the file: 00022A00 // f. the date: January 30, 1998 // g. a comment about the intent of the operation request or response: // print job submission // major-version-number: 0x01 minor-version-number: 0x00 PrintJob operation-id: 0x0002 request-id: 0x00000001 operation-attributes-tag: 0x01 value-tag: 0x47 name-length: 0x0012 name: attributes-charset value length: 0x0008 value: US-ASCII value-tag: 0x48 name-length: 0x001b name: attributes-natural-language value length: 0x0005 value: en-US value-tag: 0x42 name-length: 0x0008 name: job-name value length: 0x0004 value: job1 value-tag: 0x22 name-length: 0x0016 name: ipp-attribute-fidelity value length: 0x0001 value: 0x00 value-tag: 0x42 name-length: 0x0014 name: requesting-user-name value length: 0x0005 value: steve value-tag: 0x42 name-length: 0x000d name: document-name value length: 0x0009 value: document1 job-attributes-tag: 0x02 value-tag: 0x21 name-length: 0x0006 name: copies value length: 0x0004 value: 0x00000001 value-tag: 0x21 name-length: 0x000c name: job-priority value length: 0x0004 value: 0x00000001 end-of-attributes-tag: 0x03 // document data follows --------------18DCE6EA6C6E08C09D15CCAD Content-Type: text/plain; charset=us-ascii; name="00022B00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="00022B00.txt" // a. the person posting the trace file: Carl Kugler // b. contact information for that person : kugler@us.ibm.com // c. the unique sequence number for the conversation (SSSS): 0002 // d. the name of the operation (O): PrintJob // d. whether it is a request or a response (R): response // e. the file name of the file: 00022B00 // f. the date: January 30, 1998 // g. a comment about the intent of the operation request or response: // print job submission // major-version-number: 0x01 minor-version-number: 0x00 status-code: 0x0000 request-id: 0x00000001 operation-attributes-tag: 0x01 value-tag: 0x42 name-length: 0x000b name: status-code value length: 0x0006 value: good 2 value-tag: 0x42 name-length: 0x000b name: status-code value length: 0x0006 value: good 2 job-attributes-tag: 0x02 value-tag: 0x42 name-length: 0x0008 name: job-name value length: 0x0004 value: Job1 value-tag: 0x42 name-length: 0x0009 name: job-state value length: 0x0009 value: Job1 Job2 value-tag: 0x42 name-length: 0x0009 name: job-state value length: 0x0009 value: Job1 Job2 value-tag: 0x42 name-length: 0x0011 name: job-state-reasons value length: 0x0004 value: Job1 value-tag: 0x42 name-length: 0x0011 name: job-state-message value length: 0x0004 value: YO 2 value-tag: 0x42 name-length: 0x0011 name: job-state-message value length: 0x0004 value: YO 2 unsupported-attributes-tag: 0x05 value-tag: 0x41 name-length: 0x0005 name: sides value length: 0x000b value: unsupported end-of-attributes-tag: 0x03 --------------18DCE6EA6C6E08C09D15CCAD-- From ipp-owner@pwg.org Fri Jan 30 16:46:33 1998 Delivery-Date: Fri, 30 Jan 1998 16:46:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA19239 for ; Fri, 30 Jan 1998 16:46:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20395 for ; Fri, 30 Jan 1998 16:49:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA19314 for ; Fri, 30 Jan 1998 16:44:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 16:34:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18452 for ipp-outgoing; Fri, 30 Jan 1998 16:07:19 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TES - sharing binary IPP trace files Message-ID: <5030100016889126000002L062*@MHS> Date: Fri, 30 Jan 1998 16:06:39 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100016889126" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100016889126 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another "conversation". Binaries to be uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces = --Boundary=_0.0_=5030100016889126 Content-Type: application/octet-stream; name=00034B00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwMw0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IFZhbGlk YXRlSm9iDQovLyBkLiB3aGV0aGVyIGl0IGlzIGEgcmVxdWVzdCBvciBhIHJlc3BvbnNlIChSKTog cmVzcG9uc2UNCi8vIGUuIHRoZSBmaWxlIG5hbWUgb2YgdGhlIGZpbGU6IDAwMDIyQjAwDQovLyBm LiB0aGUgZGF0ZTogIEphbnVhcnkgMzAsIDE5OTgNCi8vIGcuIGEgY29tbWVudCBhYm91dCB0aGUg aW50ZW50IG9mIHRoZSBvcGVyYXRpb24gcmVxdWVzdCBvciByZXNwb25zZToNCi8vICAgIHZhbGlk YXRlIGpvYiByZXNwb25zZTsgbm8gc2VjdXJpdHkNCi8vIA0KSVBQRGF0YU91dHB1dFN0cmVhbTog IG1ham9yLXZlcnNpb24tbnVtYmVyOiAgICAgMHgwMQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG1p bm9yLXZlcnNpb24tbnVtYmVyOiAgICAgMHgwMA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHN0YXR1 cy1jb2RlOiAgICAgIDB4MDAwMA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHJlcXVlc3QtaWQ6ICAg ICAgIDB4MDAwMDAwMDENCklQUERhdGFPdXRwdXRTdHJlYW06ICBvcGVyYXRpb24tYXR0cmlidXRl cy10YWc6IDB4MDENCklQUERhdGFPdXRwdXRTdHJlYW06ICB2YWx1ZS10YWc6ICAgICAgICAweDQy DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFtZS1sZW5ndGg6ICAgICAgMHgwMDEzDQpJUFBEYXRh T3V0cHV0U3RyZWFtOiAgbmFtZTogICAgIHN0YXR1cy1jb2RlLW1lc3NhZ2UNCklQUERhdGFPdXRw dXRTdHJlYW06ICB2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDQNCklQUERhdGFPdXRwdXRTdHJlYW06 ICB2YWx1ZTogICAgZ29vZA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHVuc3VwcG9ydGVkLWF0dHJp YnV0ZXMtdGFnOiAgICAgICAweDA1DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUtdGFnOiAg ICAgICAgMHg0MQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWUtbGVuZ3RoOiAgICAgIDB4MDAw NQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWU6ICAgICBzaWRlcw0KSVBQRGF0YU91dHB1dFN0 cmVhbTogIHZhbHVlIGxlbmd0aDogICAgIDB4MDAwYg0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHZh bHVlOiAgICB1bnN1cHBvcnRlZA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIGVuZC1vZi1hdHRyaWJ1 dGVzLXRhZzogICAgMHgwMw0K --Boundary=_0.0_=5030100016889126 Content-Type: application/octet-stream; name=00034A00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwMw0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IFZhbGlk YXRlSm9iDQovLyBkLiB3aGV0aGVyIGl0IGlzIGEgcmVxdWVzdCBvciBhIHJlc3BvbnNlIChSKTog cmVxdWVzdA0KLy8gZS4gdGhlIGZpbGUgbmFtZSBvZiB0aGUgZmlsZTogMDAwMzRBMDANCi8vIGYu IHRoZSBkYXRlOiAgSmFudWFyeSAzMCwgMTk5OA0KLy8gZy4gYSBjb21tZW50IGFib3V0IHRoZSBp bnRlbnQgb2YgdGhlIG9wZXJhdGlvbiByZXF1ZXN0IG9yIHJlc3BvbnNlOg0KLy8gICAgcHJpbnQg am9iIHZhbGlkYXRpb247IG5vIHNlY3VyaXR5DQovLyANCklQUERhdGFPdXRwdXRTdHJlYW06ICBt YWpvci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDENCklQUERhdGFPdXRwdXRTdHJlYW06ICBtaW5v ci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDANCklQUERhdGFPdXRwdXRTdHJlYW06ICBWYWxpZGF0 ZUpvYiBvcGVyYXRpb24taWQ6IDB4MDAwNA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHJlcXVlc3Qt aWQ6ICAgICAgIDB4MDAwMDAwMDENCklQUERhdGFPdXRwdXRTdHJlYW06ICBvcGVyYXRpb24tYXR0 cmlidXRlcy10YWc6IDB4MDENCklQUERhdGFPdXRwdXRTdHJlYW06ICB2YWx1ZS10YWc6ICAgICAg ICAweDQ3DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFtZS1sZW5ndGg6ICAgICAgMHgwMDEyDQpJ UFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFtZTogICAgIGF0dHJpYnV0ZXMtY2hhcnNldA0KSVBQRGF0 YU91dHB1dFN0cmVhbTogIHZhbHVlIGxlbmd0aDogICAgIDB4MDAwOA0KSVBQRGF0YU91dHB1dFN0 cmVhbTogIHZhbHVlOiAgICBVUy1BU0NJSQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHZhbHVlLXRh ZzogICAgICAgIDB4NDgNCklQUERhdGFPdXRwdXRTdHJlYW06ICBuYW1lLWxlbmd0aDogICAgICAw eDAwMWINCklQUERhdGFPdXRwdXRTdHJlYW06ICBuYW1lOiAgICAgYXR0cmlidXRlcy1uYXR1cmFs LWxhbmd1YWdlDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDA1 DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWU6ICAgIGVuLVVTDQpJUFBEYXRhT3V0cHV0U3Ry ZWFtOiAgdmFsdWUtdGFnOiAgICAgICAgMHg0Mg0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWUt bGVuZ3RoOiAgICAgIDB4MDAwOA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWU6ICAgICBqb2It bmFtZQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHZhbHVlIGxlbmd0aDogICAgIDB4MDAwNA0KSVBQ RGF0YU91dHB1dFN0cmVhbTogIHZhbHVlOiAgICBqb2IxDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAg dmFsdWUtdGFnOiAgICAgICAgMHgyMg0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWUtbGVuZ3Ro OiAgICAgIDB4MDAxNg0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWU6ICAgICBpcHAtYXR0cmli dXRlLWZpZGVsaXR5DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUgbGVuZ3RoOiAgICAgMHgw MDAxDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWU6ICAgIDB4MDANCklQUERhdGFPdXRwdXRT dHJlYW06ICB2YWx1ZS10YWc6ICAgICAgICAweDQyDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFt ZS1sZW5ndGg6ICAgICAgMHgwMDE0DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFtZTogICAgIHJl cXVlc3RpbmctdXNlci1uYW1lDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUgbGVuZ3RoOiAg ICAgMHgwMDA1DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWU6ICAgIHN0ZXZlDQpJUFBEYXRh T3V0cHV0U3RyZWFtOiAgdmFsdWUtdGFnOiAgICAgICAgMHg0Mg0KSVBQRGF0YU91dHB1dFN0cmVh bTogIG5hbWUtbGVuZ3RoOiAgICAgIDB4MDAwZA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIG5hbWU6 ICAgICBkb2N1bWVudC1uYW1lDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUgbGVuZ3RoOiAg ICAgMHgwMDA5DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWU6ICAgIGRvY3VtZW50MQ0KSVBQ RGF0YU91dHB1dFN0cmVhbTogIGpvYi1hdHRyaWJ1dGVzLXRhZzogICAgICAgMHgwMg0KSVBQRGF0 YU91dHB1dFN0cmVhbTogIHZhbHVlLXRhZzogICAgICAgIDB4MjENCklQUERhdGFPdXRwdXRTdHJl YW06ICBuYW1lLWxlbmd0aDogICAgICAweDAwMDYNCklQUERhdGFPdXRwdXRTdHJlYW06ICBuYW1l OiAgICAgY29waWVzDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWUgbGVuZ3RoOiAgICAgMHgw MDA0DQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgdmFsdWU6ICAgIDB4MDAwMDAwMDENCklQUERhdGFP dXRwdXRTdHJlYW06ICB2YWx1ZS10YWc6ICAgICAgICAweDIxDQpJUFBEYXRhT3V0cHV0U3RyZWFt OiAgbmFtZS1sZW5ndGg6ICAgICAgMHgwMDBjDQpJUFBEYXRhT3V0cHV0U3RyZWFtOiAgbmFtZTog ICAgIGpvYi1wcmlvcml0eQ0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHZhbHVlIGxlbmd0aDogICAg IDB4MDAwNA0KSVBQRGF0YU91dHB1dFN0cmVhbTogIHZhbHVlOiAgICAweDAwMDAwMDAxDQpJUFBE YXRhT3V0cHV0U3RyZWFtOiAgZW5kLW9mLWF0dHJpYnV0ZXMtdGFnOiAgICAweDAzDQo= --Boundary=_0.0_=5030100016889126-- From ipp-owner@pwg.org Fri Jan 30 16:49:13 1998 Delivery-Date: Fri, 30 Jan 1998 16:49:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA19316 for ; Fri, 30 Jan 1998 16:49:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20437 for ; Fri, 30 Jan 1998 16:51:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA19668 for ; Fri, 30 Jan 1998 16:49:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 16:40:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18472 for ipp-outgoing; Fri, 30 Jan 1998 16:12:29 -0500 (EST) Mime-Version: 1.0 Date: Fri, 30 Jan 1998 16:10:57 -0500 Message-ID: <4D2416A1.@xionics.com> From: RMcComiskie@xionics.com (Robert McComiskie) Subject: Re: IPP> Consensus on sending our drafts to the IESG 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 submit the drafts to the IESG. The world is waiting. Bob. ********************************************************************* ** Bob McComiskie Voice: 781-229-7021 ** ** Product Line Manager Fax: 781-229-7119 ** ** Xionics Document Technologies, Inc ** ** 70 Blanchard Road rmccomiskie@xionics.com ** ** Burlington, MA 01803 USA http://www.xionics.com ** ********************************************************************* From ipp-owner@pwg.org Fri Jan 30 17:19:34 1998 Delivery-Date: Fri, 30 Jan 1998 17:19:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19909 for ; Fri, 30 Jan 1998 17:19:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA20570 for ; Fri, 30 Jan 1998 17:22:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA20388 for ; Fri, 30 Jan 1998 17:19:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 17:07:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19012 for ipp-outgoing; Fri, 30 Jan 1998 16:41:35 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TES - sharing binary IPP trace files Message-ID: <5030100016890547000002L072*@MHS> Date: Fri, 30 Jan 1998 16:40:47 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100016890547" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100016890547 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another "conversation". Binaries to be uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces = --Boundary=_0.0_=5030100016890547 Content-Type: application/octet-stream; name=0004AB00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNA0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldEpv YnMNCi8vIGQuIHdoZXRoZXIgaXQgaXMgYSByZXF1ZXN0IG9yIGEgcmVzcG9uc2UgKFIpOiByZXNw b25zZQ0KLy8gZS4gdGhlIGZpbGUgbmFtZSBvZiB0aGUgZmlsZTogMDAwNEFCMDANCi8vIGYuIHRo ZSBkYXRlOiAgSmFudWFyeSAzMCwgMTk5OA0KLy8gZy4gYSBjb21tZW50IGFib3V0IHRoZSBpbnRl bnQgb2YgdGhlIG9wZXJhdGlvbiByZXF1ZXN0IG9yIHJlc3BvbnNlOg0KLy8gICAgUmVzcG9uc2Ug dG8gR2V0Sm9iczsgbm8gc2VjdXJpdHkNCi8vIA0KbWFqb3ItdmVyc2lvbi1udW1iZXI6ICAgICAw eDAxDQptaW5vci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDANCnN0YXR1cy1jb2RlOiAgICAgIDB4 MDAwMA0KcmVxdWVzdC1pZDogICAgICAgMHgwMDAwMDAwMQ0Kb3BlcmF0aW9uLWF0dHJpYnV0ZXMt dGFnOiAweDAxDQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAw MTINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLWNoYXJzZXQNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAw Mg0KdmFsdWU6ICAgIHlvDQpqb2ItYXR0cmlidXRlcy10YWc6ICAgICAgIDB4MDINCnZhbHVlLXRh ZzogICAgICAgIDB4MjENCm5hbWUtbGVuZ3RoOiAgICAgIDB4MDAwNg0KbmFtZTogICAgIGpvYi1p ZA0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDA0DQp2YWx1ZTogICAgMHgwMDAwMDAwMQ0KdmFsdWUt dGFnOiAgICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA3DQpuYW1lOiAgICAgam9i LXVyaQ0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDIzDQp2YWx1ZTogICAgbG9jYWxob3N0L3NlcnZs ZXQvSVBQU2VydmxldC9qb2JzLzENCmpvYi1hdHRyaWJ1dGVzLXRhZzogICAgICAgMHgwMg0KdmFs dWUtdGFnOiAgICAgICAgMHgyMQ0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA2DQpuYW1lOiAgICAg am9iLWlkDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDQNCnZhbHVlOiAgICAweDAwMDAwMDAyDQp2 YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAwMDcNCm5hbWU6ICAg ICBqb2ItdXJpDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMjMNCnZhbHVlOiAgICBsb2NhbGhvc3Qv c2VydmxldC9JUFBTZXJ2bGV0L2pvYnMvMg0KZW5kLW9mLWF0dHJpYnV0ZXMtdGFnOiAgICAweDAz DQo= --Boundary=_0.0_=5030100016890547 Content-Type: application/octet-stream; name=0004AA00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNA0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldEpv YnMNCi8vIGQuIHdoZXRoZXIgaXQgaXMgYSByZXF1ZXN0IG9yIGEgcmVzcG9uc2UgKFIpOiByZXF1 ZXN0DQovLyBlLiB0aGUgZmlsZSBuYW1lIG9mIHRoZSBmaWxlOiAwMDA0QUEwMA0KLy8gZi4gdGhl IGRhdGU6ICBKYW51YXJ5IDMwLCAxOTk4DQovLyBnLiBhIGNvbW1lbnQgYWJvdXQgdGhlIGludGVu dCBvZiB0aGUgb3BlcmF0aW9uIHJlcXVlc3Qgb3IgcmVzcG9uc2U6DQovLyAgICBHZXRKb2JzIHJl cXVlc3Q7IG5vIHNlY3VyaXR5DQovLyANCm1ham9yLXZlcnNpb24tbnVtYmVyOiAgICAgMHgwMQ0K bWlub3ItdmVyc2lvbi1udW1iZXI6ICAgICAweDAwDQpHZXRKb2JzIG9wZXJhdGlvbi1pZDogICAg IDB4MDAwYQ0KcmVxdWVzdC1pZDogICAgICAgMHgwMDAwMDAwMQ0Kb3BlcmF0aW9uLWF0dHJpYnV0 ZXMtdGFnOiAweDAxDQp2YWx1ZS10YWc6ICAgICAgICAweDQ3DQpuYW1lLWxlbmd0aDogICAgICAw eDAwMTINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLWNoYXJzZXQNCnZhbHVlIGxlbmd0aDogICAgIDB4 MDAwOA0KdmFsdWU6ICAgIFVTLUFTQ0lJDQp2YWx1ZS10YWc6ICAgICAgICAweDQ4DQpuYW1lLWxl bmd0aDogICAgICAweDAwMWINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLW5hdHVyYWwtbGFuZ3VhZ2UN CnZhbHVlIGxlbmd0aDogICAgIDB4MDAwNQ0KdmFsdWU6ICAgIGVuLVVTDQp2YWx1ZS10YWc6ICAg ICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAwMDgNCm5hbWU6ICAgICBqb2ItbmFtZQ0K dmFsdWUgbGVuZ3RoOiAgICAgMHgwMDA0DQp2YWx1ZTogICAgam9iMQ0KdmFsdWUtdGFnOiAgICAg ICAgMHgyMg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDE2DQpuYW1lOiAgICAgaXBwLWF0dHJpYnV0 ZS1maWRlbGl0eQ0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDAxDQp2YWx1ZTogICAgMHgwMA0KdmFs dWUtdGFnOiAgICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDE0DQpuYW1lOiAgICAg cmVxdWVzdGluZy11c2VyLW5hbWUNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwNQ0KdmFsdWU6ICAg IHN0ZXZlDQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAwMGQN Cm5hbWU6ICAgICBkb2N1bWVudC1uYW1lDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDkNCnZhbHVl OiAgICBkb2N1bWVudDENCnZhbHVlLXRhZzogICAgICAgIDB4NDINCm5hbWUtbGVuZ3RoOiAgICAg IDB4MDAwYg0KbmFtZTogICAgIHByaW50ZXItdXJpDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMWMN CnZhbHVlOiAgICBsb2NhbGhvc3Qvc2VydmxldC9JUFBTZXJ2bGV0DQplbmQtb2YtYXR0cmlidXRl cy10YWc6ICAgIDB4MDMNCg== --Boundary=_0.0_=5030100016890547-- From ipp-owner@pwg.org Fri Jan 30 17:52:50 1998 Delivery-Date: Fri, 30 Jan 1998 17:52:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA20270 for ; Fri, 30 Jan 1998 17:52:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA20686 for ; Fri, 30 Jan 1998 17:55:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21100 for ; Fri, 30 Jan 1998 17:52:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 17:40:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19767 for ipp-outgoing; Fri, 30 Jan 1998 16:57:14 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TES - sharing binary IPP trace files Message-ID: <5030100016891092000002L022*@MHS> Date: Fri, 30 Jan 1998 16:56:33 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100016891092" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100016891092 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another "conversation". Binaries to be uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces = --Boundary=_0.0_=5030100016891092 Content-Type: application/octet-stream; name=0005BA00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNQ0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldEpv YkF0dHJpYnV0ZXMNCi8vIGQuIHdoZXRoZXIgaXQgaXMgYSByZXF1ZXN0IG9yIGEgcmVzcG9uc2Ug KFIpOiByZXF1ZXN0DQovLyBlLiB0aGUgZmlsZSBuYW1lIG9mIHRoZSBmaWxlOiAwMDA1QkEwMA0K Ly8gZi4gdGhlIGRhdGU6ICBKYW51YXJ5IDMwLCAxOTk4DQovLyBnLiBhIGNvbW1lbnQgYWJvdXQg dGhlIGludGVudCBvZiB0aGUgb3BlcmF0aW9uIHJlcXVlc3Qgb3IgcmVzcG9uc2U6DQovLyAgICBB IHJlcXVlc3QgZm9yIGpvYiBhdHRyaWJ1dGVzOyBubyBzZWN1cml0eS4NCi8vIA0KbWFqb3ItdmVy c2lvbi1udW1iZXI6ICAgICAweDAxDQptaW5vci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDANCkdl dEpvYkF0dHJpYnV0ZXMgb3BlcmF0aW9uLWlkOiAgICAweDAwMGINCnJlcXVlc3QtaWQ6ICAgICAg IDB4MDAwMDAwMDENCm9wZXJhdGlvbi1hdHRyaWJ1dGVzLXRhZzogMHgwMQ0KdmFsdWUtdGFnOiAg ICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA2DQpuYW1lOiAgICAgam9iLWlkDQp2 YWx1ZSBsZW5ndGg6ICAgICAweDAwMDENCnZhbHVlOiAgICAxDQp2YWx1ZS10YWc6ICAgICAgICAw eDQ3DQpuYW1lLWxlbmd0aDogICAgICAweDAwMTINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLWNoYXJz ZXQNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwOA0KdmFsdWU6ICAgIFVTLUFTQ0lJDQp2YWx1ZS10 YWc6ICAgICAgICAweDQ4DQpuYW1lLWxlbmd0aDogICAgICAweDAwMWINCm5hbWU6ICAgICBhdHRy aWJ1dGVzLW5hdHVyYWwtbGFuZ3VhZ2UNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwNQ0KdmFsdWU6 ICAgIGVuLVVTDQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAw MTMNCm5hbWU6ICAgICByZXF1ZXN0ZWRBdHRyaWJ1dGVzDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAw MGMNCnZhbHVlOiAgICBwcmludGVyLW5hbWUNCnZhbHVlLXRhZzogICAgICAgIDB4NDINCm5hbWUt bGVuZ3RoOiAgICAgIDB4MDAxNA0KbmFtZTogICAgIHJlcXVlc3RpbmctdXNlci1uYW1lDQp2YWx1 ZSBsZW5ndGg6ICAgICAweDAwMDUNCnZhbHVlOiAgICBzdGV2ZQ0KZW5kLW9mLWF0dHJpYnV0ZXMt dGFnOiAgICAweDAzDQo= --Boundary=_0.0_=5030100016891092 Content-Type: application/octet-stream; name=0005BB00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNQ0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldEpv YkF0dHJpYnV0ZXMNCi8vIGQuIHdoZXRoZXIgaXQgaXMgYSByZXF1ZXN0IG9yIGEgcmVzcG9uc2Ug KFIpOiByZXNwb25zZQ0KLy8gZS4gdGhlIGZpbGUgbmFtZSBvZiB0aGUgZmlsZTogMDAwNUJCMDAN Ci8vIGYuIHRoZSBkYXRlOiAgSmFudWFyeSAzMCwgMTk5OA0KLy8gZy4gYSBjb21tZW50IGFib3V0 IHRoZSBpbnRlbnQgb2YgdGhlIG9wZXJhdGlvbiByZXF1ZXN0IG9yIHJlc3BvbnNlOg0KLy8gICAg UmVzcG9uc2UgdG8gR2V0Sm9iQXR0cmlidXRlczsgbm8gc2VjdXJpdHkNCi8vIA0KbWFqb3ItdmVy c2lvbi1udW1iZXI6ICAgICAweDAxDQptaW5vci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDANCnN0 YXR1cy1jb2RlOiAgICAgIDB4MDAwMA0KcmVxdWVzdC1pZDogICAgICAgMHgwMDAwMDAwMQ0Kb3Bl cmF0aW9uLWF0dHJpYnV0ZXMtdGFnOiAweDAxDQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1l LWxlbmd0aDogICAgICAweDAwMTINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLWNoYXJzZXQNCnZhbHVl IGxlbmd0aDogICAgIDB4MDAwMg0KdmFsdWU6ICAgIHlvDQpqb2ItYXR0cmlidXRlcy10YWc6ICAg ICAgIDB4MDINCnZhbHVlLXRhZzogICAgICAgIDB4NDINCm5hbWUtbGVuZ3RoOiAgICAgIDB4MDAw Ng0KbmFtZTogICAgIGNvcGllcw0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDAxDQp2YWx1ZTogICAg Mg0KdmFsdWUtdGFnOiAgICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA4DQpuYW1l OiAgICAgcHJpb3JpdHkNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwMQ0KdmFsdWU6ICAgIDINCmVu ZC1vZi1hdHRyaWJ1dGVzLXRhZzogICAgMHgwMw0K --Boundary=_0.0_=5030100016891092-- From ipp-owner@pwg.org Fri Jan 30 18:02:20 1998 Delivery-Date: Fri, 30 Jan 1998 18:02:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA20340 for ; Fri, 30 Jan 1998 18:02:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20704 for ; Fri, 30 Jan 1998 18:05:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA22066 for ; Fri, 30 Jan 1998 18:02:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 17:54:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA19852 for ipp-outgoing; Fri, 30 Jan 1998 17:07:50 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TES - sharing binary IPP trace files Message-ID: <5030100016891642000002L022*@MHS> Date: Fri, 30 Jan 1998 17:07:00 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100016891642" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100016891642 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another "conversation". Binaries to be uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces = --Boundary=_0.0_=5030100016891642 Content-Type: application/octet-stream; name=00068B00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNg0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IENhbmNl bEpvYg0KLy8gZC4gd2hldGhlciBpdCBpcyBhIHJlcXVlc3Qgb3IgYSByZXNwb25zZSAoUik6IHJl c3BvbnNlDQovLyBlLiB0aGUgZmlsZSBuYW1lIG9mIHRoZSBmaWxlOiAwMDA2OEIwMA0KLy8gZi4g dGhlIGRhdGU6ICBKYW51YXJ5IDMwLCAxOTk4DQovLyBnLiBhIGNvbW1lbnQgYWJvdXQgdGhlIGlu dGVudCBvZiB0aGUgb3BlcmF0aW9uIHJlcXVlc3Qgb3IgcmVzcG9uc2U6DQovLyAgICBSZXNwb25z ZSB0byBDYW5jZWxKb2I7IG5vIHNlY3VyaXR5Lg0KLy8gDQptYWpvci12ZXJzaW9uLW51bWJlcjog ICAgIDB4MDENCm1pbm9yLXZlcnNpb24tbnVtYmVyOiAgICAgMHgwMA0Kc3RhdHVzLWNvZGU6ICAg ICAgMHgwMDAwDQpyZXF1ZXN0LWlkOiAgICAgICAweDAwMDAwMDAxDQpvcGVyYXRpb24tYXR0cmli dXRlcy10YWc6IDB4MDENCnZhbHVlLXRhZzogICAgICAgIDB4NDINCm5hbWUtbGVuZ3RoOiAgICAg IDB4MDAxMg0KbmFtZTogICAgIGF0dHJpYnV0ZXMtY2hhcnNldA0KdmFsdWUgbGVuZ3RoOiAgICAg MHgwMDAyDQp2YWx1ZTogICAgeW8NCmVuZC1vZi1hdHRyaWJ1dGVzLXRhZzogICAgMHgwMw0K --Boundary=_0.0_=5030100016891642 Content-Type: application/octet-stream; name=00068A00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNg0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IENhbmNl bEpvYg0KLy8gZC4gd2hldGhlciBpdCBpcyBhIHJlcXVlc3Qgb3IgYSByZXNwb25zZSAoUik6IHJl cXVlc3QNCi8vIGUuIHRoZSBmaWxlIG5hbWUgb2YgdGhlIGZpbGU6IDAwMDY4QTAwDQovLyBmLiB0 aGUgZGF0ZTogIEphbnVhcnkgMzAsIDE5OTgNCi8vIGcuIGEgY29tbWVudCBhYm91dCB0aGUgaW50 ZW50IG9mIHRoZSBvcGVyYXRpb24gcmVxdWVzdCBvciByZXNwb25zZToNCi8vICAgIENhbmNlbHMg YSBwYXJ0aWN1bGFyIGpvYi4gIE5vIHNlY3VyaXR5Lg0KLy8gDQptYWpvci12ZXJzaW9uLW51bWJl cjogICAgIDB4MDENCm1pbm9yLXZlcnNpb24tbnVtYmVyOiAgICAgMHgwMA0KQ2FuY2VsSm9iIG9w ZXJhdGlvbi1pZDogICAweDAwMDgNCnJlcXVlc3QtaWQ6ICAgICAgIDB4MDAwMDAwMDENCm9wZXJh dGlvbi1hdHRyaWJ1dGVzLXRhZzogMHgwMQ0KdmFsdWUtdGFnOiAgICAgICAgMHg0Nw0KbmFtZS1s ZW5ndGg6ICAgICAgMHgwMDEyDQpuYW1lOiAgICAgYXR0cmlidXRlcy1jaGFyc2V0DQp2YWx1ZSBs ZW5ndGg6ICAgICAweDAwMDgNCnZhbHVlOiAgICBVUy1BU0NJSQ0KdmFsdWUtdGFnOiAgICAgICAg MHg0OA0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDFiDQpuYW1lOiAgICAgYXR0cmlidXRlcy1uYXR1 cmFsLWxhbmd1YWdlDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDUNCnZhbHVlOiAgICBlbi1VUw0K dmFsdWUtdGFnOiAgICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA3DQpuYW1lOiAg ICAgam9iLXVyaQ0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDA4DQp2YWx1ZTogICAgL3NnZWJlcnQN CnZhbHVlLXRhZzogICAgICAgIDB4NDINCm5hbWUtbGVuZ3RoOiAgICAgIDB4MDAxNA0KbmFtZTog ICAgIHJlcXVlc3RpbmctdXNlci1uYW1lDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDUNCnZhbHVl OiAgICBzdGV2ZQ0KZW5kLW9mLWF0dHJpYnV0ZXMtdGFnOiAgICAweDAzDQo= --Boundary=_0.0_=5030100016891642-- From ipp-owner@pwg.org Fri Jan 30 18:04:32 1998 Delivery-Date: Fri, 30 Jan 1998 18:04:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA20356 for ; Fri, 30 Jan 1998 18:04:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20717 for ; Fri, 30 Jan 1998 18:07:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA22315 for ; Fri, 30 Jan 1998 18:04:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 17:57:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20279 for ipp-outgoing; Fri, 30 Jan 1998 17:16:36 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TES - sharing binary IPP trace files Message-ID: <5030100016892001000002L012*@MHS> Date: Fri, 30 Jan 1998 17:15:43 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100016892001" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100016892001 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Another "conversation". Binaries to be uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces = --Boundary=_0.0_=5030100016892001 Content-Type: application/octet-stream; name=00079B00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNw0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldFBy aW50ZXJBdHRyaWJ1dGVzDQovLyBkLiB3aGV0aGVyIGl0IGlzIGEgcmVxdWVzdCBvciBhIHJlc3Bv bnNlIChSKTogcmVzcG9uc2UNCi8vIGUuIHRoZSBmaWxlIG5hbWUgb2YgdGhlIGZpbGU6IDAwMDc5 QjAwDQovLyBmLiB0aGUgZGF0ZTogIEphbnVhcnkgMzAsIDE5OTgNCi8vIGcuIGEgY29tbWVudCBh Ym91dCB0aGUgaW50ZW50IG9mIHRoZSBvcGVyYXRpb24gcmVxdWVzdCBvciByZXNwb25zZToNCi8v ICAgIFJlc3BvbnNlIHRvIEdldFByaW50ZXJBdHRyaWJ1dGVzOyBubyBzZWN1cml0eQ0KLy8gDQpt YWpvci12ZXJzaW9uLW51bWJlcjogICAgIDB4MDENCm1pbm9yLXZlcnNpb24tbnVtYmVyOiAgICAg MHgwMA0Kc3RhdHVzLWNvZGU6ICAgICAgMHgwMDAwDQpyZXF1ZXN0LWlkOiAgICAgICAweDAwMDAw MDAxDQpvcGVyYXRpb24tYXR0cmlidXRlcy10YWc6IDB4MDENCnZhbHVlLXRhZzogICAgICAgIDB4 NDINCm5hbWUtbGVuZ3RoOiAgICAgIDB4MDAxMg0KbmFtZTogICAgIGF0dHJpYnV0ZXMtY2hhcnNl dA0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDAyDQp2YWx1ZTogICAgeW8NCj8/PzogICAgICAweDA0 DQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpuYW1lLWxlbmd0aDogICAgICAweDAwMDUNCm5hbWU6 ICAgICBpbmZvMQ0KdmFsdWUgbGVuZ3RoOiAgICAgMHgwMDA0DQp2YWx1ZTogICAgSm9iMQ0KdmFs dWUtdGFnOiAgICAgICAgMHg0Mg0KbmFtZS1sZW5ndGg6ICAgICAgMHgwMDA1DQpuYW1lOiAgICAg aW5mbzINCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwNA0KdmFsdWU6ICAgIEpvYjINCmVuZC1vZi1h dHRyaWJ1dGVzLXRhZzogICAgMHgwMw0K --Boundary=_0.0_=5030100016892001 Content-Type: application/octet-stream; name=00079A00.txt Content-Transfer-Encoding: base64 Ly8gYS4gdGhlIHBlcnNvbiBwb3N0aW5nIHRoZSB0cmFjZSBmaWxlOiAgQ2FybCBLdWdsZXINCi8v IGIuIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoYXQgcGVyc29uIDoga3VnbGVyQHVzLmlibS5j b20NCi8vIGMuIHRoZSB1bmlxdWUgc2VxdWVuY2UgbnVtYmVyIGZvciB0aGUgY29udmVyc2F0aW9u IChTU1NTKTogMDAwNw0KLy8gZC4gdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiAoTyk6IEdldFBy aW50ZXJBdHRyaWJ1dGVzDQovLyBkLiB3aGV0aGVyIGl0IGlzIGEgcmVxdWVzdCBvciBhIHJlc3Bv bnNlIChSKTogcmVxdWVzdA0KLy8gZS4gdGhlIGZpbGUgbmFtZSBvZiB0aGUgZmlsZTogMDAwNzlB MDANCi8vIGYuIHRoZSBkYXRlOiAgSmFudWFyeSAzMCwgMTk5OA0KLy8gZy4gYSBjb21tZW50IGFi b3V0IHRoZSBpbnRlbnQgb2YgdGhlIG9wZXJhdGlvbiByZXF1ZXN0IG9yIHJlc3BvbnNlOg0KLy8g ICAgUmVxdWVzdCBmb3IgcHJpbnRlciBhdHRyaWJ1dGVzOyBubyBzZWN1cml0eS4NCi8vIA0KbWFq b3ItdmVyc2lvbi1udW1iZXI6ICAgICAweDAxDQptaW5vci12ZXJzaW9uLW51bWJlcjogICAgIDB4 MDANCkdldFByaW50ZXJBdHRyaWJ1dGVzIG9wZXJhdGlvbi1pZDogICAgICAgIDB4MDAwOQ0KcmVx dWVzdC1pZDogICAgICAgMHgwMDAwMDAwMQ0Kb3BlcmF0aW9uLWF0dHJpYnV0ZXMtdGFnOiAweDAx DQp2YWx1ZS10YWc6ICAgICAgICAweDQ3DQpuYW1lLWxlbmd0aDogICAgICAweDAwMTINCm5hbWU6 ICAgICBhdHRyaWJ1dGVzLWNoYXJzZXQNCnZhbHVlIGxlbmd0aDogICAgIDB4MDAwOA0KdmFsdWU6 ICAgIFVTLUFTQ0lJDQp2YWx1ZS10YWc6ICAgICAgICAweDQ4DQpuYW1lLWxlbmd0aDogICAgICAw eDAwMWINCm5hbWU6ICAgICBhdHRyaWJ1dGVzLW5hdHVyYWwtbGFuZ3VhZ2UNCnZhbHVlIGxlbmd0 aDogICAgIDB4MDAwNQ0KdmFsdWU6ICAgIGVuLVVTDQp2YWx1ZS10YWc6ICAgICAgICAweDQyDQpu YW1lLWxlbmd0aDogICAgICAweDAwMTMNCm5hbWU6ICAgICByZXF1ZXN0ZWRBdHRyaWJ1dGVzDQp2 YWx1ZSBsZW5ndGg6ICAgICAweDAwMGMNCnZhbHVlOiAgICBwcmludGVyLW5hbWUNCnZhbHVlLXRh ZzogICAgICAgIDB4NDINCm5hbWUtbGVuZ3RoOiAgICAgIDB4MDAxNA0KbmFtZTogICAgIHJlcXVl c3RpbmctdXNlci1uYW1lDQp2YWx1ZSBsZW5ndGg6ICAgICAweDAwMDUNCnZhbHVlOiAgICBzdGV2 ZQ0KZW5kLW9mLWF0dHJpYnV0ZXMtdGFnOiAgICAweDAzDQo= --Boundary=_0.0_=5030100016892001-- From ipp-owner@pwg.org Fri Jan 30 18:32:11 1998 Delivery-Date: Fri, 30 Jan 1998 18:32:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA20555 for ; Fri, 30 Jan 1998 18:32:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20773 for ; Fri, 30 Jan 1998 18:34:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA23007 for ; Fri, 30 Jan 1998 18:31:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 18:27:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22435 for ipp-outgoing; Fri, 30 Jan 1998 18:12:15 -0500 (EST) Date: Fri, 30 Jan 1998 15:17:22 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9801302317.AA29112@snorkel.eso.mc.xerox.com> To: RMcComiskie@xionics.com, ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG Sender: ipp-owner@pwg.org I vote to submit the current IPP/1.0 Model and Protocol drafts to the IESG for adoption. Cheers, - Ira McDonald High North Inc 221 Ridge Ave Grand Marais, MI 49839 906-494-2434 From ipp-owner@pwg.org Fri Jan 30 21:54:36 1998 Delivery-Date: Fri, 30 Jan 1998 21:54:36 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA21638 for ; Fri, 30 Jan 1998 21:54:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21086 for ; Fri, 30 Jan 1998 21:57:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23746 for ; Fri, 30 Jan 1998 21:54:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 30 Jan 1998 21:50:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA23216 for ipp-outgoing; Fri, 30 Jan 1998 21:34:48 -0500 (EST) Date: Fri, 30 Jan 98 18:19:55 -0800 From: Peter Michalek Subject: Re: IPP> Consensus on sending our drafts to the IESG To: ipp@pwg.org X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <9801302317.AA29112@snorkel.eso.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I think the work you guys have done on providing the IPP protocol is solid and ready for submission. I am sure it will be possible to provide enhancements like XML support in post 1.0 versions. I vote to submit the current IPP drafts to the IESG. Peter ---------------------------------------------------- Peter Michalek | (408) 446-5040 | ShineSoft Systems | mailto:peterm@shinesoft.com | 10025 Crescent Rd. | | Cupertino CA 95014 | | From ipp-owner@pwg.org Mon Feb 2 05:20:46 1998 Delivery-Date: Mon, 02 Feb 1998 05:20:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id FAA20945 for ; Mon, 2 Feb 1998 05:20:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA01744 for ; Mon, 2 Feb 1998 05:23:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA27445 for ; Mon, 2 Feb 1998 05:20:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 05:11:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA26893 for ipp-outgoing; Mon, 2 Feb 1998 04:55:46 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: ipp@pwg.org Message-Id: Date: Mon, 2 Feb 1998 09:55:19 +0100 Subject: Re: IPP> Consensus on sending our drafts to the IESG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org As requested, I reafirm my decision, as expressed during the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards and the remaining three drafts as Informational RFCs without further delay. Henrik Holst ______________________________________________ Henrik Holst i-data International henrik.holst@i-data.com www.i-data.com From ipp-owner@pwg.org Mon Feb 2 08:37:15 1998 Delivery-Date: Mon, 02 Feb 1998 08:37:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA23368 for ; Mon, 2 Feb 1998 08:37:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02019 for ; Mon, 2 Feb 1998 08:39:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA28273 for ; Mon, 2 Feb 1998 08:37:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 08:28:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA27706 for ipp-outgoing; Mon, 2 Feb 1998 08:12:40 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: ipp@pwg.org Message-Id: Date: Mon, 2 Feb 1998 13:12:18 +0100 Subject: IPP> IPP > FAQ - How should the server behave? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org As mentioned in Maui I would like a FAQ list. Here is my questions when I read the IPP model & protocol document. I am looking forward to the 'developers guide', which should describe the behavior of the IPP printer when an IRQ occour etc. 1. If an IPP-client transmit a request to the IPP-server and close the tcp-connection, should the IPP-server open a new tcp-session and transmit the response? 2. Must the IPP-server wait with the response, on a print-job request, to the whole job is received? 3. How should a non-spooling IPP-server handle concurrent print-job requests? Henrik Holst * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Henrik Holst * * Software engineer - developing embedded Printservers * * i-data International * * Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark * * Voice: (45) 44366271 * * Fax: (45) 44366111 * * Email: henrik.holst@i-data.com * * WEB: www.i-data.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From ipp-owner@pwg.org Mon Feb 2 11:37:18 1998 Delivery-Date: Mon, 02 Feb 1998 11:37:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA27492 for ; Mon, 2 Feb 1998 11:37:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA02863 for ; Mon, 2 Feb 1998 11:39:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA29112 for ; Mon, 2 Feb 1998 11:37:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 11:26:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28533 for ipp-outgoing; Mon, 2 Feb 1998 11:10:59 -0500 (EST) From: Carl Kugler To: Subject: IPP> IPP > FAQ - How should the server behave? Message-ID: <5030100016952594000002L042*@MHS> Date: Mon, 2 Feb 1998 11:10:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA27492 Henrik- My understandings: > 1. If an IPP-client transmit a request to the IPP-server and close the > tcp-connection, should the IPP-server open a new tcp-session and transmit the > response? Impossible. The client isn't listening on a server port. > 2. Must the IPP-server wait with the response, on a print-job request, to > the whole job is received? The server should respond to the request before accepting appended document content. See 3.1.7 and 15.4 in the model document. > 3. How should a non-spooling IPP-server handle concurrent print-job > requests? Return server-error-service-unavailable (0x0502) to indicate that the server is temporarily unable to handle a request. -Carl ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 02/02/98 08:41 AM --------------------------- ipp-owner@pwg.org on 02/02/98 01:31:15 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> IPP > FAQ - How should the server behave? As mentioned in Maui I would like a FAQ list. Here is my questions when I read the IPP model & protocol document. I am looking forward to the 'developers guide', which should describe the behavior of the IPP printer when an IRQ occour etc. 1. If an IPP-client transmit a request to the IPP-server and close the tcp-connection, should the IPP-server open a new tcp-session and transmit the response? 2. Must the IPP-server wait with the response, on a print-job request, to the whole job is received? 3. How should a non-spooling IPP-server handle concurrent print-job requests? Henrik Holst * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Henrik Holst * * Software engineer - developing embedded Printservers * * i-data International * * Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark * * Voice: (45) 44366271 * * Fax: (45) 44366111 * * Email: henrik.holst@i-data.com * * WEB: www.i-data.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From adm Mon Feb 2 12:03:47 1998 Delivery-Date: Mon, 02 Feb 1998 12:12:10 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA28635 for ietf-123-outbound.10@ietf.org; Mon, 2 Feb 1998 12:02:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA26723; Mon, 2 Feb 1998 11:16:00 -0500 (EST) Message-Id: <199802021616.LAA26723@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-05.txt Date: Mon, 02 Feb 1998 11:15:59 -0500 Sender: cclark@cnri.reston.va.us --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) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-05.txt Pages : 8 Date : 29-Jan-98 This document describes a protocol intended to provide lossless compression for Internet Protocol 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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-05.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: <19980129174452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980129174452.I-D@ietf.org> --OtherAccess-- --NextPart-- From jmp-owner@pwg.org Mon Feb 2 12:47:35 1998 Delivery-Date: Mon, 02 Feb 1998 12:47:35 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA00379 for ; Mon, 2 Feb 1998 12:47:34 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03143 for ; Mon, 2 Feb 1998 12:50:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA29808 for ; Mon, 2 Feb 1998 12:47:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 12:43:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29298 for jmp-outgoing; Mon, 2 Feb 1998 12:39:06 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> PWG meeting in Austin on 3/2-6 Message-ID: <5040300012000069000002L092*@MHS> Date: Mon, 2 Feb 1998 12:37:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From pwg-owner@pwg.org Mon Feb 2 12:54:43 1998 Delivery-Date: Mon, 02 Feb 1998 12:54:44 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA00554 for ; Mon, 2 Feb 1998 12:54:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03181 for ; Mon, 2 Feb 1998 12:57:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA00524 for ; Mon, 2 Feb 1998 12:54:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 12:45:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29279 for pwg-outgoing; Mon, 2 Feb 1998 12:38:56 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> PWG meeting in Austin on 3/2-6 Message-ID: <5040300012000069000002L092*@MHS> Date: Mon, 2 Feb 1998 12:37:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 2 13:11:17 1998 Delivery-Date: Mon, 02 Feb 1998 13:11:18 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA01025 for ; Mon, 2 Feb 1998 13:11:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03272 for ; Mon, 2 Feb 1998 13:13:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA01187 for ; Mon, 2 Feb 1998 13:11:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 13:05:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29318 for ipp-outgoing; Mon, 2 Feb 1998 12:39:16 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> PWG meeting in Austin on 3/2-6 Message-ID: <5040300012000069000002L092*@MHS> Date: Mon, 2 Feb 1998 12:37:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 2 14:26:47 1998 Delivery-Date: Mon, 02 Feb 1998 14:26:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA02550 for ; Mon, 2 Feb 1998 14:26:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03593 for ; Mon, 2 Feb 1998 14:29:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02227 for ; Mon, 2 Feb 1998 14:26:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 14:21:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01646 for ipp-outgoing; Mon, 2 Feb 1998 14:06:11 -0500 (EST) Content-return: allowed Date: Mon, 2 Feb 1998 10:37:56 PST From: "Zehler, Peter " Subject: RE: IPP> Consensus on sending our drafts to the IESG To: "IPP Discussion List (E-mail)" Cc: "Carl-Uno Manros (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org All, I reaffirm my position that we send the existing documents to the IESG last call. The XML overview by Microsoft, while technically interesting, was not compelling enough to cause me to abandon a specification that satisfies the IPP requirements. I urge Microsoft to come back with a detailed proposal equal to the level of the existing protocol document. The current document is 26 pages. Eleven of those pages layout the protocol mapping. The XML protocol mapping document will clarify the magnitude of the change that is being requested. I am also concerned with the lack of structured data types in XML that are required by IPP. I am not convinced that the time for XML is at hand. Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Mon Feb 2 17:26:39 1998 Delivery-Date: Mon, 02 Feb 1998 17:26:39 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06879 for ; Mon, 2 Feb 1998 17:26:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04589 for ; Mon, 2 Feb 1998 17:29:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03072 for ; Mon, 2 Feb 1998 17:26:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 17:22:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02491 for ipp-outgoing; Mon, 2 Feb 1998 17:06:26 -0500 (EST) From: Carl Kugler To: Subject: IPP> MOD Need Clarification re: Type4 keywords Message-ID: <5030100016970070000002L002*@MHS> Date: Mon, 2 Feb 1998 17:06:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA06879 Attributes with type 4 keywords also allow the 'name' attribute syntax for administrator defined names. Keywords SHALL be in U.S. English, but attributes that are indicated to have the 'name' attribute syntax also automatically have the 'nameWithLanguage' attribute syntax. So in general, attributes with type 4 keywords can use the Language Override Mechanism? -Carl From adm Mon Feb 2 18:17:51 1998 Delivery-Date: Mon, 02 Feb 1998 18:21:36 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id SAA07518 for ietf-outbound.10@ietf.org; Mon, 2 Feb 1998 18:15:04 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA07473 for ; Mon, 2 Feb 1998 18:11:26 -0500 (EST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id <1C9ZDT4Q>; Mon, 2 Feb 1998 15:11:30 -0800 Message-ID: <60602D8F29B3D011879800805FD47224021FCB7F@red-11-msg.dns.microsoft.com> From: Tony Hain To: Tripp Lilley Cc: "Raides J." , Noel Chiappa , ietf@ns.ietf.org Subject: RE: COM names != US trade marks (was Re: Future of IANA) Date: Mon, 2 Feb 1998 15:11:25 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Tripp, I agree brand recognition has value to companies. Your example assumes that people would have to know anything besides Pepsi. If the apps had grown up with a rule to auto-insert the country code of the originator when in doubt, you could accomplish both the brand recognition and localized presentations at the same time. I am not trying to advocate that country codes are necessarily the right answer, just present the view that the trademark issues would be minimized in that environment since they are more likely to map to existing law. Taking the view that the Internet obscures the concept of countries (therefore country codes), I am left without a good answer as to what the right thing would be. As always, these comments are my own and do not in any way reflect those of my employer. ====================================================================== Tony Hain tonyhain@microsoft.com "I think that's self-evident, but not true." -- Bill Clinton -----Original Message----- From: Tripp Lilley [SMTP:tlilley@PERSPEX.COM] Sent: Monday, February 02, 1998 2:43 PM To: Tony Hain Cc: Raides J.; Noel Chiappa; ietf@ns.ietf.org Subject: RE: COM names != US trade marks (was Re: Future of IANA) On Mon, 2 Feb 1998, Tony Hain wrote: > > (router and stack vendors) without concern for the long term. If today's > knowledge were applied, and a hard line had been taken to put all commercial > interests in the country TLD's, their trademark issues and laws would align > with the name space they were in. In fact there is no reason a given company > couldn't use the country TLD's today, except their marketing departments > think .com is the place to be. I would argue that Noel is applying the logic Conspiracy theories aside, I'm not sure the country TLD is the soothing answer to this that it might seem. Do we really believe that, for instance, Pepsi wants to be known as pepsi.com.us and pepsi.co.uk and pepsi.co.jp? That is diametrically opposed to the brand recognition they're trying to assert worldwide. They want to be known as "pepsi", without regard to where Pepsi is. Ideally, I suspect (and this is all conjecture) they'd like the technology to make pepsi.com (or whatever non-country TLD under which they fall) resolve differently based on the country of the visitor's origin -- in much the same way that a Pepsi banner or Pepsi commercial or Pepsi product is presented differently in different countries and cultures. But the bottom line is that no matter where one goes, one sees simply "Pepsi", not "Pepsi US" and "Pepsi UK" and so forth. I can get philosophical or poetic and say that they're tapping in to some universal urge to "belong" worldwide, but the bottom line is that companies appreciate the TLDs because (among other reasons) they abstract away geographic boundaries and make pepsi just pepsi. FWIW, - t. ----------------------------------------------------------------------- Tripp Lilley, Perspex Imageworks, Inc. (tripp.lilley@perspex.com) ----------------------------------------------------------------------- "Give me a fast computer, for I intend to go in harm's way" - updating John Paul Jones From ipp-owner@pwg.org Mon Feb 2 19:52:32 1998 Delivery-Date: Mon, 02 Feb 1998 19:52:33 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA08986 for ; Mon, 2 Feb 1998 19:52:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05063 for ; Mon, 2 Feb 1998 19:55:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA03822 for ; Mon, 2 Feb 1998 19:52:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 19:46:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03249 for ipp-outgoing; Mon, 2 Feb 1998 19:31:18 -0500 (EST) Message-Id: <3.0.1.32.19980202143708.00f136e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Feb 1998 14:37:08 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Future change: early binding of defaults: more understandable Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org This is one of the future extensions that we didn't get time to discuss at the IPP meeting last week, though I handed out the paper. This paper is an updated version of that paper. I've copied the .doc, .pdf, and .txt files to: ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.doc ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.pdf ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.txt The .txt file follows: Subj: Future Model change: early binding of defaults is more understandable to end-users From: Tom Hastings Date: 2/2/98 File: clearer-defaulting.doc This paper proposes a future upwards-compatible tweak to the Model document that preserves the current semantics for attribute defaulting (default value is used only if the PDL does not contain a corresponding embedded instruction), but makes it clearer to the end-user what the default values are/were for the end-user's job. This tweak also allows the system administrator to change the defaults on a Printer object without affecting any submitted jobs, thereby allowing us to drop the warning note on page 60. The idea is for the Printer object to copy its "xxx-default" attributes and values to the Job object in the create operation for any supported attribute that the client does not supply. In other words, the "xxx- default" value is bound to the Job object at create time, instead of using the Printer object's value at job processing time. Since the name of the Job attribute is "xxx-default", not "xxx", it is clear that the value is used only if the document data does not contain an equivalent instruction. This is "early" binding of defaults to the Job object. The user can query the Job object before or after the job is printed to see what the defaults are/were. This is particularly helpful to a user who is surprised at his/her print job results and wants to check what attributes the job had (while the job is in the 'completed' state). It is also helpful to the user while the job is in the 'pending' or 'pending-held'state. The simplest change is to extend the definition of Job Template Job attributes to include the "xxx-default" attributes (column two of the table in section 4.2). Then the Get-Attributes operation returns both "xxx" and "xxx-default" Job object attributes (in response Group 3) when the requester supplies the "job-template" value in the "requested- attributes" operation attribute. The changes to the Model document are not that many (page/line numbers refer to the ipp-model-980116.pdf version): 1. Page 15, lines 521-523: modify the explanation of job template Job attributes: "job-template" attributes: These attributes are OPTIONALLY supplied by the client or end user and include job processing instructions which are intended to override any Printer object defaults and/or instructions embedded within the document data. (See section 4.2) to give: "job-template" attributes: These attributes are either "xxx" or "xxx-default" attributes. The "xxx" attributes are OPTIONALLY supplied by the client or end user and include job processing instructions which are intended to override any Printer object defaults and/or instructions embedded within the document data. The "xxx-default" attributes supplied by the Printer object when the client does not supply the corresponding "xxx" attribute. The "xxx- 1 instructions embedded within the document data. (See section 4.2) 2. Page 20, line 705, add to the description of Job Template attribute the phrase: "and which were supplied as defaults by the Printer object in case the document contains no such corresponding instructions embedded in the data" to give: The Job object can later be queried to find out what Job Template attributes were originally requested in the create request and which were supplied as defaults by the Printer object in case the document contains no such corresponding instructions embedded in the data, and such attributes are returned in the response as Job Object Attributes. 3. Page 20, line 709, delete the phrase ", though such attributes are returned in the response as Printer Object Attributes" to give the following: The Printer object can be queried about its Job Template attributes to find out what type of job processing capabilities are supported and/or what the default job processing behaviors are, though such attributes are returned in the response as Printer Object Attributes. 4. Page 33, after line 1168, add the following bullet to the list: - Copies its "xxx-default" attributes to the Job object for any "xxx" Job Template attribute not supplied by the client. 5. Page 33, lines 1169-1171, change the last bullet from: - at job processing time, uses its corresponding default value attributes for the supported Job Template attributes that were not supplied by the client as IPP attribute or embedded instructions in the document data. to: - at job processing time, uses the Job's "xxx-default" attributes for the supported Job Template attributes that were not embedded instructions in the document data. 6. Page 48, lines 1708-1709, replace "first column" with "first and second columns" in the description of the "job-template" attribute group name in the Get-Job-Attributes operation description to give: - 'job-template': all of the Job Template attributes that apply to a Job object (the first and second columns of the table in Section 4.2). 7. Page 60, line 2084, add the sentence: The Printer object indicates its default value for each "xxx" attribute by copying its corresponding "xxx-default" attribute and value to the Job object as part of the create job operation. 8. Page 60, lines 2086-2088, delete the note: Note: Since an administrator MAY change the default value attribute after a Job object has been submitted but before it has been processed, the default value used by the Printer object at job processing time may be different that the default value in effect at job submission time. 9. Page 61, lines 2120:2127, indicate that column two (xxx-default) is a Job Template attribute for both the Job and Printer objects as follows: The table below summarizes the names and relationships for all Job Template attributes. The first two columns of the table (labeled "Job Attribute") show the name and syntax for each Job Template attribute in the Job object. These are the attributes that can optionally be supplied by the client in a create request. The last two columns (labeled "Job/Printer: Default Value Attribute" and "Printer: Supported Values Attribute") shows the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the supported values attribute). A "No" in the table means the Job and Printer SHALL NOT support the attribute (that is, the attribute is simply not applicable). For brevity in the table, the 'text' and 'name' entries do not show (MAX). 10. Page 62, line 2129, change the column two heading from "Printer: Default Value Attribute" to "Job and Printer: Default Value Attribute" 11. Page 151, lines 5134-5135: add to the end of the sentence: by copying its "job-priority-default" attribute and value to the Job object to give: IF NOT supplied by the client, use the value of the Printer object's "job-priority-default" attribute at job submission time by copying its "job-priority-default" attribute and value to the Job object. 12. Page 151, lines 5145:5146: add to the end of the sentence: by copying its "job-hold-until-default" attribute and value to the Job object to give: IF NOT supplied by the client, use the value of the Printer object's "job-hold-until-default" attribute at job submission time by copying its "job-hold-until-default" attribute and value to the Job object. 13. Pages 155-156, lines 5300:5302: add: and the corresponding Printer object's "xxx-default" is copied to the Job object to give: If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object and the corresponding Printer object's "xxx-default" is copied to the Job object (so that the normal default behavior at job processing time will take place for that attribute). 14. Page 156, lines 5304:5306: add: and the corresponding Printer object's "xxx-default" is copied to the Job object to give: If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object and the corresponding Printer object's "xxx-default" is copied to the Job object (so that the normal default behavior at job processing time will take place for that attribute). 15. Page 156, line 5318, add: (but not "xxx-default") to give: Note: All "xxx" (but not "xxx-default") Job Template attributes that are persistently stored with the Job object are intended to be "override values"; that is, they that take precedence over whatever other embedded instructions might be in the document data itself. 16. Page 156, lines 5323:5328, change the paragraph to describe copying the "xxx-default" Printer object attributes to the Job object, to give: There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer copies its "xxx-default" attributes to populate Job attributes when creating the new Job object. These copied Job default values are only used later at Job processing time if no other IPP attribute or instruction embedded in the document data is present. 17. Page 156, lines 5329:5335, change the first sentence of the note to explain the copying of the lower precedance "xxx-default" attributes, rather than "xxx" to the Job object, giving: Note: If the default values associated with Job Template attributes that the client did not supply were to be used to populate the Job object as "xxx" (instead of "xxx-default") attributes, then these values would become "override values" rather than defaults. If the Printer supports the 'attempted' value of the "pdl-override- supported" attribute, then these override values could replace values specified within the document data. This is not the intent of the default value mechanism. A default value for an attribute is used only if the create request did not specify that attribute (or it was ignored when allowed by "ipp-attribute-fidelity" being 'false') and no value was provided within the content of the document data. From ipp-owner@pwg.org Mon Feb 2 21:28:00 1998 Delivery-Date: Mon, 02 Feb 1998 21:28:00 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA10469 for ; Mon, 2 Feb 1998 21:27:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05261 for ; Mon, 2 Feb 1998 21:30:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA04571 for ; Mon, 2 Feb 1998 21:27:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Feb 1998 21:22:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03999 for ipp-outgoing; Mon, 2 Feb 1998 21:07:11 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> TLS security section of protocol document Date: Mon, 2 Feb 1998 18:03:54 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Just a note from the WG meeting in Hawaii... During the discussions of security related matters regarding using multiple HTTP methods at the last meeting, Josh brought up a point that proxies should be no problem with using a new method (such as PRINT) because it would just transparently pass it on through. I'm assuming that proxies do this with all methods the proxy does not recognize (unless some type of method filtering is turned on). This discussion got me thinking about proxies and IPP in general, with my initial conclusion being that we have a problem using TLS for end-to-end security in the presence of proxies. There is currently no standard for delegation of authentication info across proxies ( or any kind of "firewall" type of software). If the IPP client is configured to work with a particular proxy, and the IPP client is attempting communication with a TLS-based printer URI, we might need to indicate in the protocol document that this (and possibly other scenarios) can happen and what the implications of these scenarios might be. My immediate question is do we consider updating the security considerations section of the protocol document prior to IETF last call? Randy From jmp-owner@pwg.org Tue Feb 3 00:25:53 1998 Delivery-Date: Tue, 03 Feb 1998 00:25:54 -0500 Return-Path: jmp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA20277 for ; Tue, 3 Feb 1998 00:25:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA05653 for ; Tue, 3 Feb 1998 00:28:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA05429 for ; Tue, 3 Feb 1998 00:25:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 00:20:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA04832 for jmp-outgoing; Tue, 3 Feb 1998 00:17:14 -0500 (EST) Message-ID: <01BD301E.C8504DA0@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: JMP> RE: PWG> PWG meeting in Austin on 3/2-6 Date: Mon, 2 Feb 1998 21:08:59 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 107 TEXT Sender: jmp-owner@pwg.org Keith: I will be attending. 1) What meeting dates will you attend? 3-2 and 3-3 2) Will you stay at the Hyatt hotel? Yes 3) If you are staying at the Hyatt, what are your arrival and departure dates? Probably arrive the day before and leave the day after. Regards, Mark Edmead **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Monday, February 02, 1998 9:37 AM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Print gurus, > > I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the > scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. > > HOTEL INFORMATION > > Hyatt Regency Austin (located on Town Lake in downtown Austin). > Phone: 512-477-1234 > $101 per night (single occupancy). > Meeting room charge will be based on meeting attendance per day (see PING > INFORMATION) > Cab fare from airport is $12-14. > Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 > blocks for the athletically inclined). > Restaurants within 1 block of the hotel include: Threadgills (famous for their > home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al > Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). > The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) > and other restaurants are within a short drive of the hotel. > For you olympians, there is a public jogging trail that goes by the hotel and > around the lake. > > PWG MEETING AGENDA > > Here is the agenda proposed by Don Wright: > > Monday (3/2), Tuesday (3/3): > -- 1394 Printing > Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing > Wednesday (3/4) PM: > -- IPP > Thursday (3/5): > -- IPP > Friday (3/6): > -- Finisher > -- Job MIB Traps > > Please address any questions on the PWG agenda to Don Wright. Please address > any questions on a working group agenda to the working group chair. > > PING INFORMATION > > Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following > information: > > 1) What meeting dates will you attend? > 2) Will you stay at the Hyatt hotel? > 3) If you are staying at the Hyatt, what are your arrival and departure dates? > > On 2/11, I'll provide the information to the hotel, distribute a list of > attendees to the PWG distribution lists, and provide you with the meeting room > costs per day. On 2/12 you may start making your reservations at the Hyatt > hotel under the name "Printer Working Group". > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 From pwg-owner@pwg.org Tue Feb 3 00:32:26 1998 Delivery-Date: Tue, 03 Feb 1998 00:32:26 -0500 Return-Path: pwg-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA20533 for ; Tue, 3 Feb 1998 00:32:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA05686 for ; Tue, 3 Feb 1998 00:35:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA05914 for ; Tue, 3 Feb 1998 00:32:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 00:26:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA04856 for pwg-outgoing; Tue, 3 Feb 1998 00:17:34 -0500 (EST) Message-ID: <01BD301E.C8504DA0@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: RE: PWG> PWG meeting in Austin on 3/2-6 Date: Mon, 2 Feb 1998 21:08:59 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 107 TEXT Sender: owner-pwg@pwg.org Keith: I will be attending. 1) What meeting dates will you attend? 3-2 and 3-3 2) Will you stay at the Hyatt hotel? Yes 3) If you are staying at the Hyatt, what are your arrival and departure dates? Probably arrive the day before and leave the day after. Regards, Mark Edmead **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Monday, February 02, 1998 9:37 AM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Print gurus, > > I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the > scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. > > HOTEL INFORMATION > > Hyatt Regency Austin (located on Town Lake in downtown Austin). > Phone: 512-477-1234 > $101 per night (single occupancy). > Meeting room charge will be based on meeting attendance per day (see PING > INFORMATION) > Cab fare from airport is $12-14. > Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 > blocks for the athletically inclined). > Restaurants within 1 block of the hotel include: Threadgills (famous for their > home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al > Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). > The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) > and other restaurants are within a short drive of the hotel. > For you olympians, there is a public jogging trail that goes by the hotel and > around the lake. > > PWG MEETING AGENDA > > Here is the agenda proposed by Don Wright: > > Monday (3/2), Tuesday (3/3): > -- 1394 Printing > Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing > Wednesday (3/4) PM: > -- IPP > Thursday (3/5): > -- IPP > Friday (3/6): > -- Finisher > -- Job MIB Traps > > Please address any questions on the PWG agenda to Don Wright. Please address > any questions on a working group agenda to the working group chair. > > PING INFORMATION > > Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following > information: > > 1) What meeting dates will you attend? > 2) Will you stay at the Hyatt hotel? > 3) If you are staying at the Hyatt, what are your arrival and departure dates? > > On 2/11, I'll provide the information to the hotel, distribute a list of > attendees to the PWG distribution lists, and provide you with the meeting room > costs per day. On 2/12 you may start making your reservations at the Hyatt > hotel under the name "Printer Working Group". > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 From ipp-owner@pwg.org Tue Feb 3 00:47:48 1998 Delivery-Date: Tue, 03 Feb 1998 00:47:48 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA21074 for ; Tue, 3 Feb 1998 00:47:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA05725 for ; Tue, 3 Feb 1998 00:50:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA06524 for ; Tue, 3 Feb 1998 00:47:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 00:42:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA04891 for ipp-outgoing; Tue, 3 Feb 1998 00:18:00 -0500 (EST) Message-ID: <01BD301E.C8504DA0@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: IPP> RE: PWG> PWG meeting in Austin on 3/2-6 Date: Mon, 2 Feb 1998 21:08:59 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 107 TEXT Sender: ipp-owner@pwg.org Keith: I will be attending. 1) What meeting dates will you attend? 3-2 and 3-3 2) Will you stay at the Hyatt hotel? Yes 3) If you are staying at the Hyatt, what are your arrival and departure dates? Probably arrive the day before and leave the day after. Regards, Mark Edmead **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Monday, February 02, 1998 9:37 AM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Print gurus, > > I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the > scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. > > HOTEL INFORMATION > > Hyatt Regency Austin (located on Town Lake in downtown Austin). > Phone: 512-477-1234 > $101 per night (single occupancy). > Meeting room charge will be based on meeting attendance per day (see PING > INFORMATION) > Cab fare from airport is $12-14. > Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 > blocks for the athletically inclined). > Restaurants within 1 block of the hotel include: Threadgills (famous for their > home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al > Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). > The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) > and other restaurants are within a short drive of the hotel. > For you olympians, there is a public jogging trail that goes by the hotel and > around the lake. > > PWG MEETING AGENDA > > Here is the agenda proposed by Don Wright: > > Monday (3/2), Tuesday (3/3): > -- 1394 Printing > Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing > Wednesday (3/4) PM: > -- IPP > Thursday (3/5): > -- IPP > Friday (3/6): > -- Finisher > -- Job MIB Traps > > Please address any questions on the PWG agenda to Don Wright. Please address > any questions on a working group agenda to the working group chair. > > PING INFORMATION > > Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following > information: > > 1) What meeting dates will you attend? > 2) Will you stay at the Hyatt hotel? > 3) If you are staying at the Hyatt, what are your arrival and departure dates? > > On 2/11, I'll provide the information to the hotel, distribute a list of > attendees to the PWG distribution lists, and provide you with the meeting room > costs per day. On 2/12 you may start making your reservations at the Hyatt > hotel under the name "Printer Working Group". > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 From adm Tue Feb 3 02:12:47 1998 Delivery-Date: Tue, 03 Feb 1998 02:16:20 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id CAA23461 for ietf-outbound.10@ietf.org; Tue, 3 Feb 1998 02:10:03 -0500 (EST) Received: from germany.it.earthlink.net (germany-c.it.earthlink.net [204.250.46.123]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA23287 for ; Tue, 3 Feb 1998 02:05:08 -0500 (EST) Received: from bmonsour (1Cust57.tnt5.sfo3.da.uu.net [153.37.15.57]) by germany.it.earthlink.net (8.8.7/8.8.5) with SMTP id XAA24491; Mon, 2 Feb 1998 23:05:00 -0800 (PST) Message-Id: <3.0.1.32.19980202225716.00703958@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 02 Feb 1998 22:57:16 -0800 To: "William Allen Simpson" From: Bob Monsour Subject: Re: Last Call: IP Payload Compression ... Cc: ietf@ns.ietf.org, ippcp@external.cisco.com In-Reply-To: <6965.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bill, If you have objections or recommendations regarding the IP Payload Compression working group activities or the draft, I'd suggest copying them to the wg list. If you've made informal recommendations, it's likely to be news to those working on the drafts. At 08:00 PM 2/2/98 GMT, William Allen Simpson wrote: >While I'm thinking about it (with regard to IP compression techniques), >I'd like to make a more formal objection to the IP Payload Compression. >The Last Call expired Jan 20, but the new draft (-05) went the exact >opposite of my informal recommendations. > >This is a not unreasonable proposal. The main problem is that the >authors are coming from the IPSec arena, and thus concieved this as >an extension to IPSec, rather than taking a more general approach, >and incorporating both Header and Data compression. The wg was formed to solve the payload compression problem, not the header compression problem. As the IESG is attempting to set up working groups to solve specific problems and this was the scope agreed to with the area directors involved. See the charter excerpt below. >This draft suffers the same myopia that afflicts the Header Compression >with IPv6. The authors come from a particular background, and have not >envisioned a more general solution. > >But the worst problem, in my view, is that the draft does not stand on >its own. It is dependent on ISAKMP, used by some in the IPSec WG. As stated in the charter for the wg: The immediate problem the Working Group will address is the development of a payload compression protocol for use in conjunction with IPSec. The working group will develop its specifications to support both IPv4 and IPv6. Although the primary motivation for this WG is the need to compress packets when IPSec is used, the WG will develop an architecture that does not preclude its use with other potential protocols or the absence of IPSec. The working group will identify and document the mechanisms that allow two communicating parties to negotiate the use of compression as well as the compression format to be employed. The Working Group will consider defining extensions to ISAKMP to support the negotiation of compression parameters. Use of ISAKMP as the immediate effort shall not preclude compression in the absence of IPsec. Alternate negotiation mechanisms (or even static negotiation), if appropriate, shall be identified and extended as needed to accommodate the use of payload compression functionality. Since compression will be negotiated, existing implementations of IP will interoperate with implementations that support compression. [end charter excerpt] >In this recent draft, the compression numbers have been removed to the >ISAKMP DOI. Instead, those numbers should remain in this document, and >the ISAKMP DOI should refer to this document. All references to ISAKMP >should be removed! > >That change would allow this document to be referenced by other WG >efforts, including L2TP, MobileIP, and TLS. Why would TLS need to reference the IP payload specifications when TLS already includes the capability to negotiate and deploy compression (even though no algorithms have been defined for its use)? I would expect that in the absence of IPSec, L2TP and MobileIP would make use of PPP compression. If IPSec is present to protect those connections, then it would make sense to use IPPCP. >As in the Header Compression draft, terminology and typography could be >cleaned up considerably. In addition, these folks could learn a bit >about grammar from the non-native English speakers that wrote the Header >Compression draft. (heavy sigh) > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > > > ---------------------------------------------------------------- Bob Monsour Hi/fn Inc. rmonsour@hifn.com 2105 Hamilton Avenue 408-558-8065 Suite 230 408-558-8074 fax San Jose, CA 95125 ---------------------------------------------------------------- From adm Tue Feb 3 09:45:16 1998 Delivery-Date: Tue, 03 Feb 1998 09:50:36 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA02168 for ietf-outbound.10@ietf.org; Tue, 3 Feb 1998 09:45:02 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ext-ns3.baynetworks.com [192.32.253.3] (may be forged)) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02038 for ; Tue, 3 Feb 1998 09:42:12 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.84] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id JAA29045; Tue, 3 Feb 1998 09:37:19 -0500 (EST) Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with SMTP id JAA08942; Tue, 3 Feb 1998 09:36:51 -0500 (EST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA18143; Tue, 3 Feb 98 09:36:34 EST for ippcp@external.cisco.com Received: from ndoraswa.corpeast.baynetworks.com ([192.32.242.16]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA10834; Tue, 3 Feb 1998 09:35:32 -0500 Message-Id: <3.0.32.19980203093625.0077b62c@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Feb 1998 09:36:25 -0500 To: "Bernard Aboba" , "William Allen Simpson" , "Bob Monsour" From: Naganand Doraswamy Subject: Re: Last Call: IP Payload Compression ... Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" One of the goals of the working group was to define a compression protocol that works with or without ISAKMP. We thougth it should be generic enough to work with any key mgmt. protocol. However, it was decided to use ISAKMP as it is an Internet Standard Key Mgmt. Protocol. In the absence of ISAKMP, one can use their own key mgmt. protocol to negotiate keys. As we all know, all we need to is SPI and how the SPI is negotiated is upto the implementations. The DOI is key mgmt. protocol specific. We had a discussion on where to put the DOI values- the architecture draft or the DOI document and there was a consensus that it should be defined in the DOI draft. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)670-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From ipp-owner@pwg.org Tue Feb 3 12:22:57 1998 Delivery-Date: Tue, 03 Feb 1998 12:22:57 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA08390 for ; Tue, 3 Feb 1998 12:22:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08398 for ; Tue, 3 Feb 1998 12:25:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA08486 for ; Tue, 3 Feb 1998 12:22:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 12:11:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07670 for ipp-outgoing; Tue, 3 Feb 1998 11:55:53 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> TLS security section of protocol document Message-ID: <5030100017003897000002L072*@MHS> Date: Tue, 3 Feb 1998 11:55:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA08390 Is the approach in Network Working Group Ari Luotonen Request for Comments: XXXX Netscape Communications Corporation Category: Informational September, 1997 Tunneling SSL through Web Proxy Servers draft-luotonen-ssl-tunneling-03.txt, expires on 9/26/97 being considered for TLS? -Carl ipp-owner@pwg.org on 02/02/98 02:25:38 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> TLS security section of protocol document Just a note from the WG meeting in Hawaii... During the discussions of security related matters regarding using multiple HTTP methods at the last meeting, Josh brought up a point that proxies should be no problem with using a new method (such as PRINT) because it would just transparently pass it on through. I'm assuming that proxies do this with all methods the proxy does not recognize (unless some type of method filtering is turned on). This discussion got me thinking about proxies and IPP in general, with my initial conclusion being that we have a problem using TLS for end-to-end security in the presence of proxies. There is currently no standard for delegation of authentication info across proxies ( or any kind of "firewall" type of software). If the IPP client is configured to work with a particular proxy, and the IPP client is attempting communication with a TLS-based printer URI, we might need to indicate in the protocol document that this (and possibly other scenarios) can happen and what the implications of these scenarios might be. My immediate question is do we consider updating the security considerations section of the protocol document prior to IETF last call? Randy From ipp-owner@pwg.org Tue Feb 3 13:31:19 1998 Delivery-Date: Tue, 03 Feb 1998 13:31:20 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09942 for ; Tue, 3 Feb 1998 13:31:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09039 for ; Tue, 3 Feb 1998 13:33:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09662 for ; Tue, 3 Feb 1998 13:31:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 13:18:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08880 for ipp-outgoing; Tue, 3 Feb 1998 12:54:19 -0500 (EST) From: don@lexmark.com Message-Id: <199802031753.AA24062@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: sense@pwg.org, ipp@pwg.org Date: Mon, 2 Feb 1998 15:47:53 -0500 Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Jay Martin said: > >Harry Lewis wrote: > >> While there are many options that could become part of a notification scheme >> for print and printers, ranging from SNMPv3 to JAVA notification etc... I >> believe SENSE is definitely worthwhile considering. > >I appreciate your continued interest, Harry. But I really believe >that so much time has gone by that people will now be more interested >in pursuing other mechanisms. > >Recall that Sense was started in November of 1995. Technology has >moved along quite a bit since then. I have grown pretty tired of >constantly analyzing "Sense vs. XYZ" as new approaches have come >onto the scene. > >I really think it's time to just shut this effort down. > > ...jay I tend to agree with Jay... While the technology of SENSE is very much worth considering, I believe that rather than a stand-alone effort, SENSE or some parts of it might be folded into another project. There was a long, long discussion of notification at the IPP meeting last week and there was interest in investigating how some of the SENSE concepts and work could be included. I think this will be a hot topic for the Austin IPP meeting. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Feb 3 13:53:58 1998 Delivery-Date: Tue, 03 Feb 1998 13:53:58 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA10474 for ; Tue, 3 Feb 1998 13:53:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09138 for ; Tue, 3 Feb 1998 13:56:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA10825 for ; Tue, 3 Feb 1998 13:53:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 13:44:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09062 for ipp-outgoing; Tue, 3 Feb 1998 13:06:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl Kugler'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> TLS security section of protocol document Date: Tue, 3 Feb 1998 10:03:11 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org This and other work being considered for credential delegation would be potential solutions but nothing is standards-track (yet), and it is unclear whether anything is being considered for any kind of near-term deployment. If anyone has any other info, please post the DL. I haven't seen any activity on the ietf-tls-apps mailing list either. I just thought a paragraph describing the current situation might be needed in the protocol document, possibly before submission to the IESG for publication as an RFC. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Tuesday, February 03, 1998 8:56 AM To: ipp@pwg.org Subject: Re: IPP> TLS security section of protocol document Is the approach in Network Working Group Ari Luotonen Request for Comments: XXXX Netscape Communications Corporation Category: Informational September, 1997 Tunneling SSL through Web Proxy Servers draft-luotonen-ssl-tunneling-03.txt, expires on 9/26/97 being considered for TLS? -Carl ipp-owner@pwg.org on 02/02/98 02:25:38 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> TLS security section of protocol document Just a note from the WG meeting in Hawaii... During the discussions of security related matters regarding using multiple HTTP methods at the last meeting, Josh brought up a point that proxies should be no problem with using a new method (such as PRINT) because it would just transparently pass it on through. I'm assuming that proxies do this with all methods the proxy does not recognize (unless some type of method filtering is turned on). This discussion got me thinking about proxies and IPP in general, with my initial conclusion being that we have a problem using TLS for end-to-end security in the presence of proxies. There is currently no standard for delegation of authentication info across proxies ( or any kind of "firewall" type of software). If the IPP client is configured to work with a particular proxy, and the IPP client is attempting communication with a TLS-based printer URI, we might need to indicate in the protocol document that this (and possibly other scenarios) can happen and what the implications of these scenarios might be. My immediate question is do we consider updating the security considerations section of the protocol document prior to IETF last call? Randy From ipp-owner@pwg.org Tue Feb 3 13:55:49 1998 Delivery-Date: Tue, 03 Feb 1998 13:55:51 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA10526 for ; Tue, 3 Feb 1998 13:55:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09141 for ; Tue, 3 Feb 1998 13:58:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11020 for ; Tue, 3 Feb 1998 13:55:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 13:47:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09079 for ipp-outgoing; Tue, 3 Feb 1998 13:11:20 -0500 (EST) From: don@lexmark.com Message-Id: <199802031811.AA27864@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 3 Feb 1998 13:00:26 -0500 Subject: IPP> January Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the meeting minutes from the January Meeting in Maui. I have also posted these to the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0198.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0198.pdf ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ----------------------------------------------------------------- Internet Printing Project Meeting Minutes January 28/29, 1998 Kaanapali, Maui, Hawaii The meeting started on January 28, 1998 at 10:30 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: - Randy Turner - Sharp - Ron Bergman - DataProducts - Peter Zehler - Xerox - Lee Farrell - Canon - Bob Pentecost - HP - Dave Kuntz - HP - Kris Schoff - HP - Don Wright - Lexmark - Tom Hastings - Xerox - Carl-Uno Manros - Xerox - Stuart Rowley - Kyocera - Bob Herriot - Sun - Henrik Holst - I-Data - Atsushi Uchino - Seiko-Epson - Xavier Riley - Xerox - Harry Lewis - IBM - Josh Cohen - Microsoft - Paul Moore - Microsoft - Jim Walker - Dazel - Roberto Sannino - SGS Thomason Conference Call Dial-in Participants: - Jay Martin - Underscore - Ira MacDonald - HighNorth - Scott Isaacson - Novell - Roger Debry - IBM - Keith Carter - IBM - Steve Gebbler - IBM - Carl Kugler - IBM - Sven Johnson - Xerox - Peter Michalek - Shinesoft System - Daniel Manchala - Xerox - Shivaun Albright - HP Carl-Uno Manros reviewed the agenda for the day. Paul Moore started off the meeting with an overview of the Microsoft XML proposal including the proposal to use another method rather than POST. The charts used were distributed on the mailing list as IPPPRES.PPT, IPPPRES.PDF and as text before the meeting. The first area of discussion was whether we should use the POST method or create new methods. John Cohen presented the results of an informal survey he conducted asking HTTP server and Firewall vendors what they thought about it. He reported that most of those he surveyed did not what to overload POST. Next, Paul Moore presented the reasoning behind proposing XML as the structured data representation rather than the current IPP proposal. XML offers a way of describing complex structured data that wasn't available when the group originally considered using an simple ASCII representation. The proposal includes including the DTD in the spec but not forcing run-time DTD checking. Additionally XSL would not initially be included. Paul and Josh suggest using weak typing using multi-part related MIME. When should we do this? - with IPP V1 * XML is not ready yet * Creates legacy - with IPP V2 - Never Paul and Josh recommend doing it now using a simple subset of the total XML definition. Paul Moore listed the benefits of going to XML: 1) Extensibility issues which we haven't hit are probably already addressed by XML. 2) 3rd party tools that know how to parse XML will be able to parse IPP. 3) In environments where XML already exists, less new code is needed. The group identified some disadvantages of XML: 1) Over the wire, XML is less byte efficient than existing IPP. 2) Implementation experience would indicate that an XML parser would take 2 to 3 times more code space. The group broke for lunch. After lunch, the conference call began. The first issue discussed was whether we should discuss the technical merits of the proposal or discuss its appropriateness first. The group voted as to whether to discuss the technical merits or to reject the proposal as "too late" (Yes = Discuss, No = Reject) No Votes 13: Jay Martin, Ira MacDonald, Scott Isaacson, Roger Debry, Keith Carter, Steve Gebert, Carl Kugler, Sven Johnson, Peter M. (Shinesoft System), Daniel M. (Xerox), Ron Bergman, Harry Lewis, Don Wright Yes Votes 16: Randy Turner, Bob Pentecost, Kris Schoff, Dave Kuntz, Stuart Rowley, Henrik Holst, Paul Moore, Josh Cohen, Asushi Uchino, Lee Farrell, Jim Walker, Bob Herriot, Xavier Riley, Peter Zehler, Tom Hastings, Carl-Uno Manros The group began discussing the issue of replacing the POST method with one or more IPP specific methods. Paul Moore presented a summary of this issue for the conference call participants. There were are number of arguments presented from the other side including changes needed for many web servers, the fact that others use POST to pass data to back-end applications, etc. Roger Debry questioned the capability of adding additional methods to servers and hooking those methods to a Java Serverlet. The group discussed whether having a separate method would assist firewall administrators in differentiating print function versus using other ways to different and deal with the security issues of POST. Once the proposal goes to the IESG, there is a real possibility that the issue of POST could be raised as well as almost any other thing including the perpetual question of "why are we using HTTP?" No decision was made on this issue. The group moved to the issue of XML. Paul Moore presented the summary of "why XML" again. Bob Herriot presented his views on the PROs and CONs of using XML. The group discussed the issues again including data typing, new data types, footprint size of XML parser, etc. There were widely divergent opinions expressed. A discussion on the overall merits of XML and the problems with delaying IPP due to time to market issues. If we delay will some now non-compliant internet printing products ship confusing the marketplace? Randy Turner proposed forwarding the document to the IESG for last call to prevent the group spending 3 to 6 month on XML and then having the IESG reject the XML proposal. Should we send the current documents with the binary protocol to the IESG for last call? Submit Now: Roger Debry, Carl Kugler, Steve Gebert, Keith Carter, Harry Lewis, Ron Bergman, Jay Martin, Ira MacDonald, Shivaun Albright, Daniel M., Stuart Rowley, Henrik Holst, Atsushi Uchino, Don Wright, Bob Herriot, Xavier Riley, Peter Zehler, Tom Hastings, Carl-Uno Manros, Randy Turner Wait later: Bob Pentacost, Kris Schoff, Dave Kuntz, Paul Moore, Josh Cohen, Jim Walker The group re-affirmed its desire to take the existing documents to last call. The group began discussing what should be discussed tomorrow; some of wich could be considered for future enhancements for IPP V1+: - Enhancements in the area of multiple documents per job - document object - attributes for that object - Have we tried to please too many masters by developing a protocol for both the embedded printer and server based solutions? - Should we add a higher level of abstraction above "printer" to be able to represent a server with a pool of printers attached. - Revisit the philosophical decision to limit the intersection of IPP and SNMP. Should all the SNMP information be available through the IPP? - Automatic IPP printer installation - Notifications - Authorization (Access Control Lists) - Job Management - Printer Management - Print System Management - IPP MIB - Printing Commerce - Accounting - Fonts - Dictionary Syntax - Universal Print Driver Overview The meeting adjourned for the day at 5:15 PM. The meeting resumed on Thursday at 8:45 AM. Peter Zehler led the discussion on the Testing and Prototyping effort. The agenda was: A) Testing methodology 1) How to test an implementation - test suite - scenarios - simple instructions, capture of results, compare - trace file repository 2) Internet Pair-wise test/bake-off 3) Face to face bake-up 4) How to document results 5) Establish milestones - develop test plan (Pete & Randy) 2 weeks - organize pair-wise testing (Pete) - update FAQ (Carl-Uno) 2 weeks 6) Public Demo - At a trade show such as Xplor or Fall Networld-Interop - At some other locale B) Conformance/Compliance 1) Minimum level definition 2) Operation & Attribute coverage 3) Security coverage & intervention C) Preliminary Schedule for milestones, action items and deliverables - Who is developing IPP clients/servers? IBM (prototype client ready, server not ready) Sharp (prototype server ready, client almost) -- ipp.sharplabs.com HP (defers to Microsoft (client and server)) Kyocera (not ready) I-Data (not ready) Microsoft (client and server prototypes subsequent to NT Beta 1) Epson (not ready) Canon (not ready) Dazel (not ready) Lexmark (not ready) Sun (not ready) Xerox (1 test client, 2 servers) - How soon can pair-wise testing occur? - Develop test plan (Pete & Randy) - test cases - good - bad - chunked - collect and document problems, post to TES DL (Pete Z) - Hide owners of prototype in test - less of concern with early prototypes versus shipping products - advantage of privacy from 3rd party - disadvantage in follow-up - should focus on misunderstandings of the spec - data gathered could be used to create an "Implementers guide to IPP" What do we think the behavior be if the client is unable to send a job to a non- spooling printer? - should operations, etc. be defined in the protocol to handle this? - should the client report back the situation but continue trying but send without "locking out" the user? - is this a TCP/IP, an HTTP, or an IPP error? - How do we make IPP a great experience? - How can IPP be able to do much more than what LPD and other existing print services? - Can we come up with a consistent contention model due to the interaction of IPP with Web servers, etc. - Contention is not an error, it is really normal operation. - Should we more accurately call some of the responses as status codes rather than error codes? - Randy will post a list of network programming issues for IPP. A subgroup will be formed from interested parties after this is posted. Paul Moore and Randy Turner will kick off this effort to clarify the contention behavior of V1 and identify potential work in this area for a future enhancement to IPP V1. The LP-to-IPP mapping document should include this issue. The group attempted to identify the high priority items from the discussion list created yesterday. 6 - Enhancements in the area of multiple documents per job - document object - attributes for that object 0 - Have we tried to please too many masters by developing a protocol for both the embedded printer and server based solutions? 2 - Should we add a higher level of abstraction above "printer" to be able to represent a server with a pool of printers attached. 10 - Revisit the philosophical decision to limit the intersection of IPP and SNMP. Should all the SNMP information be available through the IPP? 2 - Automatic IPP printer installation 6 - Notifications 0 - Authorization (Access Control Lists) 6 - Job Management 6 - Printer Management 1 - Print System Management 0 - IPP MIB 1 - Printing Commerce 3 - Accounting 5 - Fonts 1 - Dictionary Syntax 9 - Universal Print Driver Overview 1 - defaulting Dictionary Syntax: Tom Hastings and Roger Debry will present a proposal. IPP versus SNMP: - server based versus embedded - if we add a "server" to the model, on which end of the protocol is the server? + from the printer perspective the server is on the source end + from the client perspective the server is on the target end - IPP Method to retrieve SNMP OID? - Could additional printer attributes to enable getting and setting printer characteristics that are now only accessible by using SNMP. - What would the media model be -- select by tray or select by name? -- the OS probably needs both because the user might want to see it presented different ways. - Could use IPP to configure drivers? - We could push to get SNMP mgmt of printers allowed through firewalls - Tom Hastings will kick off the efforts. Interested participants should contact Tom. Universal Printer Driver: Paul Moore described the capabilities of GPD and Unidrive 5 from the perspective of creating a universal print driver. +--------------------+ | | | Client | | | +--------------------+ ^ | V +--------------------+ | | | Unidrive 5 | | | +--------------------+ ^ | Generic | | +-------+ Printer ------- +---->| | Description | Prtr | +-------+ The OS uses the GPD to dynamically build the UI for the printer based upon the device options, constraints and other information provided with the printer and information provided at install time. The GPD syntax has the ability to include macros which can be called to set a group of setting to achieve some singular purpose (fastest, best quality, etc.) GPDs - ASCII text - about 30K per printer - escapes for advanced features / UI - NT 5 supports about 1000 printers Documentation for GPD is available in the NT 5 DDK. Paul Moore proposed that the group look at the current GPD syntax and investigate standardizing the syntax. There are certain parts of GPD today that are Windows specific and would perhaps need to be made more general. Additionally, additional functions could be identified that might need to be added. The group decided to take a look at specification and whether to work on this as a standard will be discussed at a future meeting. Notification: Randy Turner presented his thoughts on notification. . . - Should it be ASYNC (out of band)? - How timely should the notification occur? - Should it be reliable - Should we use a protocol outside IPP? - What type of information should be included in a notification? (Enumerate type of notifications) - Subscription and filtering - Subscription lifetimes ** Are "job finished" kind of messages which might be e-mailed different from other types of notifications (i.e. alerts( such as "interpreter error" ** Should the "alert" contain both machine readable and human readable fields ** Should notifications be directly readable by the recipient or should an application that receives the notifications be assumed? ** E-mail is really a special case that should be optional and included with the job submission that creates an e-mail when the job completes, aborts, etc. ** Could have both e-mail and IPP protocol notifications where the IPP protocol notification reports a superset of the e-mail method. ** LDAP includes something called a "persistence search" which includes maintaining an open connection which causes the notification to return when the criteria is met. We could use a similar concept. ** If we specified a means where the printer would notify by opening a connection on a certain port then that would require the client to listen for opens. ** Should we look at SENSE again? How is it applicable to this scenario? There are a number of issues about opening and maintaining connections. How does the server remember subscriptions if the connection is closed? John Cohen says there are some other efforts underway to create a generic notification service. He will post more information on the mailing list. Job Management: - Additional job management operations like * Hold, Resume * Move * Modify Printer Management: - Is SNMP good enough? - What about its reliability? What about firewalls and SNMP? Multi-document Jobs: - Need to add the Document Object back into the model - Would allow more flexibility to controlling documents - Jim Walker will distribute his thoughts on this subject to the DL. Do we need a slot in the next IETF meeting? -- Yes. The meeting adjourned at 5:35 PM. From ipp-owner@pwg.org Tue Feb 3 14:32:29 1998 Delivery-Date: Tue, 03 Feb 1998 14:32:30 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA11205 for ; Tue, 3 Feb 1998 14:32:29 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09404 for ; Tue, 3 Feb 1998 14:35:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA11951 for ; Tue, 3 Feb 1998 14:32:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 14:20:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11141 for ipp-outgoing; Tue, 3 Feb 1998 13:56:52 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1BA@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Notifications Date: Tue, 3 Feb 1998 10:51:15 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Has anybody noticed that IPP will be useless for notifications due to the asymmetry of the protocol? As currently constituted a printer cannot send an unsolicted message to anybody. Was this discussed later on on the Thursday brainstorm? From ipp-owner@pwg.org Tue Feb 3 14:56:46 1998 Delivery-Date: Tue, 03 Feb 1998 14:56:47 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA11740 for ; Tue, 3 Feb 1998 14:56:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09677 for ; Tue, 3 Feb 1998 14:59:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12728 for ; Tue, 3 Feb 1998 14:56:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 14:44:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11197 for ipp-outgoing; Tue, 3 Feb 1998 14:06:19 -0500 (EST) Message-Id: <3.0.1.32.19980203093704.00905940@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Feb 1998 09:37:04 PST To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> TLS security section of protocol document In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 06:03 PM 2/2/98 PST, Turner, Randy wrote: > >Just a note from the WG meeting in Hawaii... > >During the discussions of security related matters regarding using >multiple >HTTP methods at the last meeting, Josh brought up a point that proxies >should be no problem with using a new method (such as PRINT) because it >would just transparently pass it on through. I'm assuming that proxies >do this with all methods the proxy does not recognize (unless some type >of method filtering is turned on). > >This discussion got me thinking about proxies and IPP in general, with >my initial conclusion being that we have a problem using TLS for >end-to-end security in the presence of proxies. There is currently no >standard for delegation of authentication info across proxies ( or any >kind of "firewall" type of software). If the IPP client is configured to >work with a particular proxy, and the IPP client is attempting >communication with a TLS-based printer URI, we might need to indicate in >the protocol document that this (and possibly other scenarios) can >happen and what the implications of these scenarios might be. > >My immediate question is do we consider updating the security >considerations section of the protocol document prior to IETF last call? > >Randy > Randy, I think that anything to do with proxy servers and firewalls can only reliably be found out by real life testing, which is what Proposed Standards are for. I do not see any points in doing further updates to the our specification at this stage. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 3 15:16:07 1998 Delivery-Date: Tue, 03 Feb 1998 15:16:07 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA12267 for ; Tue, 3 Feb 1998 15:16:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09848 for ; Tue, 3 Feb 1998 15:18:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13795 for ; Tue, 3 Feb 1998 15:15:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 15:06:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11478 for ipp-outgoing; Tue, 3 Feb 1998 14:23:11 -0500 (EST) From: Roger K Debry To: Cc: Subject: IPP> ipp> Minutes Message-ID: <5030100017011661000002L012*@MHS> Date: Tue, 3 Feb 1998 14:22:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA12267 Don, in the minutes is a table with priorities for follow on work. Is 0 highest priority or lowest? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Feb 3 15:18:14 1998 Delivery-Date: Tue, 03 Feb 1998 15:18:14 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA12316 for ; Tue, 3 Feb 1998 15:18:13 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09877 for ; Tue, 3 Feb 1998 15:20:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14083 for ; Tue, 3 Feb 1998 15:18:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 15:10:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11979 for ipp-outgoing; Tue, 3 Feb 1998 14:32:55 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" , "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 11:29:28 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Yes, this was discussed. Several solutions were proposed. Check out the minutes of the IPP meeting that Don just posted. I think some of the ideas were included in the minutes. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Tuesday, February 03, 1998 10:51 AM To: 'ipp@pwg.org' Subject: IPP> Notifications Has anybody noticed that IPP will be useless for notifications due to the asymmetry of the protocol? As currently constituted a printer cannot send an unsolicted message to anybody. Was this discussed later on on the Thursday brainstorm? From ipp-owner@pwg.org Tue Feb 3 16:29:48 1998 Delivery-Date: Tue, 03 Feb 1998 16:29:49 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA14833 for ; Tue, 3 Feb 1998 16:29:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10492 for ; Tue, 3 Feb 1998 16:32:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA15016 for ; Tue, 3 Feb 1998 16:29:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 16:21:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14371 for ipp-outgoing; Tue, 3 Feb 1998 16:05:42 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1C7@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Turner, Randy'" , "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 13:05:03 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org The minutes dont really discuss it. There is talk about email vs 'IPP notifications' But no real discussion of how IPP notification could be done. A device-level protocol that does not allow Out of band feedback seems pretty broken > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Tuesday, February 03, 1998 11:29 AM > To: Paul Moore; 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > > Yes, this was discussed. Several solutions were proposed. Check out the > minutes of the IPP meeting that Don just posted. > I think some of the ideas were included in the minutes. > > Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 10:51 AM > To: 'ipp@pwg.org' > Subject: IPP> Notifications > > Has anybody noticed that IPP will be useless for notifications > due to the > asymmetry of the protocol? As currently constituted a printer > cannot send an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? From ipp-owner@pwg.org Tue Feb 3 17:27:50 1998 Delivery-Date: Tue, 03 Feb 1998 17:27:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA16868 for ; Tue, 3 Feb 1998 17:27:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11704 for ; Tue, 3 Feb 1998 17:30:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15948 for ; Tue, 3 Feb 1998 17:27:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 17:11:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14810 for ipp-outgoing; Tue, 3 Feb 1998 16:25:56 -0500 (EST) Message-Id: <3.0.1.32.19980203132256.00ca7500@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Feb 1998 13:22:56 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - Notifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 10:51 AM 2/3/98 PST, you wrote: >Has anybody noticed that IPP will be useless for notifications due to the >asymmetry of the protocol? As currently constituted a printer cannot send an >unsolicted message to anybody. > >Was this discussed later on on the Thursday brainstorm? > Paul, This has been extensively discussed in previous meetings and phone conferences. We are aware of the fact that IPP is a client-server protocol based on HTTP, which has some limitations. You can always find out about a print job by asking the IPP server what happened to it (Hint - heard about PUSH technology?). If we want to have a notification service that is initiated by the IPP server, we will need a separate notification protocol, which could either be unique for IPP notifications or more general to notify events from a number of different services. Previous discussions seemed to favor the letter approach, which is why we decided not to tackle it as part of IPP V1.0. We may actually only need to specify a MIME type with the right kind of content, which can be sent by email, FTP, HTTP or whatever transport is available on the IPP client side. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 3 17:40:05 1998 Delivery-Date: Tue, 03 Feb 1998 17:40:06 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17216 for ; Tue, 3 Feb 1998 17:40:05 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11775 for ; Tue, 3 Feb 1998 17:42:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16685 for ; Tue, 3 Feb 1998 17:39:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 17:27:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15108 for ipp-outgoing; Tue, 3 Feb 1998 16:32:44 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" , "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 13:29:20 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I remember we talked about maintaining persistent connections to the server during job processing, as well as possibly having the clients allocate a socket to receive UDP or TCP - based notifications from a server. And on your last statement, I disagree that we have a device-level protocol; Most IPP servers, including your own, will be implemented on server-based systems, detached from the actual physical printer. Its possible that some server-based implementations might not have device-level access or at least accurate realtime access to device status. Nonetheless, I would like to see further discussion on this topic via the mailing list. I personally favor something along the lines of a UDP message sent to a client socket from the server which includes some type of encapsulated notification message. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Tuesday, February 03, 1998 1:05 PM To: 'Turner, Randy'; 'ipp@pwg.org' Subject: RE: IPP> Notifications The minutes dont really discuss it. There is talk about email vs 'IPP notifications' But no real discussion of how IPP notification could be done. A device-level protocol that does not allow Out of band feedback seems pretty broken > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Tuesday, February 03, 1998 11:29 AM > To: Paul Moore; 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > > Yes, this was discussed. Several solutions were proposed. Check out the > minutes of the IPP meeting that Don just posted. > I think some of the ideas were included in the minutes. > > Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 10:51 AM > To: 'ipp@pwg.org' > Subject: IPP> Notifications > > Has anybody noticed that IPP will be useless for notifications > due to the > asymmetry of the protocol? As currently constituted a printer > cannot send an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? From ipp-owner@pwg.org Tue Feb 3 17:46:31 1998 Delivery-Date: Tue, 03 Feb 1998 17:46:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17444 for ; Tue, 3 Feb 1998 17:46:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11823 for ; Tue, 3 Feb 1998 17:49:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17551 for ; Tue, 3 Feb 1998 17:46:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 17:37:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15180 for ipp-outgoing; Tue, 3 Feb 1998 16:41:39 -0500 (EST) Message-Id: <3.0.1.32.19980203133133.00ca8230@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Feb 1998 13:31:33 PST To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP> ipp> Minutes Cc: In-Reply-To: <5030100017011661000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:22 AM 2/3/98 PST, Roger K Debry wrote: >Don, in the minutes is a table with priorities for follow on work. >Is 0 highest priority or lowest? > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > Roger, the numbers represent the number of people who wanted to spend time on the subject in Maui. So high numbers represent interest, with 0 equal to no interest. 0 votes does not mean that the subject should not be discussed later. BTW, I decided that we will take this Wednesday off without a phone conference. If we have new subjects for discussion next week, I suggest you let me know by the end of this week so we can set up a conference next week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 3 17:48:33 1998 Delivery-Date: Tue, 03 Feb 1998 17:48:34 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17493 for ; Tue, 3 Feb 1998 17:48:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11838 for ; Tue, 3 Feb 1998 17:51:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17820 for ; Tue, 3 Feb 1998 17:48:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 17:40:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15210 for ipp-outgoing; Tue, 3 Feb 1998 16:46:06 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1C9@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Turner, Randy'" , "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 13:45:08 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org What I was meaning regarding device level protocol is -- Today we have something that does not push the server or printer envelope - I agree it cannot be called a device protocol. We did discuss extending IPP into very precise printer managment (feature and configurtion discovery and control, plus some maybe queuing control). I really need a protocol to fill that space and I know others do as well. The fact that IPP will be severly challenged as it currently stands is a potential showstopper. The problem with using a non-HTTP based solution is the old firewall/proxy argument. We could be in the wierd position where IPP can reach the device but the notifications cannot get back. That, in theory would make a whole chunk of the protocol optional and therefore useless. Putting a web server on the client seems a bit of a sledge hammer sized solution. One solution - carry everything on raw TCP. I dont like UDP - it is a 'best endeavors' transport. You cannot build real functionality based on it because you never know if you will receive the messages. (This was the whole point of SENSE) > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Tuesday, February 03, 1998 1:29 PM > To: Paul Moore; 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > > I remember we talked about maintaining persistent connections to the > server during job processing, as well as possibly having the clients > allocate a socket to receive UDP or TCP - based notifications from a > server. And on your last statement, I disagree that we have a > device-level protocol; Most IPP servers, including your own, will be > implemented on server-based systems, detached from the actual physical > printer. Its possible that some server-based implementations might not > have device-level access or at least accurate realtime access to device > status. > > Nonetheless, I would like to see further discussion on this topic via > the mailing list. I personally favor something along the lines of a UDP > message sent to a client socket from the server which includes some type > of encapsulated notification message. > > Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 1:05 PM > To: 'Turner, Randy'; 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > The minutes dont really discuss it. There is talk about email vs > 'IPP > notifications' But no real discussion of how IPP notification > could be done. > A device-level protocol that does not allow Out of band feedback > seems > pretty broken > > > -----Original Message----- > > From: Turner, Randy [SMTP:rturner@sharplabs.com] > > Sent: Tuesday, February 03, 1998 11:29 AM > > To: Paul Moore; 'ipp@pwg.org' > > Subject: RE: IPP> Notifications > > > > > > Yes, this was discussed. Several solutions were proposed. > Check out the > > minutes of the IPP meeting that Don just posted. > > I think some of the ideas were included in the minutes. > > > > Randy > > > > > > -----Original Message----- > > From: Paul Moore [SMTP:paulmo@microsoft.com] > > Sent: Tuesday, February 03, 1998 10:51 AM > > To: 'ipp@pwg.org' > > Subject: IPP> Notifications > > > > Has anybody noticed that IPP will be useless for > notifications > > due to the > > asymmetry of the protocol? As currently constituted a > printer > > cannot send an > > unsolicted message to anybody. > > > > Was this discussed later on on the Thursday brainstorm? From adm Tue Feb 3 19:05:19 1998 Delivery-Date: Tue, 03 Feb 1998 19:09:07 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id TAA18798 for ietf-outbound.10@ietf.org; Tue, 3 Feb 1998 19:05:02 -0500 (EST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA17991 for ; Tue, 3 Feb 1998 18:07:15 -0500 (EST) Received: from shacham-home-pc-4.cisco.com (shacham-home-pc-4.cisco.com [171.69.149.181]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id PAA27533; Tue, 3 Feb 1998 15:06:42 -0800 (PST) Message-Id: <2.2.32.19980203230539.006e3f7c@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Feb 1998 15:05:39 -0800 To: "William Allen Simpson" From: Avram Shacham Subject: Re: Last Call: IP Payload Compression ... Cc: ietf@ns.ietf.org, ippcp@external.cisco.com William Allen Simpson, Bob Monsour, Bernard Aboba, and Naganand Doraswamy already answered most of the technical issues that you raised in your message, which Bob was kind enough to post to the IPPCP mailing-list. I'll add some facts and my comments on your history perspective and style. First, let me put some facts forward: 1. You are a member of the IPPCP mailing-list. 2. You _never_ posted a comment to the list, as grep-ing the 777KB archive shows. 3. The archive also shows that you were explicitly CC-ed to two messages, both dealing with the DOI aspects of IPComp and both dated 6-97. I'll forward these messages to you if you have any problem scanning the IPPCP archive. 4. A reference to the DOI draft was present in all versions of my draft, starting with version 00, posted 7-97, and continuing through the latest version, version 05. 5. The wg last-call for the protocol was issued and passed 11-97. The IESG last-call passed 1-19-98. And with these facts cleared, let's refer to the specifics of some of your issues: >At 08:00 PM 2/2/98 GMT, William Allen Simpson wrote: >>While I'm thinking about it (with regard to IP compression techniques), >>I'd like to make a more formal objection to the IP Payload Compression. >>The Last Call expired Jan 20, but the new draft (-05) Version 05 of the draft incorporated the recommendations of the IANA for wording the reference to DOI, as conveyed to the AD during the IESG last-call. Run any diff utility between version 04 and 05 to see the exact changes. You may also read the details of the changes, as included in my note to the mailing-list. >>went the exact opposite of my informal recommendations. What are those "informal recommendations" of yours? To what forum did you post your comments? >>This is a not unreasonable proposal. The main problem is that the >>authors are coming from the IPSec arena, and thus concieved this as ^^^^^^^^^ conceived (?) >>an extension to IPSec, rather than taking a more general approach, >>and incorporating both Header and Data compression. (a) The wg explicitly detached its work and drafts from IPSec. Had you attended the Munich meeting, you could have heard this fact yourself. (b) And, as the editor of the IPComp draft, I am far from being involved with IPSec. True, sometimes I read the exchanges on the IPSec list, including those in which you are involved. No doubt that your style is consistent cross mailing-lists. (c) The wg _decided_ not to compress the IP header. This increased the overall compression performance. >>This draft suffers the same myopia that afflicts the Header Compression >>with IPv6. The authors come from a particular background, and have not >>envisioned a more general solution. >> >>But the worst problem, in my view, is that the draft does not stand on >>its own. It is dependent on ISAKMP, used by some in the IPSec WG. The draft specifies three (3) mechanisms of negotiations. ISAKMP is one of those options. Please read section 4 of the document. >>In this recent draft, the compression numbers have been removed to the >>ISAKMP DOI. Instead, those numbers should remain in this document, and >>the ISAKMP DOI should refer to this document. The compression numbers were never included in the IPComp document. All post-Munich versions referred to the DOI draft. >>All references to ISAKMP should be removed! And your reasons are? >>That change would allow this document to be referenced by other WG >>efforts, including L2TP, MobileIP, and TLS. Why should L3 compression be referred to by other-layer protocols? >>As in the Header Compression draft, terminology and typography could be >>cleaned up considerably. In addition, these folks could learn a bit >>about grammar from the non-native English speakers that wrote the Header >>Compression draft. I duly note that you made this comment without referring to a single instance in the document where "terminology," "typography", or "grammar" is lacking. If you wish to present compositional inadequacies in the draft, you are welcome to do so, so long as you cite concrete examples. Doubtless one or two such mistakes slipped through the rigorous proof-reading process; you are welcome to bring your presumably illustrious knowledge of English to bear on these unfortunate errors. >> (heavy sigh) Heavy sigh indeed. avram From ipp-owner@pwg.org Tue Feb 3 19:12:12 1998 Delivery-Date: Tue, 03 Feb 1998 19:12:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA18971 for ; Tue, 3 Feb 1998 19:12:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12060 for ; Tue, 3 Feb 1998 19:14:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19414 for ; Tue, 3 Feb 1998 19:12:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 19:00:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17945 for ipp-outgoing; Tue, 3 Feb 1998 18:17:52 -0500 (EST) Message-ID: <34D7A5C7.88816311@zeno.com> Date: Tue, 03 Feb 1998 15:18:31 -0800 From: zhi-hong@zeno.com (Zhi-Hong Huang) Organization: Zenographics, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Notifications References: <5CEA8663F24DD111A96100805FFE6587030BC1C9@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I don't see there is any need for the client to open another socket waiting for the server notification. Since an IPP connection is persistent, the server can notify the client over the same socket any time. If a notification needs to be sent after the session is closed, the server can wait until the same client opens another session, provided that the server can uniquely identify the client. For completeness, a time-to-live for the message may need to be defined. What this means is that if the client is ever interested in any notification from the server, it should remain online or check back with the server later. From ipp-owner@pwg.org Tue Feb 3 19:22:11 1998 Delivery-Date: Tue, 03 Feb 1998 19:22:11 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA19346 for ; Tue, 3 Feb 1998 19:22:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12088 for ; Tue, 3 Feb 1998 19:24:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20523 for ; Tue, 3 Feb 1998 19:22:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 19:14:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18421 for ipp-outgoing; Tue, 3 Feb 1998 18:28:36 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D09B5@red-86-msg.dns.microsoft.com> From: Josh Cohen To: Paul Moore , "'Turner, Randy'" , "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 15:28:10 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I thought the consensus that the first step was to have a requirements document written up for IPP. Since there are many generalized notification efforts underway ( or soon to be), we can judge the suitability of using one of them or writing one specific to IPP. However, that can only be done if we know our requirements first. -> -----Original Message----- -> From: Paul Moore -> Sent: Tuesday, February 03, 1998 1:05 PM -> To: 'Turner, Randy'; 'ipp@pwg.org' -> Subject: RE: IPP> Notifications -> -> -> The minutes dont really discuss it. There is talk about email vs 'IPP -> notifications' But no real discussion of how IPP -> notification could be done. -> A device-level protocol that does not allow Out of band -> feedback seems -> pretty broken -> -> > -----Original Message----- -> > From: Turner, Randy [SMTP:rturner@sharplabs.com] -> > Sent: Tuesday, February 03, 1998 11:29 AM -> > To: Paul Moore; 'ipp@pwg.org' -> > Subject: RE: IPP> Notifications -> > -> > -> > Yes, this was discussed. Several solutions were proposed. -> Check out the -> > minutes of the IPP meeting that Don just posted. -> > I think some of the ideas were included in the minutes. -> > -> > Randy -> > -> > -> > -----Original Message----- -> > From: Paul Moore [SMTP:paulmo@microsoft.com] -> > Sent: Tuesday, February 03, 1998 10:51 AM -> > To: 'ipp@pwg.org' -> > Subject: IPP> Notifications -> > -> > Has anybody noticed that IPP will be useless for notifications -> > due to the -> > asymmetry of the protocol? As currently constituted a printer -> > cannot send an -> > unsolicted message to anybody. -> > -> > Was this discussed later on on the Thursday brainstorm? -> From ipp-owner@pwg.org Tue Feb 3 19:23:19 1998 Delivery-Date: Tue, 03 Feb 1998 19:23:19 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA19370 for ; Tue, 3 Feb 1998 19:23:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12094 for ; Tue, 3 Feb 1998 19:25:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20660 for ; Tue, 3 Feb 1998 19:23:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 19:15:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18741 for ipp-outgoing; Tue, 3 Feb 1998 18:33:39 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 15:30:11 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Yes, I agree, we need a requirements document first. I can't remember who had the action item for this. Randy -----Original Message----- From: Josh Cohen [SMTP:joshco@microsoft.com] Sent: Tuesday, February 03, 1998 3:28 PM To: Paul Moore; 'Turner, Randy'; 'ipp@pwg.org' Subject: RE: IPP> Notifications I thought the consensus that the first step was to have a requirements document written up for IPP. Since there are many generalized notification efforts underway ( or soon to be), we can judge the suitability of using one of them or writing one specific to IPP. However, that can only be done if we know our requirements first. -> -----Original Message----- -> From: Paul Moore -> Sent: Tuesday, February 03, 1998 1:05 PM -> To: 'Turner, Randy'; 'ipp@pwg.org' -> Subject: RE: IPP> Notifications -> -> -> The minutes dont really discuss it. There is talk about email vs 'IPP -> notifications' But no real discussion of how IPP -> notification could be done. -> A device-level protocol that does not allow Out of band -> feedback seems -> pretty broken -> -> > -----Original Message----- -> > From: Turner, Randy [SMTP:rturner@sharplabs.com] -> > Sent: Tuesday, February 03, 1998 11:29 AM -> > To: Paul Moore; 'ipp@pwg.org' -> > Subject: RE: IPP> Notifications -> > -> > -> > Yes, this was discussed. Several solutions were proposed. -> Check out the -> > minutes of the IPP meeting that Don just posted. -> > I think some of the ideas were included in the minutes. -> > -> > Randy -> > -> > -> > -----Original Message----- -> > From: Paul Moore [SMTP:paulmo@microsoft.com] -> > Sent: Tuesday, February 03, 1998 10:51 AM -> > To: 'ipp@pwg.org' -> > Subject: IPP> Notifications -> > -> > Has anybody noticed that IPP will be useless for notifications -> > due to the -> > asymmetry of the protocol? As currently constituted a printer -> > cannot send an -> > unsolicted message to anybody. -> > -> > Was this discussed later on on the Thursday brainstorm? -> From ipp-owner@pwg.org Tue Feb 3 21:38:49 1998 Delivery-Date: Tue, 03 Feb 1998 21:38:50 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA23016 for ; Tue, 3 Feb 1998 21:38:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12424 for ; Tue, 3 Feb 1998 21:41:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23235 for ; Tue, 3 Feb 1998 21:38:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 21:17:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20843 for ipp-outgoing; Tue, 3 Feb 1998 20:05:33 -0500 (EST) Message-ID: <34D7BEB4.1033438D@parc.xerox.com> Date: Tue, 3 Feb 1998 17:04:52 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I believe that "mailto" can include session-based connectivity if it's available. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 3 21:41:16 1998 Delivery-Date: Tue, 03 Feb 1998 21:41:16 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA23122 for ; Tue, 3 Feb 1998 21:41:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12433 for ; Tue, 3 Feb 1998 21:43:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23521 for ; Tue, 3 Feb 1998 21:41:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 21:18:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20824 for ipp-outgoing; Tue, 3 Feb 1998 20:02:35 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Larry Masinter'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 16:59:12 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Yes, I think we will probably reach agreement on a job completion notification via email. The real arguments will come when we want a more or less "realtime" (non store-and-forward) notification of events happening on a particular server. Randy -----Original Message----- From: Larry Masinter [SMTP:masinter@parc.xerox.com] Sent: Tuesday, February 03, 1998 4:56 PM To: Turner, Randy Cc: 'Paul Moore'; 'ipp@pwg.org' Subject: Re: IPP> Notifications I like the idea of the client supplying, as part of a request, the URL for notifications. In email, this address could be supplied by the disposition-notification-to header, as with any kind of receipt notification. For requests that get delivered via IPP and POST, the address to which notifications get posted could be supplied by the client via a URL, too. Clients would have to know their own address, though, and make some kind of service guarantee that they're willing to listen to responses at that address. In some cases, the address of notification will be different than the client address. In email delivery for Internet Fax, we've also wanted to have a notification protocol for "successful printing"; I'd like to make sure that IPP and Internet Fax don't invent different mechanisms for no good reason. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 3 21:41:32 1998 Delivery-Date: Tue, 03 Feb 1998 21:41:32 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA23134 for ; Tue, 3 Feb 1998 21:41:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12436 for ; Tue, 3 Feb 1998 21:44:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23541 for ; Tue, 3 Feb 1998 21:41:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 21:19:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20849 for ipp-outgoing; Tue, 3 Feb 1998 20:05:43 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1D0@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Larry Masinter'" , "Turner, Randy" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Tue, 3 Feb 1998 17:05:20 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org We need to distinguish two types of notification. (This was a long and exciting debate in Maui!). Firstly a client should be able to request that (for exmaple) when a print job is completed that a human readable notification be sent to some URL, that a pager be bleeped, that a robot arm should waved over a fire to create a smoke signal, whatever. We also agreed that if IPP were to be extended to manage the lower level interface from the server/cleint to the printer then some machine readable noification mechanism was needed. For example the printer is running low on paper it may signal a listener somewhere, if a configuration change takes place or whatever. This notification may even be the 'job completed' notification back to a server that triggers it to send the human readable notification that was requested in the original print job from the client to the server. > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Tuesday, February 03, 1998 4:56 PM > To: Turner, Randy > Cc: Paul Moore; 'ipp@pwg.org' > Subject: Re: IPP> Notifications > > I like the idea of the client supplying, as part of a request, > the URL for notifications. In email, this address could be > supplied by the disposition-notification-to header, as with any > kind of receipt notification. For requests that get delivered > via IPP and POST, the address to which notifications get posted > could be supplied by the client via a URL, too. Clients would > have to know their own address, though, and make some kind of > service guarantee that they're willing to listen to responses > at that address. In some cases, the address of notification will > be different than the client address. > > In email delivery for Internet Fax, we've also wanted to have > a notification protocol for "successful printing"; I'd like to > make sure that IPP and Internet Fax don't invent different > mechanisms for no good reason. > > Larry > -- > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 3 21:43:44 1998 Delivery-Date: Tue, 03 Feb 1998 21:43:44 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA23180 for ; Tue, 3 Feb 1998 21:43:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12442 for ; Tue, 3 Feb 1998 21:46:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23820 for ; Tue, 3 Feb 1998 21:43:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 21:21:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20800 for ipp-outgoing; Tue, 3 Feb 1998 19:56:53 -0500 (EST) Message-ID: <34D7BCB4.6F002D50@parc.xerox.com> Date: Tue, 3 Feb 1998 16:56:20 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: "Turner, Randy" CC: "'Paul Moore'" , "'ipp@pwg.org'" Subject: Re: IPP> Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I like the idea of the client supplying, as part of a request, the URL for notifications. In email, this address could be supplied by the disposition-notification-to header, as with any kind of receipt notification. For requests that get delivered via IPP and POST, the address to which notifications get posted could be supplied by the client via a URL, too. Clients would have to know their own address, though, and make some kind of service guarantee that they're willing to listen to responses at that address. In some cases, the address of notification will be different than the client address. In email delivery for Internet Fax, we've also wanted to have a notification protocol for "successful printing"; I'd like to make sure that IPP and Internet Fax don't invent different mechanisms for no good reason. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 3 21:48:14 1998 Delivery-Date: Tue, 03 Feb 1998 21:48:15 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA23330 for ; Tue, 3 Feb 1998 21:48:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12448 for ; Tue, 3 Feb 1998 21:50:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA24179 for ; Tue, 3 Feb 1998 21:48:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 21:32:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20879 for ipp-outgoing; Tue, 3 Feb 1998 20:11:23 -0500 (EST) Message-ID: <34D7C011.B6759E2D@parc.xerox.com> Date: Tue, 3 Feb 1998 17:10:41 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Paul Moore CC: "Turner, Randy" , "'ipp@pwg.org'" Subject: Re: IPP> Notifications References: <5CEA8663F24DD111A96100805FFE6587030BC1D0@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > Firstly a client should be able to request that (for exmaple) when a print > job is completed that a human readable notification be sent to some URL, > that a pager be bleeped, that a robot arm should waved over a fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the lower level > interface from the server/cleint to the printer then some machine readable > noification mechanism was needed. For example the printer is running low on > paper it may signal a listener somewhere, if a configuration change takes > place or whatever. This notification may even be the 'job completed' > notification back to a server that triggers it to send the human readable > notification that was requested in the original print job from the client to > the server. This ground has been well-plowed, though, in the email notification domain. If you look at the description of mail delivery notification, you will see that a notification consists of a "multipart/report", the first part of which is human readable, and the second part of which is machine readable. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 3 22:05:38 1998 Delivery-Date: Tue, 03 Feb 1998 22:05:38 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA23875 for ; Tue, 3 Feb 1998 22:05:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA12485 for ; Tue, 3 Feb 1998 22:08:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA25069 for ; Tue, 3 Feb 1998 22:05:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 22:01:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA21057 for ipp-outgoing; Tue, 3 Feb 1998 21:17:20 -0500 (EST) Message-Id: <199802040216.SAB19805@bulletin> To: Carl-Uno Manros cc: ipp@pwg.org, szilles@Adobe.COM Subject: Re: IPP> Consensus on sending our drafts to the IESG In-reply-to: Your message of "Thu, 29 Jan 1998 18:40:30 PST." <3.0.1.32.19980129184030.00b37330@garfield> Date: Tue, 03 Feb 1998 18:16:22 PST From: "Steve Zilles" Sender: ipp-owner@pwg.org After having read the discussion on whether to proceed with the existing protocol I-D or to consider an alternative proposal, I vote to send the existing drafts to the IESG. Although, I am sympathetic to an XML based proposal, the discussion has convinced me that 1) There is no concrete XML proposal on the table and it is not clear when one might come into existance. Therefore, we would not be able to meet the milestones for the Working Group. 2) There is a need for the W3C XML Working Group and a related group to define a data typeing mechanism for XML to be able to express the IPP Model data. Although the IPP WG could do this, it is unlikely that it would match whatever is defined for XML as a whole and much of the synergy with XML would be lost. There is some indication that the task of defining a data description for XML may be undertaken in the near future. 3) The IPP had been structured so that the Model is independent of the protocol used to transport Model data. Therefore, it is always possible to define an XML based protocol if that seems to important to do at some time in the future. Steve ----------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com Adobe Systems Incorporated | Mailstop W14 | tel: (work) (408) 536-4766 345 Park Avenue | (Admin)(408) 536-4658 San Jose, CA 95110-2704 | fax: (408) 537-4042 ----------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 3 23:44:39 1998 Delivery-Date: Tue, 03 Feb 1998 23:44:40 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA02416 for ; Tue, 3 Feb 1998 23:44:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA12750 for ; Tue, 3 Feb 1998 23:47:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA25876 for ; Tue, 3 Feb 1998 23:44:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Feb 1998 23:38:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA25306 for ipp-outgoing; Tue, 3 Feb 1998 23:23:06 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> Notifications Message-ID: <5030300017534955000002L052*@MHS> Date: Tue, 3 Feb 1998 23:29:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id XAA02416 Regarding IPP notifications... >This ground has been well-plowed, though, in the email notification >domain. I'm not so sure. I think a printing system notification scheme should accomodate page level granularity. Ex. Page 3 of 5 completed. This could result in a lot of e-mail! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Feb 4 00:12:00 1998 Delivery-Date: Wed, 04 Feb 1998 00:12:01 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA02938 for ; Wed, 4 Feb 1998 00:12:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12779 for ; Wed, 4 Feb 1998 00:14:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA26615 for ; Wed, 4 Feb 1998 00:11:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 00:07:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA26027 for ipp-outgoing; Tue, 3 Feb 1998 23:52:09 -0500 (EST) Message-ID: <34D7F3E0.4752779F@parc.xerox.com> Date: Tue, 3 Feb 1998 20:51:44 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org Subject: Re: IPP> Notifications References: <5030300017534955000002L052*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I'm sorry if I wasn't clear: I don't think IPP should use email for all kinds of notifications, although 'job completion' might be useful. What I was saying was 'well-plowed' was the notion of having a notification format that was both human-readable and also machine processable. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 04:16:43 1998 Delivery-Date: Wed, 04 Feb 1998 04:16:43 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA06574 for ; Wed, 4 Feb 1998 04:16:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA13032 for ; Wed, 4 Feb 1998 04:19:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA27889 for ; Wed, 4 Feb 1998 04:16:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 04:11:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA27315 for ipp-outgoing; Wed, 4 Feb 1998 03:55:30 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: kugler@us.ibm.com, ipp@pwg.org Message-Id: Date: Wed, 4 Feb 1998 08:55:03 +0100 Subject: IPP> Re: IPP > FAQ - How should the server behave? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Carl, >> 1. If an IPP-client transmit a request to the IPP-server and close the >> tcp-connection, should the IPP-server open a new tcp-session and transmit the >> esponse? >Impossible. The client isn't listening on a server port. Well, maybe the IPP server doesn't know the state of the tcp-connection. However, what should the HTTP-stack on the printserver do when it receives the response from the IPP-server and the tcp-connection to the client is closed for some reasons. Should the HTTP-stack open a new tcp-connection to the client? >> 2. Must the IPP-server wait with the response, on a print-job request, to >> the whole job is received? >The server should respond to the request before accepting appended document content. >See 3.1.7 and 15.4 in the model document. If the IPP-server rejects a 'print-job' request for some reasons, must the server purge the appended document? If the document is 10 Gbytes, the server has to purge 10 Gbytes data, what a waste of network traffic. >> 3. How should a non-spooling IPP-server handle concurrent print-job >> requests? >Return server-error-service-unavailable (0x0502) to indicate that the server is temporarily unable to >handle a request. How should the client respond to this? Is it an error if the IPP-server is printing and a second 'print-job' occour? I don't think so! ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (45) 44366271 Fax: (45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Wed Feb 4 07:52:23 1998 Delivery-Date: Wed, 04 Feb 1998 07:52:23 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA09009 for ; Wed, 4 Feb 1998 07:52:22 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA13275 for ; Wed, 4 Feb 1998 07:55:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA28807 for ; Wed, 4 Feb 1998 07:52:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 07:43:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA28225 for ipp-outgoing; Wed, 4 Feb 1998 07:27:57 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'henrik.holst@i-data.com'" , kugler@us.ibm.com, ipp@pwg.org Subject: IPP> Re: IPP > FAQ - How should the server behave? Date: Wed, 4 Feb 1998 04:24:29 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org The HTTP server that is doing NSAPI, ISAPI, or CGI to a back-end IPP server will always know the state of it's end of the TCP connection. If for any reason, the generic HTTP server receives an error indicating termination of the connection to the client, it will throw away the response from the CGI IPP server. In this case the IPP client will have to reconnect and re-issue the IPP request. On the 2nd issue regarding the 10GB (wow!) print job, unfortunately its hard to predict what different generic HTTP servers will do with a PRINT-JOB request to a back-end CGI implementation of an IPP server. For a dedicated IPP server implementation that might be embedded in a physical printer, the server would immediately respond back to a client when an error was detected. And if the error was severe enough, the server would close the connection to the client so that the remainder of a very large job would not have to take up network bandwidth for no reason. -----Original Message----- From: henrik.holst@i-data.com [SMTP:henrik.holst@i-data.com] Sent: Tuesday, February 03, 1998 11:55 PM To: kugler@us.ibm.com; ipp@pwg.org Subject: IPP> Re: IPP > FAQ - How should the server behave? Carl, >> 1. If an IPP-client transmit a request to the IPP-server and close the >> tcp-connection, should the IPP-server open a new tcp-session and transmit the >> esponse? >Impossible. The client isn't listening on a server port. Well, maybe the IPP server doesn't know the state of the tcp-connection. However, what should the HTTP-stack on the printserver do when it receives the response from the IPP-server and the tcp-connection to the client is closed for some reasons. Should the HTTP-stack open a new tcp-connection to the client? >> 2. Must the IPP-server wait with the response, on a print-job request, to >> the whole job is received? >The server should respond to the request before accepting appended document content. >See 3.1.7 and 15.4 in the model document. If the IPP-server rejects a 'print-job' request for some reasons, must the server purge the appended document? If the document is 10 Gbytes, the server has to purge 10 Gbytes data, what a waste of network traffic. >> 3. How should a non-spooling IPP-server handle concurrent print-job >> requests? >Return server-error-service-unavailable (0x0502) to indicate that the server is temporarily unable to >handle a request. How should the client respond to this? Is it an error if the IPP-server is printing and a second 'print-job' occour? I don't think so! ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (45) 44366271 Fax: (45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Wed Feb 4 08:57:40 1998 Delivery-Date: Wed, 04 Feb 1998 08:57:42 -0500 Return-Path: ipp-owner@pwg.org Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA09808 for ; Wed, 4 Feb 1998 08:57:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16869 for ; Wed, 4 Feb 1998 09:00:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA29524 for ; Wed, 4 Feb 1998 08:57:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 08:53:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA28933 for ipp-outgoing; Wed, 4 Feb 1998 08:37:17 -0500 (EST) Content-return: allowed Date: Wed, 4 Feb 1998 05:30:29 PST From: "Caruso, Angelo " Subject: RE: IPP> Notifications To: "'Paul Moore'" , "'Larry Masinter'" , "Turner, Randy" Cc: "'ipp@pwg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org Paul, Has anyone considered using SNMP traps for these kinds of asynchronous notifications? It's light-weight and quick and designed for this sort of thing, unlike HTTP or email. Just a thought. Thanks, Angelo -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Tuesday, February 03, 1998 8:05 PM To: 'Larry Masinter'; Turner, Randy Cc: 'ipp@pwg.org' Subject: RE: IPP> Notifications We need to distinguish two types of notification. (This was a long and exciting debate in Maui!). Firstly a client should be able to request that (for exmaple) when a print job is completed that a human readable notification be sent to some URL, that a pager be bleeped, that a robot arm should waved over a fire to create a smoke signal, whatever. We also agreed that if IPP were to be extended to manage the lower level interface from the server/cleint to the printer then some machine readable noification mechanism was needed. For example the printer is running low on paper it may signal a listener somewhere, if a configuration change takes place or whatever. This notification may even be the 'job completed' notification back to a server that triggers it to send the human readable notification that was requested in the original print job from the client to the server. > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Tuesday, February 03, 1998 4:56 PM > To: Turner, Randy > Cc: Paul Moore; 'ipp@pwg.org' > Subject: Re: IPP> Notifications > > I like the idea of the client supplying, as part of a request, > the URL for notifications. In email, this address could be > supplied by the disposition-notification-to header, as with any > kind of receipt notification. For requests that get delivered > via IPP and POST, the address to which notifications get posted > could be supplied by the client via a URL, too. Clients would > have to know their own address, though, and make some kind of > service guarantee that they're willing to listen to responses > at that address. In some cases, the address of notification will > be different than the client address. > > In email delivery for Internet Fax, we've also wanted to have > a notification protocol for "successful printing"; I'd like to > make sure that IPP and Internet Fax don't invent different > mechanisms for no good reason. > > Larry > -- > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 12:05:26 1998 Delivery-Date: Wed, 04 Feb 1998 12:05:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17386 for ; Wed, 4 Feb 1998 12:05:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA26870 for ; Wed, 4 Feb 1998 12:07:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA00657 for ; Wed, 4 Feb 1998 12:05:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 11:56:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00043 for ipp-outgoing; Wed, 4 Feb 1998 11:41:06 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Notifications Message-ID: <5030100017052486000002L062*@MHS> Date: Wed, 4 Feb 1998 11:40:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA17386 > I don't see there is any need for the client to open > another socket waiting for the server notification. > Since an IPP connection is persistent, the server can > notify the client over the same socket any time. Won't work, unfortunately. There are a couple problems: 1. HTTP/1.1 connections only persist for a little while, and that ill-defined while is likely to be short relative to, say, the time required to process a print job. See "HTTP Connection Management" at ftp://ietf.org/internet-drafts/draft-ietf-http-connection-00.txt 2. The client has to be expecting new data to arrive after the initial response. If the response has Content-Length, a normal HTTP client will only read that much content from the connection before the next request is issued. You might be able to fake around these obstacles by using chunked transfer encoding in the response. However, I think this would be considered abuse of the protocol, and is likely to fail if there are any proxies in the communication path. > the server can wait until the same client > opens another session, provided that the server can > uniquely identify the client. For completeness, a > time-to-live for the message may need to be defined. This could work. Something like this is allowed by the current IPP model and protocol. The client polls with Get-Job-Attributes looking at job-state, job-state-reasons, and/or job-state-message. After processing is complete, the server could wait for a poll for a particular job-id or job-uri before forgetting the job, with some time-out. However, nothing in IPP says the server shall remember the job once it's complete; that's implementation dependent. -Carl Kugler ipp-owner@pwg.org on 02/03/98 12:21:17 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: Re: IPP> Notifications I don't see there is any need for the client to open another socket waiting for the server notification. Since an IPP connection is persistent, the server can notify the client over the same socket any time. If a notification needs to be sent after the session is closed, the server can wait until the same client opens another session, provided that the server can uniquely identify the client. For completeness, a time-to-live for the message may need to be defined. What this means is that if the client is ever interested in any notification from the server, it should remain online or check back with the server later. From ipp-owner@pwg.org Wed Feb 4 12:20:42 1998 Delivery-Date: Wed, 04 Feb 1998 12:20:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA17756 for ; Wed, 4 Feb 1998 12:20:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA27032 for ; Wed, 4 Feb 1998 12:23:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA01270 for ; Wed, 4 Feb 1998 12:20:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 12:16:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00118 for ipp-outgoing; Wed, 4 Feb 1998 11:57:16 -0500 (EST) From: Carl Kugler To: Cc: Subject: IPP> Re: IPP > FAQ - How should the server behave? Message-ID: <5030100017053120000002L002*@MHS> Date: Wed, 4 Feb 1998 11:56:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA17756 Henrik- > Should the HTTP-stack open a new tcp-connection to the client? How could it? It can't connect() because the client isn't listen()ing. > If the IPP-server rejects a 'print-job' request for some reasons, must the > server purge the appended document? If the document is 10 Gbytes, the server > has to purge 10 Gbytes data, what a waste of network traffic. Exactly. That's the reason why the server should respond to the request *before* accepting appended document content. The client SHOULD listen for a response while it is transmitting the document data and abort the transmission if the request was rejected. >>Return server-error-service-unavailable (0x0502) to indicate that the >>server is temporarily unable to handle a request. > How should the client respond to this? server-error-service-unavailable (0x0502) implies a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in the message. So the client should retry after delaying. -Carl henrik.holst@i-data.com on 02/03/98 08:55:38 PM Please respond to henrik.holst@i-data.com @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP > FAQ - How should the server behave? Carl, >> 1. If an IPP-client transmit a request to the IPP-server and close the >> tcp-connection, should the IPP-server open a new tcp-session and transmit the >> esponse? >Impossible. The client isn't listening on a server port. Well, maybe the IPP server doesn't know the state of the tcp-connection From ipp-owner@pwg.org Wed Feb 4 13:21:37 1998 Delivery-Date: Wed, 04 Feb 1998 13:21:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19026 for ; Wed, 4 Feb 1998 13:21:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA27375 for ; Wed, 4 Feb 1998 13:24:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA02504 for ; Wed, 4 Feb 1998 13:21:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 13:09:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01427 for ipp-outgoing; Wed, 4 Feb 1998 12:40:51 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1D6@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Caruso, Angelo '" , "'Larry Masinter'" , "Turner, Randy" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 09:40:34 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org This has been actively considered - the main problems are:- - it is a different protocol with different semantics - it is a 'best endeavors' protocol, you might or might not get the message - HTTP was chosen for IPP for its universal reach (firewalls, proxies, etc.), SNMP is not normally carried as far. > -----Original Message----- > From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] > Sent: Wednesday, February 04, 1998 5:30 AM > To: Paul Moore; 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > Paul, > > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. > > Thanks, > Angelo > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 8:05 PM > To: 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > We need to distinguish two types of notification. (This was a > long and > exciting debate in Maui!). > > Firstly a client should be able to request that (for exmaple) > when a print > job is completed that a human readable notification be sent to > some URL, > that a pager be bleeped, that a robot arm should waved over a > fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the > lower level > interface from the server/cleint to the printer then some > machine readable > noification mechanism was needed. For example the printer is > running low on > paper it may signal a listener somewhere, if a configuration > change takes > place or whatever. This notification may even be the 'job > completed' > notification back to a server that triggers it to send the human > readable > notification that was requested in the original print job from > the client to > the server. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Tuesday, February 03, 1998 4:56 PM > > To: Turner, Randy > > Cc: Paul Moore; 'ipp@pwg.org' > > Subject: Re: IPP> Notifications > > > > I like the idea of the client supplying, as part of a request, > > the URL for notifications. In email, this address could be > > supplied by the disposition-notification-to header, as with > any > > kind of receipt notification. For requests that get delivered > > via IPP and POST, the address to which notifications get > posted > > could be supplied by the client via a URL, too. Clients would > > have to know their own address, though, and make some kind of > > service guarantee that they're willing to listen to responses > > at that address. In some cases, the address of notification > will > > be different than the client address. > > > > In email delivery for Internet Fax, we've also wanted to have > > a notification protocol for "successful printing"; I'd like to > > make sure that IPP and Internet Fax don't invent different > > mechanisms for no good reason. > > > > Larry > > -- > > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 13:24:12 1998 Delivery-Date: Wed, 04 Feb 1998 13:24:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19056 for ; Wed, 4 Feb 1998 13:24:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA27389 for ; Wed, 4 Feb 1998 13:26:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA02712 for ; Wed, 4 Feb 1998 13:24:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 13:12:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01413 for ipp-outgoing; Wed, 4 Feb 1998 12:40:04 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Notifications Message-ID: <5030100017055141000002L012*@MHS> Date: Wed, 4 Feb 1998 12:39:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA19056 Paul- I would like to point out that the XML/new method proposal is no better in this respect. The problem is not that IPP is asymmetric: the underlying HTTP transport layer is asymmetric, and that is common to both approaches. - Carl ipp-owner@pwg.org on 02/03/98 12:24:44 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Notifications Has anybody noticed that IPP will be useless for notifications due to the asymmetry of the protocol? As currently constituted a printer cannot send an unsolicted message to anybody. Was this discussed later on on the Thursday brainstorm? From ipp-owner@pwg.org Wed Feb 4 13:58:03 1998 Delivery-Date: Wed, 04 Feb 1998 13:58:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19687 for ; Wed, 4 Feb 1998 13:58:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA27856 for ; Wed, 4 Feb 1998 14:00:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA03862 for ; Wed, 4 Feb 1998 13:57:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 13:50:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01710 for ipp-outgoing; Wed, 4 Feb 1998 13:12:38 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> Notifications Message-ID: <5030300017560330000002L002*@MHS> Date: Wed, 4 Feb 1998 13:18:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA19687 We need to decide if our investigation should include polling (only) solutions > the server can wait until the same client > opens another session, provided that the server can > uniquely identify the client. For completeness, a > time-to-live for the message may need to be defined. Or if we are seeking a largely event driven scenario with polling as a fallback. I prefer the later. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Feb 4 13:59:07 1998 Delivery-Date: Wed, 04 Feb 1998 13:59:07 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19703 for ; Wed, 4 Feb 1998 13:59:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA27876 for ; Wed, 4 Feb 1998 14:01:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04006 for ; Wed, 4 Feb 1998 13:58:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 13:51:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02386 for ipp-outgoing; Wed, 4 Feb 1998 13:19:24 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 10:15:54 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I agree that using SNMP solely for IPP notifications might be too much, but I still consider the use of UDP datagrams for asynchronous notification to be valid for the IPP case. And with a simple acknowledgment scheme you can achieve reliable delivery. I do not think a server would have to open a TCP connection to a notification receiver just to send a small notification message; for a notification message I think TCP is too much as well. UDP datagrams will also scale much better than TCP connections in the event of a server having to handle a lot of notification subscriptions. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, February 04, 1998 9:41 AM To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy Cc: 'ipp@pwg.org' Subject: RE: IPP> Notifications This has been actively considered - the main problems are:- - it is a different protocol with different semantics - it is a 'best endeavors' protocol, you might or might not get the message - HTTP was chosen for IPP for its universal reach (firewalls, proxies, etc.), SNMP is not normally carried as far. > -----Original Message----- > From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] > Sent: Wednesday, February 04, 1998 5:30 AM > To: Paul Moore; 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > Paul, > > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. > > Thanks, > Angelo > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 8:05 PM > To: 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > We need to distinguish two types of notification. (This was a > long and > exciting debate in Maui!). > > Firstly a client should be able to request that (for exmaple) > when a print > job is completed that a human readable notification be sent to > some URL, > that a pager be bleeped, that a robot arm should waved over a > fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the > lower level > interface from the server/cleint to the printer then some > machine readable > noification mechanism was needed. For example the printer is > running low on > paper it may signal a listener somewhere, if a configuration > change takes > place or whatever. This notification may even be the 'job > completed' > notification back to a server that triggers it to send the human > readable > notification that was requested in the original print job from > the client to > the server. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Tuesday, February 03, 1998 4:56 PM > > To: Turner, Randy > > Cc: Paul Moore; 'ipp@pwg.org' > > Subject: Re: IPP> Notifications > > > > I like the idea of the client supplying, as part of a request, > > the URL for notifications. In email, this address could be > > supplied by the disposition-notification-to header, as with > any > > kind of receipt notification. For requests that get delivered > > via IPP and POST, the address to which notifications get > posted > > could be supplied by the client via a URL, too. Clients would > > have to know their own address, though, and make some kind of > > service guarantee that they're willing to listen to responses > > at that address. In some cases, the address of notification > will > > be different than the client address. > > > > In email delivery for Internet Fax, we've also wanted to have > > a notification protocol for "successful printing"; I'd like to > > make sure that IPP and Internet Fax don't invent different > > mechanisms for no good reason. > > > > Larry > > -- > > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 15:10:18 1998 Delivery-Date: Wed, 04 Feb 1998 15:10:19 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20991 for ; Wed, 4 Feb 1998 15:10:17 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28496 for ; Wed, 4 Feb 1998 15:12:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04860 for ; Wed, 4 Feb 1998 15:10:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 14:54:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04149 for ipp-outgoing; Wed, 4 Feb 1998 14:16:13 -0500 (EST) From: Carl Kugler To: Subject: RE: IPP> Notifications Message-ID: <5030100017059848000002L082*@MHS> Date: Wed, 4 Feb 1998 14:15:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA20991 Randy- UDP datagram notificaton still has the firewalls and proxies problem, unless everyone goes to SOCKS5. -Carl ipp-owner@pwg.org on 02/04/98 11:53:58 AM Please respond to ipp-owner@pwg.org @ internet To: paulmo@microsoft.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I agree that using SNMP solely for IPP notifications might be too much, but I still consider the use of UDP datagrams for asynchronous notification to be valid for the IPP case. And with a simple acknowledgment scheme you can achieve reliable delivery. I do not think a server would have to open a TCP connection to a notification receiver just to send a small notification message; for a notification message I think TCP is too much as well. UDP datagrams will also scale much better than TCP connections in the event of a server having to handle a lot of notification subscriptions. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, February 04, 1998 9:41 AM To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy Cc: 'ipp@pwg.org' Subject: RE: IPP> Notifications This has been actively considered - the main problems are:- - it is a different protocol with different semantics - it is a 'best endeavors' protocol, you might or might not get the message - HTTP was chosen for IPP for its universal reach (firewalls, proxies, etc.), SNMP is not normally carried as far. > -----Original Message----- > From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] > Sent: Wednesday, February 04, 1998 5:30 AM > To: Paul Moore; 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > Paul, > > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. > > Thanks, > Angelo > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 8:05 PM > To: 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > We need to distinguish two types of notification. (This was a > long and > exciting debate in Maui!). > > Firstly a client should be able to request that (for exmaple) > when a print > job is completed that a human readable notification be sent to > some URL, > that a pager be bleeped, that a robot arm should waved over a > fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the > lower level > interface from the server/cleint to the printer then some > machine readable > noification mechanism was needed. For example the printer is > running low on > paper it may signal a listener somewhere, if a configuration > change takes > place or whatever. This notification may even be the 'job > completed' > notification back to a server that triggers it to send the human > readable > notification that was requested in the original print job from > the client to > the server. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Tuesday, February 03, 1998 4:56 PM > > To: Turner, Randy > > Cc: Paul Moore; 'ipp@pwg.org' > > Subject: Re: IPP> Notifications > > > > I like the idea of the client supplying, as part of a request, > > the URL for notifications. In email, this address could be > > supplied by the disposition-notification-to header, as with > any > > kind of receipt notification. For requests that get delivered > > via IPP and POST, the address to which notifications get > posted > > could be supplied by the client via a URL, too. Clients would > > have to know their own address, though, and make some kind of > > service guarantee that they're willing to listen to responses > > at that address. In some cases, the address of notification > will > > be different than the client address. > > > > In email delivery for Internet Fax, we've also wanted to have > > a notification protocol for "successful printing"; I'd like to > > make sure that IPP and Internet Fax don't invent different > > mechanisms for no good reason. > > > > Larry > > -- > > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 15:25:11 1998 Delivery-Date: Wed, 04 Feb 1998 15:25:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21192 for ; Wed, 4 Feb 1998 15:25:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28635 for ; Wed, 4 Feb 1998 15:27:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05954 for ; Wed, 4 Feb 1998 15:25:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 15:10:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04173 for ipp-outgoing; Wed, 4 Feb 1998 14:22:18 -0500 (EST) Mime-Version: 1.0 Date: Wed, 4 Feb 1998 14:27:18 -0500 Message-ID: <0003E2D8.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re[2]: IPP> Notifications Cc: "'ipp@pwg.org'" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org I don't see how a UDP datagram originating from outside the firewall is going to be let inside (without assigning a special port, and security protocol). It is possible to provide a single proxy for the clients which would receive UDP packets from the outside, but this requires extra effort in terms of security admin. and client code. In fact, one of the premises behind the firewall policy is to allow only connections that originate inside --- this is going to be problematic for any connectionless async notification --- and argues in favor of the client (or an agent for the client) polling the IPP Printer when desired. --- the notification request must be initiated by the client (which is really not async.) SMTP, although somewhat unpalatable, may not be as bad as one thinks. In fact, one could have a very simple smtp "server" (receiver) in the client, so that the mail is relayed directly to the client and does not have to pass through user agents and systems like POP3/IMAP etc. However this may be difficult from a policy/administrative view (since mail must be relayed from the company's mail server(s), and possible DNS changes to mx records). note that many so-called "push" technologies are really pull (the client or a daemon polls the external source for information). Of course, if we are dealing only with the Intranet, there are many easy solutions. Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: RE: IPP> Notifications Author: "Turner; Randy" at INTERNET Date: 2/4/98 10:15 AM I agree that using SNMP solely for IPP notifications might be too much, but I still consider the use of UDP datagrams for asynchronous notification to be valid for the IPP case. And with a simple acknowledgment scheme you can achieve reliable delivery. I do not think a server would have to open a TCP connection to a notification receiver just to send a small notification message; for a notification message I think TCP is too much as well. UDP datagrams will also scale much better than TCP connections in the event of a server having to handle a lot of notification subscriptions. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, February 04, 1998 9:41 AM To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy Cc: 'ipp@pwg.org' Subject: RE: IPP> Notifications This has been actively considered - the main problems are:- - it is a different protocol with different semantics - it is a 'best endeavors' protocol, you might or might not get the message - HTTP was chosen for IPP for its universal reach (firewalls, proxies, etc.), SNMP is not normally carried as far. > -----Original Message----- > From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] > Sent: Wednesday, February 04, 1998 5:30 AM > To: Paul Moore; 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > Paul, > > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. > > Thanks, > Angelo > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 8:05 PM > To: 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > We need to distinguish two types of notification. (This was a > long and > exciting debate in Maui!). > > Firstly a client should be able to request that (for exmaple) > when a print > job is completed that a human readable notification be sent to > some URL, > that a pager be bleeped, that a robot arm should waved over a > fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the > lower level > interface from the server/cleint to the printer then some > machine readable > noification mechanism was needed. For example the printer is > running low on > paper it may signal a listener somewhere, if a configuration > change takes > place or whatever. This notification may even be the 'job > completed' > notification back to a server that triggers it to send the human > readable > notification that was requested in the original print job from > the client to > the server. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Tuesday, February 03, 1998 4:56 PM > > To: Turner, Randy > > Cc: Paul Moore; 'ipp@pwg.org' > > Subject: Re: IPP> Notifications > > > > I like the idea of the client supplying, as part of a request, > > the URL for notifications. In email, this address could be > > supplied by the disposition-notification-to header, as with > any > > kind of receipt notification. For requests that get delivered > > via IPP and POST, the address to which notifications get > posted > > could be supplied by the client via a URL, too. Clients would > > have to know their own address, though, and make some kind of > > service guarantee that they're willing to listen to responses > > at that address. In some cases, the address of notification > will > > be different than the client address. > > > > In email delivery for Internet Fax, we've also wanted to have > > a notification protocol for "successful printing"; I'd like to > > make sure that IPP and Internet Fax don't invent different > > mechanisms for no good reason. > > > > Larry > > -- > > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 15:28:28 1998 Delivery-Date: Wed, 04 Feb 1998 15:28:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21232 for ; Wed, 4 Feb 1998 15:28:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28674 for ; Wed, 4 Feb 1998 15:31:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA06161 for ; Wed, 4 Feb 1998 15:28:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 15:13:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04184 for ipp-outgoing; Wed, 4 Feb 1998 14:25:40 -0500 (EST) Message-ID: <34D8C07F.EDD07915@us.ibm.com> Date: Wed, 04 Feb 1998 12:24:48 -0700 From: Carl Kugler X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP Mail Archive: RE: IPP> Notifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > RE: IPP> Notifications > > Josh Cohen (joshco@microsoft.com) > Tue, 3 Feb 1998 15:28:10 -0800 > > I thought the consensus that the first step was to have > a requirements document written up for IPP. > Since there are many generalized notification efforts > underway ( or soon to be), we can judge the suitability > of using one of them or writing one specific to IPP. > However, that can only be done if we know our requirements > first. Is this new requirements document to supercede "Requirements for an Internet Printing Protocol" at http://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt (which give requirements for asynchronous notification)? -Carl From ipp-owner@pwg.org Wed Feb 4 15:54:34 1998 Delivery-Date: Wed, 04 Feb 1998 15:54:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21660 for ; Wed, 4 Feb 1998 15:54:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28925 for ; Wed, 4 Feb 1998 15:57:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA07188 for ; Wed, 4 Feb 1998 15:54:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 15:45:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04415 for ipp-outgoing; Wed, 4 Feb 1998 14:58:09 -0500 (EST) Message-Id: <34D8C7A7.2A65050E@dazel.com> Date: Wed, 04 Feb 1998 13:55:19 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Carl-Uno Manros Cc: ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <3.0.1.32.19980129184030.00b37330@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I am opposed to sending the current drafts of the Model & Semantics document and Protocol Specification document to the IESG for last call. As I expressed in Maui, I believe that we have too many issues with the current drafts, with the XML encoding issue only being one of them. I would also agree with Josh Cohen's comments... my recollection was that we agreed that we had a "rough consensus", and that the minority position on XML encoding would at least be noted as we moved forward in the process. In effect, we agreed to disagree, with the discussion moving on to take place at the next higher level, IESG last call. I presume that the IESG can make the determination if we have sufficient consensus to move this on to Proposed Standard. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Feb 4 15:58:13 1998 Delivery-Date: Wed, 04 Feb 1998 15:58:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21703 for ; Wed, 4 Feb 1998 15:58:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA28988 for ; Wed, 4 Feb 1998 16:00:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA07525 for ; Wed, 4 Feb 1998 15:58:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 15:50:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05121 for ipp-outgoing; Wed, 4 Feb 1998 15:13:49 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1DC@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 12:06:42 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org No argument at all. This is othogonal to the XML debate. I am looking at expanding IPP to cover many needs beyond the relatively simple feature set currently defined, the extensibility issue led me to the XML proposal, the unsolicited message issue led me to this thread. The point I am making is that using HTTP asymmetrically (i.e the client always POSTs, the printer always listens for POST - which is the 'natural' use of HTTP) precludes the core IPP protocol from generating asynchronous or unsolicited reverse messages. This is a major limitiation - I want to be sure that everybody knows that we are doing it and that we all accept the trade-off. I'm sure we could invent lots of hacks later on the will work round this but that's not an ideal solution. What will actually happen is that we will all poll :-( > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, February 04, 1998 9:40 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > Paul- > > I would like to point out that the XML/new method proposal is no better in > this > respect. The problem is not that IPP is asymmetric: the underlying HTTP > transport layer is asymmetric, and that is common to both approaches. > > - Carl > > > > ipp-owner@pwg.org on 02/03/98 12:24:44 PM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> Notifications > > > Has anybody noticed that IPP will be useless for notifications due to the > asymmetry of the protocol? As currently constituted a printer cannot send > an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? > > > From ipp-owner@pwg.org Wed Feb 4 18:08:27 1998 Delivery-Date: Wed, 04 Feb 1998 18:08:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23546 for ; Wed, 4 Feb 1998 18:08:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA29889 for ; Wed, 4 Feb 1998 18:11:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA09189 for ; Wed, 4 Feb 1998 18:08:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 17:49:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07629 for ipp-outgoing; Wed, 4 Feb 1998 16:03:51 -0500 (EST) From: Harry Lewis To: Subject: Re: Re[2]: IPP> Notifications Message-ID: <5030300017567641000002L012*@MHS> Date: Wed, 4 Feb 1998 16:09:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA23546 Philip brings up an important issue which will continue to cloud our discussion of Notifications unless we understand it. >I don't see how a UDP datagram originating from outside the firewall >is going to be let inside (without assigning a special port, and >security protocol). >Of course, if we are dealing only with the Intranet, there are many easy >solutions. >Philip Thambidurai When we discuss notifications, I think some of us have different ideas based on whether we are thinking primarily Intranet or Internet When thinking Internet, an e-mail message for job complete is appropriate and acceptable. Here, I agree with the recommendations to investigate similar approaches in I-Fax. If you consider IPP as possibly the most prevalent way to submit print jobs on ANY network in the future, then I think a much more granular and streamline method should be considered. In PWG IPP, we need to address BOTH! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Feb 4 18:21:45 1998 Delivery-Date: Wed, 04 Feb 1998 18:22:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23670 for ; Wed, 4 Feb 1998 18:21:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA29955 for ; Wed, 4 Feb 1998 18:24:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA09744 for ; Wed, 4 Feb 1998 18:21:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 18:03:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07726 for ipp-outgoing; Wed, 4 Feb 1998 16:19:23 -0500 (EST) Message-Id: <3.0.1.32.19980204131522.00b31a00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 4 Feb 1998 13:15:22 PST To: walker@dazel.com From: Carl-Uno Manros Subject: Re: IPP> Consensus on sending our drafts to the IESG Cc: ipp@pwg.org In-Reply-To: <34D8C7A7.2A65050E@dazel.com> References: <3.0.1.32.19980129184030.00b37330@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:55 AM 2/4/98 PST, James Walker wrote: >My recollection >was that we agreed that we had a "rough consensus", and that the >minority position on XML encoding would at least be noted as we >moved forward in the process. In effect, we agreed to disagree, >with the discussion moving on to take place at the next higher level, >IESG last call. I presume that the IESG can make the determination >if we have sufficient consensus to move this on to Proposed Standard. > >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX > Jim, You and Josh are right about the: >>"rough consensus", and that the >>minority position on XML encoding would at least be noted as we >>moved forward in the process"rough consensus", and that the >minority position on XML encoding would at least be noted as we >moved forward in the process. I am sorry if this was not clear in my earlier message to the group. I will make sure that this is crisp and clear in the message to the IESG. I hope that everybody on the IPP DL have also understood the clarification on this subject. More details can be found in the minutes circulated yesterday. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From pwg-owner@pwg.org Wed Feb 4 18:40:19 1998 Delivery-Date: Wed, 04 Feb 1998 18:40:20 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23857 for ; Wed, 4 Feb 1998 18:40:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA00031 for ; Wed, 4 Feb 1998 18:42:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11069 for ; Wed, 4 Feb 1998 18:40:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 18:24:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09508 for pwg-outgoing; Wed, 4 Feb 1998 18:14:45 -0500 (EST) Message-ID: <34D8F623.AD3C1C41@underscore.com> Date: Wed, 04 Feb 1998 18:13:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: pwg@pwg.org, Sense mailing list , IPP Mailing List Subject: Re: PWG> Maui PWG Overview Minutes References: <5030300017569549000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pwg@pwg.org Harry, Part of your fine summary included this section on Sense: SENSE Notification Protocol No status. Jay Martin (SENSE Chair) not present. It is unfortunate that we were unable to schedule a SENSE discussion in Maui because IPP is interested in considering SENSE as notification scheme. IPP may also want to look at SNMPv3 (recently published RFCs). It was noted that there are many notification protocols available today that may need to be investigated. Would someone be so kind as to list the "many notification protocols available today that may need to be investigated"? I would be more than happy to start investigated those alternatives if someone would post them to the IPP list (or the Sense list, or whatever). Thanks in advance. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 4 18:44:24 1998 Delivery-Date: Wed, 04 Feb 1998 18:44:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23911 for ; Wed, 4 Feb 1998 18:44:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA00076 for ; Wed, 4 Feb 1998 18:47:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11371 for ; Wed, 4 Feb 1998 18:44:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 18:20:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07984 for ipp-outgoing; Wed, 4 Feb 1998 16:59:32 -0500 (EST) From: Roger K Debry To: Cc: Subject: Re: IPP> Consensus on sending our drafts to the IESG Message-ID: <5030100017067671000002L012*@MHS> Date: Wed, 4 Feb 1998 16:58:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA23911 Not having been in Maui, I'd be interested in what you believe the "many other" issues are. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ipp-owner@pwg.org on 02/04/98 01:48:37 PM Please respond to walker@dazel.com @ internet To: cmanros@cp10.es.xerox.com @ internet cc: ipp@pwg.org @ internet Subject: Re: IPP> Consensus on sending our drafts to the IESG I am opposed to sending the current drafts of the Model & Semantics document and Protocol Specification document to the IESG for last call. As I expressed in Maui, I believe that we have too many issues with the current drafts, with the XML encoding issue only being one of them. I would also agree with Josh Cohen's comments... my recollection was that we agreed that we had a "rough consensus", and that the minority position on XML encoding would at least be noted as we moved forward in the process. In effect, we agreed to disagree, with the discussion moving on to take place at the next higher level, IESG last call. I presume that the IESG can make the determination if we have sufficient consensus to move this on to Proposed Standard. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Feb 4 18:48:20 1998 Delivery-Date: Wed, 04 Feb 1998 18:49:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23952 for ; Wed, 4 Feb 1998 18:48:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA00109 for ; Wed, 4 Feb 1998 18:50:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11572 for ; Wed, 4 Feb 1998 18:48:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 18:26:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08384 for ipp-outgoing; Wed, 4 Feb 1998 17:22:38 -0500 (EST) Message-ID: <01BD3180.95909F60.bpenteco@boi.hp.com> From: Bob Pentecost To: "'PWG-ipp'" Subject: RE: IPP> Consensus on sending our drafts to the IESG Date: Wed, 4 Feb 1998 15:18:01 -0700 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 As stated in the IPP meeting, I am in favor of delaying the submittal of the IPP documents to the IESG for the purpose of further investigation of the XML alternative. Bob Pentecost HP From ipp-owner@pwg.org Wed Feb 4 19:09:10 1998 Delivery-Date: Wed, 04 Feb 1998 19:09:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24099 for ; Wed, 4 Feb 1998 19:09:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA00208 for ; Wed, 4 Feb 1998 19:11:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12206 for ; Wed, 4 Feb 1998 19:09:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 18:53:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07644 for ipp-outgoing; Wed, 4 Feb 1998 16:06:10 -0500 (EST) Message-Id: <3.0.1.32.19980204130216.00afb580@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 4 Feb 1998 13:02:16 PST To: Carl Kugler , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP Mail Archive: RE: IPP> Notifications In-Reply-To: <34D8C07F.EDD07915@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:24 AM 2/4/98 PST, Carl Kugler wrote: >> RE: IPP> Notifications >> >> Josh Cohen (joshco@microsoft.com) >> Tue, 3 Feb 1998 15:28:10 -0800 >> >> I thought the consensus that the first step was to have >> a requirements document written up for IPP. >> Since there are many generalized notification efforts >> underway ( or soon to be), we can judge the suitability >> of using one of them or writing one specific to IPP. >> However, that can only be done if we know our requirements >> first. > >Is this new requirements document to supercede "Requirements for an Internet >Printing Protocol" at > > http://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt > >(which give requirements for asynchronous notification)? > > -Carl > Carl, Definately not. As you point out, some of the basic requirements for IPP notifications are already documented in our existing requirements document, which is intended as an Informational RFC. If we we want to write a more detailed requirements document for notifications, we should use our existing text as a starting point. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 4 19:28:21 1998 Delivery-Date: Wed, 04 Feb 1998 19:28:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24471 for ; Wed, 4 Feb 1998 19:28:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA00282 for ; Wed, 4 Feb 1998 19:31:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14015 for ; Wed, 4 Feb 1998 19:28:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 19:12:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07628 for ipp-outgoing; Wed, 4 Feb 1998 16:03:47 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 13:04:11 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Its very likely that we come to the conclusion to poll; but there is nothing that says we can't agree on an out-of-bound mechanism to IPP for event notification, at least I don't think there's a reason. Also, there's always IPP V2 and possibly another protocol mapping document. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, February 04, 1998 12:07 PM To: 'Carl Kugler'; ipp@pwg.org Subject: RE: IPP> Notifications No argument at all. This is othogonal to the XML debate. I am looking at expanding IPP to cover many needs beyond the relatively simple feature set currently defined, the extensibility issue led me to the XML proposal, the unsolicited message issue led me to this thread. The point I am making is that using HTTP asymmetrically (i.e the client always POSTs, the printer always listens for POST - which is the 'natural' use of HTTP) precludes the core IPP protocol from generating asynchronous or unsolicited reverse messages. This is a major limitiation - I want to be sure that everybody knows that we are doing it and that we all accept the trade-off. I'm sure we could invent lots of hacks later on the will work round this but that's not an ideal solution. What will actually happen is that we will all poll :-( > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, February 04, 1998 9:40 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > Paul- > > I would like to point out that the XML/new method proposal is no better in > this > respect. The problem is not that IPP is asymmetric: the underlying HTTP > transport layer is asymmetric, and that is common to both approaches. > > - Carl > > > > ipp-owner@pwg.org on 02/03/98 12:24:44 PM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> Notifications > > > Has anybody noticed that IPP will be useless for notifications due to the > asymmetry of the protocol? As currently constituted a printer cannot send > an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? > > > From ipp-owner@pwg.org Wed Feb 4 19:28:28 1998 Delivery-Date: Wed, 04 Feb 1998 19:28:28 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24479 for ; Wed, 4 Feb 1998 19:28:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA00285 for ; Wed, 4 Feb 1998 19:31:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14043 for ; Wed, 4 Feb 1998 19:28:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 19:13:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09521 for ipp-outgoing; Wed, 4 Feb 1998 18:15:02 -0500 (EST) Message-ID: <34D8F623.AD3C1C41@underscore.com> Date: Wed, 04 Feb 1998 18:13:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: pwg@pwg.org, Sense mailing list , IPP Mailing List Subject: IPP> Re: PWG> Maui PWG Overview Minutes References: <5030300017569549000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry, Part of your fine summary included this section on Sense: SENSE Notification Protocol No status. Jay Martin (SENSE Chair) not present. It is unfortunate that we were unable to schedule a SENSE discussion in Maui because IPP is interested in considering SENSE as notification scheme. IPP may also want to look at SNMPv3 (recently published RFCs). It was noted that there are many notification protocols available today that may need to be investigated. Would someone be so kind as to list the "many notification protocols available today that may need to be investigated"? I would be more than happy to start investigated those alternatives if someone would post them to the IPP list (or the Sense list, or whatever). Thanks in advance. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 4 19:31:10 1998 Delivery-Date: Wed, 04 Feb 1998 19:31:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24562 for ; Wed, 4 Feb 1998 19:31:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA00294 for ; Wed, 4 Feb 1998 19:33:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14392 for ; Wed, 4 Feb 1998 19:31:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 19:17:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA07553 for ipp-outgoing; Wed, 4 Feb 1998 15:58:29 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl Kugler'" Cc: "'ipp@pwg.org'" Subject: RE: IPP Mail Archive: RE: IPP> Notifications Date: Wed, 4 Feb 1998 12:58:52 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I think we a need a more detailed requirements document for notification. I seem to remember the overall IPP requirements document being somewhat vague on the topic. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, February 04, 1998 11:25 AM To: ipp@pwg.org Subject: IPP Mail Archive: RE: IPP> Notifications > RE: IPP> Notifications > > Josh Cohen (joshco@microsoft.com) > Tue, 3 Feb 1998 15:28:10 -0800 > > I thought the consensus that the first step was to have > a requirements document written up for IPP. > Since there are many generalized notification efforts > underway ( or soon to be), we can judge the suitability > of using one of them or writing one specific to IPP. > However, that can only be done if we know our requirements > first. Is this new requirements document to supercede "Requirements for an Internet Printing Protocol" at http://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt (which give requirements for asynchronous notification)? -Carl From ipp-owner@pwg.org Wed Feb 4 19:33:01 1998 Delivery-Date: Wed, 04 Feb 1998 19:33:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24627 for ; Wed, 4 Feb 1998 19:33:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA00319 for ; Wed, 4 Feb 1998 19:35:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14678 for ; Wed, 4 Feb 1998 19:32:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 19:21:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA07319 for ipp-outgoing; Wed, 4 Feb 1998 15:55:30 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 12:56:00 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org UDP has no more firewall or proxy problem than TCP, given any arbitrary port number. The issues are the same for both. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, February 04, 1998 11:16 AM To: ipp@pwg.org Subject: RE: IPP> Notifications Randy- UDP datagram notificaton still has the firewalls and proxies problem, unless everyone goes to SOCKS5. -Carl ipp-owner@pwg.org on 02/04/98 11:53:58 AM Please respond to ipp-owner@pwg.org @ internet To: paulmo@microsoft.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I agree that using SNMP solely for IPP notifications might be too much, but I still consider the use of UDP datagrams for asynchronous notification to be valid for the IPP case. And with a simple acknowledgment scheme you can achieve reliable delivery. I do not think a server would have to open a TCP connection to a notification receiver just to send a small notification message; for a notification message I think TCP is too much as well. UDP datagrams will also scale much better than TCP connections in the event of a server having to handle a lot of notification subscriptions. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, February 04, 1998 9:41 AM To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy Cc: 'ipp@pwg.org' Subject: RE: IPP> Notifications This has been actively considered - the main problems are:- - it is a different protocol with different semantics - it is a 'best endeavors' protocol, you might or might not get the message - HTTP was chosen for IPP for its universal reach (firewalls, proxies, etc.), SNMP is not normally carried as far. > -----Original Message----- > From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] > Sent: Wednesday, February 04, 1998 5:30 AM > To: Paul Moore; 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > Paul, > > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. > > Thanks, > Angelo > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Tuesday, February 03, 1998 8:05 PM > To: 'Larry Masinter'; Turner, Randy > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notifications > > We need to distinguish two types of notification. (This was a > long and > exciting debate in Maui!). > > Firstly a client should be able to request that (for exmaple) > when a print > job is completed that a human readable notification be sent to > some URL, > that a pager be bleeped, that a robot arm should waved over a > fire to create > a smoke signal, whatever. > > We also agreed that if IPP were to be extended to manage the > lower level > interface from the server/cleint to the printer then some > machine readable > noification mechanism was needed. For example the printer is > running low on > paper it may signal a listener somewhere, if a configuration > change takes > place or whatever. This notification may even be the 'job > completed' > notification back to a server that triggers it to send the human > readable > notification that was requested in the original print job from > the client to > the server. > > > -----Original Message----- > > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > > Sent: Tuesday, February 03, 1998 4:56 PM > > To: Turner, Randy > > Cc: Paul Moore; 'ipp@pwg.org' > > Subject: Re: IPP> Notifications > > > > I like the idea of the client supplying, as part of a request, > > the URL for notifications. In email, this address could be > > supplied by the disposition-notification-to header, as with > any > > kind of receipt notification. For requests that get delivered > > via IPP and POST, the address to which notifications get > posted > > could be supplied by the client via a URL, too. Clients would > > have to know their own address, though, and make some kind of > > service guarantee that they're willing to listen to responses > > at that address. In some cases, the address of notification > will > > be different than the client address. > > > > In email delivery for Internet Fax, we've also wanted to have > > a notification protocol for "successful printing"; I'd like to > > make sure that IPP and Internet Fax don't invent different > > mechanisms for no good reason. > > > > Larry > > -- > > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 20:22:47 1998 Delivery-Date: Wed, 04 Feb 1998 20:22:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25535 for ; Wed, 4 Feb 1998 20:22:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA00454 for ; Wed, 4 Feb 1998 20:25:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA15309 for ; Wed, 4 Feb 1998 20:22:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 20:18:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14785 for ipp-outgoing; Wed, 4 Feb 1998 20:02:19 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: Re[2]: IPP> Notifications Date: Wed, 4 Feb 1998 17:02:56 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I am unconvinced that UDP is unsuitable for an internet solution for notification. Currently, administrators keep on a tight rein on applications entering a firewall. Josh stated in the last meeting that administrators want a finer granularity on what they secure coming in through firewalls to internal networks. If we define (and register, through IANA) a particular UDP port for IPP notifications, then if an administrator wanted to allow this type of service, then he/she would enable it; just like any other application. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Wednesday, February 04, 1998 1:10 PM To: ipp@pwg.org Subject: Re: Re[2]: IPP> Notifications Philip brings up an important issue which will continue to cloud our discussion of Notifications unless we understand it. >I don't see how a UDP datagram originating from outside the firewall >is going to be let inside (without assigning a special port, and >security protocol). >Of course, if we are dealing only with the Intranet, there are many easy >solutions. >Philip Thambidurai When we discuss notifications, I think some of us have different ideas based on whether we are thinking primarily Intranet or Internet When thinking Internet, an e-mail message for job complete is appropriate and acceptable. Here, I agree with the recommendations to investigate similar approaches in I-Fax. If you consider IPP as possibly the most prevalent way to submit print jobs on ANY network in the future, then I think a much more granular and streamline method should be considered. In PWG IPP, we need to address BOTH! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Feb 4 21:51:11 1998 Delivery-Date: Wed, 04 Feb 1998 21:51:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id VAA25968 for ; Wed, 4 Feb 1998 21:51:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA00763 for ; Wed, 4 Feb 1998 21:53:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16014 for ; Wed, 4 Feb 1998 21:51:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 21:46:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA15473 for ipp-outgoing; Wed, 4 Feb 1998 21:30:28 -0500 (EST) Message-ID: <34D921D4.A4A05414@parc.xerox.com> Date: Wed, 4 Feb 1998 18:20:04 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > UDP has no more firewall or proxy problem than TCP, given any arbitrary > port number. > The issues are the same for both. Is this a "first principles" argument? That is, are you speaking from experience with firewall developers and maintainers, or is it just based on reasoning about the nature of the protocols? What I have heard, both from local firewall maintainers at Xerox and more generally in discussions of firewall issues in other Internet protocols, is that there's a substantial difference in the considerations of a site allowing inbound UDP packets, allowing TCP connections with known semantic content, and allowing inbound HTTP posts with well known data content. Perhaps you have some different data that you could share with us? Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 22:20:00 1998 Delivery-Date: Wed, 04 Feb 1998 22:20:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA26249 for ; Wed, 4 Feb 1998 22:20:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA00874 for ; Wed, 4 Feb 1998 22:22:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA16942 for ; Wed, 4 Feb 1998 22:19:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 22:15:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16383 for ipp-outgoing; Wed, 4 Feb 1998 21:59:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Larry Masinter'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Wed, 4 Feb 1998 19:00:16 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I am speaking about our specific installation of Checkpoint Firewall-1, from which Cisco and a number of other vendors have licensed technology. It is as easy to open up a TCP pipe as it is UDP. This is of course a mechanical method. If you are talking about policy rather than how difficult it is to actually enable UDP or TCP, then that is a different story. Most firewall packages I'm aware of assume a certain semantic content based upon protocol (UDP or TCP) and the associated port number. The semantic assumptions regarding content usually stem from the "services" and "well-known-port" documents maintained by IANA, as well as some industry-wide de-facto standards for TCP/UDP port numbers. I know that a number of companies participate in IP Multicast based services and these types of applications use UDP for delivery of content. There are other organizations that allow SNMP management through firewalls through firewall-vendor specific authentication techniques, as well as source IP address filtering (excepting any IP spoofing attempts). I'm not an expert hacker, and I also don't subscribe to alt.2600, but the firewall product we use within our organization is the market leader, and we securely support UDP datagrams through our firewall. If there are CERT advisories or other real-world scenarios regarding break-ins or other misuse of UDP datagrams to thwart security, then I would like to know about them. These of course would need to be detailed explanations, hopefully not of the form "Well, I've heard UDP is a problem with firewall admins..." Randy -----Original Message----- From: Larry Masinter [SMTP:masinter@parc.xerox.com] Sent: Wednesday, February 04, 1998 6:20 PM To: Turner, Randy Cc: 'ipp@pwg.org' Subject: Re: IPP> Notifications > UDP has no more firewall or proxy problem than TCP, given any arbitrary > port number. > The issues are the same for both. Is this a "first principles" argument? That is, are you speaking from experience with firewall developers and maintainers, or is it just based on reasoning about the nature of the protocols? What I have heard, both from local firewall maintainers at Xerox and more generally in discussions of firewall issues in other Internet protocols, is that there's a substantial difference in the considerations of a site allowing inbound UDP packets, allowing TCP connections with known semantic content, and allowing inbound HTTP posts with well known data content. Perhaps you have some different data that you could share with us? Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 4 23:30:19 1998 Delivery-Date: Wed, 04 Feb 1998 23:30:19 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id XAA03389 for ; Wed, 4 Feb 1998 23:30:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA01064 for ; Wed, 4 Feb 1998 23:32:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA18014 for ; Wed, 4 Feb 1998 23:30:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Feb 1998 23:11:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17036 for ipp-outgoing; Wed, 4 Feb 1998 22:36:24 -0500 (EST) Message-ID: <34D933AC.28291B9E@underscore.com> Date: Wed, 04 Feb 1998 22:36:12 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org Subject: Re: IPP> Notifications References: <5030300017534955000002L052*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry Lewis wrote: > I think a printing system notification scheme should > accomodate page level granularity. Ex. Page 3 of 5 completed. What you're implying here is that the notification service must support something akin to "real-time" (relatively speaking, of course), and far from an "async, store-and-forward" method. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 00:27:59 1998 Delivery-Date: Thu, 05 Feb 1998 00:27:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04105 for ; Thu, 5 Feb 1998 00:27:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01187 for ; Thu, 5 Feb 1998 00:30:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19768 for ; Thu, 5 Feb 1998 00:27:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 00:08:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17065 for ipp-outgoing; Wed, 4 Feb 1998 22:47:04 -0500 (EST) Message-ID: <34D931C6.7753602D@underscore.com> Date: Wed, 04 Feb 1998 22:28:06 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: DAVID_KUNTZ@HP-Roseville-om2.om.hp.com CC: sense@pwg.org, IPP Mailing List Subject: IPP> Re: SENSE> Re: PWG> Maui PWG Overview Minutes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Dave, Thanks for the starting points. Do you have a bit more info or pointers for these? Javasoft Are you referring to some defined subset or related service of RMI, or the emerging CORBA-related stuff, or something else? Any specific documents/URLs/etc you might cite? OMG You must be referring to the CORBA Event Services? Do you know whether the Event Service can run "standalone" without requiring many other components of the CORBA environment? (A "too fat" implementation will kill most interest here, IMHO) Microsoft internal protocol Is this a documented, "open" protocol? (Had to ask.) Or is this a protocol that a few select players have access to, but is otherwise unavailable/undocumented for general use? Anything you (or anyone else) can provide would be appreciated. Hopefully everyone is interested in publicly discussing the alternatives while we simultaneous flesh out the key requirements. ...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 -- ---------------------------------------------------------------------- DAVID_KUNTZ@HP-Roseville-om2.om.hp.com wrote: > > Javasoft, OMG, and Microsoft's internal protocol were among the > emerging notification schemes mentioned at the meeting. > > Dave Kuntz - HP > > ______________________________ Reply Separator _________________________________ > Subject: SENSE> Re: PWG> Maui PWG Overview Minutes > Author: Non-HP-jkm (jkm@underscore.com) at HP-Roseville,mimegw3 > Date: 2/4/98 3:13 PM > > Harry, > > Part of your fine summary included this section on Sense: > > SENSE Notification Protocol > > No status. Jay Martin (SENSE Chair) not present. It is unfortunate > that we were unable to schedule a SENSE discussion in Maui because > IPP is interested in considering SENSE as notification scheme. IPP > may also want to look at SNMPv3 (recently published RFCs). It was > noted that there are many notification protocols available today > that may need to be investigated. > > Would someone be so kind as to list the "many notification protocols > available today that may need to be investigated"? I would be more > than happy to start investigated those alternatives if someone would > post them to the IPP list (or the Sense list, or whatever). > > Thanks in advance. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 00:28:01 1998 Delivery-Date: Thu, 05 Feb 1998 00:28:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04117 for ; Thu, 5 Feb 1998 00:28:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01190 for ; Thu, 5 Feb 1998 00:30:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19789 for ; Thu, 5 Feb 1998 00:27:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 00:10:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17167 for ipp-outgoing; Wed, 4 Feb 1998 22:49:56 -0500 (EST) Message-ID: <34D93515.1C4FFB61@underscore.com> Date: Wed, 04 Feb 1998 22:42:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Caruso, Angelo" CC: "'ipp@pwg.org'" Subject: Re: IPP> Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Angelo, > Has anyone considered using SNMP traps for these kinds of asynchronous > notifications? It's light-weight and quick and designed for this sort of > thing, unlike HTTP or email. Just a thought. The deficiencies of the SNMP Trap mechanism represent a cornerstone of the founding of the PWG's SENSE project. Here's a key snippet from the "SENSE Proposed Initial Requirements" document residing on the PWG server (ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt): =================== A primary motivation for developing the SENSE specification is to improve the delivery of critical messages as compared to the SNMP TRAP model. In particular, the SENSE specification should improve on these difficiencies in the SNMP TRAP mechanism: - No standard method for adding/removing TRAP destination addresses, either statically or dynamically - All TRAP messages are directed to a fixed UDP port number, thereby forcing the implementation of a demultiplexing mechanism on hosts where multiple recipients operate - Only a single copy of the TRAP message is delivered to any given destination address; if the message gets lost, then no recipient is able to determine that a TRAP message was sent =================== ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 00:29:24 1998 Delivery-Date: Thu, 05 Feb 1998 00:29:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04149 for ; Thu, 5 Feb 1998 00:29:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01215 for ; Thu, 5 Feb 1998 00:32:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA19935 for ; Thu, 5 Feb 1998 00:29:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 00:11:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17235 for ipp-outgoing; Wed, 4 Feb 1998 22:52:43 -0500 (EST) Message-ID: <34D93760.4B2A5B83@underscore.com> Date: Wed, 04 Feb 1998 22:52:00 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ron Bergman CC: sense@pwg.org, IPP Mailing List Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Ron Bergman wrote: > I would hope that before SENSE is shutdown that it is determined if this > technology is applicable to IPP. As you see by the email and minutes of > the Maui meeting, the issue of notifications is becoming a very hot topic. > The SENSE work and the knowledge you obtained should certainly be of > significant benefit to IPP. Ron, what would you suggest I do at this point to help describe how SENSE can be used for IPP? I have repeatedly requested folks to read the SENSE documentation, yet very few people have come back saying that agree/disagree on even the basic Proposed Requirements document. I guess I'm kind of at a loss at how to proceed. (You know, you can lead a horse to water, but you can't...) It appears to me that the folks on the IPP list are taking somewhat of a "fundamental research" technique in approaching async event notifications for IPP. Rather than examining an existing system (defined for that kind of operation) and seeing how it can be used to solve their particular problem, they appear to instead want to focus on the basics (eg, transports, etc) and work up from there, teaching themselves how to build a system from scratch in the process. I think that would be a shame, but if that's what it's going to take for people to understand the how's and why's of where we ended up with SENSE, then so be it. I just hope it doesn't take too long, that's all... 8-) If there's anything you (or anyone else) can do to help guide me in explaining how SENSE can be used to solve IPP's event notification problem, I am all ears. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 00:43:26 1998 Delivery-Date: Thu, 05 Feb 1998 00:43:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04432 for ; Thu, 5 Feb 1998 00:43:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01232 for ; Thu, 5 Feb 1998 00:46:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA21165 for ; Thu, 5 Feb 1998 00:43:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 00:35:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA17424 for ipp-outgoing; Wed, 4 Feb 1998 23:07:32 -0500 (EST) Message-ID: <34D93AED.DEE7DF2@underscore.com> Date: Wed, 04 Feb 1998 23:07:09 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> Who or What will use IPP notification? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Can we start a top-level discussion on how we see users using IPP notifications? You know, "scenario-like" paragaphs that focus on the user's environment in terms of platform tools, etc? For example, take the "Job completed" event. How would you describe the software components that would be used to convey these events to the user? One could imagine (eg, on a Microsoft platform) that once the user presses "Ok" on the Print dialog, some sort of background component would faithfully monitor the job as it progresses thru its life. Would such a component be visible/accessible on the user's desktop? Would it always be running, communicating with the Print dialog (and related dialogs) as necessary? Is this ia useful discussion to have at this point? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 00:43:29 1998 Delivery-Date: Thu, 05 Feb 1998 00:43:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04438 for ; Thu, 5 Feb 1998 00:43:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01235 for ; Thu, 5 Feb 1998 00:46:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA21174 for ; Thu, 5 Feb 1998 00:43:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 00:35:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA17413 for ipp-outgoing; Wed, 4 Feb 1998 23:07:03 -0500 (EST) Date: Wed, 4 Feb 1998 20:18:19 -0800 (PST) From: papowell@astart.com Message-Id: <199802050418.UAA22551@astart4.astart.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org, SISAACSON@novell.com Subject: Re: IPP> Consensus on sending our drafts to the IESG Sender: ipp-owner@pwg.org I agree with Scott. Please forward the draft. Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 619-874-6543 FAX 619-279-8424 LPRng - Print Spooler (http://www.astart.com) > I believe that we have strong consensus. Period. > > I have been involved in this WG since late 1996. I am the editor > and principal author of the Model and Semantics document. I have > contributed to all of the other IPP I-Ds. I have seen proprosals > raised, debated, modified, reworked, reviewed, analyzed, and finally > embraced. I have seen a lot of give and take. I have seen WG > meetings at the IETF where IETF attendees outside the WG have come > and participated and provided feedback and opinion. I have seen > the process work. In this latest case of "vehement opposition" I > have not seen a lot of cooperation and give and take. > > > Scott Isaacson > ************************************************************ > Scott A. Isaacson > Corporate Architect > Novell Inc., M/S PRV-C-121 > 122 E 1700 S, Provo, UT 84606 > voice: (801) 861-7366, (800) 453-1267 x17366 > fax: (801) 861-2517 > email: sisaacson@novell.com > web: http://www.novell.com > ************************************************************ From adm Thu Feb 5 00:55:34 1998 Delivery-Date: Thu, 05 Feb 1998 00:59:01 -0500 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.7/8.8.7a) id AAA04628 for ietf-outbound.10@ietf.org; Thu, 5 Feb 1998 00:55:02 -0500 (EST) Received: from monitor.internaut.com ([208.253.59.185]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA04590 for ; Thu, 5 Feb 1998 00:54:06 -0500 (EST) Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.8.7/8.8.7) with SMTP id GAA00669; Tue, 3 Feb 1998 06:07:50 -0800 (PST) (envelope-from aboba@internaut.com) Reply-To: "Bernard Aboba" From: "Bernard Aboba" To: "William Allen Simpson" , "Bob Monsour" Cc: , Subject: Re: Last Call: IP Payload Compression ... Date: Tue, 3 Feb 1998 22:03:48 -0800 Message-ID: <01bd3132$a87ea5c0$098939cc@multi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Bob Monsour wrote: > I would expect that in >the absence of IPSec, L2TP and MobileIP would make use of PPP compression. >If IPSec is present to protect those connections, then it would make sense >to use IPPCP. > Most PPP compression methods are stateful, while IPPCP is stateless. This means that IPPCP is more robust against packet loss for media (like the Internet) where ordering is not guaranteed, and substantial packet loss can occur. As a result, L2TP and MobileIP *should* use IPPCP, instead of PPP compression. It makes sense for the draft to encourage this. From ipp-owner@pwg.org Thu Feb 5 08:53:23 1998 Delivery-Date: Thu, 05 Feb 1998 08:53:23 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA11707 for ; Thu, 5 Feb 1998 08:53:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02464 for ; Thu, 5 Feb 1998 08:56:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA22535 for ; Thu, 5 Feb 1998 08:53:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 08:41:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA21965 for ipp-outgoing; Thu, 5 Feb 1998 08:25:58 -0500 (EST) From: Roger K Debry To: Cc: Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? Message-ID: <5030100017094273000002L032*@MHS> Date: Thu, 5 Feb 1998 08:24:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11707 Jay, I think SENSE has been more of a topic of discussion at printer MIB meetings. I don't recall ot getting much attention at IPP meetings. Of course, I have not been able to attend all of the meetings, but I have not personally seen a pointer to the documentation nor seen a formal presentation on SENSE. Would it be worthwhile at an IPP meeting to do this? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/05/98 06:21 AM --------------------------- ipp-owner@pwg.org on 02/04/98 10:16:49 PM Please respond to ipp-owner@pwg.org @ internet To: rbergma@dpc.com @ internet cc: ipp@pwg.org @ internet, sense@pwg.org @ internet Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? Ron Bergman wrote: > I would hope that before SENSE is shutdown that it is determined if this > technology is applicable to IPP. As you see by the email and minutes of > the Maui meeting, the issue of notifications is becoming a very hot topic. > The SENSE work and the knowledge you obtained should certainly be of > significant benefit to IPP. Ron, what would you suggest I do at this point to help describe how SENSE can be used for IPP? I have repeatedly requested folks to read the SENSE documentation, yet very few people have come back saying that agree/disagree on even the basic Proposed Requirements document. I guess I'm kind of at a loss at how to proceed. (You know, you can lead a horse to water, but you can't...) It appears to me that the folks on the IPP list are taking somewhat of a "fundamental research" technique in approaching async event notifications for IPP. Rather than examining an existing system (defined for that kind of operation) and seeing how it can be used to solve their particular problem, they appear to instead want to focus on the basics (eg, transports, etc) and work up from there, teaching themselves how to build a system from scratch in the process. I think that would be a shame, but if that's what it's going to take for people to understand the how's and why's of where we ended up with SENSE, then so be it. I just hope it doesn't take too long, that's all... 8-) If there's anything you (or anyone else) can do to help guide me in explaining how SENSE can be used to solve IPP's event notification problem, I am all ears. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 09:32:43 1998 Delivery-Date: Thu, 05 Feb 1998 09:32:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA12085 for ; Thu, 5 Feb 1998 09:32:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02592 for ; Thu, 5 Feb 1998 09:35:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23153 for ; Thu, 5 Feb 1998 09:32:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 09:28:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22628 for ipp-outgoing; Thu, 5 Feb 1998 09:12:24 -0500 (EST) Content-return: allowed Date: Thu, 5 Feb 1998 06:05:34 PST From: "Zehler, Peter " Subject: IPP> TES Trace files uploaded To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org All, A new batch of trace files has been uploaded to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces. The file ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/readme.pdf contains a description of the traces. Any comments to improve this process would be appreciated. Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Thu Feb 5 11:03:21 1998 Delivery-Date: Thu, 05 Feb 1998 11:03:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13332 for ; Thu, 5 Feb 1998 11:03:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03283 for ; Thu, 5 Feb 1998 11:06:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24568 for ; Thu, 5 Feb 1998 11:03:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 10:56:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23306 for ipp-outgoing; Thu, 5 Feb 1998 10:23:06 -0500 (EST) Message-Id: <3.0.1.32.19980205072129.009f4250@mail2.cp10.es.xerox.com> X-Sender: xriley@mail2.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Feb 1998 07:21:29 PST To: ipp@pwg.org From: "Xavier D. Riley" Subject: Re: IPP> Consensus on sending our drafts to the IESG Cc: xriley@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I reaffirm my decision, as expressed during the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards without further delay. As one that has been actually implementing a prototyping of this standard, I think the current specification is a workable solution. ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Thu Feb 5 11:03:26 1998 Delivery-Date: Thu, 05 Feb 1998 11:03:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13337 for ; Thu, 5 Feb 1998 11:03:26 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03286 for ; Thu, 5 Feb 1998 11:06:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24566 for ; Thu, 5 Feb 1998 11:03:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 10:54:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23316 for ipp-outgoing; Thu, 5 Feb 1998 10:23:10 -0500 (EST) Mime-Version: 1.0 Date: Thu, 5 Feb 1998 10:27:54 -0500 Message-ID: <0003E6AA.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: IPP> Some notification reqmts? 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 SOME REQUIREMENTS FOR NOTIFICATION. (end-user perspective, NOT administrator) 1) User/client submits a job, and can not wait for confirmation. Might be on travel or has more important business. Might have to go off-line. (Client workstation from where the job was submitted might be off). Perhaps the queue is long, or there are many large jobs pending. Here, the user simply wants to know, with high probability, if the job has completed, but not in real time. 2) User wants confirmation as soon as print is complete. User will wait for confirmation. Queue may be small and no large jobs pending. Presumably job is not huge. 3) User wants confirmation as soon as print is complete, but printer is being heavily used as determined by queue and pending job sizes. User's job may or may not be large. 4) User does not care for confirmation. 6) Is a negative ACK required? For the cases when job can not be printed although it is a perfectly valid print stream. (paper jam) Is a notification necessary if the printer determines that there will be a significant delay before printing? 7) Notification of print completion would be really useful to the receiving party. Assuming that the party is not constantly watching for output on the printer. Sorry if this is already in the model spec. This is presumably an intranet thing. SOME SITUATIONS: 1) Physical printer might run out of some resource such as paper or ink or have a mechanical problem, after the job has been submitted. Essentially this leads to UNPREDICTABLE delays in confirmation. 2) Server (assuming a non-embedded implementation) may have some unrelated failure --- either with or without loss of received print streams (after job submission). ASSUMPTIONS: 1) Job has been validated and accepted (i.e., submitted) without errors. From ipp-owner@pwg.org Thu Feb 5 11:55:42 1998 Delivery-Date: Thu, 05 Feb 1998 11:55:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14064 for ; Thu, 5 Feb 1998 11:55:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03788 for ; Thu, 5 Feb 1998 11:58:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25964 for ; Thu, 5 Feb 1998 11:55:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 11:43:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25110 for ipp-outgoing; Thu, 5 Feb 1998 11:11:41 -0500 (EST) From: Carl Kugler To: Subject: RE: IPP> Notifications Message-ID: <5030100017101142000002L022*@MHS> Date: Thu, 5 Feb 1998 11:11:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14064 But... Proxies don't open up TCP or UDP pipes. Proxies pass nothing through. Everything gets pulled up to the application level and then resent. Much more secure that way. Also, note that very few corporate firewalls are configured to let NFS through. That's partly because NFS is UDP-based and can't be securely controlled. -Carl ipp-owner@pwg.org on 02/04/98 08:17:53 PM Please respond to ipp-owner@pwg.org @ internet To: masinter@parc.xerox.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I am speaking about our specific installation of Checkpoint Firewall-1, from which Cisco and a number of other vendors have licensed technology From ipp-owner@pwg.org Thu Feb 5 12:05:12 1998 Delivery-Date: Thu, 05 Feb 1998 12:05:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14201 for ; Thu, 5 Feb 1998 12:05:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03859 for ; Thu, 5 Feb 1998 12:07:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26592 for ; Thu, 5 Feb 1998 12:05:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 11:56:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25139 for ipp-outgoing; Thu, 5 Feb 1998 11:18:04 -0500 (EST) Date: Thu, 5 Feb 1998 08:11:57 -0800 (Pacific Standard Time) From: Ron Bergman To: ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG In-Reply-To: <3.0.1.32.19980205072129.009f4250@mail2.cp10.es.xerox.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I reaffirm my decision, as expressed during the meeting in Maui, to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG with the recommendation as Proposed Standards without further delay. One of the emails that objected to this proposal indicated that there were several issues, other than the XML encoding, which needed to be resolved before these documents should be submitted. I had been waiting for a statement of these issues before reaffirming my decision. Since this never appeared, my original position stands. (I do not recall any issues, other than XML, in any of the past emails or meetings that would be a major obstacle to this position.) Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Thu Feb 5 12:35:01 1998 Delivery-Date: Thu, 05 Feb 1998 12:35:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14482 for ; Thu, 5 Feb 1998 12:35:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04001 for ; Thu, 5 Feb 1998 12:37:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27325 for ; Thu, 5 Feb 1998 12:34:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 12:22:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25346 for ipp-outgoing; Thu, 5 Feb 1998 11:41:15 -0500 (EST) From: Carl Kugler To: Subject: RE: IPP> Notifications Message-ID: <5030100017102552000002L022*@MHS> Date: Thu, 5 Feb 1998 11:40:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14482 > What will actually happen is that we will all poll :-( I think that's the best we can do if we limit ourselves to the existing Web infrastructure. Meanwhile, implementers will find ways to do asynchronous notifications outside the IPP box, as proprietary extensions. Later, the IPP v2 working group can look at what works and select or synthesize some approach as standard for IPP asynch notification. And by then maybe the Web won't be so asymmetrical. Anyway, polling might not be elegant, but I think it can do the job. With HTTP/1.1, the client will be polling over a persistant connection, so the overhead should be low. Polling rates could be fairly slow, since there's no need for instantaneous notification with an application like printing. -Carl ipp-owner@pwg.org on 02/04/98 01:53:15 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: RE: IPP> Notifications No argument at all. This is othogonal to the XML debate. I am looking at expanding IPP to cover many needs beyond the relatively simple feature set currently defined, the extensibility issue led me to the XML proposal, the unsolicited message issue led me to this thread. The point I am making is that using HTTP asymmetrically (i.e the client always POSTs, the printer always listens for POST - which is the 'natural' use of HTTP) precludes the core IPP protocol from generating asynchronous or unsolicited reverse messages. This is a major limitiation - I want to be sure that everybody knows that we are doing it and that we all accept the trade-off. I'm sure we could invent lots of hacks later on the will work round this but that's not an ideal solution. What will actually happen is that we will all poll :-( > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, February 04, 1998 9:40 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > Paul- > > I would like to point out that the XML/new method proposal is no better in > this > respect. The problem is not that IPP is asymmetric: the underlying HTTP > transport layer is asymmetric, and that is common to both approaches. > > - Carl > > > > ipp-owner@pwg.org on 02/03/98 12:24:44 PM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> Notifications > > > Has anybody noticed that IPP will be useless for notifications due to the > asymmetry of the protocol? As currently constituted a printer cannot send > an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? > > > From ipp-owner@pwg.org Thu Feb 5 12:43:18 1998 Delivery-Date: Thu, 05 Feb 1998 12:43:19 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14545 for ; Thu, 5 Feb 1998 12:43:18 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04047 for ; Thu, 5 Feb 1998 12:45:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27914 for ; Thu, 5 Feb 1998 12:43:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 12:34:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26686 for ipp-outgoing; Thu, 5 Feb 1998 12:09:03 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Thu, 5 Feb 1998 09:09:32 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I'm not sure what "proxy" means in this context. I'm assuming for the purposes of realtime asynchronous notification that we would not be using HTTP as a transport, so any issues surrounding HTTP proxies would be moot. Are we talking about some other type of proxy? In my experience, UDP wasn't the problem with NFS mounts over the internet. Rather, its just too easy to hack NFS UID-style authentication. Especially with SUNOS systems that had the annoying habit of including a "nobody" user UID in the default /etc/passwd file. This "well-known" UID pair was used by hackers to mount attacks on the "/" root partition, retrieving a sites /etc/passwd file, and then locally running "crack" on their system until they had the root password. This problem was exascerbated because administrators were too lazy configuring their "exports" file by including the "/" partition, and not restricting mounts to this partition to specific hosts only. Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3, at least on Sun SunOS/Solaris systems. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Thursday, February 05, 1998 8:11 AM To: ipp@pwg.org Subject: RE: IPP> Notifications But... Proxies don't open up TCP or UDP pipes. Proxies pass nothing through. Everything gets pulled up to the application level and then resent. Much more secure that way. Also, note that very few corporate firewalls are configured to let NFS through. That's partly because NFS is UDP-based and can't be securely controlled. -Carl ipp-owner@pwg.org on 02/04/98 08:17:53 PM Please respond to ipp-owner@pwg.org @ internet To: masinter@parc.xerox.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I am speaking about our specific installation of Checkpoint Firewall-1, from which Cisco and a number of other vendors have licensed technology From ipp-owner@pwg.org Thu Feb 5 12:48:58 1998 Delivery-Date: Thu, 05 Feb 1998 12:48:58 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14740 for ; Thu, 5 Feb 1998 12:48:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04099 for ; Thu, 5 Feb 1998 12:51:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28578 for ; Thu, 5 Feb 1998 12:48:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 12:44:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26611 for ipp-outgoing; Thu, 5 Feb 1998 12:05:20 -0500 (EST) From: Roger K Debry To: Subject: IPP> More requirements Message-ID: <5030100017103751000002L012*@MHS> Date: Thu, 5 Feb 1998 12:04:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14740 Some additional requirements in SOME REQUIREMENTS FOR NOTIFICATION. (end-user perspective, NOT administrator) 1) User/client submits a job, and can not wait for confirmation. Might be on travel or has more important business. Might have to go off-line. (Client workstation from where the job was submitted might be off). Perhaps the queue is long, or there are many large jobs pending. Here, the user simply wants to know, with high probability, if the job has completed, but not in real time. If the user is mobile and has to disconnect, might want to see all notifications when he/she re-connects to the network. notifications are queued someplace. Email seems best suited. User might want someone else (for example a secretary) to get notifications. For example "put this in the mail for me when it gets printed." Other person may be in a different authorization domain. For example "I am printing something on a printer in your office, you will get the notification when it is done so you can go and pick it up." 2) User wants confirmation as soon as print is complete. User will wait for confirmation. Queue may be small and no large jobs pending. Presumably job is not huge. 3) User wants confirmation as soon as print is complete, but printer is being heavily used as determined by queue and pending job sizes From ipp-owner@pwg.org Thu Feb 5 13:48:08 1998 Delivery-Date: Thu, 05 Feb 1998 13:48:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15611 for ; Thu, 5 Feb 1998 13:47:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04357 for ; Thu, 5 Feb 1998 13:50:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29693 for ; Thu, 5 Feb 1998 13:47:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 13:35:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28653 for ipp-outgoing; Thu, 5 Feb 1998 12:52:35 -0500 (EST) Message-Id: <3.0.1.32.19980205094813.00964250@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Feb 1998 09:48:13 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Consensus on sending our drafts to the IESG? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org This is just a reminder. Many of you have already given feedback to the IPP DL about your position. If you have not yet expressed an opinion, and want to do so, please send it to the IPP DL today. Thanks, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 5 13:51:33 1998 Delivery-Date: Thu, 05 Feb 1998 13:51:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15661 for ; Thu, 5 Feb 1998 13:51:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04384 for ; Thu, 5 Feb 1998 13:54:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00239 for ; Thu, 5 Feb 1998 13:51:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 13:41:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28686 for ipp-outgoing; Thu, 5 Feb 1998 12:56:21 -0500 (EST) Message-ID: <34D9FD25.342C9C3B@underscore.com> Date: Thu, 05 Feb 1998 12:55:49 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP> Re: SENSE> Time to shutdown the SENSE project? References: <5030100017094273000002L032*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger, > I think SENSE has been more of a topic of discussion at printer MIB meetings. > I don't recall ot getting much attention at IPP meetings. Of course, I have not > been able to attend all of the meetings, but I have not personally seen a > pointer to the documentation nor seen a formal presentation on SENSE. > Would it be worthwhile at an IPP meeting to do this? For starters, check out the PWG website (http://www.pwg.org) where you will find the SENSE project listed along with all the other PWG projects. Follow the link to the SENSE home page, where all the current documents are listed with easy single-click access to each and every document. In particular, I would request that everyone take about 5 minutes to review the very first document published for SENSE, namely the "SENSE Proposed Initial Requirements" document located at: ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt Since the document is pretty small I have taken the liberty of attaching it below so folks can start looking at the fundamentals. If nothing else, some of the functional requirements and constraints listed in that document could be used to jump-start the IPP async notification function requirements. ...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 -- ---------------------------------------------------------------------- Simple Event Notification Service Environment (SENSE) Proposed Initial Requirements Version 1.0 28 November 1995 This document describes the requirements for a Simple Event Notification Service Environment (SENSE) and related protocol(s). This document is intended to serve as a basis for ongoing research and discussion by interested parties in developing more formal specifications and implementations. Overview -------- The need for SENSE stems from the widespread need for simple notification of events from various kinds of network entities to network clients. Work in this area was originated by JK Martin (Underscore), Rick Landau (Digital) and Mike Timperman (Lexmark) in response to an identified need for transmission of events from network printer devices to network management applications designed to monitor such devices. As work progressed it became readily apparent that the need for such notification services are pervasive in today's widespread client/server environments. The operative word in this initiative is "simple"; the intent is to derive a very simple facility that serves as a "wrapper protocol" that can support the delivery of event messages from a wide variety of sources. It is all too easy to go "hog wild" and specify intricate mechanisms for such a facility. It is the intent of the original development group to keep the SENSE facility very, very simple so as to support both simple client implementations and simple server implementations. It is a specific goal to make the SENSE facility easily implementable in small embedded systems, such as low-cost network printers and printer server devices. While it is not the intent to support only network printer devices, the final results of this initiative should support network printer devices to the maximum extent possible. Glossary -------- Following is a brief set of terms used elsewhere in this document: Event Any single instance of time-oriented information that may arise during the operation of an entity. There are no semantics associated with an Event; an Event can be anything from a "warning" to an "alert" to a simple informational statement. Event Source An entity that emits Events during its operation. Event Message A message containing an Event. The contents and format of the message are not defined by the SENSE facility; that is, the message content is opaque with respect to the protocol used by the SENSE facility. Event Server A network entity that provides event notification services. Event Client A network entity that consumes event notification services. Registration The transaction initiated by an Event Client to an Event Server in which the Client requests services from the Server. A Server expects Registration requests at any time during its operation. Subscription The relationship between an Event Client and an Event Server. A Client registers a Subscription with the Server for an agreed upon period of time, afterwhich the Subscription is automatically terminated by the Server. A "Subscription" can be viewed as a time-limited session between a Client and a Server. SENSE Requirements ------------------ A primary motivation for developing the SENSE specification is to improve the delivery of critical messages as compared to the SNMP TRAP model. In particular, the SENSE specification should improve on these difficiencies in the SNMP TRAP mechanism: - No standard method for adding/removing TRAP destination addresses, either statically or dynamically - All TRAP messages are directed to a fixed UDP port number, thereby forcing the implementation of a demultiplexing mechanism on hosts where multiple recipients operate - Only a single copy of the TRAP message is delivered to any given destination address; if the message gets lost, then no recipient is able to determine that a TRAP message was sent SENSE must satisfy the following functional and operational requirements (not listed in any particular order): 1. Relatively reliable receipt of Event Messages A key requirement is for a Client to expect reasonably reliable receipt of Event Messages. The term "reasonably reliable" is used to denote the fact that a Server should make multiple attempts to deliver the message to the Client. It should be noted that absolute reliability is not considered practical, and thus, not considered as a requirement. 2. Datagrams are used at the transport layer Since stream-oriented protocols are typically considered too "heavy" for lightweight services, datagrams should be used for all SENSE protocol implementations. 3. A well-known transport address is defined for common use To facilitate interoperability, the Server should operate using a standard, "well known" transport address. 4. A Server can operate using any transport address The Server should be able to operate with any defined address within the target transport environment. This will, of course, require that Clients know of and use the non-standard transport address. This requirement is called out so as to allow a Server to operate in an environment in which the standard transport address is already in use. This requirement should be considered optional for an implementation. 5. Minimal protocol data formatting requirements To maintain simplicity, the protocol data units (PDUs) should use displayable text strings for all data components rather than the equivalent binary forms. Using displayable text circumvents the incompatibilities between various network platforms and allows for simple implementation of Client applications. Since the number of PDUs exchanged between a Client and a Server is expected to be rather small, the resulting parsing of the data components by the Client and Server should not be considered a performance problem. 6. Multiple sources of events can be managed by a single Server A Server should be able to "front-end" any number of Event Sources. No minimum or maximum number of supported Event Sources should be required. 7. A Server can be queried to determine the set of event sources managed by the Server A Client should be able to request the list of Event Sources supported by the Server. The list should be formatted in displayable text. 8. A Server can be queried to determine its operational parameters A Client should be able to request a list of operational parameters and their values from the Server. The list should be formatted in displayable text. 9. A simple loopback capability to determine Server existence A Client should be able to "ping" the Server to determine whether the Server is operating at the target transport address. This requirement could be reasonably satisfied through the implementation of Requirement #8 above 10. A client dynamically registers for receipt of events from multiple event sources A Client should be able to dynamically request the creation of a Subscription from a Server, in which any number of Event Sources may be specified as being part of the Subscription. The Subscription request also includes a requested period of time for which the Subscription remains active; once this time period is exceeded, the Server automatically terminates the Subscription without further action by the Client. 11. A client specifies the network endpoint to which all Event Messages are directed When the Client requests the creation of a Subscription, part of the request includes the destination transport address (network address and transport port number) to which all Event Messages are delivered. 12. A client can cancel a subscription at any time A Client is free to prematurely cancel a Subscription (before the Subscription period runs out). 13. Event Messages are asynchronously transmitted by the Server to all registered clients when an event occurs The Server should send Event Messages to the network/transport address specified by the Client at Subscription request time as events occur. The Server will continue to periodically retransmit an Event Message until either the Server-defined retransmit time/count runs out, or until the Client acknowledges receipt of the event. 14. Clients acknowledge receipt of events A Client must acknowledge receipt of an Event Message from a Server. 15. The precise content and format of an Event Message is opaque relative to the underlying SENSE protocol The format and contents of an Event Message are (by definition) not defined within the SENSE specification; instead, the Client is expected to be intimately familiar with the format of such messages based on the associated Event Source. 16. A Server must be able to control resource consumption A key aspect of the SENSE facility is to be highly "Server-oriented" with respect to implementation and performance. In particular, the Server should be allowed to arbitrarily implement the values for such parameters as: Maximum number of Subscriptions Maximum Subscription period Maximum number of retries for delivery of event messages It is expected that the values of these parameters (and probably many others) will be part of the response to a request for a Server's operational parameters as described in Requirement #8 above. While not called out as a requirement in the above list, it is expected that the SENSE facility should be implemented for use with at least the following transports: - UDP/IP - IPX - AppleTalk DDP Other datagram-oriented transports are not necessarily precluded from implementation. Functional Model ---------------- A crude structural diagram that can be used to describe the desired functional model is shown below: Client -----| . | |--- Event Source . | | . . | | . Client -----+----- Server ---+--- Event Source . | | . . | | . . | |--- Event Source . | Client -----| This diagram describes the three primary interworking entities: Client Server Event Source The protocol used between the Client and the Server is expected to be defined for the SENSE facility. On the other hand, the protocol(s) between the Server and the Event Sources are not expected to be defined in the SENSE specification. Protocol Exchange Example ------------------------- Following is a rough protocol diagram describing the basic, error-free exchange between a Client and a Server whereby: o The Client registers a Subscription with the Server o The Server later sends Event Messages to the Client o The Client cancels the Subscription Client Server ------ ------ >---------- registration request ----------> <---------- registration reply ----------< . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . >---------- termination request ----------> <---------- termination reply ----------< # # # # # From ipp-owner@pwg.org Thu Feb 5 13:54:02 1998 Delivery-Date: Thu, 05 Feb 1998 13:54:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15680 for ; Thu, 5 Feb 1998 13:54:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04398 for ; Thu, 5 Feb 1998 13:56:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00591 for ; Thu, 5 Feb 1998 13:53:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 13:46:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28716 for ipp-outgoing; Thu, 5 Feb 1998 13:04:25 -0500 (EST) From: Roger K Debry To: Subject: RE: IPP> Notifications Message-ID: <5030100017106455000002L052*@MHS> Date: Thu, 5 Feb 1998 13:03:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15680 > What will actually happen is that we will all poll :-( I think that's the best we can do if we limit ourselves to the existing Web infrastructure. Meanwhile, implementers will find ways to do asynchronous notifications outside the IPP box, as proprietary extensions. Later, the IPP v2 working group can look at what works and select or synthesize some approach as standard for IPP asynch notification. And by then maybe the Web won't be so asymmetrical. Anyway, polling might not be elegant, but I think it can do the job. With HTTP/1.1, the client will be polling over a persistant connection, So you assume that we would keep a connection open until a print job is completed and a notification provided? I don't know if I'd agree that this is a good idea. so the overhead should be low. Polling rates could be fairly slow, since there's no need for instantaneous notification with an application like printing. -Carl ipp-owner@pwg.org on 02/04/98 01:53:15 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: RE: IPP> Notifications No argument at all. This is othogonal to the XML debate. I am looking at expanding IPP to cover many needs beyond the relatively simple feature set currently defined, the extensibility issue led me to the XML proposal, the unsolicited message issue led me to this thread. The point I am making is that using HTTP asymmetrically (i.e the client always POSTs, the printer always listens for POST - which is the 'natural' use of HTTP) precludes the core IPP protocol from generating asynchronous or unsolicited reverse messages. This is a major limitiation - I want to be sure that everybody knows that we are doing it and that we all accept the trade-off. I'm sure we could invent lots of hacks later on the will work round this but that's not an ideal solution. What will actually happen is that we will all poll :-( > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, February 04, 1998 9:40 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > Paul- > > I would like to point out that the XML/new method proposal is no better in > this > respect. The problem is not that IPP is asymmetric: the underlying HTTP > transport layer is asymmetric, and that is common to both approaches. > > - Carl > > > > ipp-owner@pwg.org on 02/03/98 12:24:44 PM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> Notifications > > > Has anybody noticed that IPP will be useless for notifications due to the > asymmetry of the protocol? As currently constituted a printer cannot send > an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? > > > From ipp-owner@pwg.org Thu Feb 5 14:58:54 1998 Delivery-Date: Thu, 05 Feb 1998 14:58:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA16885 for ; Thu, 5 Feb 1998 14:58:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04651 for ; Thu, 5 Feb 1998 15:01:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA01299 for ; Thu, 5 Feb 1998 14:58:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 14:50:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00710 for ipp-outgoing; Thu, 5 Feb 1998 14:30:38 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Roger K Debry'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Thu, 5 Feb 1998 11:31:14 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Of course polling is the "standard" solution for status notification in IPP v1.0. Per our last meeting, IPP v1.0 is "in the bag". We're done. It was my impression that the entire discussion on async notifications was within the context of what we need for v2.0. Randy -----Original Message----- From: Roger K Debry [SMTP:rdebry@us.ibm.com] Sent: Thursday, February 05, 1998 10:04 AM To: ipp@pwg.org Subject: RE: IPP> Notifications > What will actually happen is that we will all poll :-( I think that's the best we can do if we limit ourselves to the existing Web infrastructure. Meanwhile, implementers will find ways to do asynchronous notifications outside the IPP box, as proprietary extensions. Later, the IPP v2 working group can look at what works and select or synthesize some approach as standard for IPP asynch notification. And by then maybe the Web won't be so asymmetrical. Anyway, polling might not be elegant, but I think it can do the job. With HTTP/1.1, the client will be polling over a persistant connection, So you assume that we would keep a connection open until a print job is completed and a notification provided? I don't know if I'd agree that this is a good idea. so the overhead should be low. Polling rates could be fairly slow, since there's no need for instantaneous notification with an application like printing. -Carl ipp-owner@pwg.org on 02/04/98 01:53:15 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: RE: IPP> Notifications No argument at all. This is othogonal to the XML debate. I am looking at expanding IPP to cover many needs beyond the relatively simple feature set currently defined, the extensibility issue led me to the XML proposal, the unsolicited message issue led me to this thread. The point I am making is that using HTTP asymmetrically (i.e the client always POSTs, the printer always listens for POST - which is the 'natural' use of HTTP) precludes the core IPP protocol from generating asynchronous or unsolicited reverse messages. This is a major limitiation - I want to be sure that everybody knows that we are doing it and that we all accept the trade-off. I'm sure we could invent lots of hacks later on the will work round this but that's not an ideal solution. What will actually happen is that we will all poll :-( > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, February 04, 1998 9:40 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > Paul- > > I would like to point out that the XML/new method proposal is no better in > this > respect. The problem is not that IPP is asymmetric: the underlying HTTP > transport layer is asymmetric, and that is common to both approaches. > > - Carl > > > > ipp-owner@pwg.org on 02/03/98 12:24:44 PM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> Notifications > > > Has anybody noticed that IPP will be useless for notifications due to the > asymmetry of the protocol? As currently constituted a printer cannot send > an > unsolicted message to anybody. > > Was this discussed later on on the Thursday brainstorm? > > > From ipp-owner@pwg.org Thu Feb 5 15:11:42 1998 Delivery-Date: Thu, 05 Feb 1998 15:11:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA17030 for ; Thu, 5 Feb 1998 15:11:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04711 for ; Thu, 5 Feb 1998 15:14:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01914 for ; Thu, 5 Feb 1998 15:11:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 15:06:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00735 for ipp-outgoing; Thu, 5 Feb 1998 14:43:46 -0500 (EST) Message-ID: <34DA1666.85B4CC13@underscore.com> Date: Thu, 05 Feb 1998 14:43:34 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Notifications References: <5030100017106455000002L052*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > Anyway, polling might not be elegant, but I think it can do the job. With > HTTP/1.1, the client will be polling over a persistant connection, > > So you assume that we would keep a connection open until > a print job is completed and a notification provided? I > don't know if I'd agree that this is a good idea. I agree with Roger. Maintaining a connection for the lifetime of the job will not scale very well in large environments. Maintaining a constant connection might be ok for the "Internet fax printer" scenario, but it just won't fly in the enterprise. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 5 16:12:08 1998 Delivery-Date: Thu, 05 Feb 1998 16:12:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA18205 for ; Thu, 5 Feb 1998 16:12:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04999 for ; Thu, 5 Feb 1998 16:14:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02609 for ; Thu, 5 Feb 1998 16:12:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 16:05:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02057 for ipp-outgoing; Thu, 5 Feb 1998 15:49:13 -0500 (EST) From: Carl Kugler To: Subject: RE: IPP> Notifications Message-ID: <5030100017114915000002L052*@MHS> Date: Thu, 5 Feb 1998 15:48:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18205 Randy- By "proxy", I mean "proxy server", specifically "application-level proxy server" or "gateway": a server that receives requests intended for another server and that acts on the client's behalf (as the client's proxy) to obtain the requested service. These are high-end firewall devices that operate at the upper levels of the protocol stack (i.e., all the way up to the application layer), providing the highest level of protection available today. The proxy server changes the IP address of the client packets to essentially hide the internal client to the Internet, then it acts as a proxy agent for the client on the Internet. In some cases (e.g., SGI Guantlet), a proxy server is required for each protocol on a gateway. For example, one is required for HTTP requests, another for FTP requests, and so on. Circuit-level gateways (e.g., SOCKS, rfc1928) provide a controlled network connection between internal and external systems. A virtual "circuit" exists between the internal client and the proxy server. Internet requests go through this circuit to the proxy server, and the proxy server delivers those requests to the Internet after changing the IP address. External users only see the IP address of the proxy server. Responses are then received by the proxy server and sent back through the circuit to the client. While traffic is allowed through, external systems never see the internal systems. In general the only packets allowed back through a proxy server are those that return responses to requests from inside the firewall. I think the type of firewall you're discussing is the router based packet filtering type (screening router), which works in the lower layers of the network protocol stack. It would be interesting to know the install base of the various types of firewalls. I know here at IBM we use proxy servers (now mostly SOCKS gateways, formerly mostly application proxies). If use a protocol other than HTTP as a transport for realtime asynchronous notification, won't we lose the advantages that we gained by chosing HTTP in the first place? -Carl ipp-owner@pwg.org on 02/05/98 10:44:30 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: RE: IPP> Notifications I'm not sure what "proxy" means in this context. I'm assuming for the purposes of realtime asynchronous notification that we would not be using HTTP as a transport, so any issues surrounding HTTP proxies would be moot. Are we talking about some other type of proxy? In my experience, UDP wasn't the problem with NFS mounts over the internet. Rather, its just too easy to hack NFS UID-style authentication. Especially with SUNOS systems that had the annoying habit of including a "nobody" user UID in the default /etc/passwd file. This "well-known" UID pair was used by hackers to mount attacks on the "/" root partition, retrieving a sites /etc/passwd file, and then locally running "crack" on their system until they had the root password. This problem was exascerbated because administrators were too lazy configuring their "exports" file by including the "/" partition, and not restricting mounts to this partition to specific hosts only. Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3, at least on Sun SunOS/Solaris systems. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Thursday, February 05, 1998 8:11 AM To: ipp@pwg.org Subject: RE: IPP> Notifications But... Proxies don't open up TCP or UDP pipes. Proxies pass nothing through. Everything gets pulled up to the application level and then resent. Much more secure that way. Also, note that very few corporate firewalls are configured to let NFS through. That's partly because NFS is UDP-based and can't be securely controlled. -Carl ipp-owner@pwg.org on 02/04/98 08:17:53 PM Please respond to ipp-owner@pwg.org @ internet To: masinter@parc.xerox.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I am speaking about our specific installation of Checkpoint Firewall-1, from which Cisco and a number of other vendors have licensed technology From ipp-owner@pwg.org Thu Feb 5 17:03:41 1998 Delivery-Date: Thu, 05 Feb 1998 17:03:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA18980 for ; Thu, 5 Feb 1998 17:03:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05303 for ; Thu, 5 Feb 1998 17:06:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03521 for ; Thu, 5 Feb 1998 17:03:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 16:53:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02733 for ipp-outgoing; Thu, 5 Feb 1998 16:34:51 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC1F8@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> voting on submission Date: Thu, 5 Feb 1998 11:54:33 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Just to get these things on record. I vote that we change our submission to use PRINT and to use XML. (No suprises there!) From ipp-owner@pwg.org Thu Feb 5 17:19:43 1998 Delivery-Date: Thu, 05 Feb 1998 17:19:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19204 for ; Thu, 5 Feb 1998 17:19:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05365 for ; Thu, 5 Feb 1998 17:22:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04185 for ; Thu, 5 Feb 1998 17:19:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 17:12:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02765 for ipp-outgoing; Thu, 5 Feb 1998 16:48:49 -0500 (EST) Message-Id: <3.0.32.19980205134511.0071680c@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 5 Feb 1998 13:45:12 PST To: ipp@pwg.org From: Rick Yardumian Subject: Re: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I vote to send the IPP Model & Semantics and the Protocol Specification drafts to the IESG without further delay. I'm involved in an IPP prototyping effort and based on the results I feel the current specification is a usable solution. ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-owner@pwg.org Thu Feb 5 17:39:12 1998 Delivery-Date: Thu, 05 Feb 1998 17:39:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19445 for ; Thu, 5 Feb 1998 17:39:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05408 for ; Thu, 5 Feb 1998 17:41:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04810 for ; Thu, 5 Feb 1998 17:39:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 17:33:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04008 for ipp-outgoing; Thu, 5 Feb 1998 17:15:47 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl Kugler'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notifications Date: Thu, 5 Feb 1998 14:16:18 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org The proxy you are talking about is SOCKS-based...ok, I understand how SOCKS works. That's pretty much all we had until real firewall products came along, and yes SOCKS-based products might have a problem with UDP. But I don't think the majority of enterprise firewall solutions are based on SOCKS, because it is doesn't quite have the flexibility of real firewall products. SOCKS application gateways require that all applications be modified to speak SOCKS, and if not the applications, then the runtime libraries or DLLS or whatever have to modified. Products like Checkpoint Firewall-1 and other firewall products are much more transparent with regards to their NAT (network address translation) capabilities. In my opinion, SOCKS is more of a niche player in the enterprise firewall world. But this is just my opinion. I also don't think we are losing anything by defining a notification method outside of HTTP; in fact, we could define a standards-track document for IPP async notifications that would be immune to legacy or other future protocol mapping techniques for IPP job submission. Like Paul Moore mentioned in an earlier mail message, HTTP wasn't designed for this type of functionality (async notifications) so I think a separate out-of-band (to HTTP) method is in order. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Thursday, February 05, 1998 12:49 PM To: ipp@pwg.org Subject: RE: IPP> Notifications Randy- By "proxy", I mean "proxy server", specifically "application-level proxy server" or "gateway": a server that receives requests intended for another server and that acts on the client's behalf (as the client's proxy) to obtain the requested service. These are high-end firewall devices that operate at the upper levels of the protocol stack (i.e., all the way up to the application layer), providing the highest level of protection available today. The proxy server changes the IP address of the client packets to essentially hide the internal client to the Internet, then it acts as a proxy agent for the client on the Internet. In some cases (e.g., SGI Guantlet), a proxy server is required for each protocol on a gateway. For example, one is required for HTTP requests, another for FTP requests, and so on. Circuit-level gateways (e.g., SOCKS, rfc1928) provide a controlled network connection between internal and external systems. A virtual "circuit" exists between the internal client and the proxy server. Internet requests go through this circuit to the proxy server, and the proxy server delivers those requests to the Internet after changing the IP address. External users only see the IP address of the proxy server. Responses are then received by the proxy server and sent back through the circuit to the client. While traffic is allowed through, external systems never see the internal systems. In general the only packets allowed back through a proxy server are those that return responses to requests from inside the firewall. I think the type of firewall you're discussing is the router based packet filtering type (screening router), which works in the lower layers of the network protocol stack. It would be interesting to know the install base of the various types of firewalls. I know here at IBM we use proxy servers (now mostly SOCKS gateways, formerly mostly application proxies). If use a protocol other than HTTP as a transport for realtime asynchronous notification, won't we lose the advantages that we gained by chosing HTTP in the first place? -Carl ipp-owner@pwg.org on 02/05/98 10:44:30 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: RE: IPP> Notifications I'm not sure what "proxy" means in this context. I'm assuming for the purposes of realtime asynchronous notification that we would not be using HTTP as a transport, so any issues surrounding HTTP proxies would be moot. Are we talking about some other type of proxy? In my experience, UDP wasn't the problem with NFS mounts over the internet. Rather, its just too easy to hack NFS UID-style authentication. Especially with SUNOS systems that had the annoying habit of including a "nobody" user UID in the default /etc/passwd file. This "well-known" UID pair was used by hackers to mount attacks on the "/" root partition, retrieving a sites /etc/passwd file, and then locally running "crack" on their system until they had the root password. This problem was exascerbated because administrators were too lazy configuring their "exports" file by including the "/" partition, and not restricting mounts to this partition to specific hosts only. Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3, at least on Sun SunOS/Solaris systems. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Thursday, February 05, 1998 8:11 AM To: ipp@pwg.org Subject: RE: IPP> Notifications But... Proxies don't open up TCP or UDP pipes. Proxies pass nothing through. Everything gets pulled up to the application level and then resent. Much more secure that way. Also, note that very few corporate firewalls are configured to let NFS through. That's partly because NFS is UDP-based and can't be securely controlled. -Carl ipp-owner@pwg.org on 02/04/98 08:17:53 PM Please respond to ipp-owner@pwg.org @ internet To: masinter@parc.xerox.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Notifications I am speaking about our specific installation of Checkpoint Firewall-1, from which Cisco and a number of other vendors have licensed technology From ipp-owner@pwg.org Thu Feb 5 19:48:41 1998 Delivery-Date: Thu, 05 Feb 1998 19:48:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA20593 for ; Thu, 5 Feb 1998 19:48:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05822 for ; Thu, 5 Feb 1998 19:51:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06049 for ; Thu, 5 Feb 1998 19:48:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 19:40:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04985 for ipp-outgoing; Thu, 5 Feb 1998 19:09:48 -0500 (EST) Message-Id: <3.0.1.32.19980205160909.0104fac0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 5 Feb 1998 16:09:09 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Consensus on sending our drafts to the IESG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org After having heard and been involved in the discussions on using XML, instead of our binary encoding, I'm convinced that we should forward the IPP Model and Protocol documents as they are. I was willing to consider XML, but the following persuades me that we would be ill-advised at this time: 1. XML 1.0 was designed for representing documents, not attributes. While there are some in the W3C XML group that want to extend XML for representing attributes, subsetting the parts of XML not needed and adding data types, it is not clear whether they will prevail on the part of the W3C XML group that considers XML fine as it is for representing documents. 2. If the IPP WG were to use XML 1.0 now, we would make decisions about using XML for representing attributes that would likely be different than the XML group will do, if they do at all. For example, the representation of dates, ranges, multi-valued attributes, data types, data type names, etc. (I had hoped that a draft of IPP in XML would have been forth coming during our review that just used basic XML, but that doesn't seem possible, now that we understand the current capabilities of XML a little better). 3. If the IPP WG were to wait for the W3C XML to support attributes in an approved XML version, IPP would be delayed at least six to nine months, if not longer. The prototyping work of the last year would need to be largely repeated. Printer, network, and OS vendors would likely deploy their own proprietary versions in the meantime, making IPP largely irrelevant. 4. One of the concerns that the IESG has had about IPP using HTTP is that HTTP has lots of other requirements that pull it in directions that might not suit IPP. The same is likely to be true for XML (e.g., representing documents vs. representing attributes). 5. The prototyping work that we have done during the past year shows that the current protocol is workable. 6. IPP has had a lot of significant involvement and contributions from printer vendors, NOS vendors, and OS vendors. This is a historic achievement! I have never seen a standard in this area in which all the major players have been involved. Lets not lose this "window of opportunity" in the name of waiting for something better. When that comes, if ever, there will be something coming down the pike after it, that is even better. That is the nature of our business. Lets ship what we have now, since we have shown that it meets our requirements and has been designed to be extensible to meet our future requirements. Tom Hastings From ipp-owner@pwg.org Thu Feb 5 19:49:52 1998 Delivery-Date: Thu, 05 Feb 1998 19:49:52 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA20604 for ; Thu, 5 Feb 1998 19:49:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05826 for ; Thu, 5 Feb 1998 19:52:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06196 for ; Thu, 5 Feb 1998 19:49:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Feb 1998 19:42:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05004 for ipp-outgoing; Thu, 5 Feb 1998 19:13:41 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Notifications Message-ID: <5030100017123542000002L022*@MHS> Date: Thu, 5 Feb 1998 19:12:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA20604 Persistent connections are really the domain of the HTTP transport layer, not IPP. But anyway, I was thinking of polling intervals of around 30 seconds. At that rate, maintaining a connection for the lifetime of the job is probably cheaper than tearing down and re-establishing a connection for each poll. HTTP servers are free to close connections any time, so if the server is running low on memory it can close idle connections at will. If the server has the resources to keep the connection open, then the client shouldn't close it unless the client will not be using the server again for at least a minute, since closing and then reopening adds computational overhead to the server, adds round trip delays, results in more network traffic from overhead (SYN, ACK, FIN) than payload data, and consumes server resources with closed connections in TIME_WAIT. References: HTTP Connection Management: ftp://ietf.org/internet-drafts/draft-ietf-http-connection-00.txt The Case for Persistent-Connection HTTP: http://www.research.digital.com/wrl/techreports/abstracts/95.4.html -Carl ipp-owner@pwg.org on 02/05/98 01:10:31 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: Re: IPP> Notifications > Anyway, polling might not be elegant, but I think it can do the job. With > HTTP/1.1, the client will be polling over a persistant connection, > > So you assume that we would keep a connection open until > a print job is completed and a notification provided? I > don't know if I'd agree that this is a good idea. I agree with Roger. Maintaining a connection for the lifetime of the job will not scale very well in large environments. Maintaining a constant connection might be ok for the "Internet fax printer" scenario, but it just won't fly in the enterprise. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 6 01:34:09 1998 Delivery-Date: Fri, 06 Feb 1998 01:34:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id BAA01027 for ; Fri, 6 Feb 1998 01:34:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA06345 for ; Fri, 6 Feb 1998 01:36:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA07398 for ; Fri, 6 Feb 1998 01:34:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 01:29:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA06663 for ipp-outgoing; Fri, 6 Feb 1998 01:12:09 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> For the record... Date: Thu, 5 Feb 1998 22:12:42 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org This message is just to reaffirm my motion from the Maui meeting to "last call" our current documents... Randy From ipp-owner@pwg.org Fri Feb 6 05:59:50 1998 Delivery-Date: Fri, 06 Feb 1998 05:59:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id FAA03227 for ; Fri, 6 Feb 1998 05:59:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA06590 for ; Fri, 6 Feb 1998 06:02:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA08285 for ; Fri, 6 Feb 1998 05:59:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 05:55:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA07729 for ipp-outgoing; Fri, 6 Feb 1998 05:39:18 -0500 (EST) Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D0A0A@red-86-msg.dns.microsoft.com> From: Josh Cohen To: "'ipp@pwg.org'" Subject: IPP> Vote Date: Fri, 6 Feb 1998 02:38:27 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Hi, Like Paul's message, Im sure none of you will be shocked to here me say: I vote we use XML I vote we use PRINT instead of POST. tgif, josh --- Josh Cohen Program Manager - Internet Protocols From adm Fri Feb 6 11:08:33 1998 Delivery-Date: Fri, 06 Feb 1998 11:17:54 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA07271 for ietf-123-outbound.10@ietf.org; Fri, 6 Feb 1998 11:07:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA07110; Fri, 6 Feb 1998 11:01:15 -0500 (EST) Message-Id: <199802061601.LAA07110@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-framework-02.txt Date: Fri, 06 Feb 1998 11:01:14 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Framework for IP Performance Metrics Author(s) : G. Almes, M. Mathis, J. Mahdavi, V. Paxson Filename : draft-ietf-ippm-framework-02.txt Pages : 28 Date : 05-Feb-98 The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Performance Metrics Working Group (IPPM) of the Transport Area. 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-ippm-framework-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippm-framework-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-framework-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980205111538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-framework-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980205111538.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Feb 6 11:55:25 1998 Delivery-Date: Fri, 06 Feb 1998 11:55:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA08942 for ; Fri, 6 Feb 1998 11:55:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07764 for ; Fri, 6 Feb 1998 11:58:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09159 for ; Fri, 6 Feb 1998 11:55:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 11:42:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08579 for ipp-outgoing; Fri, 6 Feb 1998 11:26:28 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 06 Feb 1998 09:25:06 -0700 From: "Scott Isaacson" To: lhoward@apple.com, ietf-asid@netscape.com, ED_REED@novell.com Cc: kwerle@apple.com, ipp@pwg.org Subject: IPP> Re: Locating printers in LDAP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA08942 All, Yes, the IPP work anticpates the use of directories. In fact we used to have a separate I-D on a proposed generic directory schema for "Printer". This was informed from many inputs - X.500, OS/2, ISO DPA, SNMP Printer MIB, NDS, NDPS, etc. However, we pulled that I-D into the latest IPP Model and Semantics document "ftp://ietf.org/internet-drafts/draft-ietf-ipp-model-09.txt" as an appendix. At the original BOF for IPP we presented a proposed schema for Printers and suggested as part of the WG charter that we could define an LDAP specific realization of that schema. However, that was shot down and specifically excluded from out charter. Now that we have completed the work items for IPP/1.0, the WG should consider drafting an LDAP schema document. The SLP WG has an I-D called "ftp://ietf.org/internet-drafts/draft-ietf-svrloc-printer-scheme-01.txt" that defines a schema for Printers for SLP. That documents shows attributes taken from the MIB, IPP, and Salutations. Also note, the SLP I-D on "ftp://ietf.org/internet-drafts/draft-ietf-svrloc-template-conversion-02.txt" So that one can translate between an LDAP schema and an SLP schema. The strategy in the IPP group, was to take a strict subset of the more static and useful Printer object attributes (useful for end-user search filters) to define the directory entry schema. Net-net: The bulk of the work has been done, now we just need the final step to formally gen the LDAP schema and I believe the WG is ready for this now. ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Ed Reed 02/05 9:46 PM >>> Let's see if the ipp group have any plans - I know that it anticipates usage of directories...Scott? Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> Luke Howard 02/05/98 07:17PM >>> Are there any proposed schema for representing printers (for lpr and/or IPP) in LDAP? I recall reading a draft several months ago (I think it was from IBM) but I can't seem to find anything on the web. -- Luke -- Luke Howard - lhoward@apple.com - +1 (408) 974-7562 Apple Computer, Inc. - Rhapsody Core Operating Systems Group 2 Infinite Loop, Mail Stop 302-4K, Cupertino, CA 95014 From ipp-owner@pwg.org Fri Feb 6 12:15:18 1998 Delivery-Date: Fri, 06 Feb 1998 12:15:28 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09452 for ; Fri, 6 Feb 1998 12:15:03 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07837 for ; Fri, 6 Feb 1998 12:17:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA09782 for ; Fri, 6 Feb 1998 12:15:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 12:11:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09094 for ipp-outgoing; Fri, 6 Feb 1998 11:54:06 -0500 (EST) Message-Id: <3.0.1.32.19980206085051.00b0c8f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 08:50:51 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-tls-https-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >Date: Thu, 5 Feb 1998 19:59:51 PST >From: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-tls-https-00.txt >To: ietf-tls >X-Listserver: ListSTAR v1.1 by StarNine Technologies, a Quarterdeck Company >Reply-To: >Errors-To: >X-List-Subscribe: >X-List-Unsubscribe: >X-List-Help: > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Transport Layer Security Working Group >of the IETF. > > Title : HTTP Over TLS > Author(s) : E. Rescorla > Filename : draft-ietf-tls-https-00.txt > Pages : 6 > Date : 27-Jan-98 > > This memo describes how to use TLS to secure HTTP connections over > the Internet. Current practice is to layer HTTP over SSL (the prede- > cessor to TLS), distinguishing secured traffic from insecure traffic > by the use of a different server port. This document standardizes > that practice using TLS. A companion document describes a method for > using HTTP/TLS over the same port as normal HTTP. > > >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-tls-https-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-tls-https-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-tls-https-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. > > >[The following attachment must be fetched by mail. Command-click the URL >below and send the resulting message to get the attachment.] >ts/draft-ietf-tls-https-00.txt> >[The following attachment must be fetched by ftp. Command-click the URL >below to ask your ftp client to fetch it.] > > > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 12:47:21 1998 Delivery-Date: Fri, 06 Feb 1998 12:47:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA10265 for ; Fri, 6 Feb 1998 12:47:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08047 for ; Fri, 6 Feb 1998 12:50:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10738 for ; Fri, 6 Feb 1998 12:47:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 12:40:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09865 for ipp-outgoing; Fri, 6 Feb 1998 12:22:44 -0500 (EST) Message-Id: <3.0.1.32.19980206091835.00c94df0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 09:18:35 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - We have strong consensus for progressing to IESG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, Counting the opinions expressed on the IPP DL this morning, I found that 29 people had expressed a view. 25 poeople suggested to pass our drafts on to the IESG without further delay 4 people supported the proposal to delay and work on an XML solution and PRINT Although this is a bit less than the 100% consensus that we had coming in to 1998, I do interpret this to mean that we have strong consensus to progress as agreed by the end of 1997. I will now send the message to the IESG for their further review and processing. Looking over the comments on the DL during the the last 7 days, I believe that the proposal from Paul Moore and Josh Cohen failed for the following three reasons: - Too LATE, in the development cycle of IPP V1.0 - Too EARLY, in the life cycle of XML - Too LITTLE, in the way of a counter proposal for the protocol solution Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 13:43:12 1998 Delivery-Date: Fri, 06 Feb 1998 13:43:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA11718 for ; Fri, 6 Feb 1998 13:43:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08394 for ; Fri, 6 Feb 1998 13:45:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12253 for ; Fri, 6 Feb 1998 13:42:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 13:31:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10642 for ipp-outgoing; Fri, 6 Feb 1998 12:45:34 -0500 (EST) Message-Id: <3.0.1.32.19980206094158.00963100@garfield> X-Sender: cmanros@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 09:41:58 PST To: ietf-secretariat@ns.ietf.org, Harald.Alvestrand@maxware.no, Keith Moore From: Carl-Uno Manros Subject: IPP> IETF Internet Printing Protocol working group: Request for IESG Consideration Cc: szilles@adobe.com, ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The IETF Internet Printing Protocol working group hereby requests IESG approval for publication of the following documents, with the specified status. The working group has been developing the content of the documents for more than one year and has reached a more than rough consensus for this initial set of specifications, seeking to provide a core set of useful functionality, for Internet printing. It should be noted however, that a small group of experts launched an idea to reconsider the current protocol encoding in favor of using XML, and to introduce an IPP specific HTTP 1.1 method called PRINT. These proposals were discussed, but were rejected by a strong majority within the working group, which wants to progress our current drafts, as they already meet the charter of the IPP WG. One small exception to the charter requirements should be noted. The subject of asynchronous notifications has been discussed and the working group suggests that this task is addresses either as a follow-on activity in the IPP WG or in a new WG, as this seems to require a separate protocol. The work of the group has made steady progress with very active and consistent participation since its first BOF in December 1996. The working group believes that the quality of its documents are entirely consistent with IETF requirements. DOCUMENT: Requirements for an Internet Printing Protocol Status: Informational Technical Summary: This document describes the requirements for an Internet printing protocol. It describes the end-user, operator and administrator wants and needs in the context of printing documents from a variety of sources. These sources include standard desktop applications (e.g. word processors, spreadsheets, and browsers), documents selected by reference (e.g. URI) and documents created by batch or background applications. Additionally, requirements for light-weight printer status and management and job status and management services will be discussed. DOCUMENT: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol Status: Informational Technical Summary: 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. DOCUMENT: Internet Printing Protocol/1.0: Model and Semantics Status: Proposed Standard Technical Summary: This document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. This document also describes how security, internationalization, and directory issues are addressed. DOCUMENT: Internet Printing Protocol/1.0: Protocol Specification Status: Proposed Standard Technical Summary: The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. DOCUMENT: Mapping between LPD and IPP Protocols Status: Informational Technical Summary: 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. Regards, Carl-Uno Manros Co-chair IETF IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 13:45:24 1998 Delivery-Date: Fri, 06 Feb 1998 13:45:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA11772 for ; Fri, 6 Feb 1998 13:45:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08413 for ; Fri, 6 Feb 1998 13:48:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12594 for ; Fri, 6 Feb 1998 13:45:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 13:33:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10533 for ipp-outgoing; Fri, 6 Feb 1998 12:44:09 -0500 (EST) Message-Id: <34DB4B41.C6E12EAA@dazel.com> Date: Fri, 06 Feb 1998 11:41:21 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <5030100017067671000002L012*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Roger K Debry wrote: > > Not having been in Maui, I'd be interested in what > you believe the "many other" issues are. Sorry about the delay in the response... There were several other issues that were discussed, some of which I thought came up during the phone conference (alas, we all know how well that technology worked :-). At any rate here are some that I remember (not meant to be an exhaustive list)... o Using a new HTTP method rather than overloading POST. Nuff said. o Concern over using HTTP at all... there was a rumor going around that the IESG was poised to reject the current IPP drafts because HTTP was being used as the protocol. In fact, part of the discussion was along the lines of "We know that this draft will get rejected anyways, so why don't we send it in, collect all of the comments at one time, and in the meantime we can think some more about XML". There also seemed to be some underriding current of uneasiness from some of the group regarding HTTP. This is just a subjective opinion of mine, but there were comments made like "now, if we had just used a simple socket-level protocol..." o IPP as an embedded printer protocol versus a print server protocol. There was a lot of discussion about whether we are trying to accomplish too much by having one protocol for both the embedded printer and the print server. For example, there is a natural tension between the space requirements that the embedded printer crowd (rightfully) defends, and the "elegance" and "extensibility" arguments that the print server crowd espouses. I think that the XML discussion, as well as the original text versus binary protocol discussion from over a year ago, are valid examples of this tension. o IPP versus SNMP. Along the same lines of some of the issues above were discussions about overlap between IPP and SNMP. There was at least one suggestion that IPP should perhaps just be a job submission (and cancellation?) protocol, and use the existing Printer and Job Monitoring MIBs for determining printer and job status. I was also concerned about comments from at least one representative from a large printer vendor that indicated very little interest in IPP as a whole. "If we already have a way to get jobs in the printer (using, say, a simple bi-directional TCP connection) and a way to monitor those jobs, as well as the printer (SNMP), what good does IPP do for us?" These are just some random recollections. I do not mean to be a gloom-and-doom'er, but I did want to document some of the observations that I made from my seat. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Fri Feb 6 13:45:55 1998 Delivery-Date: Fri, 06 Feb 1998 13:45:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA11791 for ; Fri, 6 Feb 1998 13:45:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08419 for ; Fri, 6 Feb 1998 13:48:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12627 for ; Fri, 6 Feb 1998 13:45:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 13:34:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10412 for ipp-outgoing; Fri, 6 Feb 1998 12:43:01 -0500 (EST) Message-ID: <34DB4B97.6BB93C32@underscore.com> Date: Fri, 06 Feb 1998 12:42:47 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: sense@pwg.org CC: ipp@pwg.org Subject: IPP> Re: SENSE> Time to shutdown the SENSE project? References: <34D606E0.A9D41CC6@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Well, it looks like SENSE will (again) get a stay of execution, given the recent interest by the IPP folks. Since almost no one likes cross-postings, I'd like to suggest that all SENSE threads revolving around IPP should be conducted solely on the IPP mailing list (ipp@pwg.org). The exact schedule has not yet been devised for the upcoming IPP meeting in Austin, TX (March 4-5), but I am hoping that some serious time will be allowed for discussing how SENSE can (or can't) be used for IPP. ...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 -- ---------------------------------------------------------------------- Jay Martin wrote: > > Greetings, > > Given the lack of participation in this project, it is probably > appropriate to formally shutdown the project and the mailing list. > > Any objections? Please submit your comments before the end of this > week (Friday, Feb 6). If there are no significant objections, the > project will be considered formally closed at that time. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 6 15:15:39 1998 Delivery-Date: Fri, 06 Feb 1998 15:15:39 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13895 for ; Fri, 6 Feb 1998 15:15:38 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09005 for ; Fri, 6 Feb 1998 15:18:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13416 for ; Fri, 6 Feb 1998 15:15:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 15:09:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12835 for ipp-outgoing; Fri, 6 Feb 1998 14:53:31 -0500 (EST) Message-ID: <34DB6A2F.EC8D8ED0@underscore.com> Date: Fri, 06 Feb 1998 14:53:19 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: walker@dazel.com Subject: Re: IPP> Consensus on sending our drafts to the IESG References: <5030100017067671000002L012*@MHS> <34DB4B41.C6E12EAA@dazel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I would like to go on record as sharing many (if not most) of the views and comments Jim Walker has posted. Given the current "culture" that has seemingly developed within the IPP group, Jim should be commended on being so brave as to suggest some of the views that some may describe as "nay-saying". I must admit that I am a member of the group Jim refers to in: > "We know that this draft will get rejected anyways, so > why don't we send it in, collect all of the comments at > one time, and in the meantime we can think some more > about XML". While I had strongly proposed that the current drafts be submitted as-is for IETF review, the fact is, I really don't like the IPP protocol as it is currently defined. (Wow, I said it. Now I feel better... ;-) One final note: whether IPP (as currently defined) is better or worse than XML is really a useless discussion, IMHO. Without Microsoft's aggressive support, any *pervasive* deployment of an Internet-like printing protocol will likely fail within the general domain. If Microsoft balks at IPP v1.0 (and they surely have made this comment, repeatedly!), then does anyone actually believe they will deploy it? I have longed for the day in which the Printer Industry as a whole would stand up, band together, and produce something in concert with the sum of the industry's players. But, after waiting some five years for this act to occur, I now find that this belief is but a pipe dream. Let's face it. As long as the printer industry continues to gate itself on the progress and initiative of Microsoft and HP, then true innovation deployed on a global scale--in which the efforts are conducted on an honestly "level playing field"--is likely to NEVER happen, at least not in our lifetime. (Of course, the Department of Justice could change all of that... ;-) I would like to publicly challenge Microsoft to put forth an "Internet printing" proposal in which it can demonstrate true openness for allowing the printer industry to participate in it's development and deployment. I, for one, have no problem in working within an environment that has a "benevolent dictator". After all, my company exists to make products and profit from that effort. Having a single "Master" of a given effort is fine...so long as the Master is open and honest with its "serfs". Thanks for letting me get this off my chest. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- James Walker wrote: > > Roger K Debry wrote: > > > > Not having been in Maui, I'd be interested in what > > you believe the "many other" issues are. > > Sorry about the delay in the response... > > There were several other issues that were discussed, some of which > I thought came up during the phone conference (alas, we all know > how well that technology worked :-). > > At any rate here are some that I remember (not meant to be an > exhaustive list)... > > o Using a new HTTP method rather than overloading POST. > Nuff said. > > o Concern over using HTTP at all... there was a rumor going > around that the IESG was poised to reject the current > IPP drafts because HTTP was being used as the protocol. > In fact, part of the discussion was along the lines of > "We know that this draft will get rejected anyways, so > why don't we send it in, collect all of the comments at > one time, and in the meantime we can think some more > about XML". > > There also seemed to be some underriding current of > uneasiness from some of the group regarding HTTP. > This is just a subjective opinion of mine, but there > were comments made like "now, if we had just used a > simple socket-level protocol..." > > o IPP as an embedded printer protocol versus a print server > protocol. There was a lot of discussion about whether > we are trying to accomplish too much by having one > protocol for both the embedded printer and the print > server. For example, there is a natural tension between > the space requirements that the embedded printer crowd > (rightfully) defends, and the "elegance" and > "extensibility" arguments that the print server crowd > espouses. I think that the XML discussion, as well as > the original text versus binary protocol discussion from > over a year ago, are valid examples of this tension. > > o IPP versus SNMP. Along the same lines of some of the issues > above were discussions about overlap between IPP and SNMP. > There was at least one suggestion that IPP should perhaps > just be a job submission (and cancellation?) protocol, > and use the existing Printer and Job Monitoring MIBs for > determining printer and job status. > > I was also concerned about comments from at least one > representative from a large printer vendor that indicated > very little interest in IPP as a whole. "If we already > have a way to get jobs in the printer (using, say, a > simple bi-directional TCP connection) and a way to monitor > those jobs, as well as the printer (SNMP), what good does > IPP do for us?" > > These are just some random recollections. I do not mean to be > a gloom-and-doom'er, but I did want to document some of the > observations that I made from my seat. > > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Fri Feb 6 16:17:57 1998 Delivery-Date: Fri, 06 Feb 1998 16:17:58 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA15643 for ; Fri, 6 Feb 1998 16:17:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09416 for ; Fri, 6 Feb 1998 16:20:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA14078 for ; Fri, 6 Feb 1998 16:17:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 16:11:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13536 for ipp-outgoing; Fri, 6 Feb 1998 15:55:23 -0500 (EST) From: don@lexmark.com Message-Id: <199802062054.AA27213@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 6 Feb 1998 15:54:23 -0500 Subject: IPP> ADM: Conference Calls 2/11, 2/18 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the details on the next two IPP conference calls. Date: 2/11, 2/18 Call-in: 1-608-250-1828 Access: 190148 Time: 4PM EST (1PM PST) Duration: 2.5 hours See you then! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Fri Feb 6 17:14:11 1998 Delivery-Date: Fri, 06 Feb 1998 17:14:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17012 for ; Fri, 6 Feb 1998 17:14:10 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09692 for ; Fri, 6 Feb 1998 17:16:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15272 for ; Fri, 6 Feb 1998 17:14:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 17:02:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14180 for ipp-outgoing; Fri, 6 Feb 1998 16:36:16 -0500 (EST) Message-Id: <3.0.1.32.19980206133251.00b6d8a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 13:32:51 PST To: walker@dazel.com, Roger K Debry From: Carl-Uno Manros Subject: Re: IPP> Consensus on sending our drafts to the IESG Cc: ipp@pwg.org In-Reply-To: <34DB4B41.C6E12EAA@dazel.com> References: <5030100017067671000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Jim, I don't think that any of the discussion points that you mention was new to the group. We have been over that ground earlier and done our compromises and decisions. What happened in the meeting was that some people who have been in and out of the group raised them for discussion again. This does not mean that we have to back track everything again. Carl-Uno At 09:41 AM 2/6/98 PST, James Walker wrote: >Roger K Debry wrote: >> >> Not having been in Maui, I'd be interested in what >> you believe the "many other" issues are. > >Sorry about the delay in the response... > >There were several other issues that were discussed, some of which >I thought came up during the phone conference (alas, we all know >how well that technology worked :-). > >At any rate here are some that I remember (not meant to be an >exhaustive list)... > >o Using a new HTTP method rather than overloading POST. > Nuff said. > >o Concern over using HTTP at all... there was a rumor going > around that the IESG was poised to reject the current > IPP drafts because HTTP was being used as the protocol. > In fact, part of the discussion was along the lines of > "We know that this draft will get rejected anyways, so > why don't we send it in, collect all of the comments at > one time, and in the meantime we can think some more > about XML". > > There also seemed to be some underriding current of > uneasiness from some of the group regarding HTTP. > This is just a subjective opinion of mine, but there > were comments made like "now, if we had just used a > simple socket-level protocol..." > >o IPP as an embedded printer protocol versus a print server > protocol. There was a lot of discussion about whether > we are trying to accomplish too much by having one > protocol for both the embedded printer and the print > server. For example, there is a natural tension between > the space requirements that the embedded printer crowd > (rightfully) defends, and the "elegance" and > "extensibility" arguments that the print server crowd > espouses. I think that the XML discussion, as well as > the original text versus binary protocol discussion from > over a year ago, are valid examples of this tension. > >o IPP versus SNMP. Along the same lines of some of the issues > above were discussions about overlap between IPP and SNMP. > There was at least one suggestion that IPP should perhaps > just be a job submission (and cancellation?) protocol, > and use the existing Printer and Job Monitoring MIBs for > determining printer and job status. > > I was also concerned about comments from at least one > representative from a large printer vendor that indicated > very little interest in IPP as a whole. "If we already > have a way to get jobs in the printer (using, say, a > simple bi-directional TCP connection) and a way to monitor > those jobs, as well as the printer (SNMP), what good does > IPP do for us?" > >These are just some random recollections. I do not mean to be >a gloom-and-doom'er, but I did want to document some of the >observations that I made from my seat. > >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 17:28:26 1998 Delivery-Date: Fri, 06 Feb 1998 17:28:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17191 for ; Fri, 6 Feb 1998 17:28:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09758 for ; Fri, 6 Feb 1998 17:31:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15951 for ; Fri, 6 Feb 1998 17:28:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 17:18:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14210 for ipp-outgoing; Fri, 6 Feb 1998 16:45:06 -0500 (EST) Message-Id: <3.0.1.32.19980206134144.00b70bd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 13:41:44 PST To: Jay Martin , sense@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Re: SENSE> Time to shutdown the SENSE project? Cc: ipp@pwg.org In-Reply-To: <34DB4B97.6BB93C32@underscore.com> References: <34D606E0.A9D41CC6@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 09:42 AM 2/6/98 PST, Jay Martin wrote: >Well, it looks like SENSE will (again) get a stay of execution, >given the recent interest by the IPP folks. > >Since almost no one likes cross-postings, I'd like to suggest >that all SENSE threads revolving around IPP should be conducted >solely on the IPP mailing list (ipp@pwg.org). > >The exact schedule has not yet been devised for the upcoming >IPP meeting in Austin, TX (March 4-5), but I am hoping that >some serious time will be allowed for discussing how SENSE >can (or can't) be used for IPP. > > ...jay > Jay, I am trying to get some feedback from our IETF Area Directors on how to proceed with the IPP notification subject. In the meantime, we can certainly discuss SENSE and other potential approaches for how to tackle the notification subject within the framework of the PWG. However, I think that starting to document more details about our requirements should come first, as has already been suggested by several people. Unless we are in for any surprises from the IESG, which might be higher priority, we should definately spend a good part of our PWG IPP in Austin to discuss this. Hope you can make it to Austin. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 17:42:34 1998 Delivery-Date: Fri, 06 Feb 1998 17:42:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17457 for ; Fri, 6 Feb 1998 17:42:33 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09808 for ; Fri, 6 Feb 1998 17:45:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16582 for ; Fri, 6 Feb 1998 17:42:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 17:36:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15269 for ipp-outgoing; Fri, 6 Feb 1998 17:14:00 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AE90@EXCHANGE> From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> Consensus on sending our drafts to the IESG Date: Fri, 6 Feb 1998 17:12:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org The questions voiced by Jim Walker, and Jay's addition are most disheartening. It is not because these are new concerns but because these things have been gone over and over during the course of this working group's life. Yes, to some people compromise is a dirty word; and the current specification represents very much compromise on everyone's part. In the last analysis however, the deciding factor should not be whether one or another favorite approach is used, but: does what is specified work? does it do what it was intended to do? is it producable and deployable? Jay's very practical concern about can a printing specification not implemented by Microsoft and HP ever succeed must be considered. Microsoft and HP have a history of pushing through their "alternate" solutions just as a specification nears completion. I would have thought that their extensive participation and the previous round of compromises intended to incorporate the ideas of these two giants would have may unnecessary this "end-play". Apparently, it has not. The group can continue, and can put into effect a working protocol for inter/intra net printing. It can do this with or without IESG sanction and with or without Microsoft/HP participation. The question of whether this is a viable action is one for marketeers, not engineers. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, February 06, 1998 2:53 PM > To: ipp@pwg.org > Cc: walker@dazel.com > Subject: Re: IPP> Consensus on sending our drafts to the IESG > > I would like to go on record as sharing many (if not most) of > the views and comments Jim Walker has posted. > > Given the current "culture" that has seemingly developed within > the IPP group, Jim should be commended on being so brave as to > suggest some of the views that some may describe as "nay-saying". > > I must admit that I am a member of the group Jim refers to in: > > > "We know that this draft will get rejected anyways, so > > why don't we send it in, collect all of the comments at > > one time, and in the meantime we can think some more > > about XML". > > While I had strongly proposed that the current drafts be submitted > as-is for IETF review, the fact is, I really don't like the > IPP protocol as it is currently defined. (Wow, I said it. > Now I feel better... ;-) > > One final note: whether IPP (as currently defined) is better or > worse than XML is really a useless discussion, IMHO. > > Without Microsoft's aggressive support, any *pervasive* deployment > of an Internet-like printing protocol will likely fail within the > general domain. If Microsoft balks at IPP v1.0 (and they surely > have made this comment, repeatedly!), then does anyone actually > believe they will deploy it? > > I have longed for the day in which the Printer Industry as a whole > would stand up, band together, and produce something in concert > with the sum of the industry's players. But, after waiting some > five years for this act to occur, I now find that this belief is > but a pipe dream. > > Let's face it. As long as the printer industry continues to gate > itself on the progress and initiative of Microsoft and HP, then > true innovation deployed on a global scale--in which the efforts > are conducted on an honestly "level playing field"--is likely > to NEVER happen, at least not in our lifetime. (Of course, the > Department of Justice could change all of that... ;-) > > I would like to publicly challenge Microsoft to put forth an > "Internet printing" proposal in which it can demonstrate true > openness for allowing the printer industry to participate in > it's development and deployment. > > I, for one, have no problem in working within an environment > that has a "benevolent dictator". After all, my company exists > to make products and profit from that effort. Having a single > "Master" of a given effort is fine...so long as the Master is > open and honest with its "serfs". > > Thanks for letting me get this off my chest. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > James Walker wrote: > > > > Roger K Debry wrote: > > > > > > Not having been in Maui, I'd be interested in what > > > you believe the "many other" issues are. > > > > Sorry about the delay in the response... > > > > There were several other issues that were discussed, some of which > > I thought came up during the phone conference (alas, we all know > > how well that technology worked :-). > > > > At any rate here are some that I remember (not meant to be an > > exhaustive list)... > > > > o Using a new HTTP method rather than overloading POST. > > Nuff said. > > > > o Concern over using HTTP at all... there was a rumor going > > around that the IESG was poised to reject the current > > IPP drafts because HTTP was being used as the protocol. > > In fact, part of the discussion was along the lines of > > "We know that this draft will get rejected anyways, so > > why don't we send it in, collect all of the comments at > > one time, and in the meantime we can think some more > > about XML". > > > > There also seemed to be some underriding current of > > uneasiness from some of the group regarding HTTP. > > This is just a subjective opinion of mine, but there > > were comments made like "now, if we had just used a > > simple socket-level protocol..." > > > > o IPP as an embedded printer protocol versus a print server > > protocol. There was a lot of discussion about whether > > we are trying to accomplish too much by having one > > protocol for both the embedded printer and the print > > server. For example, there is a natural tension between > > the space requirements that the embedded printer crowd > > (rightfully) defends, and the "elegance" and > > "extensibility" arguments that the print server crowd > > espouses. I think that the XML discussion, as well as > > the original text versus binary protocol discussion from > > over a year ago, are valid examples of this tension. > > > > o IPP versus SNMP. Along the same lines of some of the issues > > above were discussions about overlap between IPP and SNMP. > > There was at least one suggestion that IPP should perhaps > > just be a job submission (and cancellation?) protocol, > > and use the existing Printer and Job Monitoring MIBs for > > determining printer and job status. > > > > I was also concerned about comments from at least one > > representative from a large printer vendor that indicated > > very little interest in IPP as a whole. "If we already > > have a way to get jobs in the printer (using, say, a > > simple bi-directional TCP connection) and a way to monitor > > those jobs, as well as the printer (SNMP), what good does > > IPP do for us?" > > > > These are just some random recollections. I do not mean to be > > a gloom-and-doom'er, but I did want to document some of the > > observations that I made from my seat. > > > > ...walker > > > > -- > > Jim Walker > > System Architect/DAZEL Wizard > > DAZEL Corporation, Austin, TX From pwg-owner@pwg.org Fri Feb 6 22:02:08 1998 Delivery-Date: Fri, 06 Feb 1998 22:02:08 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA20108 for ; Fri, 6 Feb 1998 22:02:02 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10242 for ; Fri, 6 Feb 1998 22:04:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA17424 for ; Fri, 6 Feb 1998 22:01:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 21:50:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16897 for pwg-outgoing; Fri, 6 Feb 1998 21:38:38 -0500 (EST) Message-Id: <3.0.1.32.19980206183723.00b22c50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 18:37:23 PST To: Jay Martin , Harry Lewis From: Tom Hastings Subject: Re: SENSE> Re: PWG> Maui PWG Overview Minutes Cc: pwg@pwg.org, Sense mailing list , IPP Mailing List In-Reply-To: <34D8F623.AD3C1C41@underscore.com> References: <5030300017569549000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org One more is that Carl-Uno says that the SMTP protocols use a notifiation method between mail servers. We could consider using one of them. Tom At 15:13 02/04/1998 PST, Jay Martin wrote: >Harry, > >Part of your fine summary included this section on Sense: > > SENSE Notification Protocol > > No status. Jay Martin (SENSE Chair) not present. It is unfortunate > that we were unable to schedule a SENSE discussion in Maui because > IPP is interested in considering SENSE as notification scheme. IPP > may also want to look at SNMPv3 (recently published RFCs). It was > noted that there are many notification protocols available today > that may need to be investigated. > >Would someone be so kind as to list the "many notification protocols >available today that may need to be investigated"? I would be more >than happy to start investigated those alternatives if someone would >post them to the IPP list (or the Sense list, or whatever). > >Thanks in advance. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From ipp-owner@pwg.org Fri Feb 6 22:49:00 1998 Delivery-Date: Fri, 06 Feb 1998 22:49:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22058 for ; Fri, 6 Feb 1998 22:49:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10289 for ; Fri, 6 Feb 1998 22:51:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA19200 for ; Fri, 6 Feb 1998 22:48:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 22:33:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16841 for ipp-outgoing; Fri, 6 Feb 1998 21:24:32 -0500 (EST) Message-ID: <34DBC5C5.2844CCCB@underscore.com> Date: Fri, 06 Feb 1998 21:24:05 -0500 From: Jeff Schnitzer Reply-To: jds@underscore.com Organization: Underscore, Inc. X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> ADM - How to follow the fate of the IPP drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org [The following message from Carl-Uno was filtered by Majordomo as a misdirected admin request due to the word "ubscribe-say" being used within the first five lines of the message body -- /Jeff Schnitzer] Date: Fri, 6 Feb 1998 11:16:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: ADM - How to follow the fate of the IPP drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" With the message now sent to the IESG to process the IPP drafts for publishing as RFCs, they are now out of our control. If you want to find out how the next step in the processing chain develops, you should subscribe to the IETF annoncement list. See description below on how to subscribe. Carl-Uno --- The IETF announcement list is a "controlled" list that receives the following types of messages: IETF Meeting logistics, Agendas for working group and BOF sessions at IETF meetings, working group actions, Internet-Draft announcements, IESG Last Calls, IESG protocol and document actions, and RFC announcements. To join the announcement list, send a request to: ietf-announce-request@ietf.org and enter the word subscribe in the Subject line of the message. ---- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 6 22:51:02 1998 Delivery-Date: Fri, 06 Feb 1998 22:51:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22068 for ; Fri, 6 Feb 1998 22:51:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10292 for ; Fri, 6 Feb 1998 22:53:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA19430 for ; Fri, 6 Feb 1998 22:50:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 22:36:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16863 for ipp-outgoing; Fri, 6 Feb 1998 21:28:28 -0500 (EST) Message-Id: <3.0.1.32.19980206182736.00b22210@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 18:27:36 PST To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> IPP > FAQ - How should the server behave? In-Reply-To: <5030100016952594000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 08:10 02/02/1998 PST, Carl Kugler wrote: >Henrik- snip... >> 3. How should a non-spooling IPP-server handle concurrent print-job >> requests? > >Return server-error-service-unavailable (0x0502) to indicate that the server is >temporarily unable to handle a request. > > > -Carl > >---------------------- Forwarded by Carl Kugler/Boulder/IBM on 02/02/98 08:41 We also discussed that a server MAY keep a list of clients that are trying to connect in a "queue", and then serve each one one at a time. Then the client doesn't receive an error (except if the "queue" is filled). This gives the end-user a much happier experience. I think that both approaches should be put into the FAQ. Tom From ipp-owner@pwg.org Fri Feb 6 22:51:28 1998 Delivery-Date: Fri, 06 Feb 1998 22:51:28 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22073 for ; Fri, 6 Feb 1998 22:51:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10295 for ; Fri, 6 Feb 1998 22:54:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA19464 for ; Fri, 6 Feb 1998 22:51:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 22:36:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16852 for ipp-outgoing; Fri, 6 Feb 1998 21:26:08 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC21E@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Wagner, William'" , ipp@pwg.org Subject: RE: IPP> Consensus on sending our drafts to the IESG Date: Fri, 6 Feb 1998 18:25:54 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org MS & HP will state to the IESG our concerns with the current design (just as anybody in the Internet comunity can). Having said that - we will implement what the IESG ratifies. It is our aim to have maximum interoperability, not to divide the world into different camps - that would be a war we can all do without. Our intent is purely to do the right thing both for the short term and the long term. We saw IPP as an opportunity for printing to 'do it right' from day 1 as opposed to always having to compromise on other solutions (SNMP, LPR/LPD, ...). Our view is that spending a little more time on it would provide a more flexible, future-proof solution. This argument did not win the day - instead we did a 'hey its good enough, lets ship it' - so be it (although, as I stated before, we will raise our objection to the IESG level). > -----Original Message----- > From: Wagner, William [SMTP:WWagner@wal.osicom.com] > Sent: Friday, February 06, 1998 2:13 PM > To: ipp@pwg.org > Subject: RE: IPP> Consensus on sending our drafts to the IESG > > The questions voiced by Jim Walker, and Jay's addition are most > disheartening. It is not because these are new concerns but because > these things have been gone over and over during the course of this > working group's life. Yes, to some people compromise is a dirty word; > and the current specification represents very much compromise on > everyone's part. In the last analysis however, the deciding factor > should not be whether one or another favorite approach is used, but: > does what is specified work? does it do what it was intended to do? is > it producable and deployable? > > Jay's very practical concern about can a printing specification not > implemented by Microsoft and HP ever succeed must be considered. > Microsoft and HP have a history of pushing through their "alternate" > solutions just as a specification nears completion. I would have thought > that their extensive participation and the previous round of compromises > intended to incorporate the ideas of these two giants would have may > unnecessary this "end-play". Apparently, it has not. > > The group can continue, and can put into effect a working protocol for > inter/intra net printing. It can do this with or without IESG sanction > and with or without Microsoft/HP participation. The question of whether > this is a viable action is one for marketeers, not engineers. > > W. A. Wagner (Bill Wagner) > OSICOM/DPI > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Friday, February 06, 1998 2:53 PM > > To: ipp@pwg.org > > Cc: walker@dazel.com > > Subject: Re: IPP> Consensus on sending our drafts to the IESG > > > > I would like to go on record as sharing many (if not most) of > > the views and comments Jim Walker has posted. > > > > Given the current "culture" that has seemingly developed within > > the IPP group, Jim should be commended on being so brave as to > > suggest some of the views that some may describe as "nay-saying". > > > > I must admit that I am a member of the group Jim refers to in: > > > > > "We know that this draft will get rejected anyways, so > > > why don't we send it in, collect all of the comments at > > > one time, and in the meantime we can think some more > > > about XML". > > > > While I had strongly proposed that the current drafts be submitted > > as-is for IETF review, the fact is, I really don't like the > > IPP protocol as it is currently defined. (Wow, I said it. > > Now I feel better... ;-) > > > > One final note: whether IPP (as currently defined) is better or > > worse than XML is really a useless discussion, IMHO. > > > > Without Microsoft's aggressive support, any *pervasive* deployment > > of an Internet-like printing protocol will likely fail within the > > general domain. If Microsoft balks at IPP v1.0 (and they surely > > have made this comment, repeatedly!), then does anyone actually > > believe they will deploy it? > > > > I have longed for the day in which the Printer Industry as a whole > > would stand up, band together, and produce something in concert > > with the sum of the industry's players. But, after waiting some > > five years for this act to occur, I now find that this belief is > > but a pipe dream. > > > > Let's face it. As long as the printer industry continues to gate > > itself on the progress and initiative of Microsoft and HP, then > > true innovation deployed on a global scale--in which the efforts > > are conducted on an honestly "level playing field"--is likely > > to NEVER happen, at least not in our lifetime. (Of course, the > > Department of Justice could change all of that... ;-) > > > > I would like to publicly challenge Microsoft to put forth an > > "Internet printing" proposal in which it can demonstrate true > > openness for allowing the printer industry to participate in > > it's development and deployment. > > > > I, for one, have no problem in working within an environment > > that has a "benevolent dictator". After all, my company exists > > to make products and profit from that effort. Having a single > > "Master" of a given effort is fine...so long as the Master is > > open and honest with its "serfs". > > > > Thanks for letting me get this off my chest. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > > > > > > James Walker wrote: > > > > > > Roger K Debry wrote: > > > > > > > > Not having been in Maui, I'd be interested in what > > > > you believe the "many other" issues are. > > > > > > Sorry about the delay in the response... > > > > > > There were several other issues that were discussed, some of which > > > I thought came up during the phone conference (alas, we all know > > > how well that technology worked :-). > > > > > > At any rate here are some that I remember (not meant to be an > > > exhaustive list)... > > > > > > o Using a new HTTP method rather than overloading POST. > > > Nuff said. > > > > > > o Concern over using HTTP at all... there was a rumor going > > > around that the IESG was poised to reject the current > > > IPP drafts because HTTP was being used as the protocol. > > > In fact, part of the discussion was along the lines of > > > "We know that this draft will get rejected anyways, so > > > why don't we send it in, collect all of the comments at > > > one time, and in the meantime we can think some more > > > about XML". > > > > > > There also seemed to be some underriding current of > > > uneasiness from some of the group regarding HTTP. > > > This is just a subjective opinion of mine, but there > > > were comments made like "now, if we had just used a > > > simple socket-level protocol..." > > > > > > o IPP as an embedded printer protocol versus a print server > > > protocol. There was a lot of discussion about whether > > > we are trying to accomplish too much by having one > > > protocol for both the embedded printer and the print > > > server. For example, there is a natural tension between > > > the space requirements that the embedded printer crowd > > > (rightfully) defends, and the "elegance" and > > > "extensibility" arguments that the print server crowd > > > espouses. I think that the XML discussion, as well as > > > the original text versus binary protocol discussion from > > > over a year ago, are valid examples of this tension. > > > > > > o IPP versus SNMP. Along the same lines of some of the issues > > > above were discussions about overlap between IPP and SNMP. > > > There was at least one suggestion that IPP should perhaps > > > just be a job submission (and cancellation?) protocol, > > > and use the existing Printer and Job Monitoring MIBs for > > > determining printer and job status. > > > > > > I was also concerned about comments from at least one > > > representative from a large printer vendor that indicated > > > very little interest in IPP as a whole. "If we already > > > have a way to get jobs in the printer (using, say, a > > > simple bi-directional TCP connection) and a way to monitor > > > those jobs, as well as the printer (SNMP), what good does > > > IPP do for us?" > > > > > > These are just some random recollections. I do not mean to be > > > a gloom-and-doom'er, but I did want to document some of the > > > observations that I made from my seat. > > > > > > ...walker > > > > > > -- > > > Jim Walker > > > System Architect/DAZEL Wizard > > > DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Fri Feb 6 22:56:33 1998 Delivery-Date: Fri, 06 Feb 1998 22:56:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA22093 for ; Fri, 6 Feb 1998 22:56:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10302 for ; Fri, 6 Feb 1998 22:59:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA20110 for ; Fri, 6 Feb 1998 22:56:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 22:51:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16915 for ipp-outgoing; Fri, 6 Feb 1998 21:38:56 -0500 (EST) Message-Id: <3.0.1.32.19980206183723.00b22c50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Feb 1998 18:37:23 PST To: Jay Martin , Harry Lewis From: Tom Hastings Subject: IPP> Re: SENSE> Re: PWG> Maui PWG Overview Minutes Cc: pwg@pwg.org, Sense mailing list , IPP Mailing List In-Reply-To: <34D8F623.AD3C1C41@underscore.com> References: <5030300017569549000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org One more is that Carl-Uno says that the SMTP protocols use a notifiation method between mail servers. We could consider using one of them. Tom At 15:13 02/04/1998 PST, Jay Martin wrote: >Harry, > >Part of your fine summary included this section on Sense: > > SENSE Notification Protocol > > No status. Jay Martin (SENSE Chair) not present. It is unfortunate > that we were unable to schedule a SENSE discussion in Maui because > IPP is interested in considering SENSE as notification scheme. IPP > may also want to look at SNMPv3 (recently published RFCs). It was > noted that there are many notification protocols available today > that may need to be investigated. > >Would someone be so kind as to list the "many notification protocols >available today that may need to be investigated"? I would be more >than happy to start investigated those alternatives if someone would >post them to the IPP list (or the Sense list, or whatever). > >Thanks in advance. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From ipp-owner@pwg.org Fri Feb 6 23:23:50 1998 Delivery-Date: Fri, 06 Feb 1998 23:23:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA27290 for ; Fri, 6 Feb 1998 23:23:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA10327 for ; Fri, 6 Feb 1998 23:26:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA20760 for ; Fri, 6 Feb 1998 23:23:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Feb 1998 23:19:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA20209 for ipp-outgoing; Fri, 6 Feb 1998 23:03:17 -0500 (EST) Message-ID: <19980207040246.3716.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> Re: How should the server behave Content-Type: text/plain Date: Fri, 06 Feb 1998 20:02:46 PST Sender: ipp-owner@pwg.org :: >> 3. How should a non-spooling IPP-server handle concurrent ::print-job ::>> requests? :: > ::>Return server-error-service-unavailable (0x0502) to indicate that the server is >temporarily unable to handle a request. > >We also discussed that a server MAY keep a list of clients that are trying >to connect in a "queue", and then serve each one one at a time. Then the >client doesn't receive an error (except if the "queue" is filled). This >gives the end-user a much happier experience. Consider the scenario: An IPP Client tries to print a job to an IPP server. A non-spooling HTTP/IPP server received TCP SYN pkt on port 80 from the IPP client, responded back with a TCP SYN-ACK pkt, and then received an ACK pkt from the IPP client. At this point, the HTTP/IPP server does not know whether the next pkt is going to be an IPP request or a simple HTTP operation for its embedded web. Next comes the first HTTP POST pkt with IPP header and IPP data. However, at this time, the HTTP/IPP server realized that another IPP job is in the process of printing. What will the IPP server do? if we follow the first recommendation, it will immediately send a 0x0502 IPP status to indicate that the service is temporarily. However, if we follow the second recommendation, should the non-spooling IPP server just sit idle and not respond to the new HTTP POST operation? Thanks, PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Sun Feb 8 16:18:09 1998 Delivery-Date: Sun, 08 Feb 1998 16:18:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA05246 for ; Sun, 8 Feb 1998 16:18:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA01053 for ; Sun, 8 Feb 1998 16:20:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24890 for ; Sun, 8 Feb 1998 16:18:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 8 Feb 1998 16:05:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24318 for ipp-outgoing; Sun, 8 Feb 1998 15:48:48 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC222@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Jay Martin'" Cc: ipp@pwg.org Subject: RE: IPP> Consensus on sending our drafts to the IESG Date: Sun, 8 Feb 1998 12:48:42 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org The problem is that nobody wants to do the other thing! I saw two problems with two , potentially different, soultions (hence my double vote). I rolled with what I saw as the simple solution (HTTP - interesting that you percieve them the opposite way round) and proposed something called SIMPLE web printing based on what we were building - that just did job submission. That eventually evolved into what we have today. Now we move on to address the issues that were lurking in the background - printer discovery, feature dicsovery , configuration discovery, managment, notification, flow control, peer queuing,.... (things for s/w to printer interface) and billing, quotas, access control, server managemnt, job redirection, ... (things for client to print subsystem interface). The WG is DETERMINED that this will be done by one protocol - I have expressed (with you and others) my opionion that this is not acheiveable (its desirability is understandable) many times. We are not listened to and I do not wish to continue to bash my forehead against that wall forever. So I have changed tactics and am now thinking 'how can I make IPP into all the things I need?'. Hence the current apparent change of stance, XML suggestions, questions about notification, etc. I just want to get down and build good stuff for users - I am trying to find the path of least resistance. > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Saturday, February 07, 1998 10:16 AM > To: Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> Consensus on sending our drafts to the IESG > > Paul, > > > MS & HP will state to the IESG our concerns with the current > > design (just as anybody in the Internet comunity can). > > And rightly so. We all look forward to seeing your concerns posted > to the IESG, where a larger domain of reviewers may be able to shed > additional light on this situation. > > > > Having said that - we will implement what the IESG > > ratifies. It is our aim to have maximum interoperability, > > not to divide the world into different camps - that would > > be a war we can all do without. > > This is certainly good news. We all needed to hear these "official" > words from Microsoft. Whether the protocol/model is good or bad is > not nearly as important as solidarity, given the critical mass > nature of our efforts. > > Are you able to speak on behalf of HP, or should a similar statement > be made from an HP representative? > > > > Our intent is purely to do the right thing both for the > > short term and the long term. We saw IPP as an opportunity > > for printing to 'do it right' from day 1 as opposed to > > always having to compromise on other solutions (SNMP, > > LPR/LPD, ...). > > Now this paragraph is totally confusing to me, Paul. I vividly > recall back at the May '97 IPP meeting (San Diego) the group > explicitly discussed the notion of "something quick vs. something > long term" in terms of whether to go "Web/HTTP" vs. a "simple, > socket-based approach". > > Recall that meeting? It was the meeting in which I was supposed > to get up and make "one last pitch" for a simple, socket-based > approach" using the CPAP protocol as an example starting point. > Having sensed the group's strong desire to leverage HTTP server > technology (based on assumptions that have since proven to be > totally *false* and unworkable), I decided to be "politically > correct" and not give a CPAP presentation, so as not to appear > as if I were "rocking the boat". (I have since regretted that > decision.) > > The official minutes for this meeting, however, did not detail > some of the critical statements made during this discussion. > (ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0597.txt) > > What did happen was that Carl-Uno took a vote from the group > as to the desired direction to proceed. The vote was in > favor of an HTTP approach (by quite a large margin). > > Those who attended that meeting should recall that you > surprised all those in attendance by voting for BOTH > approaches! To say the least, I was quite shocked and > asked you why you voted both ways. > > Your reply was something like this (not your exact words, > but pretty close for all intents and purposes): > > If we wanted a real, long-term useful printing protocol, > then we would of course design a protocol using a simple > socket-based approach. Such a protocol would allow us to > do much more than just job submission, but could also allow > us to effect critical management functions using the same > protocol. However, since the world appears to strongly > desire some sort of Web-based interface, let's just develop > a simple HTTP-based submission protocol. Afterwards, we > can then address a more suitable protocol usable in the > long-term. > > I LOVED THIS STATEMENT. It seemed so pragmatic and clearly > thought out that I immediately jumped on the bandwagon to > develop a *simple* HTTP-based protocol, hoping (of course) > that the effort would not be long and drug out, and that > we all could finish the effort in the originally intended > schedule. > > From what I could see, it was in my best interest to help > complete the HTTP-based effort as quickly as possible so > as to be able to more quickly move on to the development > of a REAL, long-term protocol. > > However, as time moved on, more and more people started > to view IPP as both an INTERnet protocol *and* and INTRAnet > protocol. And this is where the real disaster strikes, IMHO. > > So now, when you say: > > > Our intent is purely to do the right thing both for the > > short term and the long term. We saw IPP as an opportunity > > for printing to 'do it right' from day 1 as opposed to > > always having to compromise on other solutions (SNMP, > > LPR/LPD, ...). > > This appears to be a complete reversal of your great comments > made to the group back in May in San Diego. In San Diego, > you implied that IPP would serve as an interim protocol, as > anything HTTP-based would not easily allow for the kind of > long-term printing protocol the world really needs, at least > not within enterprise environments. > > This is truly disappointing. And I know for a fact I am not > alone in this belief. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Sun Feb 8 17:26:13 1998 Delivery-Date: Sun, 08 Feb 1998 17:26:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA05596 for ; Sun, 8 Feb 1998 17:26:12 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01166 for ; Sun, 8 Feb 1998 17:28:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25639 for ; Sun, 8 Feb 1998 17:26:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 8 Feb 1998 17:19:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25059 for ipp-outgoing; Sun, 8 Feb 1998 17:02:41 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC224@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Jay Martin'" , ipp@pwg.org Cc: Puru Bish Subject: RE: IPP> Re: How should the server behave Date: Sun, 8 Feb 1998 14:02:33 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org The fundamental mind shift would be to recognize that two people trying to hit the printer at the same time is not an error condition, but is part of the fundamental feature set of a network printer. (Imagine a deli-counter that said to you 'sorry we have a problem please come back later' if there was somebody else in line, even if they did tell you that the problem was that there were other people in the line) > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Saturday, February 07, 1998 10:33 AM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> Re: How should the server behave > > Puru Bish's scenario and questions strike a strong chord > with me, having long been involved in protocol design and > development. > > A robust protocol should allow a client to easily distinguish > the difference between these two situations: > > 1) The server is not available (program not running, > host not on the network, or unreachable in someway). > > 2) The server is "too busy" to handle the client's request > at the moment; the client should try again "in the near > future" when the server has finished its current load. > > All too many times the "too busy" situation is handled by > a "silent" approach by the server...making it very, very > difficult for the client to determine if a process problem > exists (ie, a system component--the server--is not available, > thereby making the "system" unusable), or if the client must > "throttle back" and repeat the request at a later time. > > I hope we don't suggest the "silent" approach for IPP, > especially if we're interested in a "much happier experience" > for the end-user (as Tom Hastings has pointed out). > > In the case of an "IPP server too busy" situation, Carl Kugler > has suggested: > > > Return server-error-service-unavailable (0x0502) to indicate > > that the server is temporarily unable to handle a request. > > This is fine by me IFF that error code has precisely (and ONLY) > the semantics of "too busy, try back later". Otherwise, if > this error code is overloaded, we should define a different > and unique error code to declare the "too busy" condition. > > I know it may be asking too much (particularly at this late > stage), but it would be ideal if, for a "too busy" condition, > the server not only returns a distinguishing error code, but > also returns some sort of "hint" as to when the client should > try again (eg, 5 minutes, 3 hours, etc.). In doing so, the > IPP protocol would be helping to reduce network traffic, as > well as improving the predictability of the printing process. > > Comments? > > ...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 -- > ---------------------------------------------------------------------- > > > Puru Bish wrote: > > > > :: >> 3. How should a non-spooling IPP-server handle concurrent > > ::print-job > > ::>> requests? > > :: > > > ::>Return server-error-service-unavailable (0x0502) to indicate that the > > server is > > >temporarily unable to handle a request. > > > > > > > >We also discussed that a server MAY keep a list of clients that are > > trying > > >to connect in a "queue", and then serve each one one at a time. Then > > the > > >client doesn't receive an error (except if the "queue" is filled). > > This > > >gives the end-user a much happier experience. > > > > Consider the scenario: > > An IPP Client tries to print a job to an IPP server. A > non-spooling > > HTTP/IPP server received TCP SYN pkt on port 80 > > from the IPP > > client, responded back with a TCP SYN-ACK pkt, and then received > > an ACK pkt from the IPP client. At this point, the HTTP/IPP > > server does not know whether the next pkt is going to be an IPP request > > or a simple HTTP operation for its embedded web. > > Next comes the first HTTP POST > > pkt with IPP header and IPP data. However, at this time, the > > HTTP/IPP server realized that another IPP job is in the process > > of printing. What will the IPP server do? if we follow the first > > recommendation, it will immediately send a 0x0502 IPP status > > to indicate that the service is temporarily. However, if we follow the > > second recommendation, should the non-spooling IPP server just sit > > idle and not respond to the new HTTP POST operation? > > > > Thanks, > > PB > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com From jmp-owner@pwg.org Mon Feb 9 09:41:36 1998 Delivery-Date: Mon, 09 Feb 1998 09:41:36 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18782 for ; Mon, 9 Feb 1998 09:41:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02522 for ; Mon, 9 Feb 1998 09:44:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA28730 for ; Mon, 9 Feb 1998 09:41:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 09:35:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28095 for jmp-outgoing; Mon, 9 Feb 1998 09:29:53 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> A friendly reminder to "ping" for the PWG meeting in Austin Message-ID: <5040300012315622000002L022*@MHS> Date: Mon, 9 Feb 1998 09:27:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Here's a friendly reminder. Please send me a "ping" by 3:00PM CST on Tuesday, 2/10 for the PWG meeting in Austin, Texas on 3/2-6. Attached is my original note with the information and request. To date, only 10 people have sent me a "ping". Thanks, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-09-98 08:23 AM --------------------------- Keith Carter 02-02-98 11:29 AM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From adm Mon Feb 9 09:36:23 1998 Delivery-Date: Mon, 09 Feb 1998 09:44:07 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA18570 for ietf-123-outbound.10@ietf.org; Mon, 9 Feb 1998 09:32:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18525; Mon, 9 Feb 1998 09:29:58 -0500 (EST) Message-Id: <199802091429.JAA18525@ns.ietf.org> To: IETF-Announce: ; Cc: ipp@pwg.org From: The IESG SUBJECT: Last Call: Internet Printing Protocol/1.0: Protocol Specification to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 09 Feb 1998 09:29:57 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Internet Printing Protocol Working Group to consider publication of the following documents o Internet Printing Protocol/1.0: Protocol Specification as a Proposed Standard. o Internet Printing Protocol/1.0: Model and Semantics as a Proposed Standard. o Requirements for an Internet Printing Protocol as an Informational RFC. o Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol as an Informational RFC. o Mapping between LPD and IPP Protocols as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 23, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-09.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt From pwg-owner@pwg.org Mon Feb 9 09:49:57 1998 Delivery-Date: Mon, 09 Feb 1998 09:49:57 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18947 for ; Mon, 9 Feb 1998 09:49:57 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02569 for ; Mon, 9 Feb 1998 09:52:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA29166 for ; Mon, 9 Feb 1998 09:49:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 09:40:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28076 for pwg-outgoing; Mon, 9 Feb 1998 09:29:42 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> A friendly reminder to "ping" for the PWG meeting in Austin Message-ID: <5040300012315622000002L022*@MHS> Date: Mon, 9 Feb 1998 09:27:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Here's a friendly reminder. Please send me a "ping" by 3:00PM CST on Tuesday, 2/10 for the PWG meeting in Austin, Texas on 3/2-6. Attached is my original note with the information and request. To date, only 10 people have sent me a "ping". Thanks, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-09-98 08:23 AM --------------------------- Keith Carter 02-02-98 11:29 AM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 10:19:55 1998 Delivery-Date: Mon, 09 Feb 1998 10:19:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20274 for ; Mon, 9 Feb 1998 10:19:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02720 for ; Mon, 9 Feb 1998 10:22:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA00352 for ; Mon, 9 Feb 1998 10:19:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 10:12:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28109 for ipp-outgoing; Mon, 9 Feb 1998 09:30:00 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> A friendly reminder to "ping" for the PWG meeting in Austin Message-ID: <5040300012315622000002L022*@MHS> Date: Mon, 9 Feb 1998 09:27:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Here's a friendly reminder. Please send me a "ping" by 3:00PM CST on Tuesday, 2/10 for the PWG meeting in Austin, Texas on 3/2-6. Attached is my original note with the information and request. To date, only 10 people have sent me a "ping". Thanks, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-09-98 08:23 AM --------------------------- Keith Carter 02-02-98 11:29 AM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 10:19:59 1998 Delivery-Date: Mon, 09 Feb 1998 10:20:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20282 for ; Mon, 9 Feb 1998 10:19:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02723 for ; Mon, 9 Feb 1998 10:22:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA00364 for ; Mon, 9 Feb 1998 10:19:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 10:10:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28140 for ipp-outgoing; Mon, 9 Feb 1998 09:30:27 -0500 (EST) Message-Id: <199802091429.JAA18525@ns.ietf.org> To: IETF-Announce: ; Cc: ipp@pwg.org From: The IESG Subject: IPP> Last Call: Internet Printing Protocol/1.0: Protocol Specification to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 09 Feb 1998 09:29:57 -0500 Sender: ipp-owner@pwg.org The IESG has received a request from the Internet Printing Protocol Working Group to consider publication of the following documents o Internet Printing Protocol/1.0: Protocol Specification as a Proposed Standard. o Internet Printing Protocol/1.0: Model and Semantics as a Proposed Standard. o Requirements for an Internet Printing Protocol as an Informational RFC. o Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol as an Informational RFC. o Mapping between LPD and IPP Protocols as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 23, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-09.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt From adm Mon Feb 9 10:47:28 1998 Delivery-Date: Mon, 09 Feb 1998 10:54:30 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA21970 for ietf-123-outbound.10@ietf.org; Mon, 9 Feb 1998 10:47:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA19451; Mon, 9 Feb 1998 10:02:39 -0500 (EST) Message-Id: <199802091502.KAA19451@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-lzs-03.txt Date: Mon, 09 Feb 1998 10:02:38 -0500 Sender: cclark@cnri.reston.va.us --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 Using LZS Author(s) : R. Friend, R. Monsour Filename : draft-ietf-ippcp-lzs-03.txt Pages : 7 Date : 06-Feb-98 This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. 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-lzs-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-lzs-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-lzs-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: <19980206163333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-lzs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-lzs-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980206163334.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Mon Feb 9 11:55:10 1998 Delivery-Date: Mon, 09 Feb 1998 11:55:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24702 for ; Mon, 9 Feb 1998 11:55:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03256 for ; Mon, 9 Feb 1998 11:57:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA02546 for ; Mon, 9 Feb 1998 11:55:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 11:44:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00661 for ipp-outgoing; Mon, 9 Feb 1998 11:07:42 -0500 (EST) Message-ID: <34DF28DE.56886BFF@underscore.com> Date: Mon, 09 Feb 1998 11:03:42 -0500 From: "Jeffrey D. Schnitzer" Reply-To: James Walker Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> ADM - How to follow the fate of the IPP drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org [The following message from Jim Walker was filtered by Majordomo as a misdirected admin request due to the word "ubscribe-say" being used within the first five lines of the message body -- /Jeff Schnitzer] > With the message now sent to the IESG to process the IPP drafts for > publishing as RFCs, they are now out of our control. If you want to find > out how the next step in the processing chain develops, you should > subscribe to the IETF annoncement list. See description below on how to > subscribe. I am curious as to how the discussion will work. Is it simply the case that comments will be posted on iesg@ietf.org or ietf@ietf.org, and there will be no discussion of those comments? Or will there be some lively interchanges that we will all be interested in following, and diving into? Will all comments (and discussion) be forwarded automatically to the IPP DL? Or are comments usually cc'ed to the appropriate DL out of courtesy? Or do we all need to run over and subscribe to the IESG and IETF DL's? inquiring mind... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Mon Feb 9 11:58:49 1998 Delivery-Date: Mon, 09 Feb 1998 11:58:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24831 for ; Mon, 9 Feb 1998 11:58:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03280 for ; Mon, 9 Feb 1998 12:01:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA02809 for ; Mon, 9 Feb 1998 11:58:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 11:48:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00693 for ipp-outgoing; Mon, 9 Feb 1998 11:11:53 -0500 (EST) Message-Id: <1.5.4.32.19980209161312.0068065c@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Feb 1998 08:13:12 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Last Call: Internet Printing Protocol/1.0: Protocol Specification to Proposed Standard Sender: ipp-owner@pwg.org Just in case you have not yet signed up for the IETF-Announce DL. The deadline for comments to the IESG is on February 23. Carl-Uno --- >To: ;@IETF-Announce >Cc: ipp@pwg.org >From: The IESG >Subject: IPP> Last Call: Internet Printing Protocol/1.0: Protocol > Specification to Proposed Standard >Reply-to: iesg@ns.ietf.org >Date: Mon, 09 Feb 1998 09:29:57 -0500 >Sender: ipp-owner@pwg.org > > >The IESG has received a request from the Internet Printing Protocol Working Group to consider publication of the following documents > > o Internet Printing Protocol/1.0: Protocol Specification > as a Proposed Standard. > o Internet Printing Protocol/1.0: Model and Semantics > as a Proposed Standard. > o Requirements for an Internet Printing Protocol > as an Informational RFC. > o Rationale for the Structure of the Model and Protocol for the > Internet Printing Protocol as an > Informational RFC. > o Mapping between LPD and IPP Protocols > as an Informational RFC. > > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by February 23, 1998. > >Files can be obtained via >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-05.txt >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-09.txt >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-02.txt >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-lpd-ipp-map-03.txt > > From ipp-owner@pwg.org Mon Feb 9 12:15:29 1998 Delivery-Date: Mon, 09 Feb 1998 12:15:30 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA25183 for ; Mon, 9 Feb 1998 12:15:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03379 for ; Mon, 9 Feb 1998 12:18:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA03471 for ; Mon, 9 Feb 1998 12:15:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 12:11:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01899 for ipp-outgoing; Mon, 9 Feb 1998 11:48:06 -0500 (EST) Date: Mon, 9 Feb 1998 08:39:39 -0800 (Pacific Standard Time) From: Ron Bergman To: ipp@pwg.org Subject: IPP> MOD> A New View of Notification Requirements Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org A major point missing from the previously posted notification requirements concerns the location or intent of the user. I believe this to be the most important factor to be considered, and should minimize much of the discussion concerning firewalls. This analysis assumes, as in the previously posted requirements, that submission problems such as transmission errors and acceptance of the job are handled by the job submission protocol. REMOTE USER: - The remote user is always the submitter of the job. - A firewall may or may not exist between the remote user and the printer. - The document will not be directly retrieved by the remote user. - The remote user does not require any notifications other than an indication that the job has completed. The remote user may desire additional notifications, but since he is remote from the printer, he will be unable to perform any required actions. For simplicity, I propose that we restrict notification to a remote user to job completion. - The submitter does not require immediate notification of job completion. Again he may desire immediate notification but, since he is not the person that will retrieve the job, this should not be a high priority. LOCAL USER: - The local user will never encounter a firewall in the path to the printer. - The local user may or may not be the submitter of the document to be printed. He is always the recipient of the document. - The local user should have the option of receiving all possible notifications regarding the progress of the job and any problems or errors encountered. Maintenance or support personnel may also receive problem and error notifications in addition to or instead of the local user. - The local user requires prompt notification of job completion and possibly problems and error conditions. Since only the remote user must deal with a firewall and he does not require any notification other than job completion, the protocol requirements are greatly simplified. For the remote user, email notifications should be a perfect match. I have not seen any other methods proposed that everyone agrees are firewall *safe*. Notification for the local user are open to any reasonable protocol, no firewall is ever encountered in this case. The is the area that will require the most effort to resolve the notification issue. The model document should include the following attributes to support these requirements. 1. remote-notification-uri (Job Template Attribute) No job completion notification is returned to the remote user if this attribute is not included in the job submission request. 2. local-notification-uri (Job Template Attribute) No job notifications are returned to the local user if this attribute is not included in the job submission request. 3. Local-notification-types-requested (Job Template Attribute) An enum or bit map which defines the types of notifications requested. Includes job completion, job progress, job errors, printer errors, printer warnings, etc. 4. local-notification-types-default (Printer Description Attribute) 5. printer-service-notification-uri (Printer Description Attribute) All printer problems are reported to this URI. This is not intended to be a complete notification solution for IPP. My only intent is to minimize the discussion regarding firewalls. (This discussion (firewalls) appears to be making very little progress.) There is still a significant amount of work remaining to complete the IPP notification effort. Comments invited! Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Mon Feb 9 13:24:21 1998 Delivery-Date: Mon, 09 Feb 1998 13:24:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA27255 for ; Mon, 9 Feb 1998 13:24:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03770 for ; Mon, 9 Feb 1998 13:27:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04198 for ; Mon, 9 Feb 1998 13:24:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 13:15:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03606 for ipp-outgoing; Mon, 9 Feb 1998 12:49:03 -0500 (EST) From: Roger K Debry To: Subject: IPP> MOD> A New View of Notification Requirements Message-ID: <5030100017225748000002L082*@MHS> Date: Mon, 9 Feb 1998 12:47:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA27255 Ron, I think this is a good analysis. I agree that since remote users can't do much about a job, an email notification that the job is complete is sufficient. Perhaps to save confusion on the terms local and remote, we could use the term email-notification-uri, with the description that this is intended for users who are remote from the printer, who only need notification that print is complete, that they do not need this immediately, i.e. they are satisfied to have the notification handled by email and delivered at whenever they happen to open their email. Local users could use this scheme as well if this is the level of notification they wanted. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/09/98 10:41 AM --------------------------- ipp-owner@pwg.org on 02/09/98 10:13:19 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> MOD> A New View of Notification Requirements A major point missing from the previously posted notification requirements concerns the location or intent of the user. I believe this to be the most important factor to be considered, and should minimize much of the discussion concerning firewalls. This analysis assumes, as in the previously posted requirements, that submission problems such as transmission errors and acceptance of the job are handled by the job submission protocol. REMOTE USER: - The remote user is always the submitter of the job. - A firewall may or may not exist between the remote user and the printer. - The document will not be directly retrieved by the remote user. - The remote user does not require any notifications other than an indication that the job has completed. The remote user may desire additional notifications, but since he is remote from the printer, he will be unable to perform any required actions. For simplicity, I propose that we restrict notification to a remote user to job completion. - The submitter does not require immediate notification of job completion. Again he may desire immediate notification but, since he is not the person that will retrieve the job, this should not be a high priority. LOCAL USER: - The local user will never encounter a firewall in the path to the printer. - The local user may or may not be the submitter of the document to be printed. He is always the recipient of the document. - The local user should have the option of receiving all possible notifications regarding the progress of the job and any problems or errors encountered. Maintenance or support personnel may also receive problem and error notifications in addition to or instead of the local user. - The local user requires prompt notification of job completion and possibly problems and error conditions. Since only the remote user must deal with a firewall and he does not require any notification other than job completion, the protocol requirements are greatly simplified. For the remote user, email notifications should be a perfect match. I have not seen any other methods proposed that everyone agrees are firewall *safe*. Notification for the local user are open to any reasonable protocol, no firewall is ever encountered in this case. The is the area that will require the most effort to resolve the notification issue. The model document should include the following attributes to support these requirements. 1. remote-notification-uri (Job Template Attribute) No job completion notification is returned to the remote user if this attribute is not included in the job submission request. 2. local-notification-uri (Job Template Attribute) No job notifications are returned to the local user if this attribute is not included in the job submission request. 3. Local-notification-types-requested (Job Template Attribute) An enum or bit map which defines the types of notifications requested. Includes job completion, job progress, job errors, printer errors, printer warnings, etc. 4. local-notification-types-default (Printer Description Attribute) 5. printer-service-notification-uri (Printer Description Attribute) All printer problems are reported to this URI. This is not intended to be a complete notification solution for IPP. My only intent is to minimize the discussion regarding firewalls. (This discussion (firewalls) appears to be making very little progress.) There is still a significant amount of work remaining to complete the IPP notification effort. Comments invited! Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Mon Feb 9 13:34:08 1998 Delivery-Date: Mon, 09 Feb 1998 13:34:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA27414 for ; Mon, 9 Feb 1998 13:34:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03824 for ; Mon, 9 Feb 1998 13:36:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04820 for ; Mon, 9 Feb 1998 13:34:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 13:26:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03625 for ipp-outgoing; Mon, 9 Feb 1998 12:57:09 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> IPP > FAQ - How should the server behave? Message-ID: <5030100017226148000002L082*@MHS> Date: Mon, 9 Feb 1998 12:54:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA27414 > We also discussed that a server MAY keep a list of clients that are trying > to connect in a "queue", and then serve each one one at a time. This is easy to implement, but the connection attempt will appear to "hang" indefinitely. > Then the > client doesn't receive an error (except if the "queue" is filled). This > gives the end-user a much happier experience. I'd be happier to get server-error-service-unavailable (0x0502) with an estimate of the the length of the delay indicated in the message. A client could then give a user the choice of canceling, retrying, or queuing locally and retrying after delay. At that point the user might decide to try another printer, or just queue the job locally (client side) and go on. > I think that both approaches should be put into the FAQ. Fine with me. -Carl hastings@cp10.es.xerox.com on 02/06/98 07:34:46 PM Please respond to hastings@cp10.es.xerox.com @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> IPP > FAQ - How should the server behave? At 08:10 02/02/1998 PST, Carl Kugler wrote: >Henrik- snip... >> 3. How should a non-spooling IPP-server handle concurrent print-job >> requests? > >Return server-error-service-unavailable (0x0502) to indicate that the server is >temporarily unable to handle a request. > > > -Carl > >---------------------- Forwarded by Carl Kugler/Boulder/IBM on 02/02/98 08:41 We also discussed that a server MAY keep a list of clients that are trying to connect in a "queue", and then serve each one one at a time. Then the client doesn't receive an error (except if the "queue" is filled). This gives the end-user a much happier experience. I think that both approaches should be put into the FAQ. Tom From ipp-owner@pwg.org Mon Feb 9 14:23:43 1998 Delivery-Date: Mon, 09 Feb 1998 14:23:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28164 for ; Mon, 9 Feb 1998 14:23:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04082 for ; Mon, 9 Feb 1998 14:26:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06123 for ; Mon, 9 Feb 1998 14:23:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:04:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04291 for ipp-outgoing; Mon, 9 Feb 1998 13:25:32 -0500 (EST) Message-Id: <3.0.1.32.19980209101026.00ba5b20@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Feb 1998 10:10:26 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Confeence Call on 980211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Confeence Call on 980211 After your "free" week last week, we will hold a phone conference again on Wednesday. I suggest that we concentrate on discussing the subject of requirements for notifications. Do we have somebody volonteering to take on the task of becoming editor for a notifications requirement document? Can we try to establish what we think is "in scope" vs. "out of scope" for IPP notifications? The dial-in information is: Here are the details on the next two IPP conference calls. Date: 2/11 Call-in: 1-608-250-1828 Access: 190148 Time: 4PM EST (1PM PST) Duration: 2.5 hours Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Mon Feb 9 14:27:15 1998 Delivery-Date: Mon, 09 Feb 1998 14:27:15 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28209 for ; Mon, 9 Feb 1998 14:27:15 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04098 for ; Mon, 9 Feb 1998 14:29:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06447 for ; Mon, 9 Feb 1998 14:27:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:18:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05236 for jmp-outgoing; Mon, 9 Feb 1998 14:09:38 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> Getting the $101 rate at the Hyatt hotel for the PWG meeting Message-ID: <5040300012332527000002L072*@MHS> Date: Mon, 9 Feb 1998 14:06:24 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From pwg-owner@pwg.org Mon Feb 9 14:33:04 1998 Delivery-Date: Mon, 09 Feb 1998 14:33:05 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28292 for ; Mon, 9 Feb 1998 14:33:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04150 for ; Mon, 9 Feb 1998 14:35:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06846 for ; Mon, 9 Feb 1998 14:32:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:20:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05171 for pwg-outgoing; Mon, 9 Feb 1998 14:08:58 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Message-ID: <5040300012332527000002L072*@MHS> Date: Mon, 9 Feb 1998 14:06:24 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 14:43:31 1998 Delivery-Date: Mon, 09 Feb 1998 14:43:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA28458 for ; Mon, 9 Feb 1998 14:43:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04203 for ; Mon, 9 Feb 1998 14:46:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07545 for ; Mon, 9 Feb 1998 14:43:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:28:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04912 for ipp-outgoing; Mon, 9 Feb 1998 13:35:02 -0500 (EST) Message-ID: <34DF4C3D.EC71C26@underscore.com> Date: Mon, 09 Feb 1998 13:34:37 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> IPP > FAQ - How should the server behave? References: <5030100017226148000002L082*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl Kugler wrote: > I'd be happier to get server-error-service-unavailable (0x0502) with an > estimate of the the length of the delay indicated in the message. A client > could then give a user the choice of canceling, retrying, or queuing locally > and retrying after delay. At that point the user might decide to try another > printer, or just queue the job locally (client side) and go on. Is the "server-error-service-unavailable" (0x0502) error code used for any other type of error condition? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jmp-owner@pwg.org Mon Feb 9 15:04:57 1998 Delivery-Date: Mon, 09 Feb 1998 15:05:01 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA28844 for ; Mon, 9 Feb 1998 15:04:47 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04319 for ; Mon, 9 Feb 1998 15:04:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA08553 for ; Mon, 9 Feb 1998 14:59:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:53:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07723 for jmp-outgoing; Mon, 9 Feb 1998 14:46:08 -0500 (EST) Message-ID: <01BD354F.E8E5BA60.mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: JMP> RE: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Date: Mon, 9 Feb 1998 11:43:14 -0800 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 45 TEXT Sender: jmp-owner@pwg.org Keith: Yes, I already made reservervations for myself and Larry Stein at the higher rate. If you could inform Hyatt when you call them that would be great. Like I said earlier, I will be out of the country for a while, this is why I made the reservations so early. Thanks! Mark -----Original Message----- From: Keith Carter [SMTP:carterk@us.ibm.com] Sent: Monday, February 09, 1998 11:06 AM To: p1394@pwg.org; pwg@pwg.org; fin@pwg.org; jmp@pwg.org; ipp@pwg.org Subject: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 15:17:03 1998 Delivery-Date: Mon, 09 Feb 1998 15:17:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29014 for ; Mon, 9 Feb 1998 15:16:56 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04391 for ; Mon, 9 Feb 1998 15:19:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA09699 for ; Mon, 9 Feb 1998 15:16:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 14:56:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04950 for ipp-outgoing; Mon, 9 Feb 1998 13:49:41 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059CC1@EXCHANGE> From: "Gordon, Charles" To: ipp@pwg.org Subject: IPP> Three types of notification. Date: Mon, 9 Feb 1998 13:48:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org It seems to me that there are three types of notification to deal with. 1. Notifying the sender of the job whether or not the job is printed and if so when. 2. Notifying the intended receiver of the job that he has a new job at the printer. 3. Notifying MIS when and if problems occur printing the job. I would suggest that IPP not concern itself with case 3. I think this is best left to the implementer of the IPP print server to define for their own environment. As suggested in the previous messages, case 1 is probably best done via email. However, I think IPP should provide the flexibility for other mechanisms. Perhaps sender notification can be a job attribute which includes notification method and address as part of the job. Notification methods might include: 1. Human readable email which is sent directly to the person who sent the job. In this case, the address would be the sender's email address. The message would be sent in English. 2. Machine readable email which is sent to a mailbox accessible by software on the sender's PC. The address would be a special email address which the PC software could check periodically in the background. When the software finds a notification message, it pops up a Window saying so. The advantage in this method is that the software on the local PC can provide the notification in the sender's native language. This is difficult to do on the IPP server. However, the sender's PC is (obviously) already setup with the correct character sets and should have a localized version of the IPP software. The method also allows the IPP software to give faster notification since it can continuously poll the mailbox in the background rather than waiting for the user to check his email. 3. Some other notification method to be developed later. I haven't read any email on the IPP mailing list about case 2 yet. Maybe no one is planning to support receiver notification, or maybe no one has thought of it yet. I think it is important. If I send a print job to Sam in Portland, I would like Sam to be told when the job is printed and what printer it's on. Receiver notification may be difficult. First of all, the receiver should notified quickly when his job is printed. Some people may consider email too slow for this. Secondly, the receive may not be using IP protocol, or may not be networked at all (as unlikely as this may be). I think IPP should start by supporting email notification of the job receipient using the methods I described above for the sender. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Ron Bergman [SMTP:rbergma@dpc.com] > Sent: Monday, February 09, 1998 11:40 AM > To: ipp@pwg.org > Subject: IPP> MOD> A New View of Notification Requirements > > A major point missing from the previously posted notification > requirements concerns the location or intent of the user. I believe > this to be the most important factor to be considered, and should > minimize much of the discussion concerning firewalls. This analysis > assumes, as in the previously posted requirements, that submission > problems such as transmission errors and acceptance of the job are > handled by the job submission protocol. > > REMOTE USER: > > - The remote user is always the submitter of the job. > - A firewall may or may not exist between the remote user and the > printer. > - The document will not be directly retrieved by the remote user. > - The remote user does not require any notifications other than an > indication that the job has completed. The remote user may desire > additional notifications, but since he is remote from the printer, > he will be unable to perform any required actions. For simplicity, > > I propose that we restrict notification to a remote user to job > completion. > - The submitter does not require immediate notification of job > completion. Again he may desire immediate notification but, since > he is not the person that will retrieve the job, this should not be > > a high priority. > > LOCAL USER: > > - The local user will never encounter a firewall in the path to the > printer. > - The local user may or may not be the submitter of the document to > be > printed. He is always the recipient of the document. > - The local user should have the option of receiving all possible > notifications regarding the progress of the job and any problems or > > errors encountered. Maintenance or support personnel may also > receive problem and error notifications in addition to or instead > of the local user. > - The local user requires prompt notification of job completion and > possibly problems and error conditions. > > Since only the remote user must deal with a firewall and he does not > require any notification other than job completion, the protocol > requirements are greatly simplified. For the remote user, email > notifications should be a perfect match. I have not seen any other > methods proposed that everyone agrees are firewall *safe*. > > Notification for the local user are open to any reasonable protocol, > no > firewall is ever encountered in this case. The is the area that will > require the most effort to resolve the notification issue. > > The model document should include the following attributes to support > these requirements. > > 1. remote-notification-uri (Job Template Attribute) No job > completion notification is returned to the remote user if this > attribute is not included in the job submission request. > 2. local-notification-uri (Job Template Attribute) No job > notifications are returned to the local user if this attribute > is > not included in the job submission request. > 3. Local-notification-types-requested (Job Template Attribute) An > enum or bit map which defines the types of notifications > requested. Includes job completion, job progress, job errors, > printer errors, printer warnings, etc. > 4. local-notification-types-default (Printer Description Attribute) > 5. printer-service-notification-uri (Printer Description Attribute) > All printer problems are reported to this URI. > > This is not intended to be a complete notification solution for IPP. > My > only intent is to minimize the discussion regarding firewalls. (This > discussion (firewalls) appears to be making very little progress.) > There > is still a significant amount of work remaining to complete the IPP > notification effort. > > Comments invited! > > > Ron Bergman > Dataproducts Corp. > From pwg-owner@pwg.org Mon Feb 9 15:25:02 1998 Delivery-Date: Mon, 09 Feb 1998 15:25:02 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29138 for ; Mon, 9 Feb 1998 15:25:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04442 for ; Mon, 9 Feb 1998 15:27:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA10052 for ; Mon, 9 Feb 1998 15:24:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 15:14:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07779 for pwg-outgoing; Mon, 9 Feb 1998 14:46:57 -0500 (EST) Message-ID: <01BD354F.E8E5BA60.mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: RE: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Date: Mon, 9 Feb 1998 11:43:14 -0800 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 45 TEXT Sender: owner-pwg@pwg.org Keith: Yes, I already made reservervations for myself and Larry Stein at the higher rate. If you could inform Hyatt when you call them that would be great. Like I said earlier, I will be out of the country for a while, this is why I made the reservations so early. Thanks! Mark -----Original Message----- From: Keith Carter [SMTP:carterk@us.ibm.com] Sent: Monday, February 09, 1998 11:06 AM To: p1394@pwg.org; pwg@pwg.org; fin@pwg.org; jmp@pwg.org; ipp@pwg.org Subject: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 15:44:46 1998 Delivery-Date: Mon, 09 Feb 1998 15:44:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA29520 for ; Mon, 9 Feb 1998 15:44:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04565 for ; Mon, 9 Feb 1998 15:47:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA10663 for ; Mon, 9 Feb 1998 15:44:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 15:31:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05259 for ipp-outgoing; Mon, 9 Feb 1998 14:10:06 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> Getting the $101 rate at the Hyatt hotel for the PWG meeting Message-ID: <5040300012332527000002L072*@MHS> Date: Mon, 9 Feb 1998 14:06:24 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 16:05:50 1998 Delivery-Date: Mon, 09 Feb 1998 16:05:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29869 for ; Mon, 9 Feb 1998 16:05:49 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04676 for ; Mon, 9 Feb 1998 16:08:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11804 for ; Mon, 9 Feb 1998 16:05:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 15:50:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07836 for ipp-outgoing; Mon, 9 Feb 1998 14:47:48 -0500 (EST) Message-ID: <01BD354F.E8E5BA60.mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: IPP> RE: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Date: Mon, 9 Feb 1998 11:43:14 -0800 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 45 TEXT Sender: ipp-owner@pwg.org Keith: Yes, I already made reservervations for myself and Larry Stein at the higher rate. If you could inform Hyatt when you call them that would be great. Like I said earlier, I will be out of the country for a while, this is why I made the reservations so early. Thanks! Mark -----Original Message----- From: Keith Carter [SMTP:carterk@us.ibm.com] Sent: Monday, February 09, 1998 11:06 AM To: p1394@pwg.org; pwg@pwg.org; fin@pwg.org; jmp@pwg.org; ipp@pwg.org Subject: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Mon Feb 9 16:06:52 1998 Delivery-Date: Mon, 09 Feb 1998 16:06:52 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29898 for ; Mon, 9 Feb 1998 16:06:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04690 for ; Mon, 9 Feb 1998 16:09:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11906 for ; Mon, 9 Feb 1998 16:06:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 15:52:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08440 for ipp-outgoing; Mon, 9 Feb 1998 14:57:53 -0500 (EST) From: Harry Lewis To: Subject: IPP> Submission vs. Monitoring and Management Message-ID: <5030300017732130000002L002*@MHS> Date: Mon, 9 Feb 1998 15:02:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA29898 I'm confused about part of the thread which was "IPP> Consensus on sending our drafts to the IESG". Here, Paul Moore makes a distinction between job submission, for which, in the context of IPP, Microsoft proposed SWP... >I saw two problems with two , potentially different, solutions (hence my >double vote). I rolled with what I saw as the simple solution (HTTP - >interesting that you percieve them the opposite way round) and proposed >something called SIMPLE web printing based on what we were building - that >just did job submission. That eventually evolved into what we have today. ... and other job related issues that could be addressed (i.e. Monitoring and Management). >Now we move on to address the issues that were lurking in the background - >printer discovery, feature dicsovery , configuration discovery, managment, >notification, flow control, peer queuing,.... (things for s/w to printer >interface) and billing, quotas, access control, server managemnt, job >redirection, ... (things for client to print subsystem interface). In that thread, Paul said: >The WG is DETERMINED that this will be done by one protocol - I have >expressed (with you and others) my opionion that this is not acheiveable >(its desirability is understandable) many times. I guess it could be perceived, at this juncture, that the PWG is only interested in one, "soup to nuts", printing protocol, but I contest that there has been a sideband approach to job monitoring in co-development for over two years. When the SNMP Job MIB project started, we promptly acknowledged the need for submission standards. In late 1995, I lobbied for a job submission "wrapper" to encapsulate submission attributes (i.e. job submission standard) to facilitate monitoring via the MIB. This was ill received and it wasn't until submission via the Internet became an issue that we had the opportunity, finally, to correlate the monitoring channel with submission. At first, I was concerned that the IPP group was going "whole hog", beyond submission, but I was reassured that correlation with JMP was paramount (for accounting and administration) even if the IETF had rejected the notion of a Job MIB internet standard. Indeed, Tom (especially), Scott, and others have done a great job helping see to it. I know there is distaste, among some, regarding the use of SNMP as it relates to print jobs. Most of the criticism relates to the unreliable nature of UDP and the lack of registration and trap direction. SNMPv3 begins to address these issues and SENSE goes even farther, with the edition filter. While most of the IPP people go home Thursday night, there are a substantial number who have remained for the Friday JMP meeting. Most of the interested parties have indicated that their private implementations or prototypes of the standard have ALL resorted to some proprietary event mechanism (i.e. Job Traps) to get the job done. Standardization of job traps is on the Austin agenda. So, when I hear the statement >The problem is that nobody wants to do the other thing! I'm wondering: A. What is the other thing? B. Is this really true? If the other thing is a side band for job monitoring and management, correlated with the submission protocol in terms of objects and attributes, then I think there ARE people in the PWG who have demonstrated their desire to do it. AND, I think the common point between submission and effective monitoring is clearly NOTIFICATION! Harry Lewis From pwg-owner@pwg.org Mon Feb 9 17:20:40 1998 Delivery-Date: Mon, 09 Feb 1998 17:20:40 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA01274 for ; Mon, 9 Feb 1998 17:20:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05121 for ; Mon, 9 Feb 1998 17:23:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12515 for ; Mon, 9 Feb 1998 17:20:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 17:05:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12063 for pwg-outgoing; Mon, 9 Feb 1998 16:55:24 -0500 (EST) From: don@lexmark.com Message-Id: <199802092154.AA07941@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, pwg@pwg.org, carterk@us.ibm.com, harryl@us.ibm.com Date: Mon, 9 Feb 1998 16:52:27 -0500 Subject: PWG> Austin Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org I would like to proposed the UPD group meet on Tuesday evening. Any violent objects? Keith, can we have the room in the evening? Thanks! Don ---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM --------------------------- From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM To: Don Wright@Lexmark cc: paulmo%microsoft.com@interlock.lexmark.com bcc: Subject: Austin Agenda Don, what about Universal Print Driver on the agenda? >PWG MEETING AGENDA > >Here is the agenda proposed by Don Wright: > >Monday (3/2), Tuesday (3/3): > -- 1394 Printing >Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing >Wednesday (3/4) PM: > -- IPP >Thursday (3/5): > -- IPP >Friday (3/6): > -- Finisher > -- Job MIB Traps I have in my PWG minutes (moments from issuing) that Paul was to provide a sample (or spec) in prep for a discussion in Austin. Am I wrong? We could try to fit this in with PWG overview / NC Print or even squeeze it into Tuesday for those willing to endure the overlap with P1394. Harry Lewis - IBM Printing Systems From pwg-owner@pwg.org Mon Feb 9 17:36:32 1998 Delivery-Date: Mon, 09 Feb 1998 17:36:32 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA01431 for ; Mon, 9 Feb 1998 17:36:31 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05216 for ; Mon, 9 Feb 1998 17:39:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12927 for ; Mon, 9 Feb 1998 17:36:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 17:24:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12267 for pwg-outgoing; Mon, 9 Feb 1998 17:10:50 -0500 (EST) From: don@lexmark.com Message-Id: <199802092210.AA08833@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Ipp@pwg.org, Pwg@pwg.org, Carterk@Us.Ibm.Com, Harryl@Us.Ibm.Com Date: Mon, 9 Feb 1998 17:09:40 -0500 Subject: Re: PWG> Austin Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org That should be violent OBJECTIONS. Violent objects will be later. Don To: ipp%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com, carterk%us.ibm.com@interlock.lexmark.com, harryl%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: PWG> Austin Agenda I would like to proposed the UPD group meet on Tuesday evening. Any violent objects? Keith, can we have the room in the evening? Thanks! Don ---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM --------------------------- From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM To: Don Wright@Lexmark cc: paulmo%microsoft.com@interlock.lexmark.com bcc: Subject: Austin Agenda Don, what about Universal Print Driver on the agenda? >PWG MEETING AGENDA > >Here is the agenda proposed by Don Wright: > >Monday (3/2), Tuesday (3/3): > -- 1394 Printing >Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing >Wednesday (3/4) PM: > -- IPP >Thursday (3/5): > -- IPP >Friday (3/6): > -- Finisher > -- Job MIB Traps I have in my PWG minutes (moments from issuing) that Paul was to provide a sample (or spec) in prep for a discussion in Austin. Am I wrong? We could try to fit this in with PWG overview / NC Print or even squeeze it into Tuesday for those willing to endure the overlap with P1394. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Feb 9 18:05:27 1998 Delivery-Date: Mon, 09 Feb 1998 18:05:28 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA01911 for ; Mon, 9 Feb 1998 18:05:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05347 for ; Mon, 9 Feb 1998 18:08:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA13925 for ; Mon, 9 Feb 1998 18:05:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 17:39:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12030 for ipp-outgoing; Mon, 9 Feb 1998 16:46:57 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> IPP > FAQ - How should the server behave? Message-ID: <5030100017238078000002L082*@MHS> Date: Mon, 9 Feb 1998 16:44:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA01911 The 0x0502 status code means "The IPP object is currently unable to handle the request due to a temporary overloading or maintenance of the IPP object. " So, yes, it could also mean the IPP object is down for maintenance. -Carl ipp-owner@pwg.org on 02/09/98 12:34:38 PM Please respond to ipp-owner@pwg.org @ internet To: Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org @ internet Subject: Re: IPP> IPP > FAQ - How should the server behave? Carl Kugler wrote: > I'd be happier to get server-error-service-unavailable (0x0502) with an > estimate of the the length of the delay indicated in the message. A client > could then give a user the choice of canceling, retrying, or queuing locally > and retrying after delay. At that point the user might decide to try another > printer, or just queue the job locally (client side) and go on. Is the "server-error-service-unavailable" (0x0502) error code used for any other type of error condition? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Feb 9 18:51:04 1998 Delivery-Date: Mon, 09 Feb 1998 18:51:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02344 for ; Mon, 9 Feb 1998 18:51:04 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05465 for ; Mon, 9 Feb 1998 18:53:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16305 for ; Mon, 9 Feb 1998 18:50:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 18:31:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12073 for ipp-outgoing; Mon, 9 Feb 1998 16:57:05 -0500 (EST) From: Harry Lewis To: , Subject: Re: IPP> MOD> A New View of Notification Requirements Message-ID: <5030300017737211000002L012*@MHS> Date: Mon, 9 Feb 1998 17:02:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA02344 Ron, I agree with your qualifications of the notification requirements. I'm not sure I understand this one, however: > The local user may or may not be the submitter of the document > to be printed. He is always the recipient of the document. Can you please elaborate? Unless (and perhaps even if) the submitter is capable of directing notification to a specific recipient, as suggested by Charles Gordon in another thread (Three Types of Notification). >2. Notifying the intended receiver of the job that he has a new job at >the printer. I would always think of the submitter as wanting notification. Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 02/09/98 10:12:51 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> MOD> A New View of Notification Requirements A major point missing from the previously posted notification requirements concerns the location or intent of the user. I believe this to be the most important factor to be considered, and should minimize much of the discussion concerning firewalls. This analysis assumes, as in the previously posted requirements, that submission problems such as transmission errors and acceptance of the job are handled by the job submission protocol. REMOTE USER: - The remote user is always the submitter of the job. - A firewall may or may not exist between the remote user and the printer. - The document will not be directly retrieved by the remote user. - The remote user does not require any notifications other than an indication that the job has completed. The remote user may desire additional notifications, but since he is remote from the printer, he will be unable to perform any required actions. For simplicity, I propose that we restrict notification to a remote user to job completion. - The submitter does not require immediate notification of job completion. Again he may desire immediate notification but, since he is not the person that will retrieve the job, this should not be a high priority. LOCAL USER: - The local user will never encounter a firewall in the path to the printer. - The local user may or may not be the submitter of the document to be printed. He is always the recipient of the document. - The local user should have the option of receiving all possible notifications regarding the progress of the job and any problems or errors encountered. Maintenance or support personnel may also receive problem and error notifications in addition to or instead of the local user. - The local user requires prompt notification of job completion and possibly problems and error conditions. Since only the remote user must deal with a firewall and he does not require any notification other than job completion, the protocol requirements are greatly simplified. For the remote user, email notifications should be a perfect match. I have not seen any other methods proposed that everyone agrees are firewall *safe*. Notification for the local user are open to any reasonable protocol, no firewall is ever encountered in this case. The is the area that will require the most effort to resolve the notification issue. The model document should include the following attributes to support these requirements. 1. remote-notification-uri (Job Template Attribute) No job completion notification is returned to the remote user if this attribute is not included in the job submission request. 2. local-notification-uri (Job Template Attribute) No job notifications are returned to the local user if this attribute is not included in the job submission request. 3. Local-notification-types-requested (Job Template Attribute) An enum or bit map which defines the types of notifications requested. Includes job completion, job progress, job errors, printer errors, printer warnings, etc. 4. local-notification-types-default (Printer Description Attribute) 5. printer-service-notification-uri (Printer Description Attribute) All printer problems are reported to this URI. This is not intended to be a complete notification solution for IPP. My only intent is to minimize the discussion regarding firewalls. (This discussion (firewalls) appears to be making very little progress.) There is still a significant amount of work remaining to complete the IPP notification effort. Comments invited! Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Mon Feb 9 18:52:32 1998 Delivery-Date: Mon, 09 Feb 1998 18:52:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02354 for ; Mon, 9 Feb 1998 18:52:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05472 for ; Mon, 9 Feb 1998 18:55:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16426 for ; Mon, 9 Feb 1998 18:52:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 18:33:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12055 for ipp-outgoing; Mon, 9 Feb 1998 16:55:09 -0500 (EST) From: don@lexmark.com Message-Id: <199802092154.AA07941@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, pwg@pwg.org, carterk@us.ibm.com, harryl@us.ibm.com Date: Mon, 9 Feb 1998 16:52:27 -0500 Subject: IPP> Austin Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I would like to proposed the UPD group meet on Tuesday evening. Any violent objects? Keith, can we have the room in the evening? Thanks! Don ---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM --------------------------- From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM To: Don Wright@Lexmark cc: paulmo%microsoft.com@interlock.lexmark.com bcc: Subject: Austin Agenda Don, what about Universal Print Driver on the agenda? >PWG MEETING AGENDA > >Here is the agenda proposed by Don Wright: > >Monday (3/2), Tuesday (3/3): > -- 1394 Printing >Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing >Wednesday (3/4) PM: > -- IPP >Thursday (3/5): > -- IPP >Friday (3/6): > -- Finisher > -- Job MIB Traps I have in my PWG minutes (moments from issuing) that Paul was to provide a sample (or spec) in prep for a discussion in Austin. Am I wrong? We could try to fit this in with PWG overview / NC Print or even squeeze it into Tuesday for those willing to endure the overlap with P1394. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Feb 9 18:58:54 1998 Delivery-Date: Mon, 09 Feb 1998 18:58:54 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02406 for ; Mon, 9 Feb 1998 18:58:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05489 for ; Mon, 9 Feb 1998 19:01:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16887 for ; Mon, 9 Feb 1998 18:58:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 18:37:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12383 for ipp-outgoing; Mon, 9 Feb 1998 17:14:58 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC233@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Harry Lewis'" , ipp@pwg.org Subject: RE: IPP> Submission vs. Monitoring and Management Date: Mon, 9 Feb 1998 14:09:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org My primary division ('this thing' and 'the other thing') is - - client/app talking to printing subsystem (thing #1) - printing subsystem talking to printing device (thing #2). It is not a submission/end-user vs. admin/managment. Bits of these issues live in both of the interfaces above. Note that I am not necessarily talking about 3 separate boxes, merely three separate logical entities. I beleive that any printing model that refuses to recognized the existence of printer servers or other software other than the client app is bound to ultimately break down. Note also that we should not confuse end-user experience with protocols. There does not need to be a one to one mapping between the user feature set and the protocol. For example the argument goes - the user does not distinguish between a printer and a server therefore we should only have one endpoint. Perfectly true that this is desirable from a user experience viewpoint, but that does not mean that what goes on under the hood has to be built that way. The current notifcation debate is a perfect example - we all agree that it should be possible for a user to ask for email telling him that his job has printed. This does not mean that the protocol has to support that feature, just that something has to do it. It is perfectly possible to implemnt that without any modification to the existing protocol (the client polls the printer for the job, when the job has gone the client send email to the user - I am not suggesting that this is the right solution, merely that it is a possibility). Another possibility is that a SNMP trap-like message is sent to something (we dont have a word for it in the current model) that then goes 'ahha the job is finished I must send email'. We now reach the situation that beacuse we want to send notifications one way, and because we want the user to get email , then all notifications should go via email, and this is what the protocol should say. So we effectively have a proposal to replace SNMP traps by human readable email. This going from one extreme to another. Now if somebody wants to have a separate debate about writing a really robust protocol for interfacing to printers (and I mean the real hardware not some logical abstraction) then that will suit me fine. Lets start a new track and call it, say, NLS (Not LPD and SNMP). This is what I initially wanted to do but could not persuade enough people. I dont know if thats clear or not - probably just made things more obscure :-) > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Monday, February 09, 1998 12:03 PM > To: ipp@pwg.org > Subject: IPP> Submission vs. Monitoring and Management > > I'm confused about part of the thread which was "IPP> Consensus on sending > our > drafts to the IESG". Here, Paul Moore makes a distinction between job > submission, for which, in the context of IPP, Microsoft proposed SWP... > > >I saw two problems with two , potentially different, solutions (hence my > >double vote). I rolled with what I saw as the simple solution (HTTP - > >interesting that you percieve them the opposite way round) and proposed > >something called SIMPLE web printing based on what we were building - > that > >just did job submission. That eventually evolved into what we have today. > > ... and other job related issues that could be addressed (i.e. Monitoring > and > Management). > > >Now we move on to address the issues that were lurking in the background > - > >printer discovery, feature dicsovery , configuration discovery, > managment, > >notification, flow control, peer queuing,.... (things for s/w to printer > >interface) and billing, quotas, access control, server managemnt, job > >redirection, ... (things for client to print subsystem interface). > > In that thread, Paul said: > > >The WG is DETERMINED that this will be done by one protocol - I have > >expressed (with you and others) my opionion that this is not acheiveable > >(its desirability is understandable) many times. > > I guess it could be perceived, at this juncture, that the PWG is only > interested in one, "soup to nuts", printing protocol, but I contest that > there > has been a sideband approach to job monitoring in co-development for over > two > years. > > When the SNMP Job MIB project started, we promptly acknowledged the need > for > submission standards. In late 1995, I lobbied for a job submission > "wrapper" to > encapsulate submission attributes (i.e. job submission standard) to > facilitate > monitoring via the MIB. This was ill received and it wasn't until > submission > via the Internet became an issue that we had the opportunity, finally, to > correlate the monitoring channel with submission. At first, I was > concerned > that the IPP group was going "whole hog", beyond submission, but I was > reassured that correlation with JMP was paramount (for accounting and > administration) even if the IETF had rejected the notion of a Job MIB > internet > standard. Indeed, Tom (especially), Scott, and others have done a great > job > helping see to it. > > I know there is distaste, among some, regarding the use of SNMP as it > relates > to print jobs. Most of the criticism relates to the unreliable nature of > UDP > and the lack of registration and trap direction. SNMPv3 begins to address > these > issues and SENSE goes even farther, with the edition filter. While most of > the > IPP people go home Thursday night, there are a substantial number who have > remained for the Friday JMP meeting. Most of the interested parties have > indicated that their private implementations or prototypes of the standard > have > ALL resorted to some proprietary event mechanism (i.e. Job Traps) to get > the > job done. Standardization of job traps is on the Austin agenda. > > So, when I hear the statement > > >The problem is that nobody wants to do the other thing! > > I'm wondering: > > A. What is the other thing? > B. Is this really true? > > If the other thing is a side band for job monitoring and management, > correlated > with the submission protocol in terms of objects and attributes, then I > think > there ARE people in the PWG who have demonstrated their desire to do it. > AND, I > think the common point between submission and effective monitoring is > clearly > NOTIFICATION! > > Harry Lewis From ipp-owner@pwg.org Mon Feb 9 18:58:55 1998 Delivery-Date: Mon, 09 Feb 1998 18:58:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02409 for ; Mon, 9 Feb 1998 18:58:54 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05490 for ; Mon, 9 Feb 1998 19:01:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16888 for ; Mon, 9 Feb 1998 18:58:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 18:37:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12259 for ipp-outgoing; Mon, 9 Feb 1998 17:10:27 -0500 (EST) From: don@lexmark.com Message-Id: <199802092210.AA08833@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Ipp@pwg.org, Pwg@pwg.org, Carterk@Us.Ibm.Com, Harryl@Us.Ibm.Com Date: Mon, 9 Feb 1998 17:09:40 -0500 Subject: IPP> Re: PWG> Austin Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org That should be violent OBJECTIONS. Violent objects will be later. Don To: ipp%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com, carterk%us.ibm.com@interlock.lexmark.com, harryl%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: PWG> Austin Agenda I would like to proposed the UPD group meet on Tuesday evening. Any violent objects? Keith, can we have the room in the evening? Thanks! Don ---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM --------------------------- From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM To: Don Wright@Lexmark cc: paulmo%microsoft.com@interlock.lexmark.com bcc: Subject: Austin Agenda Don, what about Universal Print Driver on the agenda? >PWG MEETING AGENDA > >Here is the agenda proposed by Don Wright: > >Monday (3/2), Tuesday (3/3): > -- 1394 Printing >Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing >Wednesday (3/4) PM: > -- IPP >Thursday (3/5): > -- IPP >Friday (3/6): > -- Finisher > -- Job MIB Traps I have in my PWG minutes (moments from issuing) that Paul was to provide a sample (or spec) in prep for a discussion in Austin. Am I wrong? We could try to fit this in with PWG overview / NC Print or even squeeze it into Tuesday for those willing to endure the overlap with P1394. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Feb 9 19:53:21 1998 Delivery-Date: Mon, 09 Feb 1998 19:53:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA02702 for ; Mon, 9 Feb 1998 19:53:20 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05643 for ; Mon, 9 Feb 1998 19:55:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18859 for ; Mon, 9 Feb 1998 19:53:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 19:40:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15387 for ipp-outgoing; Mon, 9 Feb 1998 18:41:42 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC239@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Harry Lewis'" Cc: ipp@pwg.org Subject: RE: IPP> Submission vs. Monitoring and Management Date: Mon, 9 Feb 1998 15:41:02 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org #1 > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Monday, February 09, 1998 3:43 PM > To: Paul Moore > Cc: ipp@pwg.org > Subject: RE: IPP> Submission vs. Monitoring and Management > > If either, > > >My primary division ('this thing' and 'the other thing') is - > >- client/app talking to printing subsystem (thing #1) > >- printing subsystem talking to printing device (thing #2). > > Which would you charactize IPP as, today. > > Harry Lewis - IBM Printing Systems > > > > > paulmo@microsoft.com on 02/09/98 03:24:52 PM > Please respond to paulmo@microsoft.com @ internet > To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus > cc: > Subject: RE: IPP> Submission vs. Monitoring and Management > > > My primary division ('this thing' and 'the other thing') is - > - client/app talking to printing subsystem (thing #1) > - printing subsystem talking to printing device (thing #2). > > It is not a submission/end-user vs. admin/managment. Bits of these issues > live in both of the interfaces above. > > Note that I am not necessarily talking about 3 separate boxes, merely > three > separate logical entities. > > I beleive that any printing model that refuses to recognized the existence > of printer servers or other software other than the client app is bound to > ultimately break down. > > Note also that we should not confuse end-user experience with protocols. > There does not need to be a one to one mapping between the user feature > set > and the protocol. > > For example the argument goes - the user does not distinguish between a > printer and a server therefore we should only have one endpoint. Perfectly > true that this is desirable from a user experience viewpoint, but that > does > not mean that what goes on under the hood has to be built that way. > > The current notifcation debate is a perfect example - we all agree that it > should be possible for a user to ask for email telling him that his job > has > printed. This does not mean that the protocol has to support that feature, > just that something has to do it. It is perfectly possible to implemnt > that > without any modification to the existing protocol (the client polls the > printer for the job, when the job has gone the client send email to the > user > - I am not suggesting that this is the right solution, merely that it is a > possibility). Another possibility is that a SNMP trap-like message is sent > to something (we dont have a word for it in the current model) that then > goes 'ahha the job is finished I must send email'. > > We now reach the situation that beacuse we want to send notifications one > way, and because we want the user to get email , then all notifications > should go via email, and this is what the protocol should say. So we > effectively have a proposal to replace SNMP traps by human readable email. > This going from one extreme to another. > > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a > new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. > > I dont know if thats clear or not - probably just made things more obscure > :-) > > > > -----Original Message----- > > From: Harry Lewis [SMTP:harryl@us.ibm.com] > > Sent: Monday, February 09, 1998 12:03 PM > > To: ipp@pwg.org > > Subject: IPP> Submission vs. Monitoring and Management > > > > I'm confused about part of the thread which was "IPP> Consensus on > sending > > our > > drafts to the IESG". Here, Paul Moore makes a distinction between job > > submission, for which, in the context of IPP, Microsoft proposed SWP... > > > > >I saw two problems with two , potentially different, solutions (hence > my > > >double vote). I rolled with what I saw as the simple solution (HTTP - > > >interesting that you percieve them the opposite way round) and proposed > > >something called SIMPLE web printing based on what we were building - > > that > > >just did job submission. That eventually evolved into what we have > today. > > > > ... and other job related issues that could be addressed (i.e. > Monitoring > > and > > Management). > > > > >Now we move on to address the issues that were lurking in the > background > > - > > >printer discovery, feature dicsovery , configuration discovery, > > managment, > > >notification, flow control, peer queuing,.... (things for s/w to > printer > > >interface) and billing, quotas, access control, server managemnt, job > > >redirection, ... (things for client to print subsystem interface). > > > > In that thread, Paul said: > > > > >The WG is DETERMINED that this will be done by one protocol - I have > > >expressed (with you and others) my opionion that this is not > acheiveable > > >(its desirability is understandable) many times. > > > > I guess it could be perceived, at this juncture, that the PWG is only > > interested in one, "soup to nuts", printing protocol, but I contest that > > there > > has been a sideband approach to job monitoring in co-development for > over > > two > > years. > > > > When the SNMP Job MIB project started, we promptly acknowledged the need > > for > > submission standards. In late 1995, I lobbied for a job submission > > "wrapper" to > > encapsulate submission attributes (i.e. job submission standard) to > > facilitate > > monitoring via the MIB. This was ill received and it wasn't until > > submission > > via the Internet became an issue that we had the opportunity, finally, > to > > correlate the monitoring channel with submission. At first, I was > > concerned > > that the IPP group was going "whole hog", beyond submission, but I was > > reassured that correlation with JMP was paramount (for accounting and > > administration) even if the IETF had rejected the notion of a Job MIB > > internet > > standard. Indeed, Tom (especially), Scott, and others have done a great > > job > > helping see to it. > > > > I know there is distaste, among some, regarding the use of SNMP as it > > relates > > to print jobs. Most of the criticism relates to the unreliable nature of > > UDP > > and the lack of registration and trap direction. SNMPv3 begins to > address > > these > > issues and SENSE goes even farther, with the edition filter. While most > of > > the > > IPP people go home Thursday night, there are a substantial number who > have > > remained for the Friday JMP meeting. Most of the interested parties have > > indicated that their private implementations or prototypes of the > standard > > have > > ALL resorted to some proprietary event mechanism (i.e. Job Traps) to get > > the > > job done. Standardization of job traps is on the Austin agenda. > > > > So, when I hear the statement > > > > >The problem is that nobody wants to do the other thing! > > > > I'm wondering: > > > > A. What is the other thing? > > B. Is this really true? > > > > If the other thing is a side band for job monitoring and management, > > correlated > > with the submission protocol in terms of objects and attributes, then I > > think > > there ARE people in the PWG who have demonstrated their desire to do it. > > AND, I > > think the common point between submission and effective monitoring is > > clearly > > NOTIFICATION! > > > > Harry Lewis > > > From ipp-owner@pwg.org Mon Feb 9 19:53:25 1998 Delivery-Date: Mon, 09 Feb 1998 19:53:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA02707 for ; Mon, 9 Feb 1998 19:53:25 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05646 for ; Mon, 9 Feb 1998 19:56:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18877 for ; Mon, 9 Feb 1998 19:53:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 19:41:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15916 for ipp-outgoing; Mon, 9 Feb 1998 18:46:46 -0500 (EST) Message-Id: <3.0.1.32.19980209154547.00c8f100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Feb 1998 15:45:47 PST To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input for FAQ] In-Reply-To: <5030100016970070000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 14:06 02/02/1998 PST, Carl Kugler wrote: >Attributes with type 4 keywords also allow the 'name' attribute syntax for >administrator defined names. Keywords SHALL be in U.S. English, but attributes >that are indicated to have the 'name' attribute syntax also automatically have >the 'nameWithLanguage' attribute syntax. > >So in general, attributes with type 4 keywords can use the Language Override >Mechanism? Correct, but because the 13 attributes that have 'type 4 keyword' data type, also have the 'name' data type: +-------------------+----------------------+----------------------+ | job-hold-until | job-hold-until- |job-hold-until- | | (type4 keyword | | default | supported | | name) | (type4 keyword | |(1setOf | | | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ | job-sheets | job-sheets-default |job-sheets-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ +-------------------+----------------------+----------------------+ | media | media-default | media-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| | | | | | | | media-ready | | | |(1setOf | | | | type4 keyword | name)| +-------------------+----------------------+----------------------+ not just because they have the 'type 4 keyword' data type. But we thought that if an administrator is making up names (which is what type 4 keywords are), that an implementation may want to be simple and treat them as names in the language that the administrator is using or may want to be more complex and allow the administrator to define keywords that clients can localize into various languages. Sounds like something for the FAQ: Why are there attributes that have both 'type4 keyword' and 'name' (and hence 'nameWithLanguage) data types? Tom > > -Carl > > From ipp-owner@pwg.org Mon Feb 9 19:54:02 1998 Delivery-Date: Mon, 09 Feb 1998 19:54:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA02716 for ; Mon, 9 Feb 1998 19:54:01 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05649 for ; Mon, 9 Feb 1998 19:56:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18961 for ; Mon, 9 Feb 1998 19:53:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Feb 1998 19:42:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14937 for ipp-outgoing; Mon, 9 Feb 1998 18:38:00 -0500 (EST) From: Harry Lewis To: Cc: Subject: RE: IPP> Submission vs. Monitoring and Management Message-ID: <5030300017742664000002L042*@MHS> Date: Mon, 9 Feb 1998 18:42:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA02716 If either, >My primary division ('this thing' and 'the other thing') is - >- client/app talking to printing subsystem (thing #1) >- printing subsystem talking to printing device (thing #2). Which would you charactize IPP as, today. Harry Lewis - IBM Printing Systems paulmo@microsoft.com on 02/09/98 03:24:52 PM Please respond to paulmo@microsoft.com @ internet To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Subject: RE: IPP> Submission vs. Monitoring and Management My primary division ('this thing' and 'the other thing') is - - client/app talking to printing subsystem (thing #1) - printing subsystem talking to printing device (thing #2). It is not a submission/end-user vs. admin/managment. Bits of these issues live in both of the interfaces above. Note that I am not necessarily talking about 3 separate boxes, merely three separate logical entities. I beleive that any printing model that refuses to recognized the existence of printer servers or other software other than the client app is bound to ultimately break down. Note also that we should not confuse end-user experience with protocols From ipp-owner@pwg.org Tue Feb 10 11:22:45 1998 Delivery-Date: Tue, 10 Feb 1998 11:22:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA22384 for ; Tue, 10 Feb 1998 11:22:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07658 for ; Tue, 10 Feb 1998 11:25:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA23472 for ; Tue, 10 Feb 1998 11:22:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 11:11:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA22499 for ipp-outgoing; Tue, 10 Feb 1998 10:52:36 -0500 (EST) From: don@lexmark.com Message-Id: <199802101552.AA14682@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 10 Feb 1998 10:51:46 -0500 Subject: IPP> XML 1.0: W3C Recommendation; XML Activity Update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org For those of you not on the W3C mailing list, here's a couple of relevant snips: >From Tim Berners-Lee, Director W3C: > I am pleased to announce that the Membership voted in favor of the > Proposed Recommendation of 8 Dec 1997, and I hereby endorse > xtensible Markup Language (XML) 1.0 as a W3C Recommendation. > > All the votes were "yes" votes, some with comments. The editors have > responded to the comments; some of the comments were incorporated in > the specification; for details see the comments by the editors. The > remaining comments have been taken into account in planning new work. > Members should be aware of the future paths we expect for the > evolution of XML technology. ... > > A proposal has been made to start work on > a new schema language for XML to provide and enhance DTD > functionality. There has also been a related submission > (http://www.w3.org/Submission/1998/01/ ) (XML Data Schemas). > The relationship between the roles of XML level > (structural) schemas and RDF level (semantic) schemas is not yet > clear. A Briefing Package will be circulated to Members about the > extension of the scope of the XML activity; this will allow discussion > of the implications by the Membership. Seems to me that the work mentiones in the XML Data Schemas might be of interest to the group. The XML Data submission might be in a members-only area. (I can't tell because I have access) On the Microsoft site, there is also a copy of the XML Data submission at http://www.microsoft.com/standards/xml/xmldata-f.htm although I can't be sure they are the same. Don From ipp-owner@pwg.org Tue Feb 10 12:07:20 1998 Delivery-Date: Tue, 10 Feb 1998 12:07:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23390 for ; Tue, 10 Feb 1998 12:07:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07883 for ; Tue, 10 Feb 1998 12:09:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24469 for ; Tue, 10 Feb 1998 12:07:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 11:54:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23543 for ipp-outgoing; Tue, 10 Feb 1998 11:24:13 -0500 (EST) From: Roger K Debry To: Subject: IPP> Notification Requirements Message-ID: <5030100017270909000002L092*@MHS> Date: Tue, 10 Feb 1998 11:22:28 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100017270909" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100017270909 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have taken a pass at writing down a set of notification requirements.= They are in the PDF file attached to this note. I'd be glad to take comments and suggestions and turn this into a formal requirements document, if you all feel that this would be useful. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 = --Boundary=_0.0_=5030100017270909 Content-Type: application/octet-stream; name=notify.pdf Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTEyIDAgb2JqDTw8DS9MZW5ndGggMTMgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0cjAQDcYDgXDIaCAQFQiA2DRMQHIziAGi8jQYYjKHFQz RKPmMQQaHncQCgpGU4nU0nIym0ym46HMQFM6GE6TGZnQQGY3nIQEkoFAQE43nQ0mY0mOdGk3m4Uw 81SIWjIbC6Gw8iCCNQYci6Ox+Qi0YC6EjQayOUlMxm84GWplSqwarjIXDiP12NDEQDGzwmyRK0DA a2uHyTAjAZjaPygUFQ0GUQHO33EQG8zCA6Gg0zaYS2XzyaTY5zmdzKaCDPz+giCZmQQHU5mU5HMX Q4gmzOm86mc0awyT2mmE2CCZGM0GE3Z82zY2mE8iAxZTh0w3GUyXO6iAW2OuSXCjWtlTFYUZjfHy mgUI3Uml8WlVGbe0QGEyG0083TnKdKCmzXrg2z/tuFjOM80zUNInwyDeMqbPenz8DImA5pszsIMo OQ3jZCAXO4Br0rwGi9JMiCvI2ECwvAkCRMS8SEhs8rIIdEIWxGrS9LuFwZo88KzLQGIbMdGETsgK jbP0942DeM48xCuwZLwvTwr6v7AyrFzFhqv0jMLGiUiSnzWuyMcIDmMI5OmOg3hA679soMLKjKnz NM5JSbP2zI5OGoU2upOQxQ8zk3DHD01DY6YyjwOELQwyaKpYlyYNUmrXDlKLvRarrFhtLzzRixj1 hRCT4qc+Y3ToOQ7KbCD71UoijCmPLTpjECqKshiFvKvgjI8wC0S0kMuLYxYaR+KjICUN4xJuOoxP 0OilDci4ijc2QqtqOQdRCGKO2Ekq9xSv1gsEh9iPHZLzhgxgc1I3QQDQOro1U2LZ22EA7jRNw52h aSbTnRz9p8NVm0LWChqKEAoDlgjbNyyTWri26oxvb68ME79k068by3Yxj1JOlLoum1+ShBCVA30N LOz3DLKjCmU6DGOuHDo6cHOjPYw0gymG4eOWIwSEGKDmqLkOlPmkunlTq01jdx2PkVQ2PMIUDOMs nP8ODPKcNlFZSMs1QQymBppiGoV2hlxo1YEssHqdjTBq9mWcKd/5baiLiCOA4DY+SoDcHQQW9Xcf XFKwjXLuF0MJdsS7nyAZ1IINVDDv3AVRwQQC4FD7UZmW/zk6idOU+/M8CqIuBTA4wjHvbM1U6rlj Yzc7uZi/Do9qLwy5j9RPTUl7to20D32prg39aOW4DouHNXg1nUA5mFKNoG0aEh9I8xv/VVVlGT6V pzKDvlrPVVmE0plqFOVExGqzBUDINrmub5yN+d8vn2Gegnb2mJMBdS5tpD4ShMofICBrLW3MNeOM 2E7LZGYNnf+rguiugaK8bar9LC4XHLHXWqIGi72RgoCmGV+zLTphEfyGE/bhEQg3RNBtxkHktnjf gyAxqpAjGvgmzYOAbzaoBM2y4mwZDPs1Qu4JA76k6mZM2dkOgdyghrBAW8NsQTsmlX0144JTipK5 BbDJTbHIRPAWOloyEWA2h1Oaqh8r5zfE+DOG8/ZFzOocN+cFgSHA8MmKEUwmAd4Hm5CCzRm0Kk3w tT2yg6sCmtBna5A5sB0w7G2Sgrkuz7nfuSMZGolIbE1NZQO6APDolCAtVgHlv7r44suViEIJoLgh hPlm2qDLbHFNvhsulyCWmQA0cpCVWQIAhuAJ7DBXINSzg4hm4qGq54brtBrMB4Mw1lEpe2ZRo4Zo ppqMpFiLRPXZNlivMg1Yc1ampi68k1kWUPKWf5MVRxSQ3lvDZBYqoLZmF5R22tXqKZeTSl8DAGka EwNUWWwclYYw0hwDST1EINSw0GcSihK65lhuPMNCR+K7XEQlcJIdea9YupuNazAOpvA0nRJ3Fc+i 9DbRQnNBQED0jchJfAcw6ZTohoINa+ZsDK0Mo3ooWghrvUUSdS/SChRKX1tmNs0d/c5m7LPeYtOO 4IFrrZW2gcMQdSfRGbEdplJST7hskIrWoikafBlNzD0oToZ4BlQOUsoa+C5SajK1I8cnlkKkmKoC myc0HM1UtOWPrQTWOXOobROKF2ipqDodlTMYi8AzByDVqhilSBcSmDJKLHpPPChLEQpiZ0DhJPuG 2qzB28VZdjV0EC2njIhCoCp99CKnKkeQoSCdU2kWsYetic1h6ZGrPtI06dYQ52RJsHCyllkb2Zs3 Z2i5kLQJTtGu0G0ITFgyo8/SKFqTKUpUjVehtD6Ik0NyTc/aZ3ZV7gvbmEVHpgrJMgndmEdTjREe saxDCbpHhhUGZSwj/mxQSUjSspVLkNwovZOS/ikYKVmjmHCsTx3ym+DYdtXN9kuXgPReMlJ7w5HR kqbBRsKKx3poZhKiE5FASPZepGqMiH7yLf0fcObrrjQLklA04uK4Ip/Mnbi3VTKPshVI9iCoIAkB vDuGWS4comtEgRWg41aybSPZhW+uJr66OjtWZVvKE3nsEpuwd16HLJMwp0/+KShclPBmslybBkE5 wxIXRdjrkFjKkCWfsNYb7qo9uuWwFF27RSatJU3J1p81zpX4HCnNrTqFJOCzC2K0nYr3tsUI5hsm YXqxle0OlYKxV5Zk2J89M8j1nsvBeMef6laBo7aW/RKcbzcZlNyFEiWcY8hdVVmGUG018KvLmgLb oO0Eo5abJp5FSaoodjM1bDQ3x/mVBcHKVJn0YcXtGjeTIdSgBRIdozSHXuxaQ7Q4zt4i4wWdevbQ dL306smHIpTNZRZYtfvfVNEoxbhn9X13x41QTBfmSnbkf2ihoVrkVsNEAxhrJsHUOFNX/VmuRYkM yHLXbJ4/wKvGp8Y7Z1VFc5jKmKHt5KcsOj7S8S6qXwywCpAzRudg4JobP4/HTNaiHhEztAUC3M3F MF+IRa9BQGJnIZTsMtcFRODLkUTq+mjuddXO4SyQgY13izTWx6kuNr9mLM367Efxj1nvHmgz6Aad 8GgN0emO1zCKHMIkizZBRXLFkqK7V5eWtI++lWCsH5G/leT+cEYEbNx82W7vFUzJ0vqKtOdE2as5 oOEujru0Guw1ZUhsnABrMoG06b9SYE5TXnbZknK/6SBpw8FHGIrcc7k9HN1xsNJkTs+DqYcw105f S0St6B9XWu3fVvuIYtOAgqvp9vVW7aajVhiC+uS4cWl7/QvgnLCem5Cb62FHr01dEYDz9auPjkHT 4iHnuiUtnQboH16X9gGrhFkuNW3w1URCBsIURm6SoycammMM4ahEVIpGDcZMDMcI+qzStmuM1GQP Aotkq2b6e8gIDdAy5WwmJoQONebsRvAIBdAM72xGtKxMJU4K226G/qO8oA/w6Wg+TAmwmC3U/8nJ ACnICCayJoW6VyMALOcQ62XJBxAUBqxIpBBeBA3YQ4yGtceQdOJgTODSkuJsysJ6QCdmDKdq3onN C8NXCzBG30m2PvCGJ8ZKYuXaR6d49omot40m8AJy9UMq8gPu5+aQ3jDE3mpoZhDQ3ylKKCkIT7DK /+rGTdEJBiJ8VaTmaOZmOMzoKekuOQbGDcDm5sr8/29sz2JSc8lM8IQOukaynNEK1UdZBKKEJaDK DqwQUjDMJ8PslEf+UkDoYcysOMOoTYUjFW/Klwg0l3CYoKoOsAqeBQKQKUtSKeaRB8NLCKguBwBq K0IbCVAQl6o47usAfgRqctAicIeenuTQjuBaNOLgLiDIQOjATOQ9HaPu+k38O1FcpgrqJ2DI7oCK IGICDWVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNMjcxOQ1lbmRvYmoNNCAwIG9iag08PA0vVHlw ZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0v RjEgOCAwIFIgDS9GMiAxMCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxMiAw IFINPj4NZW5kb2JqDTE1IDAgb2JqDTw8DS9MZW5ndGggMTYgMCBSDS9GaWx0ZXIgL0xaV0RlY29k ZSANPj4Nc3RyZWFtDQqAEIqA0cjAQDcYjAXDEbCAQFQiA2DRMQHIziAGi8jDIQQkXDAcQ4qGaJR8 YDQaSIxiCFDCTjeRHcQCgkm02mUyGkwnQyiAnG86GkzGkxzs0m83CmHmqCDkXDOGwaHkQQRoYx2W yGHySWjAa1oqSuujOUw+ZCgdT6gUKiUakHMQHMym46CA6G+7GiemU7XO6nIymM0nA034QG85Xm93 26RXA4PC3SlFSmC0ZU8cjWYQ+xTGZlwZaHJ0yujUcyqWSYZxyzTO4GEz4Y0m64nUxmgQGHRg0Wjm nVAQC0Y6yIamXDWG5zjDAZjXPCg7mE83md4oQXzDGE5HI0324GmbTidTw2HkXbuDZYaC4ZWXixqO R6QSKuaqwWKTDUZ88iGU2OknC1KCoaiqCpAdN2HIYhclCWJEqirKwj6wPq47UK6GirtaFEBLZAqj jcuA7jQojcO0no3KAEDwJunKdjKFwQCKNowjSNgQDuN46jYMgQDEnowtoMo8DCNo4DYno3jM3IQD I/0ADI3bewXBrhOIqiuhs4jOw3FMBrbAw3POpaJOC9r2PdCCNwk+atpKlwaOSsLlho50NiQOsaNo Ia3zyMIxSRDsCLcN0ETIGMGqk94jKu+UKTer0tuWGbTw3QUwRBEUSNu3LARWui5ydHq7x8noxz7F sfOmNE/SEN0ejquQ5DnKVEJTK00Qeqs10c+lIBm+8HQ2pDyt2GIcVzRU1UarNfNK9z8JdYDnxiKi 9OnU66Rq2kUhBGjbtmnrADCMk/0DYwaBuFyo11DFgww/cNrnU6cjcM64SU6zsLpGMZxrG8cx3Hsf tzIUiSNQN8jCEE8T1WobBqFwcVu4d2vyzc5rG9yz2yOc/UBFC10HMMxspMr1VyqddvjZs3QxO2Mp NOLniaMNwDcns+RDj9Ap/L8PwPdCnBvdmVQjXuXZlSuYzg4iz0voEQxxTcTU82aeVfAIzMQEGOzy OEw1VJg4DkN4zjlIoWVqGmhobK2LOPd7VXiKiz49Tgwte2gkigKAQCGNjIjpGOa5vnNUXNkOf0Iu EaOmMI2DmvFsjpbYQVZPTHXJxNP62OUaZI9EzBm9iwTUgynYrpIYWPaFhbqmYpDKOI6jSwCbrpWk yPS0OJV1o+WpHSGZuVDE5LPBaHWMkNlOXmFopPDXYBQIIQCUN4xBAKY6jENo0jooN7RlV4QCrWVv ViuuCc5Ug5jgx4zOmPQy7Kw7EjaxDFsMwDBMIvymi5m1e6998JFzdO7OC6o4ppXpPQY2TNsjVwQB qewyUyqx4EpXTonKBzxyZmXeUod5jcCvQNToc8K5ejaPufgHk2cBkhGML+Y9/xdAWJMeu9l7cA3w QvfGj18z9H0BzfUkBkBdi8QsME/Ew7OH7Lefy6Jt7KjStyWk3Qs6XkPKEOvDIuDnjqF1X3DN/rgo LG8gxFOBbMoOQbOe6SELJoMPNWehc1TGCzwpgDEooULnxJBi6/uGjgobh0L09Z7D2nuPeh6+IIr5 Igv3fSqU3MR32vviWdMMr3y9ByilApLB+VJFjaWWdFh4kXxPScf8PKAYtMjRACCMEhjqxjMdGUvy MSHokcadKSiQ0jlEe/Ddrh4JgoBDEdOQwZTdhUBU86OycHpFnJvIYN6PV8yrO6/RbAaA3lyNpMk6 0OZFQ8gLD98qsoznCJDGqUKcI2vGOeeuOJTI5wkP1NE5hYI8wqLjJiPsPmFyvUwUiQMNocSJh3Iy c8j4gPnDbJN9clok0AiZLQusFAxAtk/BpLM+jVnPiIi8Fq43JNSYJOAurkCkEXDvJw61BGow3RHA GjFBy6hvDGGMOqs51xplBG54sbDnsRnqA2e8VD8vPUnHgmafCbUGm0X0OR05qzeDIHOG6MAzoxDK jRG0N6IxEkox4OAcDEE8DIjFvjfqXhsRul5JoZShxOe+vgO63GRUFKTAidydITGlOfVObgIGyFAp 0G8NlP521BnlUOeBzwbS6eW6+d8JZ9QPBQtZ+hPQ0lwW6YB2jtqvmGlnIetoIAoHcVAYl/kmw7Q+ mXYa1kM3aBlrIqQOzkA0rlJ4da3pfnvnTYVX1kx6bHH5bo9Baa8oZS3MgX6G6KTE2zT+ja4Zh0l2 zDmHmIlX4kVzcDVRgtOLw03f5dExreTHW3u+j0LgKHPTNmeaWUbMjnpDSKkcMsNyhL6ufemGpdbP ggrkdVHIcg1xIXKHkLgKbGQZhI8RphJ4PAoXVUepMazj33WlKUmYSA3h3OwHKG8gLU2ravEKsZdb duBt9Z4OhrwxXYDpMovFhDEyAlsrG2Uh4+FDQDjoPNHZ8TxNUzBuxt7S1sSW99Job7cYGRVWatAc i63cosYVHoc8mE3mJdXIGW0A5eL0TdFZ3w3Yvt7LJrjkib30edYG/CG6TFIkLP7KAc5vMCMc+4pC oy8WzgiY20QdbcF1pfIa8r9GymJWyTl0KZJ2OjdK78IzqCFnEJIC0loMSEIXOeFMMZcztFHd1cdM xl3TK7WYhNZ1RLIYWOe8kEFlY6H5yQtLC4STchtLjASHxs1vXEDMgRID5GPQ8bHbWCciVSaEtrEI MmIzaWzDQ5CxYINfJFU+dYOaRSelyp4dzG+RqlIW1mDRpxM9q1gNpezaWK8dvkXyqenpcobmxbM2 gOCm9tHTZwdqXWvjomNVIGtFJMpTouPIdOmptA2nT0KHTOSGGMQOs1RpHCNkbsEVOwgMtagQXxmL duTtnjX20ewkgNuD1SlFViT22e1aeO4Lrt3YGCQ1w+oNgWnpsV+bc4vUukGF9lyMOtxXZ72dFm4t m1uuGI6BPgO4GIOpPA5qGjlO1M4NNWkaP20h4QLWIgyBuDiEx6zkKIOeaAGxMNcaY1em14RpddnM yUTMItz3ZS4MaC1b0zNKVAMv2DTHY3g6d7P2ntYLu22a7h3KEVltXJsUeaWphY8Ls+i22Hvr/zgm 5rgrWxvh+whG8VrBN3Zj2eONR2wG3bkN+T1v5V5rwPWd3110c58OQW0jJ5SUMreS3+jlbqmC/p0G ep9X3bxnr+1ex8h7PyQMu4+3675b3X0FIA1w8czEAKPPSwKQC3G77/R8NPH4Rk3Zlbntwn3nChZ4 QfantCPdJJ2lwO3aJo1+RwMQ56fEDMbK2Am8zQSCy6kWygYW6Y442iyA3Eto3oNyzU6WMAtiR0Lg v05EjOuQo8PydcLGqcBQxExIqohuDmNm1K25ACwRAGhu18KKDcrk3+u8LargOmNiyykO6YKGYSMS 2qYKDykMh86eRWcG24LrBqRwRq4sTImcTo/6To/+DqLoRtBfB6vC54LywKDCDMJ4DkRSKQRjBQxL BmSkMuUoM01E9qNCBkPQZk/C72BQR6cCDWJ64mLiMCMAcqqqvCMIDGwWDqDgOsR0DoDg6yYKR7EW wIpyuMKZCmvspA/HD4ScDmwWclCUyitxEkN5DYMy4ydeLONANEd2aUsy/+LrC4DYm+pyMSWMBmIU /0w4K882NUwue8DmBbCCJwrYgE6VAe2c45CS6isVFepej+6sDS6w6064guOGd8ZQ8QaM9U8wV89c 7Q+mOU9k9oem9s7nGu7q8yuUpAn47478kGMM8FD43JD+O0yK8K+ZGsUW+eUfG29hG8+rHBFM+w8o +29yUZGydWK9BIjuOe/Kr4pwLg8E6Y5Cv4J49Mgy+a8TIK7K8bG6TnG++u+zHGUXHK1iOOuWUnHS /Ir2aiLsDy/U8E/YReN2CKIGICANZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag0yNzk5DWVuZG9i ag0xNCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0Zv bnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDS9GMiAxMCAwIFIgDS9GMyAxNyAwIFIgDT4+DS9Q cm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxNSAwIFINPj4NZW5kb2JqDTIwIDAgb2JqDTw8DS9M ZW5ndGggMjEgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0cjAQDYcDYXD QQCAqEQGwaJCA5GcQA0XkYYiAYjAXDAcQ0qGaIx8YDQbSIxiCPDCTymHHcQCgZi6GimHGoGjGQwa HESWSYajOVUGXDMcyKZCgkiAwm0QHM0nQ6Gk3RarCA2nkQG8zGY0mMy043GSonUxG2p04QHA5VY6 CA1G8xCA6G+yCAy1erGUynKnXEwm69Xw3X631cQWA5VA72M7m85GsQHepmicFSdQYWjEZSKgS0YD XPw6V6KkUqZm/CGEQGQwmk2VwxGGpHObU3InU2WY2Gk12M0X+7Xg1m43zI78PCHTh23E3G53U0nM QGM3m04GwynQyiyo3jnGG4nPnmPB22w5S1nU4ZmdFQVUbR0TTfQZyGYzMzHLsrs563Lg4isuGwAx Dq2QyKsM6bBAJK4uqEA0u0yQ6MGuLxvK545DKOw0jKmS1reM40MEO4wjy3KzrStbnLHAQ3Okuj4A a+T6BqmAqNOkwZhq1QUMs50ALGMw3jYNjkwYwI6LfBDvDmHUap4EAWhkGiFv0h4QIyoiOo/LSSBa GoXBkG4cI2+8sRyGKGP2FAuBkGwbhBKaetBLiNI4lswpKlwazdHb8S0pYijsva4ikMoxjSOEQRlK rCjOvriPJSVKMSizGDbGrOpCzoZSzPEuz3MCRTFMkzTQos1htNsgTjOc6pync7p/PKNy+kFTz80d Ax4o86TeJw3qqsD0Kq1i9UPGTrBa6C4Ou7Ltu6MtOypUFRVvUldT7McyzPNNBVbV831jOk7JZUc9 W7XjRKGorUUImdiWMsLyDTZQ6DyOCx2fCg2jLBbyWtWkxoZK1AtCkyUXjhkdKXLCb1pKifS20QaK S++MNKKilqap8JtaEA0WKMo2IoN7/sGsw5r2szXRjGa6rutk7IVK91VvjF4yAJarDWN9O1CpAa2F QU4BlpUa3fjtgBg1M3usOa7w7kUiOKO7CZAxzJDXJarPArLJDI4i72uhMy4Qz08XfcWn0CpYzu6t mZYEigyjhCzFslrGAu7JeuSZl+wOa542skN0GQcKarLFB+hhdoujtPWGlBlpmGPtQWMXmFCoDON8 ljeOsMrxBY3MOOWmSrtmdqFHWnhniCZjCMzvMApu5wyNEJOnFi1KpgTwPTgGBDTggQORe1kXywjI jdyPJ57c3L8ylwabfHEgLiMi8YCrQ6jGNAQdCN4yJsJDkw8v7wCT6Qc6N6mPJnOOl1pjmHexjX6B Q3xwCxtnVojdjD/G4MdKW+NRZ7HDFjcQHJxRigxBlSM1YpoZC3qHOK1hKYNwYguJSxZhb2H5lLZ+ G5oL8H5H3aS/czSvQawGPxAgmbU2qwBLwy4sYaQzNYLAdxkhtgQQTL2tBGTAibBBMIGUNpsQ2LXg 9CB1rHYRmjR+xtHrtAUPLh4vdZJhEJBzDqV8sKjy4wVQAhIOAdQ5N6ZciuMSLXeIwOiXIuhlTLw+ SOkkyxijyJNDSk8MqUV0sJW0ltbifFeLfVU9pcjcX6pyXQxRW0iF2SKIcSRd7sT8RXf6oZRAIFFK MUdKFZ7AW0RTkOUCRKppMgNkYuFVgLk2SQaSrJdMIlcKlV3K9d6vz8NHKWvWLrzVlPsWapFmS0jt HcO9KlbINEtSsCMl6TBI5YKplkmqWirpbLnVnC9iq61czXk0UJzbsnPTEWOvhfS/F/F6iabJGoRS BkBADWVuZHN0cmVhbQ1lbmRvYmoNMjEgMCBvYmoNMTI3MA1lbmRvYmoNMTkgMCBvYmoNPDwNL1R5 cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMSA4IDAgUiAN L0YzIDE3IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDIwIDAgUg0+Pg1lbmRv YmoNNiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YwDS9C YXNlRm9udCAvQXJpYWwsQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBb IDI4MCAzMDAgNDgwIDU2MCA1NjAgODQwIDcyMCAyNDAgMzQwIDM0MCAzODAgNTgwIDI4MCAzNDAg MjgwIDI4MCANNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDM0MCAzNDAg NTgwIDU4MCA1ODAgNjIwIA05ODAgNzAwIDcyMCA3MjAgNzIwIDY2MCA2MjAgNzgwIDcyMCAyNjAg NTYwIDcyMCA2MjAgODIwIDcyMCA3ODAgDTY2MCA3ODAgNzIwIDY2MCA2NDAgNzIwIDY2MCA5NDAg NjYwIDY2MCA2MjAgMzQwIDI4MCAzNDAgNTgwIDU2MCANMzQwIDU2MCA2MjAgNTYwIDYyMCA1NjAg MzQwIDYyMCA2MDAgMjgwIDI4MCA1NjAgMjgwIDg4MCA2MDAgNjIwIA02MjAgNjIwIDM4MCA1NjAg MzQwIDYwMCA1NDAgNzgwIDU2MCA1NDAgNTAwIDM4MCAyODAgMzgwIDU4MCA3NjAgDTc2MCA3NjAg NTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA3NjAgNzYwIDc2MCAN NzYwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDc2MCA3 NjAgNTgwIA0yODAgMzQwIDU2MCA1NjAgNTYwIDU2MCAyODAgNTYwIDM0MCA3NDAgMzgwIDU2MCA1 ODAgMzQwIDc0MCA1NjAgDTQwMCA1NDAgMzQwIDM0MCAzNDAgNTgwIDU2MCAyODAgMzIwIDM0MCAz NjAgNTYwIDg0MCA4NDAgODQwIDYyMCANNzAwIDcwMCA3MDAgNzAwIDcwMCA3MDAgMTAwMCA3MjAg NjYwIDY2MCA2NjAgNjYwIDI2MCAyNjAgMjYwIDI2MCANNzIwIDcyMCA3ODAgNzgwIDc4MCA3ODAg NzgwIDU4MCA3ODAgNzIwIDcyMCA3MjAgNzIwIDY2MCA2NjAgNjIwIA01NjAgNTYwIDU2MCA1NjAg NTYwIDU2MCA4ODAgNTYwIDU2MCA1NjAgNTYwIDU2MCAyODAgMjgwIDI4MCAyODAgDTYyMCA2MDAg NjIwIDYyMCA2MjAgNjIwIDYyMCA1NDAgNjIwIDYwMCA2MDAgNjAwIDYwMCA1NDAgNjIwIDU0MCAN XQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2NyaXB0b3IgNyAwIFINPj4NZW5k b2JqDTcgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvQXJpYWwsQm9s ZA0vRmxhZ3MgMTY0MTYNL0ZvbnRCQm94IFsgLTI1MCAtMjEyIDEyMDAgMTA1NSBdDS9NaXNzaW5n V2lkdGggMzQwDS9TdGVtViAxNTMNL1N0ZW1IIDE1Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0 IDkwNQ0vWEhlaWdodCA0NTMNL0FzY2VudCA5MDUNL0Rlc2NlbnQgLTIxMg0vTGVhZGluZyAxNTAN L01heFdpZHRoIDEwMDANL0F2Z1dpZHRoIDQ3OQ0+Pg1lbmRvYmoNOCAwIG9iag08PA0vVHlwZSAv Rm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvVGltZXNOZXdSb21h bg0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI2MSAzMzMgNDA0IDUwMCA1 MDAgODMzIDc2MSAxOTAgMzMzIDMzMyA1MDAgNTcxIDI2MSAzMzMgMjYxIDI4NSANNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI4NSAyODUgNTcxIDU3MSA1NzEgNDI4IA05 MjggNzE0IDY0MiA2NjYgNzE0IDYxOSA1NDcgNzE0IDY5MCAzMzMgMzgwIDcxNCA1OTUgODgwIDcx NCA3MTQgDTU0NyA3MTQgNjQyIDU0NyA2MTkgNjkwIDcxNCA5MjggNzE0IDcxNCA1OTUgMzMzIDI2 MSAzMzMgNDc2IDUwMCANMzMzIDQ1MiA0NzYgNDI4IDUwMCA0MjggMzA5IDUwMCA1MjMgMjg1IDI2 MSA1MDAgMjg1IDc4NSA1MjMgNDc2IA01MDAgNTAwIDM1NyAzODAgMjg1IDUwMCA0NzYgNjkwIDUw MCA0NTIgNDUyIDQ3NiAxOTAgNDc2IDU0NyA3ODUgDTc4NSA3ODUgNTcxIDU3MSA1NzEgNTcxIDU3 MSA1NzEgNTcxIDU3MSA1NzEgNTcxIDU3MSA3ODUgNzg1IDc4NSANNzg1IDU3MSA1NzEgNTcxIDU3 MSA1NzEgNTcxIDU3MSA1NzEgNTcxIDU3MSA1NzEgNTcxIDc4NSA3ODUgNTcxIA0yNjEgMzMzIDUw MCA1MDAgNTAwIDUwMCAxOTAgNTAwIDMwOSA3NjEgMjYxIDUwMCA1NzEgMzMzIDc2MSA1MDAgDTQw NCA1NDcgMzA5IDMwOSAzMDkgNTQ3IDQ1MiAyNjEgMzA5IDMwOSAzMDkgNTAwIDc2MSA3NjEgNzYx IDQyOCANNzE0IDcxNCA3MTQgNzE0IDcxNCA3MTQgOTA0IDY2NiA2MTkgNjE5IDYxOSA2MTkgMzMz IDMzMyAzMzMgMzMzIA03MzggNzE0IDcxNCA3MTQgNzE0IDcxNCA3MTQgNTcxIDcxNCA2OTAgNjkw IDY5MCA2OTAgNzE0IDU3MSA1MDAgDTQ1MiA0NTIgNDUyIDQ1MiA0NTIgNDUyIDY2NiA0MjggNDI4 IDQyOCA0MjggNDI4IDI4NSAyODUgMjg1IDI4NSANNTAwIDUyMyA0NzYgNDc2IDQ3NiA0NzYgNDc2 IDU0NyA0NzYgNTAwIDUwMCA1MDAgNTAwIDQ1MiA1MjMgNDUyIA1dDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciA5IDAgUg0+Pg1lbmRvYmoNOSAwIG9iag08PA0vVHlw ZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuDS9GbGFncyAzNA0vRm9u dEJCb3ggWyAtMjUwIC0yMTYgMTExNSAxMDQwIF0NL01pc3NpbmdXaWR0aCAzMzMNL1N0ZW1WIDcz DS9TdGVtSCA3Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDg5MQ0vWEhlaWdodCA0NDYNL0Fz Y2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01heFdpZHRoIDkyOQ0vQXZnV2lk dGggNDAxDT4+DWVuZG9iag0xMCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5 cGUNL05hbWUgL0YyDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbixCb2xkDS9GaXJzdENoYXIgMzIN L0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjYxIDMzMyA1NDcgNTAwIDUwMCAxMDIzIDgzMyAyODUg MzMzIDMzMyA1MDAgNTcxIDI2MSAzMzMgMjYxIDI4NSANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgNTcxIDU3MSA1NzEgNTAwIA05MjggNzE0IDY5MCA3MTQg NzE0IDY2NiA1OTUgNzg1IDc4NSAzODAgNTAwIDc4NSA2NjYgOTUyIDcxNCA3ODUgDTU5NSA4MDkg NzE0IDU0NyA2NjYgNzE0IDcxNCAxMDAwIDcxNCA3MzggNjY2IDMzMyAyODUgMzMzIDU3MSA1MDAg DTMzMyA1MDAgNTQ3IDQ1MiA1NDcgNDUyIDMzMyA1MDAgNTQ3IDI4NSAzMzMgNTcxIDI4NSA4MDkg NTQ3IDQ3NiANNTQ3IDU0NyA0NTIgMzgwIDMzMyA1MjMgNDc2IDcxNCA0NzYgNTAwIDQ1MiA0MDQg MjE0IDQwNCA1MjMgNzg1IA03ODUgNzg1IDU3MSA1NzEgNTcxIDU3MSA1NzEgNTcxIDU3MSA1NzEg NTcxIDU3MSA1NzEgNzg1IDc4NSA3ODUgDTc4NSA1NzEgNTcxIDU3MSA1NzEgNTcxIDU3MSA1NzEg NTcxIDU3MSA1NzEgNTcxIDU3MSA3ODUgNzg1IDU3MSANMjYxIDM1NyA1MDAgNTAwIDUwMCA1MDAg MjE0IDUwMCAzNTcgNzM4IDMwOSA1MDAgNTcxIDMzMyA3MzggNTAwIA00MDQgNTQ3IDMwOSAzMDkg MzMzIDU3MSA1NDcgMjM4IDMzMyAzMDkgMzMzIDUwMCA3NjEgNzYxIDc2MSA1MDAgDTcxNCA3MTQg NzE0IDcxNCA3MTQgNzE0IDEwMDAgNzE0IDY2NiA2NjYgNjY2IDY2NiAzODAgMzgwIDM4MCAzODAg DTcxNCA3MTQgNzg1IDc4NSA3ODUgNzg1IDc4NSA1NzEgNzg1IDcxNCA3MTQgNzE0IDcxNCA3Mzgg NjE5IDU0NyANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNzE0IDQ1MiA0NTIgNDUyIDQ1MiA0NTIg Mjg1IDI4NSAyODUgMjg1IA01MDAgNTQ3IDQ3NiA0NzYgNDc2IDQ3NiA0NzYgNTQ3IDUwMCA1MjMg NTIzIDUyMyA1MjMgNTAwIDU0NyA1MDAgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0Zv bnREZXNjcmlwdG9yIDExIDAgUg0+Pg1lbmRvYmoNMTEgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNj cmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbixCb2xkDS9GbGFncyAxNjQxOA0vRm9udEJC b3ggWyAtMjUwIC0yMTYgMTIyOSAxMDQwIF0NL01pc3NpbmdXaWR0aCAzMzMNL1N0ZW1WIDEzNg0v U3RlbUggMTM2DS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgODkxDS9YSGVpZ2h0IDQ0Ng0vQXNj ZW50IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFkaW5nIDE0OQ0vTWF4V2lkdGggMTAyNA0vQXZnV2lk dGggNDI3DT4+DWVuZG9iag0xNyAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5 cGUNL05hbWUgL0YzDS9CYXNlRm9udCAvU3ltYm9sDS9GaXJzdENoYXIgMzANL0xhc3RDaGFyIDI1 NQ0vV2lkdGhzIFsgNTk1IDI2MSAzMzMgNjkwIDQ3NiA1NDcgODMzIDc4NSA0NTIgMzMzIDMzMyA1 MDAgNTQ3IDIzOCA1NDcgMjYxIA0yODUgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDI4NSAyMzggNTQ3IDU0NyA1NDcgDTQ1MiA1NzEgNzE0IDY2NiA3MzggNjE5IDYxOSA4 MDkgNTk1IDczOCAzMzMgNTk1IDczOCA2OTAgOTA0IDcxNCANNzE0IDc4NSA3MzggNTcxIDYxOSA1 OTUgNjY2IDQyOCA3ODUgNjkwIDgwOSA2MTkgMzMzIDg1NyAyNjEgNjY2IA01MDAgNDc2IDYxOSA1 OTUgNTk1IDU5NSA5NzYgNTAwIDc2MSAxMDQ3IDU5NSA2OTAgNTcxIDc2MSA3ODUgNTk1IA01OTUg NTk1IDU5NSA1OTUgNTk1IDcxNCA1MDAgNTQ3IDU0NyA1OTUgNTQ3IDM4MCAyNjEgNTk1IDc4NSAx MDAwIA00MDQgNTk1IDU5NSA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcg NTQ3IDU0NyA3MzggDTE2NiA1OTUgNTk1IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcg NTQ3IDU0NyA1NDcgNTQ3IDc2MSANNjkwIDU0NyA2OTAgMjM4IDk3NiA3NjEgODA5IDU5NSA1NzEg NTIzIDU5NSA0NzYgNzE0IDQyOCA3NjEgNzE0IA02OTAgNzE0IDcxNCA3MzggMzgwIDQ3NiA3MTQg NjkwIDc2MSA5NzYgNDA0IDUwMCA1OTUgOTA0IDc4NSA3ODUgDTU5NSAzODAgMzgwIDU5NSA1OTUg MzMzIDU0NyA1NzEgNTQ3IDUyMyA1OTUgNTQ3IDUyMyA1MjMgNTIzIDU5NSANNTcxIDQyOCA3MTQg NjQyIDM4MCA0NTIgNDc2IDY5MCA1MDAgNTAwIDE5MCA0NTIgNjE5IDU5NSA1NDcgNTk1IA01OTUg MzgwIDUwMCA1NzEgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1 NDcgDTU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1 NDcgNTQ3IDU0NyANNTQ3IDU0NyBdDS9Gb250RGVzY3JpcHRvciAxOCAwIFINPj4NZW5kb2JqDTE4 IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1N5bWJvbA0vRmxhZ3Mg Ng0vRm9udEJCb3ggWyAtMjUwIC0yMjAgMTI1OCAxMjMwIF0NL01pc3NpbmdXaWR0aCA4NTcNL1N0 ZW1WIDEwNg0vU3RlbUggMTA2DS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgMTAwNQ0vWEhlaWdo dCA1MDMNL0FzY2VudCAxMDA1DS9EZXNjZW50IC0yMjANL0xlYWRpbmcgMjI1DS9NYXhXaWR0aCAx MDQ4DS9BdmdXaWR0aCA1ODINPj4NZW5kb2JqDTIgMCBvYmoNWyAvUERGIC9UZXh0ICBdDWVuZG9i ag01IDAgb2JqDTw8DS9LaWRzIFs0IDAgUiAxNCAwIFIgMTkgMCBSIF0NL0NvdW50IDMNL1R5cGUg L1BhZ2VzDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NPj4NZW5kb2JqDTEgMCBvYmoNPDwNL0Ny ZWF0b3IgKCkNL0NyZWF0aW9uRGF0ZSAoRDoxOTk4MDIxMDA5MTU1MSkNL1RpdGxlIChSZXF1aXJl bWVudHOFKQ0vQXV0aG9yIChBZG1pbmlzdHJhdG9yKQ0vUHJvZHVjZXIgKEFjcm9iYXQgUERGV3Jp dGVyIDMuMDIgZm9yIFdpbmRvd3MgTlQpDS9LZXl3b3JkcyAoKQ0vU3ViamVjdCAoKQ0+Pg1lbmRv YmoNMyAwIG9iag08PA0vUGFnZXMgNSAwIFINL1R5cGUgL0NhdGFsb2cNPj4NZW5kb2JqDXhyZWYN MCAyMg0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMTMwMzkgMDAwMDAgbiANMDAwMDAxMjkxMCAw MDAwMCBuIA0wMDAwMDEzMjI3IDAwMDAwIG4gDTAwMDAwMDI4MzUgMDAwMDAgbiANMDAwMDAxMjk0 MSAwMDAwMCBuIA0wMDAwMDA3NTI3IDAwMDAwIG4gDTAwMDAwMDg2MTEgMDAwMDAgbiANMDAwMDAw ODg3NCAwMDAwMCBuIA0wMDAwMDA5OTYwIDAwMDAwIG4gDTAwMDAwMTAyMjAgMDAwMDAgbiANMDAw MDAxMTMxNiAwMDAwMCBuIA0wMDAwMDAwMDE5IDAwMDAwIG4gDTAwMDAwMDI4MTQgMDAwMDAgbiAN MDAwMDAwNTg3MyAwMDAwMCBuIA0wMDAwMDAyOTc3IDAwMDAwIG4gDTAwMDAwMDU4NTIgMDAwMDAg biANMDAwMDAxMTU4OCAwMDAwMCBuIA0wMDAwMDEyNjUyIDAwMDAwIG4gDTAwMDAwMDczOTUgMDAw MDAgbiANMDAwMDAwNjAyOCAwMDAwMCBuIA0wMDAwMDA3Mzc0IDAwMDAwIG4gDXRyYWlsZXINPDwN L1NpemUgMjINL1Jvb3QgMyAwIFINL0luZm8gMSAwIFINL0lEIFs8MDJlOTMwMDA3Yzk4YmYyZGMw OWNiNjE1NDYzZDMyOWM+PDAyZTkzMDAwN2M5OGJmMmRjMDljYjYxNTQ2M2QzMjljPl0NPj4Nc3Rh cnR4cmVmDTEzMjc2DSUlRU9GDQ== --Boundary=_0.0_=5030100017270909-- From ipp-owner@pwg.org Tue Feb 10 12:23:00 1998 Delivery-Date: Tue, 10 Feb 1998 12:23:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23759 for ; Tue, 10 Feb 1998 12:22:59 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07941 for ; Tue, 10 Feb 1998 12:25:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25165 for ; Tue, 10 Feb 1998 12:22:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 12:13:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23591 for ipp-outgoing; Tue, 10 Feb 1998 11:33:05 -0500 (EST) Date: Tue, 10 Feb 1998 08:26:40 -0800 (Pacific Standard Time) From: Ron Bergman To: Roger K Debry cc: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements In-Reply-To: <5030100017225748000002L082*@MHS> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Roger, Your term "email-notification-uri" certainly is better. I like the fact that the same attribute can then be used by both a remote and local user. Ron Bergman Dataproducts Corp. On Mon, 9 Feb 1998, Roger K Debry wrote: > Ron, > > I think this is a good analysis. I agree that since remote users > can't do much about a job, an email notification that the job is > complete is sufficient. Perhaps to save confusion on the terms > local and remote, we could use the term email-notification-uri, > with the description that this is intended for users who are remote > from the printer, who only need notification that print is complete, > that they do not need this immediately, i.e. they are satisfied to > have the notification handled by email and delivered at whenever > they happen to open their email. Local users could use this > scheme as well if this is the level of notification they wanted. > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > > > ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/09/98 10:41 > AM --------------------------- > > > ipp-owner@pwg.org on 02/09/98 10:13:19 AM > Please respond to ipp-owner@pwg.org @ internet > To: ipp@pwg.org @ internet > cc: > Subject: IPP> MOD> A New View of Notification Requirements > > > A major point missing from the previously posted notification > requirements concerns the location or intent of the user. I believe > this to be the most important factor to be considered, and should > minimize much of the discussion concerning firewalls. This analysis > assumes, as in the previously posted requirements, that submission > problems such as transmission errors and acceptance of the job are > handled by the job submission protocol. > > REMOTE USER: > > - The remote user is always the submitter of the job. > - A firewall may or may not exist between the remote user and the > printer. > - The document will not be directly retrieved by the remote user. > - The remote user does not require any notifications other than an > indication that the job has completed. The remote user may desire > additional notifications, but since he is remote from the printer, > he will be unable to perform any required actions. For simplicity, > I propose that we restrict notification to a remote user to job > completion. > - The submitter does not require immediate notification of job > completion. Again he may desire immediate notification but, since > he is not the person that will retrieve the job, this should not be > a high priority. > > LOCAL USER: > > - The local user will never encounter a firewall in the path to the > printer. > - The local user may or may not be the submitter of the document to be > printed. He is always the recipient of the document. > - The local user should have the option of receiving all possible > notifications regarding the progress of the job and any problems or > errors encountered. Maintenance or support personnel may also > receive problem and error notifications in addition to or instead > of the local user. > - The local user requires prompt notification of job completion and > possibly problems and error conditions. > > Since only the remote user must deal with a firewall and he does not > require any notification other than job completion, the protocol > requirements are greatly simplified. For the remote user, email > notifications should be a perfect match. I have not seen any other > methods proposed that everyone agrees are firewall *safe*. > > Notification for the local user are open to any reasonable protocol, no > firewall is ever encountered in this case. The is the area that will > require the most effort to resolve the notification issue. > > The model document should include the following attributes to support > these requirements. > > 1. remote-notification-uri (Job Template Attribute) No job > completion notification is returned to the remote user if this > attribute is not included in the job submission request. > 2. local-notification-uri (Job Template Attribute) No job > notifications are returned to the local user if this attribute is > not included in the job submission request. > 3. Local-notification-types-requested (Job Template Attribute) An > enum or bit map which defines the types of notifications > requested. Includes job completion, job progress, job errors, > printer errors, printer warnings, etc. > 4. local-notification-types-default (Printer Description Attribute) > 5. printer-service-notification-uri (Printer Description Attribute) > All printer problems are reported to this URI. > > This is not intended to be a complete notification solution for IPP. My > only intent is to minimize the discussion regarding firewalls. (This > discussion (firewalls) appears to be making very little progress.) There > is still a significant amount of work remaining to complete the IPP > notification effort. > > Comments invited! > > > Ron Bergman > Dataproducts Corp. > > > > > > From ipp-owner@pwg.org Tue Feb 10 12:30:55 1998 Delivery-Date: Tue, 10 Feb 1998 12:30:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23859 for ; Tue, 10 Feb 1998 12:30:55 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07963 for ; Tue, 10 Feb 1998 12:33:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25820 for ; Tue, 10 Feb 1998 12:30:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 12:26:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23860 for ipp-outgoing; Tue, 10 Feb 1998 11:52:24 -0500 (EST) Date: Tue, 10 Feb 1998 08:44:09 -0800 (Pacific Standard Time) From: Ron Bergman To: Harry Lewis cc: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements In-Reply-To: <5030300017737211000002L012*@MHS> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Harry, In my analysis, the submitter would always have the ability to request a notification of job completion. He also could elect to not receive notification. The local user is always the recipient of the printed document and also should always receive notification of, at least, job completion. (After thinking about your question and my response, did you interpret "He is always the recipient of the document." to mean "...the notification."?) Ron Bergman Dataproducts Corp. On Mon, 9 Feb 1998, Harry Lewis wrote: > Ron, I agree with your qualifications of the notification > requirements. I'm not sure I understand this one, however: > > > The local user may or may not be the submitter of the document > > to be printed. He is always the recipient of the document. > > Can you please elaborate? Unless (and perhaps even if) the submitter > is capable of directing notification to a specific recipient, as suggested > by Charles Gordon in another thread (Three Types of Notification). > > >2. Notifying the intended receiver of the job that he has a new job at > >the printer. > > I would always think of the submitter as wanting notification. > > Harry Lewis - IBM Printing Systems > > From pwg-owner@pwg.org Tue Feb 10 13:13:43 1998 Delivery-Date: Tue, 10 Feb 1998 13:13:43 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA24399 for ; Tue, 10 Feb 1998 13:13:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08150 for ; Tue, 10 Feb 1998 13:16:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA26556 for ; Tue, 10 Feb 1998 13:13:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 13:07:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26104 for pwg-outgoing; Tue, 10 Feb 1998 13:01:32 -0500 (EST) Message-Id: <3.0.1.32.19980210085135.00916100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Feb 1998 08:51:35 PST To: don@lexmark.com, ipp@pwg.org, pwg@pwg.org, carterk@us.ibm.com, harryl@us.ibm.com From: Tom Hastings Subject: Re: PWG> Austin Agenda [will there by a UPD meeting Tues evening?] In-Reply-To: <199802092154.AA07941@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Those of us booking non-refundable tickets need to know whether there will be a meeting Tuesday night or not to discuss the Universal Printer Driver. The difference is between $359 and $800. Thanks, Tom At 13:52 02/09/1998 PST, don@lexmark.com wrote: > >I would like to proposed the UPD group meet on Tuesday evening. > >Any violent objects? Keith, can we have the room in the evening? > >Thanks! > >Don > > >---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM >--------------------------- > > > >From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM > >To: Don Wright@Lexmark >cc: paulmo%microsoft.com@interlock.lexmark.com >bcc: >Subject: Austin Agenda > > > > >Don, what about Universal Print Driver on the agenda? >>PWG MEETING AGENDA >> >>Here is the agenda proposed by Don Wright: >> >>Monday (3/2), Tuesday (3/3): >> -- 1394 Printing >>Wednesday (3/4) AM: >> -- PWG overview session >> -- Discussion on NC Printing >>Wednesday (3/4) PM: >> -- IPP >>Thursday (3/5): >> -- IPP >>Friday (3/6): >> -- Finisher >> -- Job MIB Traps >I have in my PWG minutes (moments from issuing) that Paul was to provide a >sample (or spec) in prep for a discussion in Austin. Am I wrong? We could >try >to fit this in with PWG overview / NC Print or even squeeze it into Tuesday >for >those willing to endure the overlap with P1394. >Harry Lewis - IBM Printing Systems > > > > > > > From ipp-owner@pwg.org Tue Feb 10 13:26:38 1998 Delivery-Date: Tue, 10 Feb 1998 13:26:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA24561 for ; Tue, 10 Feb 1998 13:26:37 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08216 for ; Tue, 10 Feb 1998 13:29:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27178 for ; Tue, 10 Feb 1998 13:26:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 13:22:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26096 for ipp-outgoing; Tue, 10 Feb 1998 13:01:25 -0500 (EST) Message-Id: <3.0.1.32.19980210085135.00916100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Feb 1998 08:51:35 PST To: don@lexmark.com, ipp@pwg.org, pwg@pwg.org, carterk@us.ibm.com, harryl@us.ibm.com From: Tom Hastings Subject: IPP> Re: PWG> Austin Agenda [will there by a UPD meeting Tues evening?] In-Reply-To: <199802092154.AA07941@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Those of us booking non-refundable tickets need to know whether there will be a meeting Tuesday night or not to discuss the Universal Printer Driver. The difference is between $359 and $800. Thanks, Tom At 13:52 02/09/1998 PST, don@lexmark.com wrote: > >I would like to proposed the UPD group meet on Tuesday evening. > >Any violent objects? Keith, can we have the room in the evening? > >Thanks! > >Don > > >---------------------- Forwarded by Don Wright on 02/09/98 04:52 PM >--------------------------- > > > >From: harryl%us.ibm.com@interlock.lexmark.com on 02/04/98 02:38 PM > >To: Don Wright@Lexmark >cc: paulmo%microsoft.com@interlock.lexmark.com >bcc: >Subject: Austin Agenda > > > > >Don, what about Universal Print Driver on the agenda? >>PWG MEETING AGENDA >> >>Here is the agenda proposed by Don Wright: >> >>Monday (3/2), Tuesday (3/3): >> -- 1394 Printing >>Wednesday (3/4) AM: >> -- PWG overview session >> -- Discussion on NC Printing >>Wednesday (3/4) PM: >> -- IPP >>Thursday (3/5): >> -- IPP >>Friday (3/6): >> -- Finisher >> -- Job MIB Traps >I have in my PWG minutes (moments from issuing) that Paul was to provide a >sample (or spec) in prep for a discussion in Austin. Am I wrong? We could >try >to fit this in with PWG overview / NC Print or even squeeze it into Tuesday >for >those willing to endure the overlap with P1394. >Harry Lewis - IBM Printing Systems > > > > > > > From ipp-owner@pwg.org Tue Feb 10 13:57:41 1998 Delivery-Date: Tue, 10 Feb 1998 13:57:41 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA25054 for ; Tue, 10 Feb 1998 13:57:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA08357 for ; Tue, 10 Feb 1998 14:00:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27880 for ; Tue, 10 Feb 1998 13:57:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 13:52:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27278 for ipp-outgoing; Tue, 10 Feb 1998 13:35:56 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> IPP Server Contention Analysis Date: Tue, 10 Feb 1998 10:36:27 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD360F.BF5AF320" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD360F.BF5AF320 Content-Type: text/plain I have been mulling over the IPP server contention problem, and the attached document is some of my thoughts on the subject... Randy ------ =_NextPart_000_01BD360F.BF5AF320 Content-Type: application/octet-stream; name="contention.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="contention.pdf" JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCA0Nzk0DQovRmlsdGVyIC9MWldE ZWNvZGUNCj4+DQpzdHJlYW0NCoAMRBAoEcjODQUQiwIBeRynAjOcxARSxCBiMxALRiMhANo2IBuO Y4cjLCDNCCEVIQLyNGIEVJOCo+MBBNI+ORgLhgNI6OBqLhpPCobYRNKMIINRZ0MIwVDHCBbORgMJ ed4QWxQSSgUBAUxSMRgKDKKY0KDkKRsKDtXxnYrPaRAQxSNRQbzcdDLdzTX7pdhAQa/YTcYTZcxQ ebYKDmKbbe7piy6VCVKyMNYGIJhCByLhyNprn83nRBOJ1PBsN5yNhxmKICqjS6FTwVUhgN8xVgVW CkLrINxRmLIMRyKDqKRlZrIOBQbuNYrJabPkcns4yMhcM6pmCJSqnHKd3OyVNxWCSdBAczLY41xz bxhjihAdDeIOD7BTw7HYfiaBTyjC+oUDoxjfjo/jlDKkgQDSiQwvo9a1P65ywrOjQaMO4z9QAMzA hQva2jcNK8POMrzDfDawN+MY0jkMcADq9rhjmOj/we5jlDGMqJQEFrhwMFAwvMMcaI25cIhAN4xj G4rlDkEAySWsw0jcM8jR3HsIjKEA1LI4Y3jE88oDFGEOjmxYWt9Dy6uY6SioyGIXBiGrbCo7bchQ OA5SRHKJRPCayOON7grS9oZPeEAxjYNL1SJG0AwG+L5vQOS1wOOQXBAJw3xFAsIyA+MuBRH0cyzF UWRdMcZSG49GxwiUhQBRoQDFLI2DeN41ywMgQU9PrkBbQFBBRQlDSsFA7sS+Y4QQOdlDGOg00osQ 5h2gYuBSFM2AUKgVPA2KoNoqqrhRE7jrOsNAwrYTjLbXYQDg4sUJINjEBk48HSJAS6XNH7mRQxbf DgN45Xy39lDlf87jLZzDMdCEUDKFld36sNdBlawQXI5FzuDC1CXZIbBQ4EC8w4MgWq+4460ld1lh TgGFYJhq14fS4k4m38APaGL3sRFEjjhhub4bdAYwtm+IwBY4ZN8sd7VhDj011gl0XsMgy4zoOoWw ySEW3NrvtmpamvHAI0SyOg5DC5gWrTZjnrrt8KQs8w4biskLS9t42DLnTh3u48NuUvb34PUA6UuI PAwDBG/2Mr73v5tkOxbdI0YjRFFLvxo53QtPFR3nfHdDGlyyyvaNPexd2cVuSxbPzsCbSNw5jZIe 5q+sVDwRGcpPjtOOSLtu68l2HWvMvIx9g4vJOYtK8YPSG313rbp69sLusw2VwNvcQ5yhEIwjFvfG ygxa6cYMo8Qjg1FafG8sjCiWk2Ru7iQiwq211WeR/U5Vml4V0r1CiwCNKDPcb9BocAwsDDSkp+6o IFrudqHRXq6ELIUaKupQpv1FqrQitFNKeQ3Jjg6kU5Th3qJtV+dc8KdTXlTJe9o2D3E7BDUSosuh dwXhTQQcE3wdnGBUWChQujam3JnbhEiIiAQQBJTKHVHMKQFBFJUTJBQIDNFSJ4nIG4LjVEDUKUAn hrwaGrJISZbhCYqmhM8UeNho4tAgBrHMFwNzvGtheDA70MipmWPEuIJLb3QG/PQouAwMTfI6XQcp xobWzhoSG844KBGzIULS/CSzuZFpFQsYUjRbWelwQ1JsOsmV3HJiScpMoaQxSok8e9LIc0cLBOYh aBbbw0ybfkg8M0m5TPDSZLhzSW5PypBRK0FsjHvTIOUzpNBwS2yraoyFCzvm3xGmBMaTIdAdRSBn F5op1TrkXO0eAzzYAUJvBSFQNRlCXGYJiTkG4NQckZNoatOhCGcTsMoZYl5MU3k7NXPecr1zwx8j 1DQrEQnKsudyyQ3yz0EzERQoE30yC6IKR07KhyZpmoRRDAAslGaMIXN8fuhypJXlhczQ5AS9khof ocGSkZvySI4WhSmSdNAW0Zo8/Y3ySU9yoQ2C0tpxTfGFOPSukxv5kSIQucJAhwSwn8aYiNSdKTot cNcm8HBtU3JwBpH5OptJzmyBQdadc7QFEsneZlsM856x5nwnWfdbCWT+ngRY0tAyl11W+UuGK3aF AooYDEtJ/HzyniVTVKR5g1Looub038kCJTIaYWQtoZ3lm+Dceeqj9i6VPOGzpwSZl/S5OCcM5lJL KHFLoeZtSCmnl0p5Zmoy40pOnXwlm25zrcu1OCXRntJ5IXDPhZh11n3kNEOGHVtdEUEBlt+DsFJ+ g3WScWftIEUiaEaTgnKgptCmvasKpw4aC1DtELocU4ZhULK6SRA44aTQwonPe89I5zL3yoMQ34ux 93c1PuJAdEV7FxuPkpgJLMxDlJeBAfw4Z/3UqyPTfyQjb73AoqEmVt9RT34bvgCiTxyr/wIDGGvD GCFjwZxHdRKh+HcBkYiwKlGMlsvWe3H9OzJITorwaqDCD6UIo4DgeaCr9UmqcQOCB2qMlZGIhOll Hyqrk4XSMmY3yUMO2UDmGZKD+MSKgylihACuDlKNaIWnFpbcxXUWClRA91wUY0SPfYN2Zc2qhSxn RBLp7WRSx0Uus64lZh0aUfg9WaWUAoN4tm8FXzbXgTinOu0361zuMvXCeU9J7V/oLXefum6AV9Jr qCfJrsd0IKE2Sw9iTDJZeGb6Jdj0tXauVhF+KsrKHqs3Z05doCNFhthMe1a6gY2ntCHO1RGtA2ui RsU816nw2UuzZSDBvj2lpMJK849xWcIPefD7ZDgrao/pFEjXkSNfYJN9dpBO3Uj2UQ3Sd0Bx7FO5 1mr4umtqKQEsnupBd3qwtFrJYF7DYCsTLT+WE9u/Q6bpOVo+rmkawaUvFqmsz2Z9A0N5PytpLdSF Krlp8qdgAFai5DXquFAYy6n5PeMpcezwLhTtYctqoqsLRcZerNT9bZVCyOlLOSKS7KNZhLl2cUqe lAXrOIGc5ONFLj8bKPJ3myBJU/rB0Jey0trPerh0KuzClp7Kb9ExiaUOh1kHLryRXQoCLhZFL5iz lLwPemLRvA5VUgLQmrBV65odwPfTw9/b+5Id7+Xbu1U+uHvu6XB5Idez3yST3gszjWlYP8H5jyuF pGnGlsgMOCylddvX7fnxck794KSz2ki/js+dsV2GIN7M5YcE4xpY8HNKDc24WjhRsC5chzUuplTe VUAICXZkwt0mEshuRfgxPL5SkBlfj4ylB/vlqPZzAfQAKAzo+SCGFlT8FDw3Luydf2sUAQDQhnNC a7u3KNshkLuqYVgrD8UjwxTZjAKRg+RxpXo/4sINgwrHKNImhsC8iwqx52DeZ5jv717D5Ko4JyEC j2pt52AtaS4874T4h2AOZiKZAtJ5aSRQxxR4o/bWTDTv4OR4YtMEZAZHMCTZLBMASjhySI8GZuwF puajR7xRZCx1QFBpBB7Fr3JX7cJIkJRDsBCxkH0HhAYOkGSJLr8DSngtJwYxRyiDJlRMy9J3B2B5 rtECxbK75N7gzmQqZbzVSwSwoMJha9pDg/6pYwy0CiIwxkBRy9phC9ZqxhDig6a746zqIpqsrjig xsZcQK6VBEIND64M6BcLY+A+R6UOYOgOowirBYMDwtzwR5gvB4EMxZ8MpiKWUIh4JH7t0EYEAGRt 4FizQFAGcTIN0SwEAGh6Rvr/p0JKhyQ/h5zdaS5P4352sEy4CpbOByRXZV0MovAvRojNJk5JgMq4 RdKkUNLgrjKssOLhULyiEVr4sQiFUQ7qUbyPsRaF6cLHg8gKChwriw5PzyD1IxR9ZgRARbKKiLI0 oEAGYGYGxOAjiOg1aMiMwkoBQMyNIlIzQziNo0Eh6OEfzqLjwGSfCPDVawkdwFER7/0SKJseB1AF EkR0MWcIA35EKjRkZ+LcB6LdR5LazeihzYAxY45LIJDV6w0kpYh2SI7d7bCmraaJ8Gx+ZFAvYsLe 7PijJF0XDXoOTbxC7fq6L8Q4CAoFAuQtsnh2KbCyjeEoUISKC5EmzRwEAEAI5aCHDYMpTfJLMoyl gNimkbb3a8cRcB0jgOz4hIDZsLMKhdh3so0DJySBp4ESQrS0Mko/RSSIB6BISz8ZI9Rqpt8yJO5v UMht5npA8SxiJEIiT7EMSqKRj5cCMmIjSj6qUyjzTBULp0EDIuA9ExkTs0sHEXqp5wQwcU44LNIi UacHI38w7Ycki0LnaHsBRcU0rr5xS3g98YEE5tM3J5j40qxOLPkLgiUSx2ByhlJt49q3CDMU0Z00 EFBdS3A45HUDE6rdEkMxE4ZzAvLac9EXsK4wqWE7q4E76QUvcMpt8I01TrsKIwk9EJ52ww6y8ycY xJ1A8JkS0LpITdIuArUeE4ygzqrhChMjhRDv7t4samTuM/kC7x7dDv5kZUBnQ44ODs5oiUBdapxT Tv4/jscnK0Mec4Sk5tTBRXSQL2IrY+hIhPFF0GZFs6gN7s7xq2kLLsZBr74GRvCScexojMcLjv5H dELt4McAgxI/6aNGDw71Yssew3hezrVLhH5UD3A5xdgN7zDxKT1KVJCWBXRBr6RQhCxWZJrtNCcB ihERpO0K8EbZkZM+h3M5A5c5U9E5o4k58vg5c88kcYU9TrRTkwZtYtINc/zw8KL7431AgNZLIOsK 5T9R0DT76qR0gFCig954pEM9EzMM5yRxU9c4MxKQhBExhHSSC2RBMS0yk+cy5yVVsZgtKbpbKb4j yMcQ6Fqc0RadLj6vDkSf7kjTyujUI+jkCvLkYmTUygjqaGERYrAJpdCHNcLEkSKBoEALjOqmsZjf tB1dYFBi8nIKkkQ4YF6QI4dec4T/04hSzpirzi8NcbtZSdCtVa1Z6vauNaVbau1atZzljUqgTmAG DlFPRcQI4vJBFc1GQjQuleU4cxZBBiJpQxs9BAp3wMNBk6Dr9AgNguII6QMq8arYxyVUw9EXM4BF FWdfdfoFzSUbj3igzQrlLTFgqt6eKOthLVFhbTLldbDlyvzmNblC6hD4AFAJxEiWQMJZQEFeLwce CasxZLBJp+YGTfsKpUBHxTAryZIFAwFHaVAJL9gsIMTK1mskMkSZVWtsNndnsulqNoIFDj1pat1b DTqudhSfVhjUdaFbNiFw8RkuywoJqBpPIxcGa/CJgJIJIryjNrhB8eCn0Ch3CrI/FsUJI41KR29t bCU39tQ31tpC0kQ31uDBVudyo5zwtWI312LDMYpwgtd0lvdf6sTg9oFZYn9wVgzTlo9w1pNxF5Fh yvlxt5qgz3zHZsgJSygKx3AJtuLDlrJ8J8deNu9WirJSs1VsjxQtpYttF7CJEAz+NMosN7rLQtxa LN4804A5V8bndvTSAn4Gjp6FcREusBpsSwqw4ulR5+EZMDsDVQgN05VRCUs/Rt9Ske8v4NxRE8dX dBFTR+zs01pDs+ctxB8XsymENR52ES0/sFZuNBJyWE5BE+05cVhKRt4M9UJ0OBQ85GeEJlUG45VW CBKa8YyBhJR2pJtm4sNnM9z9b3VgFn7hdWpxmB4NxhR4FlI5ZS8jxwVSULiz+FGB0aEVZ9UYZ2FW GMM62F8KYtM7R+xyU+0VcUxiLrVAkXsZxUB707ih2GmCxKguBAtAhARYhs1WNnE4dkULBXyxAFBX GL+G5xoM5PMF4tNUEx0CULLs1VjQUBbmcu0b5sgLhesWxIl+hGZRqniWwOQMgNIPQMuUVJhkeVAF o+V7qEuVB+sIS15LAiReUvZKZI00eHhIBlRS7nDPi088OXclBMZ4ZubpRIz8OZqG4iT8MYBoxCKC xKOYEHSbEfN+ZZr8JXpNJFtCbheHuH9dGY4uQtN8deoKBiIJAxKw6w1roFJCxi9G45RXR5JVjHxA NRWbjtBWN/NfI5WcBhQNOcZAdK+UxAeYkZ8QT7c9RV5GpIx/ef5IQOB7yCa6jdeRheg/T5xLOgtC SrkNV4cNoGFCsODhJslH7xJJFIjv43iDKJpE5dlsbOZdkxzwJeRnpQzALsdNTBTJcGB3CI0fBgdE emL1gwjzdMr/2oEe6Rhqzs7t9M5xlCL67xpgMezxtDmqim0a9DTv9LSY5edFkWZezxNMg9TQLsen CJJwjrb2aWCxj2LzEGIN+sFI1PGk9nygqPKwagzVs467Qu897ZqqSz649jY5a35RJWAM+OilCJGG yJFS0tkPg8xtErqJEr6npAJk6RK0LfehIM1cxBa1DYj92x8sjYRFDfK7TYsuKyjda3BdhvbepRxD JB9T+28TDgUp2y7OgOwNLwy58Plli3g+0HDfYwosMtTbc+6HIw2Huxa1j42Tj3uT9bsjgIpZmhLb rMhDElJUBWOyT/zor8hR7NbBJn2kZxpRp5ZjrBjP1NUZ+CBDmaxCJKD+GCkq5Rp8yqb/zKo80owt ubTMJAZXRAD5QsLnjOhSD0BqwwnBF019BNN9ZI1dCQr2r25LBaxiLn8lGzpQNPLqkdY2jrBcVE1N A5bxLt9KEezteu7IjrrxrxOt7wjDj1+uVrdGlGkeCk5up0Is9VJ9Trt0KaJIzG1IGu3GGJPIkkgE BKh0ds0Yr/2qBGg4ZenJslEcqKaKogINCmVuZHN0cmVhbQ0KZW5kb2JqDQozIDAgb2JqDQo8PA0K L1Byb2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMyA0IDAgUg0KL0Y1IDUgMCBSDQo+ Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA2IDAgUg0KPj4NCj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8 DQovTGVuZ3RoIDQ2NDcNCi9GaWx0ZXIgL0xaV0RlY29kZQ0KPj4NCnN0cmVhbQ0KgAxEECgRyM4N BRCLAgF5HKcCM5zEBFLEIGIzEAtGIyEA2jYgG45jhyMsIM0IIRUhAvIw1gYgKknBQ5Fw5GwgGE4E E0m07GAuGA0jo3GwuGs3KhthE5pggg0IFs/GFBmBjpdAGA3mB3hBbFBDN4pjQwFBuOhlsQxHFlFI yFB0NNhsdlEBIsQ1FBhtNrNxktNkNhptN4NxnEFptxmuQxshysVrEBJx4oKFpGmUFJdKhKhBFlQK gRpEEIHNSoQ2G41Fw0HEDGOqGccqOr1skkwqlGfnk3pu7n1A041GdGjlJpdVq9TjBUrgKrxUwYos I2FAgMJsNmLtZ3toz6pjwJlN1i6h0FIxFESOly6ggOHkFGOFuXMt+FvUNJjOhhMXwNjzhQPLzsgx AUDQMK+v8Mr3Pg9j0jmNL+vuFD/vRBYksqucMsY6o5jKOQ7Q+EAxwcszxLg7SyhYw6NLc7gZO8tA WrdFiNrKMr6vgED1x0+zqRkxIUrWwT0DdBYwhBDzLLeEEHDNITvxLHwUDTFD4PHCY5syzbjo0FzX q0KgiOSGCXCoqwFNmqbiuar0EPO9AyBeFLqDeOUkyg8zqDDPQUDrLTIRIMgy0A6sCxfIc6LeNE4S o8YYvRHdGUgFELigKDDxsOA5DfPo3jG868De/7qBcEAryPUj0ygxbq0fCz6x3RVWhAv1KLQ70nov KlFVfSoUu89ySDIwTqVA70+r07wxVVBdCxkHIUDatrLr0Fto19PtihRY9VsgOlJvRPlFMjS8R1Vb dcLZSk+y0zTOAUKjcAUqQYOLNF6oE5iuvTRi1jeOo2DIEFdLIuTLuwxbqO5Xcaxc87vX9X8WrZb6 xWjiVCWcsQbrfYC8jpP8RjfQaJDCkinDKMYyjSO0oLQsmBjS8bIJIOY4Dfmj0wW9brBANWLukMUk jrKAxWmGT0MFa9VrxLQW46wTvZzKGUjjoq10IOlTCetMi5fJs7wLpD0YO+K0XfLoYy+GkzTHNN8u ReisKFfbnPS/eQ45VcaRJvb7Y7GVgyUjS8WmtS8uisz8olvyNWjgPAOrCXArFYIwvfqAUczjrw8l Ha5Y7TK3dDjyyDREUMQ3SI385So5T4uO9jdkyJUOtq3Rk18KDZFeZutyXJSr2XNDd0G95/AvS8pD o6wkGNo8PIenw5CHSvHtN6IztcwJht967rNCvdbD9xrwwVRLEt1HrJLWOhdLd4JzGYXBmi/vTJe8 yX1NoUCMnYEAZQwhjYkk1gp1VwNgfI7BFDOi9GASSytAsDg5FxPUxJayNjzLBRI1hCjH2Bs2g8f9 pkGzqwHPk6QtJ1GyJRhWxVjyMXFtUMgFwFBHIElrU4HUM6UICg0C4ClJsHg6GBaCzpmAKGBp8Uky 9+Lakvg1TC99uS9Tlv9Qkj99QKAzszSuoppalDCpNL2ChJ63w0RhPQlpYKU0HKgRmn4+Dh1ou6Mu eM8qKwkggYY0przvDrB0LOktabHXMnleOhN4B8EpnyPoHN2zFI+oGUVEw8xGj0ICOpIdiaNEnNVP AGmOxZZLqUBalCNjr0Qp3cIDEy8hXEkajuXAMbDlpApaigCHqE1GSIizJ06p4j4RnOkfAOTKy/PZ XkmQ5a+Ctr8V02Vyx8YAwDUYtFJp446vwey/MGT9QYL6e+VhMyaE1L2me3cKcuFuTCUoydbatAZA 6XIElXyg1dHeaWdRXy20+rqBAEQMqqlrLRQEpRWrRVKQVV7D2hCm1tpYPQn1n4b2hqFoUeho61Eq KFULPEtJ3nsJce0/R+xy5xpriqVh/i/J7NVhyrxpiWi8QRd0+tKE8A3orSQeAMMkD8nXlsFwGSMD zlupo5sN6o2Zw9LXUQGQNAUlkSSh9JbLmsp3g6lA/53mBhiWczipjOqnQIYy8lplFnQVVRIzo+y1 Q5ICBlVQOZ63YVlSOgWpMTWs1oWjWoNK7qSPze5FJ/D2m7FerBF5aMPZsEkZW0stbLo6oADIqYJI dAQWBXIzhLR1LPq8Musxnk12QS2cOWRoq0YSFrLgHANlpQUrRJIGEMloYDKNgDH8PFs1KxwUpast 5cZtKGkkecy5gjLyXLXaayRbJsXMkpHVPEWj0Igt8iJk6C622+VAei4QciSR/uKeZhBk65KRr0oq sRgTCxPXivMnKZ5mTpfGfA8x6HUVaPCWaP8p1EyYLK8NPiOZFNAwEg6X7RHnlrjpR1oL1ovntr0H S2shJ2HqQdWxKR8GTwvoOZCuqDpHSxldFxRQZbMWasCdYNgc8NycQdUCX6FVKqSiZBky7Lk9hpDY fw/yAG0WDe22xtyZHwlQbjYlVbgbuocPsW7D7FK5I0fcx5UVdzzlkQXZx0R5i8O6LI0g7zOHYUML xCRjuVZgl/BRb2OKkyyF6Lcn+dmYFflusuZHPFmwUtOnYymn87GqIcP4f/MJbYEZ/mLHGANvUOBw ZVn3PGcmQaMXPox9DE0OPsyxcZG2Vy5JBg03thheM6NnBBDbQbonW2enYrHPGo9Fl40tkN+WRXup iOPfRuZyr7F5P0HWoUoZRlmBA0VLLH0PxBlsi9qcZXIo6Q8li0GzFZYCl7R1kaV0pvDRS8YNMxJb TExIklFOD0gHVtrjCMseDqp8kHLKW70HN34j/KmRJ7dqpT3KlBop1A5Slv0iLBClMFI6qPErD0Wz 97PO7MBlCPJlXynI3Kc6bF+VQBmqEFDz4Pp1LStwNajaoFCQLPnRt1zrK+2Sr5P9GXEneVUe5D88 WBhv5UrI/Ec6OLqVMFefyilw7xBB0WfcXA0SnV2y7hHIw2B1cO7lj65VMLPY/dhW4ckVp96QopQq O65ZlQXzpiCHUoLdWgutcVDOREaOqwzt6u+ZKqYGr5VtFKwXwmXr+dGvslv9DLb0tbKw4QNpzVNC lPK3cQV2wBgVfHXhlgOnZBdYGfM6bMfLE8LdihpmP1K3zT2OwmgzTjwvZYD1+aE0Ro0L4W2cc09Z nVa1wYtDgyeWkI2PsnqrdirKpjoEaYjE7iuvX+ln84d5pCNEC8c7OhLmin+SrR5PZu4u2bm2+ufb j3OWracjcxaZkdwj/mXq+gu4VodZBvZHcW4pclkJHDcgKbHZqEXStMgvlKjf5HeDFi8GGLkgUo7r HDvqfndI1lFJ6HsjhiPChKTJwrDl6ikE0AUG1gUgqA1CVgjCMF9CZCfjUgciMl6jWteAFFDQNwOi XQQCLDgDWwTQKKWKVqVMmAgjxnREMGgkMrHi0FKA4i7o5HAq6ujp2IMjvCJEJMwphHRGni1mimOg xmVpIDJkngWjvQooPi3ISEOEBMvnYEsNAAWsHEoEqizj7C8AWItgQQlwhkmQctGqambHMn0gWjCM Mv+GKFGGOoMj0w2whHdNOKRNAiSG9GOg5Q4sDQ1N0QhImnKputdLDQUL5nxNGjqMeHXjrg2NVqiu OkODJD5jMENM3Edwwg5oBkrEJg3Pro1FVlgg3EHLNHHHEMHpOLYizpuKSEvAcCsxJIpkyQLCEIbn 4QVgFCWQPiYQQgXQRwSisQTm3wVQORjiWiXiYwXigwYxnwZipl9RLQcNAwdmmQet2Qfj0Qgw7w3m tQjQ+qQw/w3EcQ4k8QyQ3wplCQnozJpwtD/wuM3QvoEQwwhR8FpkhpBRFgUQ1tHQ3QtLNJSnTtYv fmXHAk7w6QhC5Q8GOkPM/C5w4w0leC3AxsCj1M3Q+LTt3CNGOyCFfxIkvNdoqNfCvGbEHA6pjkFk DwlD4GVN0jzrKtHN5vOp2MZJjCxK4MfI/sQjqtlJ+JKqrpKsfMgEJsbGeMNxaQyt7RbgyizlJEFi SR0DqOAtODLpUmtr4ReRfSWxJqUgYRhQUjhwNRpxkRrRlxmpzxoRhjDxjCWQWxlRsDWCcRtwUOMt gvhkOOiv1FGp7uRkPg2OxlHFGqHFIk+jHFxIjlGlCszKKNCr1LjgYjqFGO4FtluuivHItHLmUCST GOIqmrdOVFWk7lBl0FFOnELIKlfTIDqnVFhFOkBjpESOaltuwp/mgmkDLszJ4FFFVEBSWHuG2xuO /l8QaMmPoEbEJGEPqGXgyPrgyIPSpvsE8qrN6IHROFNlOlPlRqqmxi2zKCyGdJLlonGNVgUElzpj EjsoXkXqaxaSlrXOslRuTkVz6OPg6gzIDokk7gwqsC8yngxMfGlloz3EAi2iyT/oAg6AxgXIgxdF 4Q7jVqiiMpvqTznJyslCsONG7gjNCORk7uvFGkFg4OZA5NYGsuwv8FgvnxPOPFClkzKlKD7O2liF FA9KIzbvrzcuFqwOillAUTZleE6uuDIueJKFKKIuRuSv8zDOrI+C2l/0VUrGlTbLdECzbzJjpOZA 4EkuimAFGu7ORmUkSTbp+0grZUprBNcy0RgO/Mkm4Ton+srmVtPTjw7EaE3soFavKOFmlmOtPC0V Bj3PdNNNGFQM6stoPtUUVs2NJLckbGUsrmcHaSIFBGeNGNLHzRyldR+swj9MromkONN1Vvvs8NN1 JI5EONEC8qtNCmYottNpLpc1BF1iyH4FIzCL9VKVXNAsrs8E+KFH2tA1Qu+F5ivNTuVjL1mVKolG U1T1rtJtMSQsrkFgRiOD+A3unMuFTAhvEqkNYtFAQARiBHbgZGOvINGO71KNaM+yu1rNNjHMuTdN ZzfNMMr1rA4TMNGQ1mGgxVrV8VStbr+VINEqcEOVegUOmV1VfOGI4tcCEO+pzxvMkNgnHVFEnpcm KJdmOyaHYnroyHNWRoEIwi3FpotQsOVnINGLNA7DrkCmiswg5lTECghwE12m9uOnNTvHNA7HSg2E QjoktEaNlVFV6G9nBD4wui3KD2SEbIxsLIMw8GnHXHSj5C8MWQqi52dlKg5kVnbzCm9j8jog0EVn JWzSpnkFwQ9Ws2npbjqHmERHSknzlsjTnH9O/KWm7gguzkMi1gkiJIvECGKIPKkgynfMItMU1LXE IFBtsmMGwAyA3lplogw0HIYVNKqRxC13EEOj9q3GTliA9WUmdUNEujhgaU8F60R09wbH+p1wpJ3O 2qQO4AQAZp6D23DTOuPx3O8UVI/ziC8uazCMuOs3lovJ3ltFZ3jrdUajqglK1XdVaKNR3XoqPQzF ZqR07UQQJxKUSwa3zn+gqg5oPIHoPmmISKDUJSEXMpKHppbA50/qcoKv3W1NoxRPeKvQ2kj1DK8P FIkPFIGLuWgmFR8kOKbIKC4gQAZW0zOPiqsmWPaqbkqKYkRUIKztjIJk8uqoAYPyImXjHW/yXUSR u31G6n+mGGDC0nIGBHkWWlrJ9ROW4tGW52iyTt7WYmJlgi4T02ZYA2T2bNuninhJSi3HiVFWVxER HHSjzHTkRWvm9jAgx2rgUH4RRCYIXlGHzpIkbPoFo4tHNYuDo4vOTppgQYh2XsUHNTPvSvFPsHhP FSQytWwRHDxWW2wGVpbA0DFlokXvnGKT7Him9oevjrEToNgMmGWW60VnUFzpREltkMSSiEOkPpVv HJpEJylIPk4uFLjkYJY4oLNP+0uEJyKFCSZyasNEdJfydIyt1Q2UEXQMfsashN9oXCNSrY0kFStO CJKEfq0OnkJsF33MGt6z3mnlosJRV1oH831XCSYgymrmXq6rMPa4UDwGgpRT2uqyQq9YDC4XPFK4 HoiOq4ANG1qquIQX7q5CyHM3impFuRNmg57HJv1EPAyAdrNvV4QmwEPPOMd4VVDAxg0mSq1j+PNZ Og5PPECqu3436K5oETwSgT3zKi1sC5rG7sEK/mjPXC1nnoWT1KZZpvaGq3QoTLUaV3QgzmJLNPMT tmwGe4UID34LgC3aYqYpLGgqz6ESmqswjaQPFCJFBvlMMT3okGB6DaQLNIaMboAT0mk54tVSZIPI Up2062Nr5X1Irl+Suj4SwPQMDD2keJFHHaVSr5ikFuD5RW9NqHnOfN7RXJU5pFea6i2D2kDqrkFt jlFPla1jqmZ62j2kEKh0cEOJPi1wrmERXEjPrq6sdGPELFTAgyGo0t8uqyhEJkiJSOu5L50EQERE pmVaHScot3FjzYWTmwUCvSQg3RYr8aZR2o47K7DXQLyFyNjNrbNZPa+pUniJ+YzagEDrNaz5RowG UESsU2VuBZO6ZN7MSOyphqYI/ttyuZY60ZZtslKNtombBN6EQrdzw7DEP7ESt7HKjbIbt7JZOojM BbLKiqpYWS0xh7MRcy3jOjPiAg0KZW5kc3RyZWFtDQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1By b2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMyA0IDAgUg0KL0Y1IDUgMCBSDQo+Pg0K L0V4dEdTdGF0ZSA8PA0KL0dTMSA2IDAgUg0KPj4NCj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0K L0xlbmd0aCA1Mjk4DQovRmlsdGVyIC9MWldEZWNvZGUNCj4+DQpzdHJlYW0NCoAMRBAoEcjODQUQ iwIBeRynAjOcxARSxCBiMxALRiMhANo2IBuOY4cjLCDNCCEVIQLyMNYGICpJwUORcORsIBhOBBNJ tOxgLhgNI6NxsLhrNyobYROaYIINCBbPxgMIEVDHS6BQZgd4QWxQRjkbxTGhyKDaKRiOBQIDCbhA SShYxiMRRcY1dBAYzYaTKbjoc7kMBQXBlhRSN7WcLHiDLYxmKDkc8ULcYYzoaTsZRZbDFixQbrFl MhcsRZ7SKDCbBAdDKctJZhSNhQabkMs+KRrqMvocRbjGYblubcdDCazKINCMbKbtxazoaOPtRQZs OKN4KDYbOTZTvaMFtMEbjOIOl1MR19dGtLsRRgI1gh0KS6VCVCBmLo9QhaMhcM4umAiKwqakKuBQ UBiFwUioNSViMjCqpkn4bhqHKMqkGAcQAhC1wVBgFJYl0IIsoAaQzC8MipAIFQujirQEqitq6FAp uS2SzhkujGsE1axrKPIUhkwQ4OON7qBjHbpMIGQZrQ2zgMEMQ3jkOklKENLmLUMg0t+3csQ4jTbD SiSSDGMrMBStUdBQMjyTA6bvNG/brLlG0gLwOkehQNE0BQ446y8MjWjZPMfyC2c8y8M8+Leuy1Ua 5w5LbPjJSkOkEvm+oFI0FwcBgG6MwQGIa0/FMXwJDb+Q7BsHphCIXQnCqoqzFEVQ5BcGxDVsRqDE 1Zw1FasxbAqvCouTHz3NK8r2vs+Twx6nDLMszzSFLBIkMM2o2wbCyZbUnhRKMpyqEA5uIOg6okMY 30CEEjME9LbRq2EcOdPNkT7Rix0dfS1jm1o7T41t2zg0IaMgtgQDg4FtSnLY6z5QbHjCOVoDjh80 3K+T6KgGoXBowqMv4GcYVLYCppdF1NRZGIFK8K7aNlPDZT2udDtk5matXmkc3JPgxhSx43yG5EjW e560Z4uAoPJbQ4LDmTrZ/UTrUG2TN6hnd8Ok7oZLU5LIDXpDZvFsQQUVmrXLoN+H5qOC80lnNAzz oubNvmrG2fbGFSm9mYBRn7HjrqrUYpJVuty4DH3DqEq6BftmvYMOoXRRd1XZqCxUwpdQBdUVSRVl eUwuqquZayAy3c7HHWiOjOS9gs4hjg0bro1LVtauXZhSsraBa5c+ckNI3y9ok4YQNU8jeMVyYvcE 6XmunerKOY5+F58vBcmFjTjJ0vUpKYWzgNgy4BajBNVdQ3S91nrI1m9FjDxdyDLi2Ay9MtrpIEAx MbN1CmCdgoBjSmQqAqRk0dZIc11NDdS7BijzTAG5NWG8ECgXUvSNu+ZfsGH7nHTw75PTAV/M9NEs 43S6C8rrDKRJ8pqFquxYM/8tZnX3Aohktk2wdFIveDgpWHAKAgloMeo8JKl2NorZCf0/7JULlCZS rIqbpEZBTPYmVnBgmJm0NyaE2wIAaHxgkE6CgSnlPGiobJtiUHcrzMfFo9pYzcmAMRG54bxjpBDT 48OK6fTLHNjoG6ORawwsASPC496hzcqDcQkBcEik+wDc2fs/rJHQEwQKhcjAVHSleCS/ssZsn+m2 WWZlnSYofwKL7Fk0JsoJyfhnK6UJzjoQ/NMWU5JalywpLkWos56zlJzI0Wo5krDfwjg+zVPZsnJL KL5Gsvxci6ESa22INJ2YfhoLaGSVz44fndZqbQukxy6TJLWSQM7E5tAtNkRIOkq1+r/dw5qJCm3P K/igySS5WYnSbb+dcvxfTdlyOW9kt5bjpFnNkj+CR1zJxzheG59svzmG5M2mQ64Z6IUBLIZ85Bnj zL1Tcns3MpjpSoDdKozxbA2BzOuCANNCAUUNdUm4vk7DpUiN1Lo0U/zgm3NzRo3s1zgEaOFOkxBe 2yGih/R89AIDQGeOYaJ8M8oCovkzJdlhXjAGyh6G+pDuwUKKLKCyF5bKtpfW1N5gxjS6KDBaWpQb BqzHsZ7VwN9Xkr1iLWXAzxdjEV1keXQOTACymtrPN1IBspqmqf4zqsB0U3VnqGzU0xgq2AoezJ2C 01AUsGOZYUtEgqnVgOScKsD4Wa1nq6XtflUTH16XyaKvzj5QWhsHY9igYbDrYrPZe29hTXVUgMyZ kk/IEU5N+8ReSXq3I+SAjsMIY0yhwdbHVZLyIQPKeYnyGgMU6r0gw9SiL7y1MVebCt1sy1sGXTyW e0BgnsnSiCReDKa6lpwea3yEC901ByauveZZ0nXljrkG+49/QQXYls8sObzQxO0UPCC8Vy5IAKqr EiTSMiSP1sLWcv9dDfzQNuWV/Zx7o3TNYmxh7vyymXNVB8tSe7CggcNEJv+IsVmQJJZ8FCeGDLju w155a6kbm2MmY98ZrKzoJR29qkNj7Ry2DdaiaJ7LVu9mFWC2FfLZUpt7bawifWKJirpkEFGOcPWd llY/CuF3R1ZTWGVRUGn1wvUiaxt8I0ivGt5ldsl5cuL7rfO+26ab/WIBkbm/mAlFwfLLfxcmfs51 7Ueo9+ehcxAgwBC8iQZQ8J802m6CBnsUlshaGGar8ZuEkpZfksZtn8StnkTmegNGUOgn1JYqGb8M umxOGW6hbA3KFi7HuUJtmuV/OkldOCUU/pwTZdg8+DDqxpXAaZ6MgXqx1kLIGIymdaMiiXrhk+um VLBzgEEwF5cGtiDO2dHO68ensbxfa7pj1CrPoOk2Qxy98mJYm1BvzgG6mTdqzicO8jkcIzW3cEAR F+BMLQwZq57GsnHCuEdcjWW1ticHOkvD6d5N+5BpluBeAwhwac0IOTfnE7ztqs/eTUHJHsbZlW8r ljNHIYpvLerUHi6zc5PWJhWSqz5Kmi2fi5XJMPBbHHNVOjczpNy/2aMrenyv6z1acoZVzhyDcGXq nWjco/l+whfx6WpsAMYxTsbDzEctqiblRVfzJ9VLkZB9vU44RvwL306mJNWGhNyHUOSZQQdOtMYi QeqDAnYfj32aoaZjmC7MWVBKci309OZspNxZy1I/r/4SmPkpGUQ9J50FBm/U99rdIXy8gs23Dkxu YnOvatV5rBNzpmIsfZnXTCrRBsjQuB93mpNh7o0GOOmkZ6KZTNhixy62absrA1oNtkWQzNUf4k+q wayZdMee/gnCnHlZw0qBtywngLDvj/g56uZfmaMQfC+dMAx7FAy3RxlSD0JOymJIino6joTWrW5F 6KR0zGphjV5Pqlh56/JMpca46ZakjURLyQZ4CDANjVQMp7JYojRY5gJ/SUxbB1Jb4NIOS5qGy54t a1iEBsKDUFaG7EKyKyCtLGy/gkiDjRqHZ751sDg6SGTBDwbVxOTWJiZP0DDU7ZcDgMR8bCrWhUJU ZX727pAGCTK4ydynROqX4yY2TJLEw1aHaVwySVydw9Jgx1pdSVx9R9idwNyzJ66ug553q1JxwEB8 jqyzw9gOjiou6EKUClyqI2Q6hryVztULosrmsQB9pm7UyyZgzVKGkMC0KD0LYvQviZ8QBa6dkLaa ZJaEKdSnMOzKpvIywOsSI7D14uhH64TXboz2zXL3Bv4MJdEOw2yqIxBRSCTwYzzwzxDTwzybDpwx AwCHKiI5axCQqxaTw0R/pZ4OyybugOsD0KKJI/yTJFQrwKR4Kfw1MG42ypgzxijLhmouxmp8I86q A5r142zsyv4Iafw1jzg5qjSiQEAJCbIz0F5bUXSsLCoIolQBQgQNIEAhAHIqQoQGYohjwoQGIG5T 5WREpaAky4YlMhAmom4pongm8hJEgEAGYGoGg/AmApR0yTqbCUimRh43IOSmQ68Y5Psd0FkiD2So gFBgCLYzw8BNYz0aEnypQMKo0oLuLvqFZ6o8Qtkeo0UeCkBbShT0sZ75ijo0Sj7SMn4McXBN6hww QManQ3seknCibHsZKjibDzkoir40Q8Y68q8NijYN0ojyh9o3qmzJ5xC6ozy6Tw0a6ekKiJkWQqcL JGTTw1jsB2ydqVxHkQCckcJbZJZOAJLAgurx8dBJBbSdL4iVyWo1EUoz5Kp7IITV7ywtC8qdxh5m I9x3kzRfA58x8BYwUyYFpg0y8yqQ6Cqd0zqoZMLESYcyAGgzaTrfaX6WMVU35nUVRPAvCzUM8No9 hJQGRyBO7EScjZkUYNcZZHMBqEjR49k1A9gNk1otgOksT6yXsqRmLWSI7N0WJlIr0BbKrQY4j1Ts adD0w2wPQMpcZbEuDxbeY2xZgxDypQ5eLvr1Rcj0gNjxUsr1qv9AhPbxh1rqwx7T4xDu6YDqCtZa 7ucFlB7x72NDDrkqsmzwItc/w24xDsculBwtYLkqUnbrJPFAL1Qy41Lx7180rs8xTrMxiQtCJfFA UoKCVBgwCtYOQLgFKx1CSlwwEV7DBYcyBbqNUUYMo7SXYFCbwukCaWccwwU2wtkL89I7BLcb0Nph MREyid05ZoKVxn5OSdxQYui+JbUEBqc6yaTz4tCwpSUUYiUM1KsrTEUQxQ4ukr4JFOw3IKlMDfkN Eyhpg21RIFCPE2rx4F60MybQSQsLgz81tFkNqdibEvUUcvgOR7IIkas9aAj2jdB0U9y4zSBLQMx1 I1pZgtRMqksQZRdOwx6PA2RR9S4x7QKQTlQvZLh4R4hpxgjSZSLfYsrCBgUHgtUw6NcE5/AzZSRL Mxk7xZNWVWjuTSdbcFhQxIdXLPdTdRB7dRZflXVaY1tayFb2ZF5lBAqe7pSA7ixsTmqVhpQEBG8S SVzeEUScKuhyhZNF7nw44vqQh6I9gsINw01GhqDhQgRrBsQsIOoM5rIEAlx+IN9hhPtJM4RHhmaz h95mpsJnJvyD6dZRZLQ9lWbGzgZPLm51RmMOk77vKnS+lf6R7fTURsTgz7FLJIAtR3tm9kpnM/rb lQxxzMhNKskApULW0KsWderXifh9JOCQKNw9yn45oxsXJOBPCCR/hmiLDx6Qg745pKRHlGKLoMgN 4MYOpG4x6gA5rb6SLcUbRUzcye8wklBnCLs4jfDfg5AOA2g3rflxI61wT1cZYxjqIOZmheJwQ6pN lG6o46osQwSbyv7ZkzNxiQk3tFQ6RthJxQdz5G43LgyUQ6p/qXhIDvDQdxxPDxjNS9g89xwwDEl2 xOZHd3w1x7t3h1VCV15HkoxJy1rfl4iHpvgxC1Bg11KR7Qd0aR96Q6rGgFFdKEBYqIashqdSAFEE AsqPCQoKFS4xCvgtVJMv0KZz8WCKMwQrUWkuA3suaoAz8TylKY42ynEx400Q40SXMrcf8cY0TtSX wtR4I6UnRfGAo5suaF9Y6fzrDuwzw65PCywvwNJ2zqy0zviqTao9yQqw0D559/6Y1ZssY5tQEdeB DvoOkdQ7GD8nNK0sAz882EFBqgQ29J8KyqzOEuBm9TyjRm5/I49QiUI2Rrgx6sgFpvKZw9k8cJKp 1Na2N87x58KXFMRaINNQicBv9bEuUxa5Mqo2VUql03yulPqhNMKV1MVY1M0UaQFHycZyK9M8sPY2 FC6Vx1tHiVjp1ltuxnQ44OcVU9AxtqRztqhkqe7o5F6faA8H0mEcmGKWk016gx9N9O45otsreEgw SmEmQzcB8oSnuAJ5w0UrZRQ0Ulo2d/smrzxbUEsmimEmMNY1o4mCCCRK6U47Y2A08oEMdPsY2SuG FGWGcKEnAzJ9EeeGssl/KgyyKKylGAdvKedvdqrpN+cBIrwJBeRrl2ZbSFq/uUrZlW6DxexgJcg4 g6SEyFDnVDhPhNmdBNdMse68iN6CTRyEOBb6hNyb1uysqzcZhRBgKsqBsykcrStdmKphbIwOGORL pPi1BaxIcrQMxLbYWej8x18emRboiStV0wbOEzsNGAF18Bs45vsQkgEUdQmQR1QvE68QqPNNKGs3 acQ2cOBaEDjFMxeQCWU2BbhOFMTuS9kQA8U/lMWOOfCiKYQzcUGgbzSkoNCW7M88OKmPSNcztMWP 8Lcfouk9DymM+rI2TnuIdMaWNVQhE9ubmki4pGWgttYx5LyDlcNYZR+iw9ujGL5OA2mTZgeEqF6y aHJx0I1AIiQM1ttrVaZ1eDi61obTY8OekykF45bSZ7IK6WCsq5J+ClaCmwx6A6xhs/VcRe6Uzq0c ROGhU2gyC6ucq3KayHo1hL1GxQeH4rNel+IGFe50xujp1gj5ZtGlJbxxzlRvzhmVrnAtdc5Z9fpz FnTA1fJu5xxihqBtI1DhjeV51iZRcUFo0PrjlmroCm9fRxwO25VgVkiYAvAki1BiRxwMgMjVhSbR u6pnjlcJ7ei9pIBg2bDcKSYqukcK9wArxGlLEzutid1QmO0QJfFMVNcS2Dh2xJOoqQsNI3U6tOKF dLk5S0It7RFNqYLM88UxYvY4zrCViQad2MOKgkg+KeQ+4/LocwBWp8JW5D5Bwl4mIrAGbRJCxXxk pWxDxEHHomRBBEojhE5X5YinvDQtoOen8RyjnBpRYJyKiQ6+Yuk2wJOLeVSZUBpf08Ykjr8OaYid 01qWN/cUdBPBVPd6mw8xultgKH5dDyMUabi7r/40+LFL7CpTZTsiV95X4FHHPI3HhERYHIAlye5W hDY8nHXI/RfJQHHJnIbcgGG3jc+uCflOxd60Lk6N6uGPBvtnIjRuwvG56vYKa+dX7vvL7GwMS3Wh Ax5NnMzm1i7hiFJQLhW6XVJnuAVnm/96jFu/Jse9lgw1G/jmLrS+jf5RguKeXQRT3G1+BA3RBVfJ HH/IPR/Q3SXRJXPH0ghj3S4nHTJF5YUBDOAJKlnKjP4tfLT/6XE8z7K04KzJy+heG7ZSe7wEDiRm u0cIbOygpZp3AjRg1eF7VXgFHgIugJNJOdrpu+6CWeWwaAGheYiQHKjCi8qdvN+nMABNWfu1Og4t RRWkPG+3qq9vsWnPDvqGgsuZdsrV8VotCCU2YxEdCIfQJBHQboeRvHBVXHZVncgn/RvIQqfSBA3c JXHbncvJfdHpebd+lq9V5GVOywWwqPaQKRzmqkY5qqI2xs5HYISM4FAIjGnDCtaRgOTsBghcdtpl /sVrdzYMdlJJBN0BZg2zm1/VwI7r3gJiSQNsgFAIq2wsNJAwooXwuT3wxyiv+eV7PwyLhx+F885I GgaHNs6RA25OXstobayQLVVsF9xzvla4hU/TsLDOAMRQquRpUgMgYgINCmVuZHN0cmVhbQ0KZW5k b2JqDQoxMyAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0IF0NCi9Gb250IDw8DQovRjMg NCAwIFINCi9GNSA1IDAgUg0KPj4NCi9FeHRHU3RhdGUgPDwNCi9HUzEgNiAwIFINCj4+DQo+Pg0K ZW5kb2JqDQoxNSAwIG9iag0KPDwNCi9MZW5ndGggNTQ0DQovRmlsdGVyIC9MWldEZWNvZGUNCj4+ DQpzdHJlYW0NCoAMRBAoEcjODQUQiwIBeRynAjOcxARSxCBiMxALRiMhANo2IBuOY4cjLCDNCCEV IQLyMNYGICpJwUORcORsIBhOBBNJtAxkNhcMBpIBjAiobYROaUIINCBQLRSVDVKyNGKNMhgLhmMp cLayMBgOJgRKcIKjUwVLJdV4sLhoOI5X7DY4RXqCMIwVDHSbvNyod4QWxQQRSLRoKDdhRyKDyKRi NRQICVhY2KDDhcgdsuLchZo0MhQczLmBQcsKNxQdhSMxQbNHnBQdMph6hkDJihRr8gcNxusRtxbi 99ieDsRAczpm8hso1hzrEjHpDfuDdwMWaeYMcOaenxTccxSXSoSrqMRcOBgN4z5sf6ipZAVT7PVK tMKxWq5GblYvfZfmtKWpemK2reuK7v4+C5I4vS+LAozAAUwQjjKxIcNyFIYNKNIxhAJAqMo1gqCg wsLBA0bKjkOQ3jkszKjGN4yDKEA6DkMMKtCNgwjo7kbxmN7ju6GIbBQNoUhkGMLwy5jFjQFMLDS6 knBQM8pM8yo6yk8DIDCMTXBAMTKSGxoZQyEAkxGFsLTRCwWMoyIyjmOAyjGNIwjYNkxzLKDvSrJY USbC0ZDgkjRRuMcZDeMzwvGpL1hc7SXP6BS5KMvdJrvBcIME7rIMS1FENI0wWtYEEizIFFONLGQ0 jcOgy1Ex8iSkMrgMhOtXBA3jYVE1lUjwFLUDTOAXUW8gFCKlQFICDQplbmRzdHJlYW0NCmVuZG9i ag0KMTYgMCBvYmoNCjw8DQovUHJvY1NldCBbL1BERiAvVGV4dCBdDQovRm9udCA8PA0KL0YzIDQg MCBSDQovRjUgNSAwIFINCj4+DQovRXh0R1N0YXRlIDw8DQovR1MxIDYgMCBSDQo+Pg0KPj4NCmVu ZG9iag0KMTcgMCBvYmoNCjw8DQovVHlwZSAvSGFsZnRvbmUNCi9IYWxmdG9uZVR5cGUgMQ0KL0hh bGZ0b25lTmFtZSAoRGVmYXVsdCkNCi9GcmVxdWVuY3kgNjANCi9BbmdsZSA0NQ0KL1Nwb3RGdW5j dGlvbiAvUm91bmQNCj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlwZSAvRXh0R1N0YXRlDQov U0EgZmFsc2UNCi9PUCBmYWxzZQ0KL0hUIC9EZWZhdWx0DQo+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8 PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YzDQovRW5jb2RpbmcgMTgg MCBSDQovQmFzZUZvbnQgL0hlbHZldGljYQ0KPj4NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9UeXBl IC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GNQ0KL0VuY29kaW5nIDE4IDAgUg0KL0Jh c2VGb250IC9UaW1lcy1Sb21hbg0KPj4NCmVuZG9iag0KMTggMCBvYmoNCjw8DQovVHlwZSAvRW5j b2RpbmcNCi9EaWZmZXJlbmNlcyBbIDAvZ3JhdmUvYWN1dGUvY2lyY3VtZmxleC90aWxkZS9tYWNy b24vYnJldmUvZG90YWNjZW50L2RpZXJlc2lzDQovcmluZy9jZWRpbGxhL2h1bmdhcnVtbGF1dC9v Z29uZWsvY2Fyb24vZG90bGVzc2kvYnVsbGV0L2J1bGxldA0KL2J1bGxldC9idWxsZXQvYnVsbGV0 L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQNCi9idWxsZXQvYnVsbGV0L2J1bGxl dC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0DQogMzkvcXVvdGVzaW5nbGUgOTYv Z3JhdmUgMTI3L2J1bGxldC9idWxsZXQvYnVsbGV0L3F1b3Rlc2luZ2xiYXNlL2Zsb3Jpbi9xdW90 ZWRibGJhc2UNCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2VyZGJsL2NpcmN1bWZsZXgvcGVydGhvdXNh bmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UNCi9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQv cXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQNCi9idWxsZXQv ZW5kYXNoL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nhcm9uL2d1aWxzaW5nbHJpZ2h0L29lDQov YnVsbGV0L2J1bGxldC9ZZGllcmVzaXMvc3BhY2UgMTY0L2N1cnJlbmN5IDE2Ni9icm9rZW5iYXIg MTY4L2RpZXJlc2lzL2NvcHlyaWdodA0KL29yZGZlbWluaW5lIDE3Mi9sb2dpY2Fsbm90L2h5cGhl bi9yZWdpc3RlcmVkL21hY3Jvbi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVyaW9yDQovdGhyZWVz dXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVyZWQvY2VkaWxsYS9vbmVzdXBlcmlvci9v cmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXINCi9vbmVoYWxmL3RocmVlcXVhcnRlcnMgMTkyL0Fn cmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVyZXNpcy9BcmluZw0KL0FFL0NjZWRp bGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJlc2lzL0lncmF2ZS9JYWN1dGUNCi9J Y2lyY3VtZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9PZ3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4 L090aWxkZQ0KL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xhc2gvVWdyYXZlL1VhY3V0ZS9VY2lyY3Vt ZmxleC9VZGllcmVzaXMvWWFjdXRlDQovVGhvcm4vZ2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2Fj aXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMvYXJpbmcNCi9hZS9jY2VkaWxsYS9lZ3JhdmUvZWFj dXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNpcy9pZ3JhdmUvaWFjdXRlDQovaWNpcmN1bWZsZXgvaWRp ZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0ZS9vY2lyY3VtZmxleC9vdGlsZGUNCi9vZGll cmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95 YWN1dGUNCi90aG9ybi95ZGllcmVzaXMNCl0NCj4+DQplbmRvYmoNCjEgMCBvYmoNCjw8DQovVHlw ZSAvUGFnZQ0KL1BhcmVudCA3IDAgUg0KL1Jlc291cmNlcyAzIDAgUg0KL0NvbnRlbnRzIDIgMCBS DQo+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNyAwIFINCi9S ZXNvdXJjZXMgMTAgMCBSDQovQ29udGVudHMgOSAwIFINCj4+DQplbmRvYmoNCjExIDAgb2JqDQo8 PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNyAwIFINCi9SZXNvdXJjZXMgMTMgMCBSDQovQ29udGVu dHMgMTIgMCBSDQo+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50 IDcgMCBSDQovUmVzb3VyY2VzIDE2IDAgUg0KL0NvbnRlbnRzIDE1IDAgUg0KPj4NCmVuZG9iag0K NyAwIG9iag0KPDwNCi9UeXBlIC9QYWdlcw0KL0tpZHMgWzEgMCBSIDggMCBSIDExIDAgUiAxNCAw IFJdDQovQ291bnQgNA0KL01lZGlhQm94IFswIDAgNjEyIDc5Ml0NCj4+DQplbmRvYmoNCjE5IDAg b2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdlcyA3IDAgUg0KPj4NCmVuZG9iag0KMjAgMCBv YmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5OTgwMjEwMTAzODE4KQ0KL1Byb2R1Y2VyIChBY3Jv YmF0IERpc3RpbGxlciAzLjAgZm9yIFdpbmRvd3MpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDIxDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTc5MzggMDAwMDAgbg0KMDAwMDAwMDAxNyAwMDAwMCBu DQowMDAwMDA0ODg5IDAwMDAwIG4NCjAwMDAwMTYyOTIgMDAwMDAgbg0KMDAwMDAxNjM5OCAwMDAw MCBuDQowMDAwMDE2MjEzIDAwMDAwIG4NCjAwMDAwMTgyOTcgMDAwMDAgbg0KMDAwMDAxODAyNiAw MDAwMCBuDQowMDAwMDA1MDA1IDAwMDAwIG4NCjAwMDAwMDk3MzAgMDAwMDAgbg0KMDAwMDAxODEx NSAwMDAwMCBuDQowMDAwMDA5ODQ3IDAwMDAwIG4NCjAwMDAwMTUyMjQgMDAwMDAgbg0KMDAwMDAx ODIwNiAwMDAwMCBuDQowMDAwMDE1MzQxIDAwMDAwIG4NCjAwMDAwMTU5NjMgMDAwMDAgbg0KMDAw MDAxNjA4MCAwMDAwMCBuDQowMDAwMDE2NTA2IDAwMDAwIG4NCjAwMDAwMTg0MDYgMDAwMDAgbg0K MDAwMDAxODQ2MiAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgMjENCi9Sb290IDE5IDAgUg0K L0luZm8gMjAgMCBSDQovSUQgWzw2OTVlZThiMThiMzdmMmQ0ZTc4YTE0ZTUwNDhkM2JhOT48Njk1 ZWU4YjE4YjM3ZjJkNGU3OGExNGU1MDQ4ZDNiYTk+XQ0KPj4NCnN0YXJ0eHJlZg0KMTg1NjkNCiUl RU9GDQo= ------ =_NextPart_000_01BD360F.BF5AF320-- From ipp-owner@pwg.org Tue Feb 10 14:36:12 1998 Delivery-Date: Tue, 10 Feb 1998 14:36:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA25897 for ; Tue, 10 Feb 1998 14:36:11 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA08602 for ; Tue, 10 Feb 1998 14:38:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA28709 for ; Tue, 10 Feb 1998 14:36:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 14:31:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28031 for ipp-outgoing; Tue, 10 Feb 1998 14:14:54 -0500 (EST) Message-ID: <34E09BE9.B4AC5AEA@parc.xerox.com> Date: Tue, 10 Feb 1998 10:26:50 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Ron Bergman CC: Roger K Debry , ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org > I think this is a good analysis. I agree that since remote users > can't do much about a job, an email notification that the job is > complete is sufficient. Perhaps to save confusion on the terms > local and remote, we could use the term email-notification-uri, > with the description that this is intended for users who are remote > from the printer, who only need notification that print is complete, > that they do not need this immediately, i.e. they are satisfied to > have the notification handled by email and delivered at whenever > they happen to open their email. Local users could use this > scheme as well if this is the level of notification they wanted. I think it's confusing the layering to have an 'email-notification-uri', since the point of using a uri is to be able to specify a resource and have the resource identifier include the mechanism by which the resource is to be contacted (email if 'mailto' and http post if 'http', as examples.) For interoperability with Internet Fax, using Message Disposition Notifications as a kind of disposition notification for printing seems perfectly reasonable. The language and syntax is capable of conveying both a human readable and machine sensible notification. I suppose the only problem is trying to find the equivalent of the 'message-id' within an IPP request. Larry -- http://www.parc.xerox.com/masinter From pwg-owner@pwg.org Tue Feb 10 15:07:52 1998 Delivery-Date: Tue, 10 Feb 1998 15:07:53 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26508 for ; Tue, 10 Feb 1998 15:07:52 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08766 for ; Tue, 10 Feb 1998 15:10:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29187 for ; Tue, 10 Feb 1998 15:07:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 15:02:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28847 for pwg-outgoing; Tue, 10 Feb 1998 14:55:07 -0500 (EST) From: don@lexmark.com Message-Id: <199802101954.AA29905@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.com Cc: Ipp@pwg.org, Pwg@pwg.org, Carterk@Us.Ibm.Com, Harryl@Us.Ibm.Com Date: Tue, 10 Feb 1998 14:54:00 -0500 Subject: Re: PWG> Austin Agenda [will there by a UPD meeting Tues evening?] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pwg@pwg.org Just in case, why not make you reservations to arrive mid-afternoon? Don From ipp-owner@pwg.org Tue Feb 10 15:19:58 1998 Delivery-Date: Tue, 10 Feb 1998 15:19:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26800 for ; Tue, 10 Feb 1998 15:19:58 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08826 for ; Tue, 10 Feb 1998 15:22:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29743 for ; Tue, 10 Feb 1998 15:19:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 15:15:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28838 for ipp-outgoing; Tue, 10 Feb 1998 14:55:01 -0500 (EST) From: don@lexmark.com Message-Id: <199802101954.AA29905@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.com Cc: Ipp@pwg.org, Pwg@pwg.org, Carterk@Us.Ibm.Com, Harryl@Us.Ibm.Com Date: Tue, 10 Feb 1998 14:54:00 -0500 Subject: IPP> Re: PWG> Austin Agenda [will there by a UPD meeting Tues evening?] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Just in case, why not make you reservations to arrive mid-afternoon? Don From pwg-owner@pwg.org Tue Feb 10 16:10:40 1998 Delivery-Date: Tue, 10 Feb 1998 16:10:40 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27442 for ; Tue, 10 Feb 1998 16:10:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09102 for ; Tue, 10 Feb 1998 16:13:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00293 for ; Tue, 10 Feb 1998 16:10:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 16:02:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29890 for pwg-outgoing; Tue, 10 Feb 1998 15:59:06 -0500 (EST) From: Keith Carter To: Cc: Harry Lewis , , Subject: PWG> IPP> Re: Meeting room for proposed UPD meeting on 3/3 Message-ID: <5040300012395568000002L082*@MHS> Date: Tue, 10 Feb 1998 15:56:27 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Don, You wrote: "I would like to propose the UPD group meet on Tuesday evening. Any violent object(ion)s? Keith, can we have the room in the evening?" The same meeting room used by the P1394 working group on Tuesday 3/3 is available for a meeting on UPD that same evening. Let me know if there is sufficient interest so I can reserve the room. Also, we'll need a start and stop time. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Tue Feb 10 17:01:27 1998 Delivery-Date: Tue, 10 Feb 1998 17:01:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28360 for ; Tue, 10 Feb 1998 17:01:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09420 for ; Tue, 10 Feb 1998 17:04:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA01463 for ; Tue, 10 Feb 1998 17:01:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 16:41:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29882 for ipp-outgoing; Tue, 10 Feb 1998 15:59:01 -0500 (EST) From: Keith Carter To: Cc: Harry Lewis , , Subject: IPP> Re: Meeting room for proposed UPD meeting on 3/3 Message-ID: <5040300012395568000002L082*@MHS> Date: Tue, 10 Feb 1998 15:56:27 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Don, You wrote: "I would like to propose the UPD group meet on Tuesday evening. Any violent object(ion)s? Keith, can we have the room in the evening?" The same meeting room used by the P1394 working group on Tuesday 3/3 is available for a meeting on UPD that same evening. Let me know if there is sufficient interest so I can reserve the room. Also, we'll need a start and stop time. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Tue Feb 10 17:12:40 1998 Delivery-Date: Tue, 10 Feb 1998 17:12:41 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28545 for ; Tue, 10 Feb 1998 17:12:19 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09479 for ; Tue, 10 Feb 1998 17:15:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02878 for ; Tue, 10 Feb 1998 17:12:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 16:59:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00192 for ipp-outgoing; Tue, 10 Feb 1998 16:08:51 -0500 (EST) Date: Tue, 10 Feb 1998 16:07:45 -0500 (EST) From: Gail Zacharias To: ipp@pwg.org Subject: IPP> IBM Client Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I have tried running the IBM client and get the following error when I select the "Submit Print Job" operation. Any suggestions? Is there something I'm doing wrong? java.lang.ArrayIndexOutOfBoundsException: 0 at ibm.boulder.penn.ipp.IPPMainFrame.submitPrintJob(IPPMainFrame.java:382) at ibm.boulder.penn.ipp.IPPMainFrame.actionPerformed(IPPMainFrame.java:281) at java.awt.MenuItem.processActionEvent(MenuItem.java:434) at java.awt.MenuItem.processEvent(MenuItem.java:398) at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:174) at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:166) at java.awt.EventDispatchThread.run(EventDispatchThread.java:65) java.lang.ArrayIndexOutOfBoundsException: 0 at ibm.boulder.penn.ipp.IPPMainFrame.submitPrintJob(IPPMainFrame.java:382) at ibm.boulder.penn.ipp.IPPMainFrame.actionPerformed(IPPMainFrame.java:281) at java.awt.MenuItem.processActionEvent(MenuItem.java:434) at java.awt.MenuItem.processEvent(MenuItem.java:398) at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:174) at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:166) at java.awt.EventDispatchThread.run(EventDispatchThread.java:65) From ipp-owner@pwg.org Tue Feb 10 17:13:08 1998 Delivery-Date: Tue, 10 Feb 1998 17:13:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28565 for ; Tue, 10 Feb 1998 17:13:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09487 for ; Tue, 10 Feb 1998 17:15:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02979 for ; Tue, 10 Feb 1998 17:12:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 17:01:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00332 for ipp-outgoing; Tue, 10 Feb 1998 16:13:00 -0500 (EST) Message-ID: <34E0C2C6.87BE7373@underscore.com> Date: Tue, 10 Feb 1998 16:12:38 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> IPP > FAQ - How should the server behave? References: <5030100017238078000002L082*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl (or anyone else), Perhaps I wasn't asking the right question, or wasn't being explicit enough, so let me re-ask the question. Is IPP currently defined such that the "server-error-service-unavailable" (0x0502) error code is used EXCLUSIVELY for the "server too busy to accept your request" condition? In particular, I am hoping this (or some other IPP error code) can be used in an unoverloaded way to precisely mean one thing, and not a bushel-basket of various conditions. ...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 Kugler wrote: > > The 0x0502 status code means "The IPP object is currently unable to handle the > request due to a temporary overloading or maintenance of the IPP object. " So, > yes, it could also mean the IPP object is down for maintenance. > > -Carl > > ipp-owner@pwg.org on 02/09/98 12:34:38 PM > Please respond to ipp-owner@pwg.org @ internet > To: Carl Kugler/Boulder/IBM@ibmus > cc: ipp@pwg.org @ internet > Subject: Re: IPP> IPP > FAQ - How should the server behave? > > Carl Kugler wrote: > > > I'd be happier to get server-error-service-unavailable (0x0502) with an > > estimate of the the length of the delay indicated in the message. A client > > could then give a user the choice of canceling, retrying, or queuing locally > > and retrying after delay. At that point the user might decide to try another > > printer, or just queue the job locally (client side) and go on. > > Is the "server-error-service-unavailable" (0x0502) error code used > for any other type of error condition? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 10 18:01:08 1998 Delivery-Date: Tue, 10 Feb 1998 18:01:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29281 for ; Tue, 10 Feb 1998 18:01:08 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09727 for ; Tue, 10 Feb 1998 18:03:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04310 for ; Tue, 10 Feb 1998 18:00:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 17:51:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03517 for ipp-outgoing; Tue, 10 Feb 1998 17:33:31 -0500 (EST) Message-ID: <34E0D5AD.A4D2C81C@underscore.com> Date: Tue, 10 Feb 1998 17:33:17 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: upd@pwg.org CC: IPP Mailing List Subject: IPP> Background for the upcoming Austin meeting (3 March 98) Content-Type: multipart/mixed; boundary="------------687EAB7FDC2369E2CDD9E156" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------687EAB7FDC2369E2CDD9E156 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For the record, the attached message serves as the first background material for the expected UPD meeting to be held as part of the regularly scheduled PWG meeting series. Note that as of this writing, the UPD meeting is tentatively planned for Tuesday *night*, March 3rd. To be consistent with all other PWG projects, all correspondence about UPD (and related discussions) should be directed to the official PWG UPD mailing list (mailto:upd@pwg.org). As usual, cross-postings to other lists should be avoided whenever possible. ...jay PS: This message is cross-posted to the IPP list so as to encourage IPP participants to use the UPD list, as necessary. ---------------------------------------------------------------------- -- 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 -- ---------------------------------------------------------------------- --------------687EAB7FDC2369E2CDD9E156 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id RAA21712 for ; Tue, 10 Feb 1998 17:11:05 -0500 (EST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id RAA21286; Tue, 10 Feb 1998 17:06:29 -0500 Received: from US.IBM.COM (d03lms03.boulder.ibm.com [9.99.80.13]) by relay1.server.ibm.com (8.8.7/8.7) with SMTP id RAA98380; Tue, 10 Feb 1998 17:07:57 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032 id 5030300017787455; Tue, 10 Feb 1998 17:15:47 -0500 From: Harry Lewis To: Cc: Subject: Re: PWG> Austin Agenda Message-ID: <5030300017787455000002L052*@MHS> Date: Tue, 10 Feb 1998 17:15:47 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In case anyone missed it... >What topic(s) are driving the need for a meeting? Can you give >some sort of an overview or explanation as to why the meeting >is being held? (Or did I miss that in another message?) here is an excerpt form the Maui PWG minutes regarding UPD... where it = was determined that there was enough interest in UPD to warrant more discus= sion. Universal Print Driver Microsoft has incorporated a technology, similar to the Postscript PPD,= for describing printer characteristics to drivers in NT5.0. They call it th= e GPD. They already have support for about 1000 printers (including the NP12/1= 7/24). Microsoft is offering the GPD specification to the PWG for standardizat= ion and potential cross platform adoption. If this occurs, print driver develo= pment could (hypothetically) be reduced to simply producing a PPD file for Po= stscript and a GPD file for PCL. The topic will be discussed further in March an= d also in a private meeting with Microsoft which I am hoping to achieve, here = in Boulder, during February. Further - Paul Moorue reintroduced the idea of a Universal Printer Driv= er, this time, based on Microsoft's GPD (Generic Printer Description) printer dr= iver syntax. This new driver technology for Windows uses a printer descripti= on file like the Postscript PPD but applies it to any raster printer (PCL etc).= The result is one "universal" driver with many GPD files that enable the cl= ient build the right PDL for each printer. About 1000 printers are already d= escribed in this syntax on the NT5.0 Beta DDK. A GPD is about 30K bytes per prin= ter. The ASCII GPD file can express device options, limitations between feat= ures (ex. "don't allow envelopes unless AUX tray is installed" or ("can't st= aple if media is transparency") and may be used to dynamically build the pri= nt driver UI. Settings can be grouped, for example, for the "fastest", or = "highest quality". Currently, the GPD is static or manually updated. A future improvement could be to dynamically update the GPD from something like = a Printer MIB database, preferable using IPP. Microsoft is offering the syntax as a model for standardization, beyond= the Windows platform. There was enough interest that an agenda item has bee= n agreed to for the March meeting in Austin. People would like an opportunity to= look at the spec prior to this meeting. Concern was expressed that, in general= , job control should be migrated out of PDLs into the control of job submissi= on languages or protocols (like IPP, PJL or the Adobe Job Ticket). Some participants were also concerned about loss of product differentiation = if one Universal Print Driver were to become ubiquitous. Others wondered if it= would be possible to structure the GPD in XML. Harry Lewis - IBM Printing Systems = --------------687EAB7FDC2369E2CDD9E156-- From ipp-owner@pwg.org Tue Feb 10 20:04:47 1998 Delivery-Date: Tue, 10 Feb 1998 20:04:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA00321 for ; Tue, 10 Feb 1998 20:04:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA10078 for ; Tue, 10 Feb 1998 20:07:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06144 for ; Tue, 10 Feb 1998 20:04:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 19:37:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04131 for ipp-outgoing; Tue, 10 Feb 1998 17:57:39 -0500 (EST) Message-ID: <34E0DB4F.28144FE4@underscore.com> Date: Tue, 10 Feb 1998 17:57:19 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Larry Masinter CC: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements References: <34E09BE9.B4AC5AEA@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Larry, Thanks for this suggestion: > For interoperability with Internet Fax, using Message Disposition Notifications > as a kind of disposition notification for printing seems perfectly reasonable. > > The language and syntax is capable of conveying both a human readable > and machine sensible notification. Sorry, but "Message Disposition Notifications" is a new term to me. Can you post any pointers to this? Is this a (separately defined) communications standard, or part-and-parcel of Internet Fax? > I suppose the only problem is trying to find the equivalent of the 'message-id' > within an IPP request. I would think Harry Lewis' oft-mentioned "Job Submission Id" would be the logical choice here. Perhaps Harry can comment. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 10 20:12:00 1998 Delivery-Date: Tue, 10 Feb 1998 20:12:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA00375 for ; Tue, 10 Feb 1998 20:12:00 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA10090 for ; Tue, 10 Feb 1998 20:14:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06596 for ; Tue, 10 Feb 1998 20:11:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 19:46:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04536 for ipp-outgoing; Tue, 10 Feb 1998 18:55:40 -0500 (EST) From: Harry Lewis To: Cc: Subject: IPP> Re: Does the world need a robust host-to-device network prin Message-ID: <5030300017793190000002L002*@MHS> Date: Tue, 10 Feb 1998 18:59:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA00375 Jay, you asked people to state their views - >Enterprise environments desparately need a fully functional >host-to-device protocol for network printing. I think the "question" should be qualified with the words STANDARD or WIDELY ADOPTED. Otherwise, it can be argued that the enterprise is already full of host-to-device protocols for network printing, some of which are defacto standards (in various markets), some of which are published and updated, with a single point of control, and some which are registered, open standards... none of which are universally adopted in the world of network printing, today. When I addressed standardizing submission to the device with my late 1995 presentation on a "job information wrapper" (possibly a first step toward a *standard* full function network printing protocol), it became clear to me that members saw no need to depart from their traditional methods of supplying data to the printer. This resulted in the need for a "mapping document" to accompany the Job MIB and the mapping is fairly sparse in most cases. I'm probably just pointing out what is already implied in your statement. But, I think it is important to know exactly what we are talking about. It's the old "buy-in" routine, and I'm concerned that there are enough existing potential solutions to "the problem" that it may be hard to convince some of the benefits of moving to a new standard. Harry Lewis jkm@underscore.com on 02/10/98 03:58:31 PM Please respond to jkm@underscore.com @ internet To: ipp@pwg.org @ internet cc: Harry Lewis/Boulder/IBM@ibmus, paulmo@microsoft.com @ internet Subject: Does the world need a robust host-to-device network printing Paul Moore wrote in the "Submission vs. Monitoring and Management" thread: > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. Paul, what people were you unable to persuade? Internal Microsoft folks, or PWG folks, or both or what? For fear of sounding as if I'm beating a dead horse to death: Enterprise environments desparately need a fully functional host-to-device protocol for network printing. Am I alone in this belief??? (I know for a fact I am NOT along.) Will others in the PWG share their views using this new thread? If this belief turns out to be a minority view, then I'd certainly like to know (so I can drop the subject once and for all, if so). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 10 20:16:29 1998 Delivery-Date: Tue, 10 Feb 1998 20:16:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA00466 for ; Tue, 10 Feb 1998 20:16:28 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA10096 for ; Tue, 10 Feb 1998 20:19:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06806 for ; Tue, 10 Feb 1998 20:16:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 19:50:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04596 for ipp-outgoing; Tue, 10 Feb 1998 19:01:18 -0500 (EST) From: Harry Lewis To: Cc: , Subject: IPP> Re: Does the world need a robust host-to-device network prin Message-ID: <5030300017793492000002L022*@MHS> Date: Tue, 10 Feb 1998 19:04:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA00466 If we were to address a new, standard, host-to-device printing protocol > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. in my opinion, it should be based on the set of attributes defined for IPP and the resulting device protocol should be as closely correlated with IPP as possible such that the mapping is very straight forward and simple. Harry Lewis From ipp-owner@pwg.org Tue Feb 10 21:20:46 1998 Delivery-Date: Tue, 10 Feb 1998 21:20:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00812 for ; Tue, 10 Feb 1998 21:20:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10206 for ; Tue, 10 Feb 1998 21:23:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07584 for ; Tue, 10 Feb 1998 21:20:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 21:01:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04799 for ipp-outgoing; Tue, 10 Feb 1998 19:10:31 -0500 (EST) Date: Tue, 10 Feb 1998 16:14:58 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9802110014.AA02768@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> IPP Server Contention Analysis Sender: ipp-owner@pwg.org Hi Randy, Would you consider not posting attachments, rather than pointers, for those of use who: 1) can't receive attachments; and 2) are without MS Word? Clueless, - Ira McDonald From ipp-owner@pwg.org Tue Feb 10 21:51:51 1998 Delivery-Date: Tue, 10 Feb 1998 21:51:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00944 for ; Tue, 10 Feb 1998 21:51:50 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10249 for ; Tue, 10 Feb 1998 21:54:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08824 for ; Tue, 10 Feb 1998 21:51:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 21:26:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04890 for ipp-outgoing; Tue, 10 Feb 1998 19:38:25 -0500 (EST) Date: Tue, 10 Feb 1998 16:22:26 -0800 (Pacific Standard Time) From: Ron Bergman To: Jay Martin cc: Ron Bergman , ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements In-Reply-To: <34E0DE6A.1385FF8B@underscore.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Jay, I would agree that several of these attributes could be multi-valued. Your example for "printer_service-notifcation-uri" is good. Also, the "local-notification-uri" could be multi-valued. For example, if you send a document to a printer at Dataproducts in Simi Valley, you could include my uri as well as a secretary. If the secretary knows that I am not in the office today, she will retrieve the document and place it in my mail box. If I am in, she will just ignore the message. A corresponding "local-notification-types-requested" should also be included. Another approach would be to have an "alternate...notification-uri", but this would always result in some limitations. The multi-valued approach is much cleaner. As we develop the scenarios, additional attributes may also be determined to be multi-valued. Tomorrows phone conference should be interesting. Unfortunately, I will not be able to participate. Ron Bergman Dataproducts Corp. On Tue, 10 Feb 1998, Jay Martin wrote: > Ron, > > > The model document should include the following attributes to support > > these requirements. > > > > 1. remote-notification-uri (Job Template Attribute) No job > > completion notification is returned to the remote user if this > > attribute is not included in the job submission request. > > > > 2. local-notification-uri (Job Template Attribute) No job > > notifications are returned to the local user if this attribute is > > not included in the job submission request. > > > > 3. Local-notification-types-requested (Job Template Attribute) An > > enum or bit map which defines the types of notifications > > requested. Includes job completion, job progress, job errors, > > printer errors, printer warnings, etc. > > > > 4. local-notification-types-default (Printer Description Attribute) > > > > 5. printer-service-notification-uri (Printer Description Attribute) > > All printer problems are reported to this URI. > > Can (should?) the URI attributes be multi-valued? > > In particular, I'm thinking the "printer-service-notification-uri" > attribute would greatly benefit from having multiple URI targets, > so as to support delivery of printer device problems to multiple > operations personnel. > > Or is the "printer-service-notification-uri" attribute to be used > for other reasons? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From ipp-owner@pwg.org Tue Feb 10 21:52:14 1998 Delivery-Date: Tue, 10 Feb 1998 21:52:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00953 for ; Tue, 10 Feb 1998 21:52:14 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10252 for ; Tue, 10 Feb 1998 21:54:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA08845 for ; Tue, 10 Feb 1998 21:52:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 21:27:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04815 for ipp-outgoing; Tue, 10 Feb 1998 19:13:17 -0500 (EST) Message-Id: <3.0.1.32.19980210160822.00cddc10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Feb 1998 16:08:22 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - How to follow up on IESG comments on IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, This is a resend of an earlier message that was caught by the S-P-A-M filter. The IETF-Announce DL contains a lot of stuff you may not be interested in, so I will forward anything I find about IPP to the IPP DL, unless people who sent comments to the other list already copied the IPP DL. Happy? Carl-Uno ----- [The following message from Carl-Uno was filtered by Majordomo as a misdirected admin request due to the word "ubscribe-say" being used within the first five lines of the message body -- /Jeff Schnitzer] Date: Fri, 6 Feb 1998 11:16:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: ADM - How to follow the fate of the IPP drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" With the message now sent to the IESG to process the IPP drafts for publishing as RFCs, they are now out of our control. If you want to find out how the next step in the processing chain develops, you should subscribe to the IETF annoncement list. See description below on how to subscribe. Carl-Uno --- The IETF announcement list is a "controlled" list that receives the following types of messages: IETF Meeting logistics, Agendas for working group and BOF sessions at IETF meetings, working group actions, Internet-Draft announcements, IESG Last Calls, IESG protocol and document actions, and RFC announcements. To join the announcement list, send a request to: ietf-announce-request@ietf.org and enter the word subscribe in the Subject line of the message. ---- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 10 23:03:48 1998 Delivery-Date: Tue, 10 Feb 1998 23:03:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08083 for ; Tue, 10 Feb 1998 23:03:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA10336 for ; Tue, 10 Feb 1998 23:06:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA10653 for ; Tue, 10 Feb 1998 23:03:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 22:44:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07036 for ipp-outgoing; Tue, 10 Feb 1998 21:03:50 -0500 (EST) Message-ID: <34E106D4.6891678@parc.xerox.com> Date: Tue, 10 Feb 1998 18:03:00 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Jay Martin CC: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements References: <34E09BE9.B4AC5AEA@parc.xerox.com> <34E0DB4F.28144FE4@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org draft-ietf-receipt-mdn-08.txt (I think it's 08), "An Extensible Message Format for Message Disposition Notifications". > This memo defines a MIME content-type [5] for message disposition > notifications (MDNs). An MDN can be used to notify the sender of a > message of any of several conditions that may occur after successful > delivery, such as display of the message contents, printing of the > message, deletion (without display) of the message, or the > recipient's refusal to provide MDNs. The > "message/disposition-notification" content-type defined herein is > intended for use within the framework of the "multipart/report" > content type defined in RFC 1892 [7]. A "print disposition notification" could be returned as a multipart/report containing a message/disposition-notification or possibly you could invent a new notification, e.g., message/print-notification. -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Tue Feb 10 23:14:32 1998 Delivery-Date: Tue, 10 Feb 1998 23:14:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08134 for ; Tue, 10 Feb 1998 23:14:32 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA10356 for ; Tue, 10 Feb 1998 23:17:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11442 for ; Tue, 10 Feb 1998 23:14:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 22:51:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07500 for ipp-outgoing; Tue, 10 Feb 1998 21:17:33 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> MOD> A New View of Notification Requirements Date: Tue, 10 Feb 1998 18:17:31 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Delivery Status Notifications (DSNs) and Message Disposition Notifications (MDNs) are all proposed extensions to SMTP to enable email senders to determine the "fate" of email messages they send. Check out the following URL: http://www.ietf.org/html.charters/receipt-charter.html Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Tuesday, February 10, 1998 2:57 PM To: Larry Masinter Cc: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements Larry, Thanks for this suggestion: > For interoperability with Internet Fax, using Message Disposition Notifications > as a kind of disposition notification for printing seems perfectly reasonable. > > The language and syntax is capable of conveying both a human readable > and machine sensible notification. Sorry, but "Message Disposition Notifications" is a new term to me. Can you post any pointers to this? Is this a (separately defined) communications standard, or part-and-parcel of Internet Fax? > I suppose the only problem is trying to find the equivalent of the 'message-id' > within an IPP request. I would think Harry Lewis' oft-mentioned "Job Submission Id" would be the logical choice here. Perhaps Harry can comment. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 10 23:14:41 1998 Delivery-Date: Tue, 10 Feb 1998 23:14:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08132 for ; Tue, 10 Feb 1998 23:14:30 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA10354 for ; Tue, 10 Feb 1998 23:17:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11433 for ; Tue, 10 Feb 1998 23:14:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 22:51:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07553 for ipp-outgoing; Tue, 10 Feb 1998 21:19:21 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> IPP Server Contention Analysis Date: Tue, 10 Feb 1998 18:19:20 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I'm assuming since I sent the document in PDF form that you are in situation #1, and cannot receive attachments. That must really hurt. I will post the PDF file to the PWG FTP server and post the list with the FTP URL. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Tuesday, February 10, 1998 4:15 PM To: ipp@pwg.org; rturner@sharplabs.com Subject: Re: IPP> IPP Server Contention Analysis Hi Randy, Would you consider not posting attachments, rather than pointers, for those of use who: 1) can't receive attachments; and 2) are without MS Word? Clueless, - Ira McDonald From ipp-owner@pwg.org Tue Feb 10 23:57:23 1998 Delivery-Date: Tue, 10 Feb 1998 23:57:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08680 for ; Tue, 10 Feb 1998 23:57:23 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10413 for ; Wed, 11 Feb 1998 00:00:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA13839 for ; Tue, 10 Feb 1998 23:57:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 23:36:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04382 for ipp-outgoing; Tue, 10 Feb 1998 18:05:56 -0500 (EST) From: KRIS_SCHOFF@HP-Boise-om8.om.hp.com X-OpenMail-Hops: 1 Date: Tue, 10 Feb 1998 16:05:32 -0700 Message-Id: In-Reply-To: <34DCA4CA.498FD46C@underscore.com> Subject: Re: IPP> Consensus on sending our drafts to the IESG MIME-Version: 1.0 TO: jkm@underscore.com CC: ipp@pwg.org, paulmo@microsoft.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org In response to Jay's query.... Yes, Hewlett-Packard agrees with Paul Moore in that we will implement what the IESG ratifies, and our aim, as well, is to promote interoperability. The intent of IPP is to enhance and standardize internet printing, not to create a political battle between companies. Kris Schoff Hewlett-Packard ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Consensus on sending our drafts to the IESG Author: Non-HP-jkm (jkm@underscore.com) at HP-Boise,mimegw7 Date: 2/7/98 10:15 AM Paul, > MS & HP will state to the IESG our concerns with the current > design (just as anybody in the Internet comunity can). And rightly so. We all look forward to seeing your concerns posted to the IESG, where a larger domain of reviewers may be able to shed additional light on this situation. > Having said that - we will implement what the IESG > ratifies. It is our aim to have maximum interoperability, > not to divide the world into different camps - that would > be a war we can all do without. This is certainly good news. We all needed to hear these "official" words from Microsoft. Whether the protocol/model is good or bad is not nearly as important as solidarity, given the critical mass nature of our efforts. Are you able to speak on behalf of HP, or should a similar statement be made from an HP representative? > Our intent is purely to do the right thing both for the > short term and the long term. We saw IPP as an opportunity > for printing to 'do it right' from day 1 as opposed to > always having to compromise on other solutions (SNMP, > LPR/LPD, ...). From ipp-owner@pwg.org Tue Feb 10 23:59:27 1998 Delivery-Date: Tue, 10 Feb 1998 23:59:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA08700 for ; Tue, 10 Feb 1998 23:59:27 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10422 for ; Wed, 11 Feb 1998 00:02:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA14062 for ; Tue, 10 Feb 1998 23:59:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 23:38:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04406 for ipp-outgoing; Tue, 10 Feb 1998 18:11:12 -0500 (EST) Message-ID: <34E0DE6A.1385FF8B@underscore.com> Date: Tue, 10 Feb 1998 18:10:34 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ron Bergman CC: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Ron, > The model document should include the following attributes to support > these requirements. > > 1. remote-notification-uri (Job Template Attribute) No job > completion notification is returned to the remote user if this > attribute is not included in the job submission request. > > 2. local-notification-uri (Job Template Attribute) No job > notifications are returned to the local user if this attribute is > not included in the job submission request. > > 3. Local-notification-types-requested (Job Template Attribute) An > enum or bit map which defines the types of notifications > requested. Includes job completion, job progress, job errors, > printer errors, printer warnings, etc. > > 4. local-notification-types-default (Printer Description Attribute) > > 5. printer-service-notification-uri (Printer Description Attribute) > All printer problems are reported to this URI. Can (should?) the URI attributes be multi-valued? In particular, I'm thinking the "printer-service-notification-uri" attribute would greatly benefit from having multiple URI targets, so as to support delivery of printer device problems to multiple operations personnel. Or is the "printer-service-notification-uri" attribute to be used for other reasons? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 00:00:16 1998 Delivery-Date: Wed, 11 Feb 1998 00:00:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA08718 for ; Wed, 11 Feb 1998 00:00:16 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10425 for ; Wed, 11 Feb 1998 00:02:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA14160 for ; Wed, 11 Feb 1998 00:00:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 23:39:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03851 for ipp-outgoing; Tue, 10 Feb 1998 17:52:54 -0500 (EST) Message-ID: <34E0DA3E.FAFF26F9@underscore.com> Date: Tue, 10 Feb 1998 17:52:46 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Paul Moore , "'Harry Lewis'" Subject: IPP> Does the world need a robust host-to-device network printing protocol? References: <5CEA8663F24DD111A96100805FFE6587030BC233@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul Moore wrote in the "Submission vs. Monitoring and Management" thread: > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. Paul, what people were you unable to persuade? Internal Microsoft folks, or PWG folks, or both or what? For fear of sounding as if I'm beating a dead horse to death: Enterprise environments desparately need a fully functional host-to-device protocol for network printing. Am I alone in this belief??? (I know for a fact I am NOT along.) Will others in the PWG share their views using this new thread? If this belief turns out to be a minority view, then I'd certainly like to know (so I can drop the subject once and for all, if so). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 00:01:46 1998 Delivery-Date: Wed, 11 Feb 1998 00:01:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA08736 for ; Wed, 11 Feb 1998 00:01:46 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10430 for ; Wed, 11 Feb 1998 00:04:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA14377 for ; Wed, 11 Feb 1998 00:01:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 23:40:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA10571 for ipp-outgoing; Tue, 10 Feb 1998 23:02:28 -0500 (EST) Message-Id: <199802110401.UAA22467@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 10 Feb 1998 20:03:20 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO latest version of XML analysis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I have just download a document on XML analysis to the following URL: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The documents are: ipp-xml-980210-6.doc MS Word 6/95. ipp-xml-980210.doc MS Word 97. ipp-xml-980210.html. HTML version This document is intended to be of interest for those of you who want to see how XML would be used for encoding IPP. It works quite well. This document is close to what Paul and I agreed to in Maui. A few changes have been made to conform to the ideas in the document "XML Data" (http:www.w3.org/TR/1998/NOTE-XML-data-0105). This document contains o the complete structure of IPP by example. o a DTD for Get-Printer-Attributes request and response. o a Schema for Get-Printer-Attributes request and response (as specified in the "XML Data"). It does a better job than the DTD. o all the examples from the IPP Protocol document plus two new ones o appendices of other rejected encoding schemes. Bob Herriot From ipp-owner@pwg.org Wed Feb 11 00:08:42 1998 Delivery-Date: Wed, 11 Feb 1998 00:08:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA08980 for ; Wed, 11 Feb 1998 00:08:42 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10452 for ; Wed, 11 Feb 1998 00:11:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA15416 for ; Wed, 11 Feb 1998 00:08:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Feb 1998 23:58:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06749 for ipp-outgoing; Tue, 10 Feb 1998 20:14:56 -0500 (EST) Message-ID: <19980211011415.9086.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: gz@harlequin.com Cc: ipp@pwg.org Subject: IPP> IBM Client Content-Type: text/plain Date: Tue, 10 Feb 1998 17:14:15 PST Sender: ipp-owner@pwg.org Write the following in the "Printer URL" field of the IBM IPP client yourmachinename/ipp Also make sure you have a filename selected before you choose the "Submit Print Job" operation. PB ::I have tried running the IBM client and get the following error when I ::select the "Submit Print Job" operation. Any suggestions? Is there something ::I'm doing wrong? ::java.lang.ArrayIndexOutOfBoundsException: 0 :: at ::ibm.boulder.penn.ipp.IPPMainFrame.submitPrintJob(IPPMainFrame.java:382) ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Feb 11 00:09:04 1998 Delivery-Date: Wed, 11 Feb 1998 00:09:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA08986 for ; Wed, 11 Feb 1998 00:08:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA10455 for ; Wed, 11 Feb 1998 00:11:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA15419 for ; Wed, 11 Feb 1998 00:08:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 00:00:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04429 for ipp-outgoing; Tue, 10 Feb 1998 18:22:18 -0500 (EST) Message-ID: <34E0E004.7CBB7E13@underscore.com> Date: Tue, 10 Feb 1998 18:17:24 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: IPP Mailing List Subject: IPP> How to monitor IESG last call comments on IPP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno, I have received several private requests for information on how to monitor comments formally submitted to the IESG on the IPP draft submission. Would you be so kind as to post some information along these lines to the IPP list for general consumption? Many thanks. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 01:29:45 1998 Delivery-Date: Wed, 11 Feb 1998 01:29:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA11020 for ; Wed, 11 Feb 1998 01:29:45 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA10581 for ; Wed, 11 Feb 1998 01:32:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA16450 for ; Wed, 11 Feb 1998 01:29:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 01:16:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA15595 for ipp-outgoing; Wed, 11 Feb 1998 00:54:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> MOD> A New View of Notification Requirements Date: Tue, 10 Feb 1998 21:55:11 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org These requirements are a perfect example of taking a simple idea like an email address to notify on job completion, and turning into an "architecture". Do we really need this complexity? I think just a simple email address to notify when a job completes would be sufficient to meet the needs of the majority of people that use this facility. I'm assuming that job completion notification is in addition to a separate method for general IPP async notification. Also, the last requirement about a URI to notify regarding printer problems is device management, and we (and the rest of the networking community) already have a solution for device management. I would like to see IPP remain a job submission, and later, a job management protocol. I'm hoping I didn't spend the last 3 - 4 years of my life developing the Printer MIB for no reason... Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Tuesday, February 10, 1998 3:11 PM To: Ron Bergman Cc: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements Ron, > The model document should include the following attributes to support > these requirements. > > 1. remote-notification-uri (Job Template Attribute) No job > completion notification is returned to the remote user if this > attribute is not included in the job submission request. > > 2. local-notification-uri (Job Template Attribute) No job > notifications are returned to the local user if this attribute is > not included in the job submission request. > > 3. Local-notification-types-requested (Job Template Attribute) An > enum or bit map which defines the types of notifications > requested. Includes job completion, job progress, job errors, > printer errors, printer warnings, etc. > > 4. local-notification-types-default (Printer Description Attribute) > > 5. printer-service-notification-uri (Printer Description Attribute) > All printer problems are reported to this URI. Can (should?) the URI attributes be multi-valued? In particular, I'm thinking the "printer-service-notification-uri" attribute would greatly benefit from having multiple URI targets, so as to support delivery of printer device problems to multiple operations personnel. Or is the "printer-service-notification-uri" attribute to be used for other reasons? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 01:58:35 1998 Delivery-Date: Wed, 11 Feb 1998 01:58:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA11136 for ; Wed, 11 Feb 1998 01:58:35 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA10596 for ; Wed, 11 Feb 1998 02:01:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA17607 for ; Wed, 11 Feb 1998 01:58:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 01:50:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA15714 for ipp-outgoing; Wed, 11 Feb 1998 01:09:36 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> contention document Date: Tue, 10 Feb 1998 22:10:07 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I posted a PDF file on the FTP server containing some ideas on IPP server contention handling. The URL is: ftp://ftp.pwg.org/pub/pwg/ipp/general/contention.pdf Randy From ipp-owner@pwg.org Wed Feb 11 01:59:44 1998 Delivery-Date: Wed, 11 Feb 1998 01:59:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA11142 for ; Wed, 11 Feb 1998 01:59:44 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA10602 for ; Wed, 11 Feb 1998 02:02:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA17746 for ; Wed, 11 Feb 1998 01:59:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 01:52:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA15775 for ipp-outgoing; Wed, 11 Feb 1998 01:13:50 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Tue, 10 Feb 1998 22:14:17 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I'm curious how this host-to-device protocol for printing would differ from IPP 1.0? Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Tuesday, February 10, 1998 2:53 PM To: ipp@pwg.org Cc: Paul Moore; 'Harry Lewis' Subject: IPP> Does the world need a robust host-to-device network printing protocol? Paul Moore wrote in the "Submission vs. Monitoring and Management" thread: > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. Paul, what people were you unable to persuade? Internal Microsoft folks, or PWG folks, or both or what? For fear of sounding as if I'm beating a dead horse to death: Enterprise environments desparately need a fully functional host-to-device protocol for network printing. Am I alone in this belief??? (I know for a fact I am NOT along.) Will others in the PWG share their views using this new thread? If this belief turns out to be a minority view, then I'd certainly like to know (so I can drop the subject once and for all, if so). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 03:58:07 1998 Delivery-Date: Wed, 11 Feb 1998 03:58:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA11620 for ; Wed, 11 Feb 1998 03:58:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA10678 for ; Wed, 11 Feb 1998 04:00:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA18506 for ; Wed, 11 Feb 1998 03:58:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 03:49:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA17926 for ipp-outgoing; Wed, 11 Feb 1998 03:29:00 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: jkm@underscore.com Cc: ipp@pwg.org Message-Id: Date: Wed, 11 Feb 1998 08:08:39 +0100 Subject: Re: IPP> IPP > FAQ - How should the server behave? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org >Carl (or anyone else), >Perhaps I wasn't asking the right question, or wasn't being >explicit enough, so let me re-ask the question. >Is IPP currently defined such that the "server-error-service-unavailable" >(0x0502) error code is used EXCLUSIVELY for the "server too busy >to accept your request" condition? >In particular, I am hoping this (or some other IPP error code) >can be used in an unoverloaded way to precisely mean one thing, >and not a bushel-basket of various conditions. >...jay If the "server-error-service-unavailable" (0x0502) error code means "server too busy to accept your request" I think the error code should say "server-warning-service-busy" or something like. However, I understands that the error code is the HTTP error code and in such case may the "server-error-service-unavailable" (0x0502) error code means that no IPP server is present at all! I can't see it's an error the IPP server is busy, it's a normal condition. /HOLST ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (+45) 44366271 Fax: (+45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Wed Feb 11 04:10:39 1998 Delivery-Date: Wed, 11 Feb 1998 04:10:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA11703 for ; Wed, 11 Feb 1998 04:10:39 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA10697 for ; Wed, 11 Feb 1998 04:13:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA19114 for ; Wed, 11 Feb 1998 04:10:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 04:06:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA17950 for ipp-outgoing; Wed, 11 Feb 1998 03:42:14 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: ipp@pwg.org Message-Id: Date: Wed, 11 Feb 1998 08:42:07 +0100 Subject: Re: IPP> FAQ - How should the server behave? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org >Carl (or anyone else), >Perhaps I wasn't asking the right question, or wasn't being >explicit enough, so let me re-ask the question. >Is IPP currently defined such that the "server-error-service-unavailable" >(0x0502) error code is used EXCLUSIVELY for the "server too busy >to accept your request" condition? >In particular, I am hoping this (or some other IPP error code) >can be used in an unoverloaded way to precisely mean one thing, >and not a bushel-basket of various conditions. >...jay If the "server-error-service-unavailable" (0x0502) error code means "server too busy to accept your request" I think the error code should say "server-warning-service-busy" or something like. However, I understands that the error code is the HTTP error code and in such case may the "server-error-service-unavailable" (0x0502) error code means that no IPP server is present at all! I can't see it's an error the IPP server is busy, it's a normal condition. /HOLST ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (+45) 44366271 Fax: (+45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Wed Feb 11 04:38:53 1998 Delivery-Date: Wed, 11 Feb 1998 04:38:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA11847 for ; Wed, 11 Feb 1998 04:38:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA10725 for ; Wed, 11 Feb 1998 04:41:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA19760 for ; Wed, 11 Feb 1998 04:38:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 04:34:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA19216 for ipp-outgoing; Wed, 11 Feb 1998 04:18:06 -0500 (EST) To: ipp@pwg.org From: "Konstantin V.Vyaznikov" Subject: RE: RE: IPP> MOD> A New View of Notification Requirements Message-ID: Date: 11 Feb 98 12:17:17 +0300 X-Priority: 3 (Normal) X-GWSamsung-Value: 1 X-GWSamsung-StatusMsg: 0 X-GWSamsung-Trace: 1 X-GWSamsung-MsgID: KVeo8dos0*KVeo8dou0*2 X-GWSamsung-PassCount: 1 X-GWSamsung-TraceInet: 1 X-GWSamsung-OrigAddress: ipp@pwg.org X-GWSamsung-Flags: 0 X-Mailer: "Groupware E-Mail". Version 1.04.095 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id EAA11847 I am not sure this List is a correct place for such information, but still. We developed a product for mail, fax and Internet fax solution, which supports Delivery Status Notifications and Message Disposition Notifications in a rather nice fashion, basing on our own technology. It would be nice to have cooperation on this or similar subjects with other companies. Sincerely yours, Dr.Konstantin Vyaznikov. Manager, Project Leader Tel: 7-(501)-797-2489 Fax: 7-(0501)-797-2502 e-mail: kv@merlin.samsung.ru Moscow, Russia. http://groupware.samsung.ru --------------------------------------- > [From: Turner, Randy > [Address: ipp-owner@pwg.org > [To: "'Jay Martin'" > [CC: "'ipp@pwg.org'" > [Date: Wed Feb 11 07:17:07 1998 > >Delivery Status Notifications (DSNs) and Message Disposition >Notifications (MDNs) are all proposed extensions to SMTP to enable email >senders to determine the "fate" of email messages they send. > >Check out the following URL: > >http://www.ietf.org/html.charters/receipt-charter.html > > >Randy > > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Tuesday, February 10, 1998 2:57 PM > To: Larry Masinter > Cc: ipp@pwg.org > Subject: Re: IPP> MOD> A New View of Notification >Requirements > > Larry, > > Thanks for this suggestion: > > > For interoperability with Internet Fax, using Message >Disposition Notifications > > as a kind of disposition notification for printing seems >perfectly reasonable. > > > > The language and syntax is capable of conveying both a human >readable > > and machine sensible notification. > > Sorry, but "Message Disposition Notifications" is a new term to >me. > Can you post any pointers to this? Is this a (separately >defined) > communications standard, or part-and-parcel of Internet Fax? > > > > I suppose the only problem is trying to find the equivalent of >the 'message-id' > > within an IPP request. > > I would think Harry Lewis' oft-mentioned "Job Submission Id" > would be the logical choice here. Perhaps Harry can comment. > > ...jay > > >---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com >-- > -- Underscore, Inc. | Voice: (603) 889-7000 >-- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 >-- > -- Hudson, NH 03051-4915 | Web: >http://www.underscore.com -- > >---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 08:47:44 1998 Delivery-Date: Wed, 11 Feb 1998 08:47:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA13501 for ; Wed, 11 Feb 1998 08:47:43 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA11087 for ; Wed, 11 Feb 1998 08:50:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA20590 for ; Wed, 11 Feb 1998 08:47:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 08:38:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA20022 for ipp-outgoing; Wed, 11 Feb 1998 08:21:49 -0500 (EST) Mime-Version: 1.0 Date: Wed, 11 Feb 1998 07:56:04 -0500 Message-ID: <00040323.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re: IPP> Does the world need a robust host-to-device network 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 strong argue in favor of such a protocol (what people are referring to as host-to-device), specifically for the Intranet environment, where we have to support several different proprietary protocols/standards today. This new protocol should cover all aspects of a distributed printing system (mananagement, queues/spooling, etc.). IPP is fine for the Internet. But the majority of print jobs will be local (Intranet). I believe this Intranet printing protocol will be far more significant than IPP, if it covers all aspects of printing, not just job submission. Of course, this might be a difficult proposition because of the "entrenched" protocols/interests/vendors. We could always consider this "total printing system" as the focus or central thrust of IPP Version 2. I think the existing IPP Requirements spec is general enough. In summary, two issues stand out to me: 1. It does not appear that IPP will have much or any impact on the multitude of printing solutions in use today (for the Intranet). 2. Lack of a ***complete*** standard printing solution within the LAN environment (Intranets included). Today we have to use proprietary solutions. Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: IPP> Does the world need a robust host-to-device network pri Author: Jay Martin at INTERNET Date: 2/10/98 5:52 PM Paul Moore wrote in the "Submission vs. Monitoring and Management" thread: > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. Paul, what people were you unable to persuade? Internal Microsoft folks, or PWG folks, or both or what? For fear of sounding as if I'm beating a dead horse to death: Enterprise environments desparately need a fully functional host-to-device protocol for network printing. Am I alone in this belief??? (I know for a fact I am NOT along.) Will others in the PWG share their views using this new thread? If this belief turns out to be a minority view, then I'd certainly like to know (so I can drop the subject once and for all, if so). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 11:12:25 1998 Delivery-Date: Wed, 11 Feb 1998 11:12:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15517 for ; Wed, 11 Feb 1998 11:12:24 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA11793 for ; Wed, 11 Feb 1998 11:15:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21790 for ; Wed, 11 Feb 1998 11:12:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 10:54:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20947 for ipp-outgoing; Wed, 11 Feb 1998 10:14:33 -0500 (EST) Message-ID: <34E1BF52.F335A715@underscore.com> Date: Wed, 11 Feb 1998 10:10:10 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> ADM - How to follow up on IESG comments on IPP References: <3.0.1.32.19980210160822.00cddc10@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Does subscribing to the "ietf-announce@ietf.org" DL give you copies of IESG Last Call comments? (I didn't think it did.) ...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 wrote: > > Hi, > > This is a resend of an earlier message that was caught by the S-P-A-M filter. > > The IETF-Announce DL contains a lot of stuff you may not be interested in, > so I will forward anything I find about IPP to the IPP DL, unless people > who sent comments to the other list already copied the IPP DL. > > Happy? > > Carl-Uno > > ----- > [The following message from Carl-Uno was filtered by Majordomo as a > misdirected admin request due to the word "ubscribe-say" being used > within the first five lines of the message body -- /Jeff Schnitzer] > > Date: Fri, 6 Feb 1998 11:16:39 PST > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: ADM - How to follow the fate of the IPP drafts > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > > With the message now sent to the IESG to process the IPP drafts for > publishing as RFCs, they are now out of our control. If you want to find > out how the next step in the processing chain develops, you should > subscribe to the IETF annoncement list. See description below on how to > subscribe. > > Carl-Uno > > --- > > The IETF announcement list is a "controlled" list that receives the > following types of messages: > > IETF Meeting logistics, > Agendas for working group and BOF sessions at IETF meetings, > working group actions, > Internet-Draft announcements, > IESG Last Calls, > IESG protocol and document actions, and > RFC announcements. > > To join the announcement list, send a request to: > > ietf-announce-request@ietf.org and enter the word subscribe in the > Subject line of the message. > > ---- > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 11 11:26:42 1998 Delivery-Date: Wed, 11 Feb 1998 11:26:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15670 for ; Wed, 11 Feb 1998 11:26:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA11838 for ; Wed, 11 Feb 1998 11:29:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22312 for ; Wed, 11 Feb 1998 11:26:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 11:07:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20962 for ipp-outgoing; Wed, 11 Feb 1998 10:19:23 -0500 (EST) Message-ID: <34E1C165.880700B2@underscore.com> Date: Wed, 11 Feb 1998 10:19:01 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Larry Masinter CC: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements References: <34E09BE9.B4AC5AEA@parc.xerox.com> <34E0DB4F.28144FE4@underscore.com> <34E106D4.6891678@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Thanks for the additional info, Larry. For the record, here's the URL for the document Larry had cited: http://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-08.txt ...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 -- ---------------------------------------------------------------------- Larry Masinter wrote: > > draft-ietf-receipt-mdn-08.txt (I think it's 08), > "An Extensible Message Format for Message Disposition Notifications". > > > This memo defines a MIME content-type [5] for message disposition > > notifications (MDNs). An MDN can be used to notify the sender of a > > message of any of several conditions that may occur after successful > > delivery, such as display of the message contents, printing of the > > message, deletion (without display) of the message, or the > > recipient's refusal to provide MDNs. The > > "message/disposition-notification" content-type defined herein is > > intended for use within the framework of the "multipart/report" > > content type defined in RFC 1892 [7]. > > A "print disposition notification" could be returned as a multipart/report > containing a message/disposition-notification > or possibly you could invent a new notification, e.g., > message/print-notification. > > -- > http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Feb 11 14:01:53 1998 Delivery-Date: Wed, 11 Feb 1998 14:01:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17405 for ; Wed, 11 Feb 1998 14:01:48 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13031 for ; Wed, 11 Feb 1998 14:04:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27482 for ; Wed, 11 Feb 1998 14:01:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 13:06:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24106 for ipp-outgoing; Wed, 11 Feb 1998 12:27:38 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> IPP > FAQ - How should the server behave? Message-ID: <5030100017324952000002L022*@MHS> Date: Wed, 11 Feb 1998 12:24:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA17405 I think would be a good idea to define a new *status* code for this purpose. It could be an informational code, rather than an error code, if this condition is considered normal. It might also be worthwhile to invent an attribute to codify the delay estimate. -Carl jkm@underscore.com on 02/11/98 09:42:40 AM Please respond to jkm@underscore.com @ internet To: ipp@pwg.org @ internet cc: Carl Kugler/Boulder/IBM@ibmus Subject: Re: IPP> IPP > FAQ - How should the server behave? Would it be too much to ask that IPP define a specific error code for the "server to busy to accept requests" condition? ...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 Kugler wrote: > > > Is IPP currently defined such that the "server-error-service-unavailable" > > (0x0502) error code is used EXCLUSIVELY for the "server too busy > > to accept your request" condition? > > No. > > -Carl > > jkm@underscore.com on 02/10/98 02:13:27 PM > Please respond to jkm@underscore.com @ internet > To: Carl Kugler/Boulder/IBM@ibmus > cc: ipp@pwg.org @ internet > Subject: Re: IPP> IPP > FAQ - How should the server behave? > > Carl (or anyone else), > > Perhaps I wasn't asking the right question, or wasn't being > explicit enough, so let me re-ask the question. > > Is IPP currently defined such that the "server-error-service-unavailable" > (0x0502) error code is used EXCLUSIVELY for the "server too busy > to accept your request" condition? > > In particular, I am hoping this (or some other IPP error code) > can be used in an unoverloaded way to precisely mean one thing, > and not a bushel-basket of various conditions. > > ...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 Kugler wrote: > > > > The 0x0502 status code means "The IPP object is currently unable to handle the > > request due to a temporary overloading or maintenance of the IPP object. " > So, > > yes, it could also mean the IPP object is down for maintenance. > > > > -Carl > > > > ipp-owner@pwg.org on 02/09/98 12:34:38 PM > > Please respond to ipp-owner@pwg.org @ internet > > To: Carl Kugler/Boulder/IBM@ibmus > > cc: ipp@pwg.org @ internet > > Subject: Re: IPP> IPP > FAQ - How should the server behave? > > > > Carl Kugler wrote: > > > > > I'd be happier to get server-error-service-unavailable (0x0502) with an > > > estimate of the the length of the delay indicated in the message. A client > > > could then give a user the choice of canceling, retrying, or queuing locally > > > and retrying after delay. At that point the user might decide to try > another > > > printer, or just queue the job locally (client side) and go on. > > > > Is the "server-error-service-unavailable" (0x0502) error code used > > for any other type of error condition? > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 14:06:10 1998 Delivery-Date: Wed, 11 Feb 1998 14:06:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17460 for ; Wed, 11 Feb 1998 14:06:09 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13056 for ; Wed, 11 Feb 1998 14:08:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27693 for ; Wed, 11 Feb 1998 14:05:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 13:06:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23842 for ipp-outgoing; Wed, 11 Feb 1998 12:09:29 -0500 (EST) Message-ID: <34E1DAF5.158D73DB@underscore.com> Date: Wed, 11 Feb 1998 12:08:05 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: ipp@pwg.org Subject: IPP> Re: Does the world need a robust host-to-device network prin References: <5CEA8663F24DD111A96100805FFE6587030BC246@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, > I dont really care what it is as long as :- > > - everybody accepts that it is worth doing and implments it > - it does what I need > - it is consistent with IPP. You first item is a foregone conclusion. Everyone can agree to that. Coming from Microsoft, we are all anxious to hear exactly what it is you need. Does IPP as it currently stand give you what you need? Or will Microsoft be "forced" into adding all kinds of vendor-specific extensions to fill the holes? > The problem is that printer manufacurers want to put IPP in their devices, > they are reluctant to put yet another print protocol in as well. As don > wright said 'I'd rather boil the ocean' You know, I could have sworn Don said "I'd rather boil HP"... ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 14:53:41 1998 Delivery-Date: Wed, 11 Feb 1998 14:53:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA18844 for ; Wed, 11 Feb 1998 14:53:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13367 for ; Wed, 11 Feb 1998 14:56:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00733 for ; Wed, 11 Feb 1998 14:53:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 14:25:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23843 for ipp-outgoing; Wed, 11 Feb 1998 12:09:30 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC247@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Jay Martin'" , ipp@pwg.org Cc: "'Harry Lewis'" Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Wed, 11 Feb 1998 09:04:26 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org You are not alone in thinking the world needs a robust, fully-featured network printer interface. Personally I think this is MUCH MORE VALUABLE to corporates than IPP - sadly it is not in the glamorous glow of the Internet with all its unlimited budgets, hype, etc. Who couldn't I persuade - Xerox, IBM, Canon, Sharp, Novell.... I had this discussion on the first day I attended a WG meeting - 'we need two things, something to provide high level features for users on the Internet, something to fix the 'LPD sucks' problem'. I continued to state this every time I was asked. Eventually I got the message that this was not a welcome topic, and still isn't. > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Tuesday, February 10, 1998 2:53 PM > To: ipp@pwg.org > Cc: Paul Moore; 'Harry Lewis' > Subject: IPP> Does the world need a robust host-to-device network > printing protocol? > > Paul Moore wrote in the "Submission vs. Monitoring and Management" > thread: > > > Now if somebody wants to have a separate debate about writing a really > > robust protocol for interfacing to printers (and I mean the real > hardware > > not some logical abstraction) then that will suit me fine. Lets start a > new > > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > > wanted to do but could not persuade enough people. > > Paul, what people were you unable to persuade? Internal Microsoft > folks, or PWG folks, or both or what? > > For fear of sounding as if I'm beating a dead horse to death: > > Enterprise environments desparately need a fully functional > host-to-device protocol for network printing. > > Am I alone in this belief??? (I know for a fact I am NOT along.) > > Will others in the PWG share their views using this new thread? > If this belief turns out to be a minority view, then I'd certainly > like to know (so I can drop the subject once and for all, if so). > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 15:04:42 1998 Delivery-Date: Wed, 11 Feb 1998 15:04:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA19290 for ; Wed, 11 Feb 1998 15:04:41 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA13441 for ; Wed, 11 Feb 1998 15:07:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27602 for ; Wed, 11 Feb 1998 14:03:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 13:06:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24254 for ipp-outgoing; Wed, 11 Feb 1998 12:41:11 -0500 (EST) Message-ID: <34E1E24E.F2BFEF2@underscore.com> Date: Wed, 11 Feb 1998 12:39:26 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? References: <5CEA8663F24DD111A96100805FFE6587030BC247@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, > You are not alone in thinking the world needs a robust, fully-featured > network printer interface. Personally I think this is MUCH MORE VALUABLE to > corporates than IPP - sadly it is not in the glamorous glow of the Internet > with all its unlimited budgets, hype, etc. Thanks for making this statement. It's great to see that we agree on this fundamental opinion. > Who couldn't I persuade - Xerox, IBM, Canon, Sharp, Novell.... I had this > discussion on the first day I attended a WG meeting - 'we need two things, > something to provide high level features for users on the Internet, > something to fix the 'LPD sucks' problem'. I continued to state this every > time I was asked. Eventually I got the message that this was not a welcome > topic, and still isn't. The opinions of these companies would appear quite disconcerting, except for one important fact... Those companies (as well as myself) originally believed IPP-over-HTTP would give us these additional (*critical*) capabilities right out of the box with virtually no effort on our part: 1. Firewall punch-thru 2. Security framework 3. Zero-client-side software installation As I have said before, ALL of these fine, excellent assumptions have now seriously fallen by the wayside. And yet, we're left with this mess called IPP-over-HTTP. Once we realized our initital assumptions were proven false, why did we continue on this track? I encourage others in the PWG to comment on this (please!). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 15:35:21 1998 Delivery-Date: Wed, 11 Feb 1998 15:35:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20640 for ; Wed, 11 Feb 1998 15:35:21 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA13616 for ; Wed, 11 Feb 1998 15:38:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA03810 for ; Wed, 11 Feb 1998 15:35:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 15:05:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00673 for ipp-outgoing; Wed, 11 Feb 1998 14:51:24 -0500 (EST) Message-Id: <34E1FEE0.37BC0515@dazel.com> Date: Wed, 11 Feb 1998 13:41:20 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Cc: Jay Martin Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? References: <5CEA8663F24DD111A96100805FFE6587030BC233@red-msg-51.dns.microsoft.com> <34E0DA3E.FAFF26F9@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Jay Martin wrote: > > ... > > For fear of sounding as if I'm beating a dead horse to death: > > Enterprise environments desparately need a fully functional > host-to-device protocol for network printing. > > Am I alone in this belief??? (I know for a fact I am NOT along.) No, Jay, you are not "along" (sic). I would like to second (or third or fourth) the idea of an industrial-strength host-to-device protocol as *exactly* what I need. As others have mentioned, it would *have* to be widely implemented to do any good (whether it is a standard or not, I could care less; little good that did for TIPSI). You know, I will have to admit being slow to come around to this view. Like many, I was intrigued with the idea of this *inter*net printing protocol that could be implemented on servers and printers alike, and solve all the world's printing problems. However, I have become more and more disillusioned with the comprimises that we make to try and satisfy both ends of the spectrum (embedded printers all the way up to fat print servers). Also, like some, I do not believe that HTTP has been the Holy Grail that we all thought it would be. There have been two observations that have led to some deeper insight for me on this issue. The first is that most of the prints in the world go from a client to a print server, or process of some kind, and then to the printing device. There are very few (any?) cases of a client application talking directly to a printing device. So what, you ask? Well, I say that this implies that there is no requirement for a single protocol that solves both the client->server and server->printer cases. That was one of the things that we were trying to do with IPP. The second observation has to do with deployment. How many of us really believe that people are going to be hooking up raw printing hardware (i.e., printers) directly to the internet for people to print to? If an *inter*net printing protocol is going to be deployed, ya' gotta' believe that it is going to be on a high-powered print server/spooler of some kind. Although only a very small sample, I confirmed this with several system administrators (and a marketeer or two ;-). Once again, I think that this argues for separate requirements for the client->server and server->printer protocols. I would love to see a simple *intra*net printing protocol for driving printing hardware. Is it IPP? No, I do not believe that it is IPP as it stands; I think that if people were to look at this as an *intra*net protocol to drive print hardware, there would probably be some thinning and some changes. I think that there are at least two "new" and important concepts coming out of IPP that I would like to see in a server->printer protocol: the separation of job control instructions (attributes) from the print data stream, and, in a related fashion, the ability for the printer to override instructions in the print data stream with the job control instructions. What else would be in that protocol? Would it be just job submission (and modification/cancellation?), or would it include job and printer monitoring? Well, there are at least a couple of vendors that have already implemented monitoring via SNMP, and if that is what the printer vendors want to use, then (gulp) us print servers will just have to be happy with that. Would it be built on top of HTTP? I do not care; once again, if that is what the printer vendors want to do, so be it. The important point is that it just be a single protocol that becomes ubiquitous. One final point about this ubiquity. It does not do us any good to design something that nobody builds. I do not know much about the history of TIPSI, but it seems a valid case in point. Although it is not necessarily a "pretty" protocol, it at least seems to address these issues of a host->device protocol (in a transport-independent fashion, to boot!). But nobody built it (sorry, Don), so who cares? Sorry about the length of this reply... I guess I had more to say than I thought! ramblin'... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Feb 11 15:39:06 1998 Delivery-Date: Wed, 11 Feb 1998 15:39:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA20760 for ; Wed, 11 Feb 1998 15:39:06 -0500 (EST) Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA13643 for ; Wed, 11 Feb 1998 15:41:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04115 for ; Wed, 11 Feb 1998 15:38:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 15:05:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00885 for ipp-outgoing; Wed, 11 Feb 1998 15:00:00 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC250@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> MS XML Proposal Date: Wed, 11 Feb 1998 11:58:57 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org These documents are now availble at ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ called draft-xml4ipp* They are in Word97, word95, html and PDF format (thanks to Jay for the last one). Read and enjoy :-) From paulmo@microsoft.com Wed Feb 11 17:38:17 1998 Delivery-Date: Wed, 11 Feb 1998 17:38:18 -0500 Return-Path: paulmo@microsoft.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23129 for ; Wed, 11 Feb 1998 17:38:17 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14373 for ; Wed, 11 Feb 1998 17:40:59 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23125 for ; Wed, 11 Feb 1998 17:38:14 -0500 (EST) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id <1X7BTB1H>; Wed, 11 Feb 1998 14:26:44 -0800 Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC253@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'iesg@ietf.org'" Cc: "'ipp@pwg.org'" Subject: IPP Last Call Date: Wed, 11 Feb 1998 14:27:53 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Re: Internet Printing Protocol (IPP) V1 > I have the following comments on this proposal. You should be aware that I > was an active participant in this process, attended many of the WG > meetings and am listed as an author of the current protocol prosposal. > I beleive that the current protocol is not the best solution and that XML should be used as the data representation. This is a change from our original position (that caused me to propose the current protocol). The initial idea was to use ASCII text but in a 'attribute:value' format. It was agreed that this was not robust enough and that no standard method of representing structed data in an ASCII stream existed - hence the current 'binary' protocol. > The reason for proposing this change :- > > a) if XML had been available at the time we would have chosen to use it. > b) It provides a much less ambigous specification (this leads to better > interop convergence) > c) It is generically parsable by any entity that understands XML (useful > for protcol analysers, proxies, etc.) > d) It is 'future-proof' in that many of the issues we deferred in IPP1 > will require a rework of the binary protocol. In fact we know of some > requirements that will not only be impossible to carry using the current > spec but there are others that will break version 1 parsers. The > requirements include the ability to pass structured data, arrays of > structs and nested structures. These are already addressed by XML. > > A full specification of the proposed XML mapping for IPP is at > ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/draft-xml4ipp.pdf > > > Paul Moore > Windows NT Program Managment > Microsoft Corporation > 425 936 0908 From moore@cs.utk.edu Wed Feb 11 18:00:43 1998 Delivery-Date: Wed, 11 Feb 1998 18:00:44 -0500 Return-Path: moore@cs.utk.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23581 for ; Wed, 11 Feb 1998 18:00:42 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA14492 for ; Wed, 11 Feb 1998 18:03:24 -0500 (EST) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23578 for ; Wed, 11 Feb 1998 18:00:38 -0500 (EST) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA23002; Wed, 11 Feb 1998 17:59:08 -0500 (EST) Message-Id: <199802112259.RAA23002@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: iesg@ns.ietf.org, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP Last Call In-reply-to: Your message of "Wed, 11 Feb 1998 14:27:53 PST." <5CEA8663F24DD111A96100805FFE6587030BC253@red-msg-51.dns.microsoft.com> Date: Wed, 11 Feb 1998 17:59:07 -0500 Sender: moore@cs.utk.edu Paul, Please provide more detail about a couple of your objections to IPP's chosen data representation. In particular: > a) if XML had been available at the time we would have chosen to use it. Okay, but IPP-WG chose not to do so, both "at the time", and again very recently. > b) It provides a much less ambigous specification (this leads to better > interop convergence) Can you point out ambiguities in the existing IPP specification which would be made less ambiguous by reference to XML? Keep in mind that there's more than one way to make a specification ambiguous or difficult to assimilate (the two the same effect on the quality of products developed from the specification). For instance, referencing some other spec might make the IPP less ambiguous, but more difficult to assimilate, due to the greater learning curve. -- Keith Moore http://www.cs.utk.edu/~moore/ Citizen of cyberspace, currently residing in Knoxville, Tennessee, USA. From paulmo@microsoft.com Wed Feb 11 19:19:38 1998 Delivery-Date: Wed, 11 Feb 1998 19:19:38 -0500 Return-Path: paulmo@microsoft.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24575 for ; Wed, 11 Feb 1998 19:19:38 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA14726 for ; Wed, 11 Feb 1998 19:22:19 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24572 for ; Wed, 11 Feb 1998 19:19:32 -0500 (EST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.1960.3) id <13QJ6S8C>; Wed, 11 Feb 1998 16:19:34 -0800 Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC256@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Keith Moore'" Cc: iesg@ns.ietf.org, ipp@pwg.org Subject: RE: IPP Last Call Date: Wed, 11 Feb 1998 16:19:32 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) a) It was not turned down 'at the time' - the choice did not exist. It was turned down at the last WG for two reasons (mainly) - It was too late - No complete proposal was presented, I actually elected to present it that way so that people could debate the desirability in general rather than get into detailed drill-downs. In retrospect that was probably a mistake, this is why I have now made a complete proposal available. b) What I was trying to say was that - since the proposal is presented in terms of a spec that has a wide industry acceptance and is already widely 'interpreted' (you can buy books on it) this means that the is less opportunity for misunderstanding. > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Wednesday, February 11, 1998 2:59 PM > To: Paul Moore > Cc: iesg@ns.ietf.org; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP Last Call > > Paul, > > Please provide more detail about a couple of your objections to > IPP's chosen data representation. > > In particular: > > > a) if XML had been available at the time we would have chosen to use it. > > Okay, but IPP-WG chose not to do so, both "at the time", and again > very recently. > > > b) It provides a much less ambigous specification (this leads to better > > interop convergence) > > Can you point out ambiguities in the existing IPP specification > which would be made less ambiguous by reference to XML? > > Keep in mind that there's more than one way to make a specification > ambiguous or difficult to assimilate (the two the same effect > on the quality of products developed from the specification). > > For instance, referencing some other spec might make the IPP less > ambiguous, > but more difficult to assimilate, due to the greater learning curve. > > -- > Keith Moore > http://www.cs.utk.edu/~moore/ > Citizen of cyberspace, currently residing in Knoxville, Tennessee, USA. From moore@cs.utk.edu Wed Feb 11 19:28:20 1998 Delivery-Date: Wed, 11 Feb 1998 19:28:21 -0500 Return-Path: moore@cs.utk.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24637 for ; Wed, 11 Feb 1998 19:28:19 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA14749 for ; Wed, 11 Feb 1998 19:31:00 -0500 (EST) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24634 for ; Wed, 11 Feb 1998 19:28:17 -0500 (EST) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id TAA23558; Wed, 11 Feb 1998 19:27:35 -0500 (EST) Message-Id: <199802120027.TAA23558@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , iesg@ns.ietf.org, ipp@pwg.org Subject: Re: IPP Last Call In-reply-to: Your message of "Wed, 11 Feb 1998 16:19:32 PST." <5CEA8663F24DD111A96100805FFE6587030BC256@red-msg-51.dns.microsoft.com> Date: Wed, 11 Feb 1998 19:27:32 -0500 Sender: moore@cs.utk.edu > b) What I was trying to say was that - since the proposal is presented in > terms of a spec that has a wide industry acceptance and is already widely > 'interpreted' (you can buy books on it) this means that the is less > opportunity for misunderstanding. the existence of books on XML is not necessarily a favorable indicator. if XML encoding is simple and clearly defined in the specs, why do we need those books? -- Keith Moore http://www.cs.utk.edu/~moore/ Citizen of cyberspace, currently residing in Knoxville, Tennessee, USA. From ipp-owner@pwg.org Wed Feb 11 19:44:27 1998 Delivery-Date: Wed, 11 Feb 1998 19:44:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24737 for ; Wed, 11 Feb 1998 19:44:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA14790 for ; Wed, 11 Feb 1998 19:47:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06122 for ; Wed, 11 Feb 1998 17:13:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 16:45:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA04996 for ipp-outgoing; Wed, 11 Feb 1998 16:09:21 -0500 (EST) From: don@lexmark.com Message-Id: <199802112108.AA05321@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: walker@dazel.com Cc: Ipp@pwg.org, Jkm@Underscore.Com Date: Wed, 11 Feb 1998 16:07:35 -0500 Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Jim Walker said: >One final point about this ubiquity. It does not do us any good to >design something that nobody builds. I do not know much about the >history of TIPSI, but it seems a valid case in point. Although it >is not necessarily a "pretty" protocol, it at least seems to address >these issues of a host->device protocol (in a transport-independent >fashion, to boot!). But nobody built it (sorry, Don), so who cares? Been there, done that. Several of us, including many from outside Lexmark worked long and hard on this with IEEE Std 1284.1-1997 (aka TIPSI or NPAP) to create a robust device to printer submission and management protocol. An obviously uninformed executive from a two-letter printer company said when asked about NPAP, "I don't know why anyone would need it." The resultant adoption rate is history. I would love to have a widely adopted protocol for this function but I am not highly motivated to plow this ground again. Tell you what, when you guys can get the work all done, I'll implement it faster than anyone else can! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jmp-owner@pwg.org Wed Feb 11 22:03:35 1998 Delivery-Date: Wed, 11 Feb 1998 22:03:35 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA25763 for ; Wed, 11 Feb 1998 22:03:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15080 for ; Wed, 11 Feb 1998 22:06:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA03141 for ; Wed, 11 Feb 1998 21:23:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 20:58:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00864 for jmp-outgoing; Wed, 11 Feb 1998 20:12:34 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> PWG meeting in Austin on 3/2-6 Message-ID: <5040300012457575000002L052*@MHS> Date: Wed, 11 Feb 1998 17:35:45 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From ipp-owner@pwg.org Wed Feb 11 22:56:00 1998 Delivery-Date: Wed, 11 Feb 1998 22:56:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA27701 for ; Wed, 11 Feb 1998 22:55:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15178 for ; Wed, 11 Feb 1998 22:58:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA08336 for ; Wed, 11 Feb 1998 22:55:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 21:16:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21629 for ipp-outgoing; Wed, 11 Feb 1998 11:09:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" , Carl-Uno Manros Cc: ipp@pwg.org Subject: RE: IPP> ADM - How to follow up on IESG comments on IPP Date: Wed, 11 Feb 1998 08:09:44 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Comments directed to WG during last-call are posted to the WG mailing list (ipp@pwg.org). Potential commenters check www.ietf.org and look at the IPP WG info, which includes charter, chair persons, mailing lists, and any mail archive info. That's how the find out which list to post with comments. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, February 11, 1998 7:10 AM To: Carl-Uno Manros Cc: ipp@pwg.org Subject: Re: IPP> ADM - How to follow up on IESG comments on IPP Does subscribing to the "ietf-announce@ietf.org" DL give you copies of IESG Last Call comments? (I didn't think it did.) ...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 wrote: > > Hi, > > This is a resend of an earlier message that was caught by the S-P-A-M filter. > > The IETF-Announce DL contains a lot of stuff you may not be interested in, > so I will forward anything I find about IPP to the IPP DL, unless people > who sent comments to the other list already copied the IPP DL. > > Happy? > > Carl-Uno > > ----- > [The following message from Carl-Uno was filtered by Majordomo as a > misdirected admin request due to the word "ubscribe-say" being used > within the first five lines of the message body -- /Jeff Schnitzer] > > Date: Fri, 6 Feb 1998 11:16:39 PST > To: ipp@pwg.org > From: Carl-Uno Manros > Subject: ADM - How to follow the fate of the IPP drafts > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > > With the message now sent to the IESG to process the IPP drafts for > publishing as RFCs, they are now out of our control. If you want to find > out how the next step in the processing chain develops, you should > subscribe to the IETF annoncement list. See description below on how to > subscribe. > > Carl-Uno > > --- > > The IETF announcement list is a "controlled" list that receives the > following types of messages: > > IETF Meeting logistics, > Agendas for working group and BOF sessions at IETF meetings, > working group actions, > Internet-Draft announcements, > IESG Last Calls, > IESG protocol and document actions, and > RFC announcements. > > To join the announcement list, send a request to: > > ietf-announce-request@ietf.org and enter the word subscribe in the > Subject line of the message. > > ---- > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 11 23:03:17 1998 Delivery-Date: Wed, 11 Feb 1998 23:03:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA02382 for ; Wed, 11 Feb 1998 23:03:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA15194 for ; Wed, 11 Feb 1998 23:05:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08748 for ; Wed, 11 Feb 1998 23:02:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 20:58:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23536 for ipp-outgoing; Wed, 11 Feb 1998 12:01:01 -0500 (EST) Message-ID: <34E1D910.E4A472D5@underscore.com> Date: Wed, 11 Feb 1998 12:00:00 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> Does the world need a robust host-to-device network prin ting protocol? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Randy, > I'm wondering if a new mapping document for IPP directly over TCP/IP (no > HTTP) would be one way to attack this lighter weight host-to-device > printing protocol? Sure, we could try to do this. Were you thinking of trying your hand at this, or have someone take a stab? Personally, I would have to decline the opportunity, since (as I mentioned before), IPP is way too closely tied to the contraints of HTTP. > I think our model document stands as a way to do printing, over > internets and intranets. We have taken a lot of strides to make sure > that the model document was transport-independent. Some may view IPP as being very transport-independent, but that doesn't mean it is the *right* kind of protocol for the job. Again, the power and simplicity of the side-band "data chennel" (ala FTP) would greatly enhance network printing, IMHO. Can IPP (as currently defined) support such a data channel? > What I would like to avoid is producing yet another printing protocol > (YAPP). I certainly understand your concern here. I, too, wish to absolutely minimize the number of supported protocols. However, the avid proponents of IPP steadfastly stated early on that IPP was for Internet use, and not necessarily for Intranet use. Yet, here we are, some 15 months later and some folks (such as Microsoft) believe this is the Last Great Protocol for network printing. And hence, this is why people are now (finally) coming out of the woodwork on this topic. > Considering that the number of mandatory stuff in IPP is pretty light, > it seems like taking this minimal IPP capability and using just TCP/IP > as a transport would be a good first strike against this > "host-to-device" protocol. I look forward to seeing such a mapping document, in whatever form. > Also, concerning the notification problem, my earlier proposal (using > lightweight, acknowledged datagrams) would be > mapping-document-independent and would be "the" way to do notifications > regardless of mapping document. Of course this assumes that all > potential mapping documents would share a common TCP/IP transport > somewhere in their design. We are in sync 100% on this topic, Randy. I'd just like to note, however, that a real, robust network printing protocol would provide for such notifications as part of the protocol itself, and not rely on separate (external) protocol mechanisms as is required with IPP today. Incidentally, most folks have long forgotten something about how and why the SENSE project was started in the first place. As IEEE 1284.1 (TIPSI) was coming to a close, the issue of scalability arose with respect to async device/job notifications. I had suggested that the group augment the stream-like protocol with a sort of "side-band-like" UDP service to solve the scalability problem. The notion was very warmly received by the TIPSI group, so much so that the group strongly suggested that this approach be presented to the PWG for general consideration. And hence, the birth of SENSE way back in October, 1995. Now, will the PWG do anything with it? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 23:04:13 1998 Delivery-Date: Wed, 11 Feb 1998 23:04:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA02955 for ; Wed, 11 Feb 1998 23:04:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA15201 for ; Wed, 11 Feb 1998 23:06:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08771 for ; Wed, 11 Feb 1998 23:03:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 21:12:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22257 for ipp-outgoing; Wed, 11 Feb 1998 11:24:29 -0500 (EST) Message-ID: <34E1D04F.2D40D4F8@underscore.com> Date: Wed, 11 Feb 1998 11:22:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Philip Thambidurai CC: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network References: <00040323.3036@okidata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Philip, Many thanks for your supporting comments. > In summary, two issues stand out to me: > > 1. It does not appear that IPP will have much or any impact on the > multitude of printing solutions in use today (for the Intranet). I concur completely. This observation is in diametric opposition to the position stated by Paul Moore, namely, that IPP is being targeted as the "all-in-one" protocol for network printing in the future, whether it be INTERnet or INTRAnet. Over the last few weeks, several people have contacted me privately asking me the same sort of question: "What (or who) on earth is IPP really good for, anyway?" This is a question that really needs to be answered, given the many people who believe IPP adds very, very little value in the Intranet (aka, enterprise) environment. Someone is supposed to be starting a thread for this kind of discussion Real Soon Now. > 2. Lack of a ***complete*** standard printing solution within the LAN > environment (Intranets included). Today we have to use proprietary > solutions. Exactly. Again, people's comments to me come out as: "When compared to existing (proprietary/defacto) network printing protocols, IPP adds so little that it does not provide the impetus to change existing infrastructures in the Intranet environment." Sure, we can certainly extend IPP in the future (and extend it, and extend it...), but one critical design flaw exists in IPP (IMHO) that prevents a clean and simple design: IPP is based on HTTP In the early days of IPP, these assumptions made HTTP the obvious choice for an INTERnet printing protocol: 1. We get a free "hole" through the firewall 2. We get to leverage external work on security models and related infrastructure so that we didn't have to do that ourselves 3. With support from browser vendors, "native" support for IPP could be shipped with all standard browsers, thereby offering the holy grail of "no client-side software installation" Sadly, one by one, these critical core assumptions have fallen. So, why did we stick with HTTP? Momentum within the group? (ie, "I already have time and code invested, and I don't want to throw it away") IMHO, the only real redeeming value of using HTTP at all is the ability to leverage common server-side program invocation services (ie, CGI). This appears, though, to only help server-side developers coding for "general purpose" servers, and not embedded environments. Comments are welcome and encouraged here. Feel free to flame as necessary... ;-) ...jay PS: I realize these comments should be directed to the IESG as part of the Last Call period, but I don't know how to post comments to the IESG. :-( ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Feb 11 23:43:53 1998 Delivery-Date: Wed, 11 Feb 1998 23:43:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA03522 for ; Wed, 11 Feb 1998 23:43:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA15251 for ; Wed, 11 Feb 1998 23:46:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11496 for ; Wed, 11 Feb 1998 23:43:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Feb 1998 23:00:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08272 for ipp-outgoing; Wed, 11 Feb 1998 22:53:59 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC260@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Jay Martin'" , Philip Thambidurai Cc: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network Date: Wed, 11 Feb 1998 19:51:28 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I concur completely. This observation is in diametric opposition to the position stated by Paul Moore, namely, that IPP is being targeted as the "all-in-one" protocol for network printing in the future, whether it be INTERnet or INTRAnet. You misunderstand me (Or I misunderstand you). I completely agree with this thread about needing a robust host-to-device protocol. My main complaint from day one has been that people are trying to make IPP into 'all things for all people' and have failed because this cannot be done. This is still my position and one that I still continue to make. I think that the group as a whole IS targetting it as the 'all-in-one' solution (it re-affirmed this at the last WG) - but I dont think it should be. I.e dont confuse my analysis of what the WG as a whole has decided IPP should be with what I think is the right thing to do - they are diametrically opposed. This ' all-in-one' approach has several bad effects 1. People are trying to cram stuff in that does not really fit 2. The is a lack of focus on what real value the IPP could have in its core space (printing over the public internet) 3. Nobody will look at a device level protocol because 'we can make IPP do that'. Hence we get into the wierd suggestion that device alerts should be sent via email! Regarding the 'value' or otherwise of IPP. I can see some scenarios where it will be genuinley useful - printing to service shops that have faster/more functional printers - printing to your neighbors printer (simpler than sneakernet) - printing when on the road (hotel business centre for example) But this is less value than the need I have for a protocol that addresses the real, actual, support desk pain in the *ssing, end user confusing, money draining problems that exist in corporates, small businesses and soon in homes. I doubt that IPP can do it, but (and this is the one change of stance here) I have decided to see if IPP COULD be pushed into doing it. Having spent some cycles I am 40/60 (yes/no) on this. Even if it could do it it would be a huge kludge but something is better than nothing. The other alternative is to do a different protocol - which I am totally in favor of. This sounds like a topic for an Austin BOF. > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Wednesday, February 11, 1998 8:23 AM > To: Philip Thambidurai > Cc: ipp@pwg.org > Subject: Re: IPP> Does the world need a robust host-to-device network > > Philip, > > Many thanks for your supporting comments. > > > In summary, two issues stand out to me: > > > > 1. It does not appear that IPP will have much or any impact on the > > multitude of printing solutions in use today (for the Intranet). > > I concur completely. This observation is in diametric opposition to > the position stated by Paul Moore, namely, that IPP is being targeted > as the "all-in-one" protocol for network printing in the future, > whether it be INTERnet or INTRAnet. > > Over the last few weeks, several people have contacted me privately > asking me the same sort of question: > > "What (or who) on earth is IPP really good for, anyway?" > > This is a question that really needs to be answered, given the > many people who believe IPP adds very, very little value in the > Intranet (aka, enterprise) environment. Someone is supposed to > be starting a thread for this kind of discussion Real Soon Now. > > > > 2. Lack of a ***complete*** standard printing solution within the > LAN > > environment (Intranets included). Today we have to use proprietary > > solutions. > > Exactly. Again, people's comments to me come out as: > > "When compared to existing (proprietary/defacto) network printing > protocols, IPP adds so little that it does not provide the impetus > to change existing infrastructures in the Intranet environment." > > Sure, we can certainly extend IPP in the future (and extend it, > and extend it...), but one critical design flaw exists in IPP (IMHO) > that prevents a clean and simple design: > > IPP is based on HTTP > > In the early days of IPP, these assumptions made HTTP the obvious > choice for an INTERnet printing protocol: > > 1. We get a free "hole" through the firewall > > 2. We get to leverage external work on security models and related > infrastructure so that we didn't have to do that ourselves > > 3. With support from browser vendors, "native" support for IPP > could be shipped with all standard browsers, thereby offering > the holy grail of "no client-side software installation" > > Sadly, one by one, these critical core assumptions have fallen. > > So, why did we stick with HTTP? Momentum within the group? > (ie, "I already have time and code invested, and I don't > want to throw it away") > > IMHO, the only real redeeming value of using HTTP at all > is the ability to leverage common server-side program > invocation services (ie, CGI). This appears, though, to > only help server-side developers coding for "general purpose" > servers, and not embedded environments. > > Comments are welcome and encouraged here. Feel free to flame > as necessary... ;-) > > ...jay > > PS: I realize these comments should be directed to the IESG > as part of the Last Call period, but I don't know how to > post comments to the IESG. :-( > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 01:36:16 1998 Delivery-Date: Thu, 12 Feb 1998 01:36:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA05862 for ; Thu, 12 Feb 1998 01:36:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA15384 for ; Thu, 12 Feb 1998 01:38:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA13767 for ; Thu, 12 Feb 1998 01:36:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 01:12:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23493 for ipp-outgoing; Wed, 11 Feb 1998 11:59:57 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC246@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Harry Lewis'" , jkm@underscore.com Cc: ipp@pwg.org Subject: IPP> RE: Does the world need a robust host-to-device network prin Date: Wed, 11 Feb 1998 08:56:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I dont really care what it is as long as :- - everybody accepts that it is worth doing and implments it - it does what I need - it is consistent with IPP. The problem is that printer manufacurers want to put IPP in their devices, they are reluctant to put yet another print protocol in as well. As don wright said 'I'd rather boil the ocean' > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Tuesday, February 10, 1998 4:05 PM > To: jkm@underscore.com > Cc: ipp@pwg.org; Paul Moore > Subject: Re: Does the world need a robust host-to-device network prin > > If we were to address a new, standard, host-to-device printing protocol > > > Now if somebody wants to have a separate debate about writing a really > > robust protocol for interfacing to printers (and I mean the real > hardware > > not some logical abstraction) then that will suit me fine. Lets start a > new > > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > > wanted to do but could not persuade enough people. > > in my opinion, it should be based on the set of attributes defined for IPP > and the resulting device protocol should be as closely correlated with IPP > as possible such that the mapping is very straight forward and simple. > > Harry Lewis From ipp-owner@pwg.org Thu Feb 12 02:19:04 1998 Delivery-Date: Thu, 12 Feb 1998 02:19:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA06038 for ; Thu, 12 Feb 1998 02:19:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA15423 for ; Thu, 12 Feb 1998 02:21:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA15766 for ; Thu, 12 Feb 1998 02:18:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 01:48:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22898 for ipp-outgoing; Wed, 11 Feb 1998 11:43:01 -0500 (EST) Message-ID: <34E1D4E7.8933FB04@underscore.com> Date: Wed, 11 Feb 1998 11:42:15 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Carl Kugler Subject: Re: IPP> IPP > FAQ - How should the server behave? References: <5030100017320671000002L012*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Would it be too much to ask that IPP define a specific error code for the "server to busy to accept requests" condition? ...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 Kugler wrote: > > > Is IPP currently defined such that the "server-error-service-unavailable" > > (0x0502) error code is used EXCLUSIVELY for the "server too busy > > to accept your request" condition? > > No. > > -Carl > > jkm@underscore.com on 02/10/98 02:13:27 PM > Please respond to jkm@underscore.com @ internet > To: Carl Kugler/Boulder/IBM@ibmus > cc: ipp@pwg.org @ internet > Subject: Re: IPP> IPP > FAQ - How should the server behave? > > Carl (or anyone else), > > Perhaps I wasn't asking the right question, or wasn't being > explicit enough, so let me re-ask the question. > > Is IPP currently defined such that the "server-error-service-unavailable" > (0x0502) error code is used EXCLUSIVELY for the "server too busy > to accept your request" condition? > > In particular, I am hoping this (or some other IPP error code) > can be used in an unoverloaded way to precisely mean one thing, > and not a bushel-basket of various conditions. > > ...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 Kugler wrote: > > > > The 0x0502 status code means "The IPP object is currently unable to handle the > > request due to a temporary overloading or maintenance of the IPP object. " > So, > > yes, it could also mean the IPP object is down for maintenance. > > > > -Carl > > > > ipp-owner@pwg.org on 02/09/98 12:34:38 PM > > Please respond to ipp-owner@pwg.org @ internet > > To: Carl Kugler/Boulder/IBM@ibmus > > cc: ipp@pwg.org @ internet > > Subject: Re: IPP> IPP > FAQ - How should the server behave? > > > > Carl Kugler wrote: > > > > > I'd be happier to get server-error-service-unavailable (0x0502) with an > > > estimate of the the length of the delay indicated in the message. A client > > > could then give a user the choice of canceling, retrying, or queuing locally > > > and retrying after delay. At that point the user might decide to try > another > > > printer, or just queue the job locally (client side) and go on. > > > > Is the "server-error-service-unavailable" (0x0502) error code used > > for any other type of error condition? > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 02:51:31 1998 Delivery-Date: Thu, 12 Feb 1998 02:51:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA06154 for ; Thu, 12 Feb 1998 02:51:31 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA15441 for ; Thu, 12 Feb 1998 02:54:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA18024 for ; Thu, 12 Feb 1998 02:51:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 02:22:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21297 for ipp-outgoing; Wed, 11 Feb 1998 11:01:31 -0500 (EST) Message-ID: <34E1CB38.7F627F3D@underscore.com> Date: Wed, 11 Feb 1998 11:00:56 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Randy, > I'm curious how this host-to-device protocol for printing would differ > from IPP 1.0? Excellent question. Right off the top of my head... For one thing, such a protocol would be one heck of a lot more efficient than IPP-over-HTTP. Anytime you frame bulk data within a transaction protocol, you lose bigtime in terms of performance. The CPAP designers learned this many years ago; the implementation of an FTP-like side-band "data channel" is one of the big features of CPAP v2. Also note that IEEE 1284.1 (aka "TIPSI", aka "NPAP") added similar support for a separate data-only channel near the end of that protocol's development. In addition to the significant increase in performance, we found that implementing such a protocol was a lot easier in terms of structure and complexity. Always a nice win, to be sure. Another way the protocol would differ from IPP is in the area of async messages during the transaction. As the client submits a job, the server can inform the client of any number of events that occur during the transaction, such as device alerts and other things the client may (or may not, granted) be interested in. Using CPAP as an example of this kind of protocol, CPAP has the ability for the server to convey to the client that the client's job was terminated (either via the front panel, or by a remote management app communicating with the server). Furthermore, the "job kill" message to the client can include exactly WHO killed the job, thereby allowing the client to provide an excellent level of detail to the job submitter as to why the job failed. There's more I can say here, but this is at least a start. I anxiously await comments from others, particularly from you, Randy! I'd really like to get this kind of thread rolling. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 03:28:44 1998 Delivery-Date: Thu, 12 Feb 1998 03:28:45 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA06363 for ; Thu, 12 Feb 1998 03:28:44 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA15479 for ; Thu, 12 Feb 1998 03:31:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA20109 for ; Thu, 12 Feb 1998 03:28:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 03:05:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA14711 for ipp-outgoing; Thu, 12 Feb 1998 02:01:05 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> RE: host-to-device protocol Date: Wed, 11 Feb 1998 23:00:45 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org There has been a lot of ranting about IPP not being able to address intranets but I have not seen any "meat" to these complaints. I would like to see valid technical reasons why IPP cannot be used in intranets as well as internets. I am talking about IPP as specified in the IPP model document and not a specific mapping such as the IPP over HTTP document. I think my earlier comment about a host-to-device protocol being just another mapping of the IPP model to a different transport still stands. Randy From ipp-owner@pwg.org Thu Feb 12 05:03:11 1998 Delivery-Date: Thu, 12 Feb 1998 05:03:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id FAA06886 for ; Thu, 12 Feb 1998 05:03:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA15551 for ; Thu, 12 Feb 1998 05:05:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA24276 for ; Thu, 12 Feb 1998 05:02:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 04:38:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA19075 for ipp-outgoing; Thu, 12 Feb 1998 03:11:16 -0500 (EST) Message-ID: <001901bd378d$7f29bc80$e3d3000d@bronze-208.parc.xerox.com> From: "Larry Masinter" To: "Jay Martin" , "Turner, Randy" Cc: Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? Date: Thu, 12 Feb 1998 00:09:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: ipp-owner@pwg.org In reply to Randy Turner's: > I'm curious how this host-to-device protocol for printing would differ > from IPP 1.0? Jay Martin wrote: > Excellent question. Right off the top of my head... > For one thing, such a protocol would be one heck of a lot more > efficient than IPP-over-HTTP. Anytime you frame bulk data within > a transaction protocol, you lose bigtime in terms of performance. Now, there's a lot you might say about IPP-over-HTTP, but this one makes little sense. HTTP is used for transmitting bulk data all the time. Admittedly, most HTTP transactions are server-to-client rather than client-to-server for bulk data, but there's not much asymmetric in the protocol itself. From ipp-owner@pwg.org Thu Feb 12 06:03:34 1998 Delivery-Date: Thu, 12 Feb 1998 06:03:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA07156 for ; Thu, 12 Feb 1998 06:03:33 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA15644 for ; Thu, 12 Feb 1998 06:06:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA25135 for ; Thu, 12 Feb 1998 06:03:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 05:43:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00434 for ipp-outgoing; Wed, 11 Feb 1998 19:40:22 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AECA@EXCHANGE> From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Wed, 11 Feb 1998 17:50:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org The arguments suggest that IPP cannot deal with both the intra and internet, and with both printers and servers. These apprehensions had been addressed over the past year, although perhaps not to your satisfaction. > -----Original Message----- > From: James Walker [SMTP:walker@dazel.com] > Sent: Wednesday, February 11, 1998 2:41 PM > To: ipp@pwg.org > Cc: Jay Martin > Subject: Re: IPP> Does the world need a robust host-to-device > network printing protocol? > > I have become more > and more disillusioned with the comprimises that we make to try and > satisfy both ends of the spectrum (embedded printers all the way up > to fat print servers). Also, like some, I do not believe that HTTP > has been the Holy Grail that we all thought it would be. [Wagner, William] Yes, there have been compromises (and some degree of excess), but I suggest that an IPP compatible implementation embedded in a printer is still quite feasible. > The first is that most of the prints in the > world go from a client to a print server, or process of some kind, > and then to the printing device. There are very few (any?) cases of > a client application talking directly to a printing device. [Wagner, William] This observation is open to interpretation. There is usually something between the application and the printer, but that something may be in the same physical device as the application or the printer. So, from a network protocol point of view, there are quite a few protocols that transfer a print job between a workstation and a printer. I say that this implies that there is no requirement > for a single protocol that solves both the client->server and > server->printer cases. That was one of the things that we were trying > to do with IPP. [Wagner, William] I think you are mistaken. From what I recall, IPP sought to define a protocol between a client application and a logical printer. That logical printer could very well have been an external server, in which case the server to printer connection was not defined. Or, the server could be embedded in the printer, in which case there was no network connection involved. > The second observation has to do with deployment. How many of us > really believe that people are going to be hooking up raw printing > hardware (i.e., printers) directly to the internet for people to > print to? If an *inter*net printing protocol is going to be deployed, > ya' gotta' believe that it is going to be on a high-powered print > server/spooler of some kind. Although only a very small sample, I > confirmed this with several system administrators (and a marketeer > or two ;-). Once again, I think that this argues for separate > requirements for the client->server and server->printer protocols. [Wagner, William] I do not agree that users will not be hooking up a printer intended to take jobs via the internet. And unless you are defining server in a functional rather than physical sense, I would not agree that a separate sever must always be present. And, if you prefer to think of IPP as a client to server protocol, that is just fine, recognizing that a server may not necessarily be what and where you are accustomed to see it. From ipp-owner@pwg.org Thu Feb 12 06:37:52 1998 Delivery-Date: Thu, 12 Feb 1998 06:37:52 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA07289 for ; Thu, 12 Feb 1998 06:37:51 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA15680 for ; Thu, 12 Feb 1998 06:40:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA25902 for ; Thu, 12 Feb 1998 06:37:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 06:13:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00491 for ipp-outgoing; Wed, 11 Feb 1998 19:45:25 -0500 (EST) Message-Id: <199802112259.RAA23002@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: iesg@ns.ietf.org, ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IPP Last Call In-reply-to: Your message of "Wed, 11 Feb 1998 14:27:53 PST." <5CEA8663F24DD111A96100805FFE6587030BC253@red-msg-51.dns.microsoft.com> Date: Wed, 11 Feb 1998 17:59:07 -0500 Sender: ipp-owner@pwg.org Paul, Please provide more detail about a couple of your objections to IPP's chosen data representation. In particular: > a) if XML had been available at the time we would have chosen to use it. Okay, but IPP-WG chose not to do so, both "at the time", and again very recently. > b) It provides a much less ambigous specification (this leads to better > interop convergence) Can you point out ambiguities in the existing IPP specification which would be made less ambiguous by reference to XML? Keep in mind that there's more than one way to make a specification ambiguous or difficult to assimilate (the two the same effect on the quality of products developed from the specification). For instance, referencing some other spec might make the IPP less ambiguous, but more difficult to assimilate, due to the greater learning curve. -- Keith Moore http://www.cs.utk.edu/~moore/ Citizen of cyberspace, currently residing in Knoxville, Tennessee, USA. From ipp-owner@pwg.org Thu Feb 12 07:13:18 1998 Delivery-Date: Thu, 12 Feb 1998 07:13:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA07453 for ; Thu, 12 Feb 1998 07:13:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA15742 for ; Thu, 12 Feb 1998 07:15:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA28126 for ; Thu, 12 Feb 1998 07:13:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 07:08:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA27387 for ipp-outgoing; Thu, 12 Feb 1998 07:08:52 -0500 (EST) Date: Thu, 12 Feb 1998 07:08:48 -0500 (EST) From: Super-User Message-Id: <199802121208.HAA27382@lists.underscore.com> To: ipp@pwg.org Subject: IPP> TEST MESSAGE - PLEASE IGNORE Sender: ipp-owner@pwg.org TEST MESSAGE ONLY. PLEASE IGNORE. From ipp-owner@pwg.org Thu Feb 12 08:04:12 1998 Delivery-Date: Thu, 12 Feb 1998 08:04:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA07761 for ; Thu, 12 Feb 1998 08:04:12 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA15870 for ; Thu, 12 Feb 1998 08:06:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA28957 for ; Thu, 12 Feb 1998 08:04:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 08:00:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA28407 for ipp-outgoing; Thu, 12 Feb 1998 07:59:58 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> Does the world need a robust host-to-device network Message-ID: <5030100017372701000002L012*@MHS> Date: Thu, 12 Feb 1998 07:56:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA07761 It seems to me that the **ONLY** real value a new printing standard can add is simply the fact that it is a standard and supported across a broad set of products that thereby achieve interoperability. >"When compared to existing (proprietary/defacto) network printing > protocols, IPP adds so little that it does not provide the impetus > to change existing infrastructures in the Intranet environment." From jmp-owner@pwg.org Thu Feb 12 09:11:19 1998 Delivery-Date: Thu, 12 Feb 1998 09:11:19 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08618 for ; Thu, 12 Feb 1998 09:11:19 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16111 for ; Thu, 12 Feb 1998 09:13:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA00104 for ; Thu, 12 Feb 1998 09:11:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 09:07:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA29112 for jmp-outgoing; Thu, 12 Feb 1998 09:02:10 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> RESEND: PWG meeting in Austin on 3/2-6 Message-ID: <5040300012488014000002L042*@MHS> Date: Thu, 12 Feb 1998 08:58:04 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-12-98 07:59 AM --------------------------- Keith Carter 02-11-98 04:24 PM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From ipp-owner@pwg.org Thu Feb 12 09:15:09 1998 Delivery-Date: Thu, 12 Feb 1998 09:15:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08679 for ; Thu, 12 Feb 1998 09:15:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16123 for ; Thu, 12 Feb 1998 09:17:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA00718 for ; Thu, 12 Feb 1998 09:15:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 09:02:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA29129 for ipp-outgoing; Thu, 12 Feb 1998 09:02:20 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> RESEND: PWG meeting in Austin on 3/2-6 Message-ID: <5040300012488014000002L042*@MHS> Date: Thu, 12 Feb 1998 08:58:04 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-12-98 07:59 AM --------------------------- Keith Carter 02-11-98 04:24 PM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From pwg-owner@pwg.org Thu Feb 12 09:15:39 1998 Delivery-Date: Thu, 12 Feb 1998 09:15:39 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08687 for ; Thu, 12 Feb 1998 09:15:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16126 for ; Thu, 12 Feb 1998 09:18:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA00760 for ; Thu, 12 Feb 1998 09:15:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 09:08:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA29093 for pwg-outgoing; Thu, 12 Feb 1998 09:02:01 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> RESEND: PWG meeting in Austin on 3/2-6 Message-ID: <5040300012488014000002L042*@MHS> Date: Thu, 12 Feb 1998 08:58:04 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-12-98 07:59 AM --------------------------- Keith Carter 02-11-98 04:24 PM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From ipp-owner@pwg.org Thu Feb 12 09:42:22 1998 Delivery-Date: Thu, 12 Feb 1998 09:42:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA09279 for ; Thu, 12 Feb 1998 09:42:21 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16311 for ; Thu, 12 Feb 1998 09:44:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA01402 for ; Thu, 12 Feb 1998 09:42:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 09:38:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA00887 for ipp-outgoing; Thu, 12 Feb 1998 09:38:16 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059CC7@EXCHANGE> From: "Gordon, Charles" To: "'Carl-Uno Manros'" , Roger K Debry , ipp@pwg.org Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 09:36:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org If localization of messages is a requirement (and it should be), I would suggest that messages be localized by software on the receiver's PC. This would work as follows: 1. IPP server sends message (by whatever means) to an IPP client on the remote user's PC. This message would be formatted to be easily machine readable. 2. Software on remote user's PC retrieves the message and localizes it. 3. Localized message it displayed to user. The advantage in this approach is that the IPP server does not need to support different languages and character sets. Instead, IPP client software does this. Since the client software is on the remote user's PC, the user would, presumably, have installed a localized version of the software, and the PC will be setup with the correct character set. It will probably be desirable to make the original message sent from the IPP server to the client human readable as well as machine readable. This would allow users to read the message even if they don't have IPP client software. This could be done by either generating the message as English text (the defacto International standard language) formatted to make parsing by software easy, or by generating a two part message where one part is text and the other part is machine readable. If email is used for notification messages (and it does seem like a good choice), then the message from the IPP server could be sent to a special mailbox setup at the remote site. The IPP client software could be a specialized mail client which decodes the messages, localizes them, and displays them to the user. If the user does not have IPP client software, he would still be able to access the messages with a standard mail client and read them in English. That's just a suggestion for how I would approach the problem. The main point I am trying to make (which I am sure someone has already made) is that the IPP server should not have to localize notification messages. Localization should be done on the client side. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Wednesday, February 11, 1998 7:32 PM > To: Roger K Debry; ipp@pwg.org > Subject: Re: IPP> Notification Requirements > > Roger, > > One requirement, which we have discussed earlier, but seems to have > been > forgotten lately, is the ability to request the human readable > notifications in different langauges. > > E.g. I want to send a document for review to our offices in Japan and > want > to have any notifications to my collegue in Tokyo in Japanese, while I > want > to have my own notifications in Swedish :-) > > Can we create a scenario for this? > > Carl-Uno > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > >I have taken a pass at writing down a set of notification > requirements. > >They are in the PDF file attached to this note. I'd be glad to take > >comments and suggestions and turn this into a formal requirements > >document, if you all feel that this would be useful. > > > > > > > > > >Roger K deBry > >Senior Technical Staff Member > >Architecture and Technology > >IBM Printing Systems > >email: rdebry@us.ibm.com > >phone: 1-303-924-4080 > > > >Attachment Converted: > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 09:48:56 1998 Delivery-Date: Thu, 12 Feb 1998 09:48:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA09430 for ; Thu, 12 Feb 1998 09:48:55 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16343 for ; Thu, 12 Feb 1998 09:51:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA02047 for ; Thu, 12 Feb 1998 09:48:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 09:44:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA01496 for ipp-outgoing; Thu, 12 Feb 1998 09:44:47 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Gordon, Charles'" , "'Carl-Uno Manros'" , Roger K Debry , ipp@pwg.org Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 06:45:18 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Can you elaborate a little on the exact method for how a client would apply localization to a server-generated message? Randy -----Original Message----- From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] Sent: Thursday, February 12, 1998 6:37 AM To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org Subject: RE: IPP> Notification Requirements If localization of messages is a requirement (and it should be), I would suggest that messages be localized by software on the receiver's PC. This would work as follows: 1. IPP server sends message (by whatever means) to an IPP client on the remote user's PC. This message would be formatted to be easily machine readable. 2. Software on remote user's PC retrieves the message and localizes it. 3. Localized message it displayed to user. The advantage in this approach is that the IPP server does not need to support different languages and character sets. Instead, IPP client software does this. Since the client software is on the remote user's PC, the user would, presumably, have installed a localized version of the software, and the PC will be setup with the correct character set. It will probably be desirable to make the original message sent from the IPP server to the client human readable as well as machine readable. This would allow users to read the message even if they don't have IPP client software. This could be done by either generating the message as English text (the defacto International standard language) formatted to make parsing by software easy, or by generating a two part message where one part is text and the other part is machine readable. If email is used for notification messages (and it does seem like a good choice), then the message from the IPP server could be sent to a special mailbox setup at the remote site. The IPP client software could be a specialized mail client which decodes the messages, localizes them, and displays them to the user. If the user does not have IPP client software, he would still be able to access the messages with a standard mail client and read them in English. That's just a suggestion for how I would approach the problem. The main point I am trying to make (which I am sure someone has already made) is that the IPP server should not have to localize notification messages. Localization should be done on the client side. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Wednesday, February 11, 1998 7:32 PM > To: Roger K Debry; ipp@pwg.org > Subject: Re: IPP> Notification Requirements > > Roger, > > One requirement, which we have discussed earlier, but seems to have > been > forgotten lately, is the ability to request the human readable > notifications in different langauges. > > E.g. I want to send a document for review to our offices in Japan and > want > to have any notifications to my collegue in Tokyo in Japanese, while I > want > to have my own notifications in Swedish :-) > > Can we create a scenario for this? > > Carl-Uno > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > >I have taken a pass at writing down a set of notification > requirements. > >They are in the PDF file attached to this note. I'd be glad to take > >comments and suggestions and turn this into a formal requirements > >document, if you all feel that this would be useful. > > > > > > > > > >Roger K deBry > >Senior Technical Staff Member > >Architecture and Technology > >IBM Printing Systems > >email: rdebry@us.ibm.com > >phone: 1-303-924-4080 > > > >Attachment Converted: > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 10:45:42 1998 Delivery-Date: Thu, 12 Feb 1998 10:45:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14425 for ; Thu, 12 Feb 1998 10:45:41 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA16675 for ; Thu, 12 Feb 1998 10:48:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04222 for ; Thu, 12 Feb 1998 10:45:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 10:37:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03121 for ipp-outgoing; Thu, 12 Feb 1998 10:37:40 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059CC8@EXCHANGE> From: "Gordon, Charles" To: "'Turner, Randy'" , ipp@pwg.org Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 10:36:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org The simplest way would be to restrict IPP to a specific set of notification messages. The localized version of the IPP client would have these messages translated into the local language. When the IPP client reads the message from the IPP server, it would determine which notification event occurred and produce the localized version version of the message for it. For a simple example, suppose IPP supports the following notification messages. 1. Print job %job-name% which was sent to you by %sender% was printed on printer %printer% on %date% %time%. 2. Print job %job-name% which was sent to you by %sender% was aborted on %date% %time% because of errors on printer %printer%. 3. Print job %job-name% which you sent to %receipient% has been printed on printer %printer% on %date% %time%. and so on.... The idea here is that we define a message for each type of event which IPP will send notification of. The strings can include tokens like %job-name% which will be replaced by the client with strings which represent the actual values assigned to them. When the IPP server sends a message, it sends it in a format which the IPP client can recognize. For example, suppose the IPP server sends a notification to a receipient that a job has been printed (message 1 above). The IPP server formats the message so that client software can recognize that it is a notification that event 1 happenned, and sends values for the %job-name%, %sender%, and other tokens. The IPP client retrieves the localized text for notification event 1 and inserts the values for the tokens into the message. The localized message can now be displayed to the user. Well written Windows programs are designed so that they can be easily localized. All text is stored in a seperate file which can be localized without changing the code. If I write a Windows program which uses English, I can send the 'resource' file (which contains all my English text strings) to some translation house and have them provide localized versions for all the languages I want to support. Localized IPP clients can be create in this fashion. I would assume that other operating systems also support localization one way or another. I know the above example is rather simple, but I think it shows how localization could be done. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Thursday, February 12, 1998 9:45 AM > To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > > Can you elaborate a little on the exact method for how a client would > apply localization to a server-generated message? > > Randy > > > -----Original Message----- > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > Sent: Thursday, February 12, 1998 6:37 AM > To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > If localization of messages is a requirement (and it should be), > I would > suggest that messages be localized by software on the receiver's > PC. > This would work as follows: > > 1. IPP server sends message (by whatever means) to an IPP > client on the > remote user's PC. This message would be formatted to be easily > machine > readable. > 2. Software on remote user's PC retrieves the message and > localizes it. > 3. Localized message it displayed to user. > > The advantage in this approach is that the IPP server does not > need to > support different languages and character sets. Instead, IPP > client > software does this. Since the client software is on the remote > user's > PC, the user would, presumably, have installed a localized > version of > the software, and the PC will be setup with the correct > character set. > > It will probably be desirable to make the original message sent > from the > IPP server to the client human readable as well as machine > readable. > This would allow users to read the message even if they don't > have IPP > client software. This could be done by either generating the > message as > English text (the defacto International standard language) > formatted to > make parsing by software easy, or by generating a two part > message where > one part is text and the other part is machine readable. > > If email is used for notification messages (and it does seem > like a good > choice), then the message from the IPP server could be sent to a > special > mailbox setup at the remote site. The IPP client software could > be a > specialized mail client which decodes the messages, localizes > them, and > displays them to the user. If the user does not have IPP client > software, he would still be able to access the messages with a > standard > mail client and read them in English. > > That's just a suggestion for how I would approach the problem. > The main > point I am trying to make (which I am sure someone has already > made) is > that the IPP server should not have to localize notification > messages. > Localization should be done on the client side. > > > ______________________________________________________________________ > __ > ________________________________ > Charles Gordon > Osicom Technologies, Inc. > cgordon@osicom.com > http://www.digprod.com > > > -----Original Message----- > > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > > Sent: Wednesday, February 11, 1998 7:32 PM > > To: Roger K Debry; ipp@pwg.org > > Subject: Re: IPP> Notification Requirements > > > > Roger, > > > > One requirement, which we have discussed earlier, but seems to > have > > been > > forgotten lately, is the ability to request the human readable > > notifications in different langauges. > > > > E.g. I want to send a document for review to our offices in > Japan and > > want > > to have any notifications to my collegue in Tokyo in Japanese, > while I > > want > > to have my own notifications in Swedish :-) > > > > Can we create a scenario for this? > > > > Carl-Uno > > > > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > > >I have taken a pass at writing down a set of notification > > requirements. > > >They are in the PDF file attached to this note. I'd be glad > to take > > >comments and suggestions and turn this into a formal > requirements > > >document, if you all feel that this would be useful. > > > > > > > > > > > > > > >Roger K deBry > > >Senior Technical Staff Member > > >Architecture and Technology > > >IBM Printing Systems > > >email: rdebry@us.ibm.com > > >phone: 1-303-924-4080 > > > > > >Attachment Converted: > > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > > > Carl-Uno Manros > > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 10:45:43 1998 Delivery-Date: Thu, 12 Feb 1998 10:46:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14430 for ; Thu, 12 Feb 1998 10:45:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA16674 for ; Thu, 12 Feb 1998 10:48:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04216 for ; Thu, 12 Feb 1998 10:45:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 10:37:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03138 for ipp-outgoing; Thu, 12 Feb 1998 10:37:48 -0500 (EST) From: Harry Lewis To: , Cc: , , Roger K Debry Subject: RE: IPP> Notification Requirements Message-ID: <5030300017870887000002L072*@MHS> Date: Thu, 12 Feb 1998 10:39:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA14430 I agree with this point... >The main point I am trying to make... is that the IPP server should not >have to localize notification messages. Localization should be done on >the client side. Which invoked the question... >Can you elaborate a little on the exact method for how a client would >apply localization to a server-generated message? This is accomplished by defining a (limited) set of notification messages which, even in some encoded form, may be distinguished (and translated) by an application. If someone thinks there is a need to "ramble on" inside a print job notification, please identify and give an example. Harry Lewis From ipp-owner@pwg.org Thu Feb 12 10:58:57 1998 Delivery-Date: Thu, 12 Feb 1998 10:58:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14964 for ; Thu, 12 Feb 1998 10:58:57 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16751 for ; Thu, 12 Feb 1998 11:01:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA05809 for ; Thu, 12 Feb 1998 10:58:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 10:48:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04405 for ipp-outgoing; Thu, 12 Feb 1998 10:48:10 -0500 (EST) Message-ID: <34E319AB.CAEAF144@underscore.com> Date: Thu, 12 Feb 1998 10:47:55 -0500 From: "Jeffrey D. Schnitzer" Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org, upd@pwg.org Subject: IPP> PWG Mail Server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org It looks like the PWG mail server is healthy again, unfortunately several messages were lost yesterday. The IPP hypermail archive had grown quite large, so I've split off a new archive. The old IPP hypermail archive is available at HTTP://www.pwg.org/hypermail/ipp-pre980212/ The new (current) IPP hypermail archive is still HTTP://www.pwg.org/hypermail/ipp/ Be aware that some messages (those with large attachments) do not always get archived successfully by hypermail. People should not be attaching large files in any case; rather they should upload their contribution to the FTP server and include just the pointer in their mail to the list. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 11:02:21 1998 Delivery-Date: Thu, 12 Feb 1998 11:02:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15085 for ; Thu, 12 Feb 1998 11:02:21 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16769 for ; Thu, 12 Feb 1998 11:05:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06165 for ; Thu, 12 Feb 1998 11:02:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 10:50:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04566 for ipp-outgoing; Thu, 12 Feb 1998 10:50:19 -0500 (EST) Message-ID: <34E31947.73C1894F@underscore.com> Date: Thu, 12 Feb 1998 10:46:15 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> ADM - How to follow up on IESG comments on IPP References: <3.0.1.32.19980210160822.00cddc10@garfield> <3.0.1.32.19980211091811.0096e630@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno Manros wrote: > Maybe you are right. The IESG Last Call message about IPP says: > > "Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing > lists by February 23, 1998." > > so to be 100% certain that I get everything, I have sent subscription > requests to those two DLs as well... The iesg@ietf.org is NOT a mailing list, so don't try subscribing to it. It is designed as a "private reflector" and is not open to the public. (See message below) To subscribe to the ietf@ietf.org mailing list, be sure to send a message to ietf-request@ietf.org with the Subject line of "subscribe". ...jay ===== iesg@ietf.org is the Internet Engineering Steering Group. You can send mail to them but you can't subscribe to anything with that name. See the IETF web pages for info on the right way to subscribe to the IETF list. And please only do that if you really want to get the discussion. If you just want announcements, subscribe to ietf-announce. ===== From ipp-owner@pwg.org Thu Feb 12 11:05:47 1998 Delivery-Date: Thu, 12 Feb 1998 11:05:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA15157 for ; Thu, 12 Feb 1998 11:05:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16798 for ; Thu, 12 Feb 1998 11:08:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06611 for ; Thu, 12 Feb 1998 11:05:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 10:54:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA05181 for ipp-outgoing; Thu, 12 Feb 1998 10:54:28 -0500 (EST) Message-ID: <34E31B1D.4F22BF83@underscore.com> Date: Thu, 12 Feb 1998 10:54:05 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Larry Masinter CC: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? References: <001901bd378d$7f29bc80$e3d3000d@bronze-208.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Larry Masinter wrote: > > For one thing, such a protocol would be one heck of a lot more > > efficient than IPP-over-HTTP. Anytime you frame bulk data within > > a transaction protocol, you lose bigtime in terms of performance. > > Now, there's a lot you might say about IPP-over-HTTP, but this one makes > little sense. HTTP is used for transmitting bulk data all the time. Admittedly, > most HTTP transactions are server-to-client rather than client-to-server for > bulk data, but there's not much asymmetric in the protocol itself. Yes, HTTP transmits bulk data all the time. However, you are ignoring the fact that HTTP has a much wider problem domain than IPP. HTTP needs the multi-part capability due to the problem domain. A printing protocol does not. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 11:48:17 1998 Delivery-Date: Thu, 12 Feb 1998 11:48:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA17855 for ; Thu, 12 Feb 1998 11:48:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17045 for ; Thu, 12 Feb 1998 11:50:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA07738 for ; Thu, 12 Feb 1998 11:48:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 11:43:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07102 for ipp-outgoing; Thu, 12 Feb 1998 11:43:17 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Gordon, Charles'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 08:43:47 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I thought this was what you meant. I just wanted to make it clear that client-localization requires defining a strict set of possible messages, with an associated token or code so that the client knows how to look up the localized version of this message in a localization dictionary (or catalog, or whatever). I wonder if absolutely restricting the set of messages that can be sent from server to client is too constraining? Randy -----Original Message----- From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] Sent: Thursday, February 12, 1998 7:36 AM To: 'Turner, Randy'; ipp@pwg.org Subject: RE: IPP> Notification Requirements The simplest way would be to restrict IPP to a specific set of notification messages. The localized version of the IPP client would have these messages translated into the local language. When the IPP client reads the message from the IPP server, it would determine which notification event occurred and produce the localized version version of the message for it. For a simple example, suppose IPP supports the following notification messages. 1. Print job %job-name% which was sent to you by %sender% was printed on printer %printer% on %date% %time%. 2. Print job %job-name% which was sent to you by %sender% was aborted on %date% %time% because of errors on printer %printer%. 3. Print job %job-name% which you sent to %receipient% has been printed on printer %printer% on %date% %time%. and so on.... The idea here is that we define a message for each type of event which IPP will send notification of. The strings can include tokens like %job-name% which will be replaced by the client with strings which represent the actual values assigned to them. When the IPP server sends a message, it sends it in a format which the IPP client can recognize. For example, suppose the IPP server sends a notification to a receipient that a job has been printed (message 1 above). The IPP server formats the message so that client software can recognize that it is a notification that event 1 happenned, and sends values for the %job-name%, %sender%, and other tokens. The IPP client retrieves the localized text for notification event 1 and inserts the values for the tokens into the message. The localized message can now be displayed to the user. Well written Windows programs are designed so that they can be easily localized. All text is stored in a seperate file which can be localized without changing the code. If I write a Windows program which uses English, I can send the 'resource' file (which contains all my English text strings) to some translation house and have them provide localized versions for all the languages I want to support. Localized IPP clients can be create in this fashion. I would assume that other operating systems also support localization one way or another. I know the above example is rather simple, but I think it shows how localization could be done. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Thursday, February 12, 1998 9:45 AM > To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > > Can you elaborate a little on the exact method for how a client would > apply localization to a server-generated message? > > Randy > > > -----Original Message----- > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > Sent: Thursday, February 12, 1998 6:37 AM > To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > If localization of messages is a requirement (and it should be), > I would > suggest that messages be localized by software on the receiver's > PC. > This would work as follows: > > 1. IPP server sends message (by whatever means) to an IPP > client on the > remote user's PC. This message would be formatted to be easily > machine > readable. > 2. Software on remote user's PC retrieves the message and > localizes it. > 3. Localized message it displayed to user. > > The advantage in this approach is that the IPP server does not > need to > support different languages and character sets. Instead, IPP > client > software does this. Since the client software is on the remote > user's > PC, the user would, presumably, have installed a localized > version of > the software, and the PC will be setup with the correct > character set. > > It will probably be desirable to make the original message sent > from the > IPP server to the client human readable as well as machine > readable. > This would allow users to read the message even if they don't > have IPP > client software. This could be done by either generating the > message as > English text (the defacto International standard language) > formatted to > make parsing by software easy, or by generating a two part > message where > one part is text and the other part is machine readable. > > If email is used for notification messages (and it does seem > like a good > choice), then the message from the IPP server could be sent to a > special > mailbox setup at the remote site. The IPP client software could > be a > specialized mail client which decodes the messages, localizes > them, and > displays them to the user. If the user does not have IPP client > software, he would still be able to access the messages with a > standard > mail client and read them in English. > > That's just a suggestion for how I would approach the problem. > The main > point I am trying to make (which I am sure someone has already > made) is > that the IPP server should not have to localize notification > messages. > Localization should be done on the client side. > > > ______________________________________________________________________ > __ > ________________________________ > Charles Gordon > Osicom Technologies, Inc. > cgordon@osicom.com > http://www.digprod.com > > > -----Original Message----- > > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > > Sent: Wednesday, February 11, 1998 7:32 PM > > To: Roger K Debry; ipp@pwg.org > > Subject: Re: IPP> Notification Requirements > > > > Roger, > > > > One requirement, which we have discussed earlier, but seems to > have > > been > > forgotten lately, is the ability to request the human readable > > notifications in different langauges. > > > > E.g. I want to send a document for review to our offices in > Japan and > > want > > to have any notifications to my collegue in Tokyo in Japanese, > while I > > want > > to have my own notifications in Swedish :-) > > > > Can we create a scenario for this? > > > > Carl-Uno > > > > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > > >I have taken a pass at writing down a set of notification > > requirements. > > >They are in the PDF file attached to this note. I'd be glad > to take > > >comments and suggestions and turn this into a formal > requirements > > >document, if you all feel that this would be useful. > > > > > > > > > > > > > > >Roger K deBry > > >Senior Technical Staff Member > > >Architecture and Technology > > >IBM Printing Systems > > >email: rdebry@us.ibm.com > > >phone: 1-303-924-4080 > > > > > >Attachment Converted: > > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > > > Carl-Uno Manros > > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 11:54:08 1998 Delivery-Date: Thu, 12 Feb 1998 11:54:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18009 for ; Thu, 12 Feb 1998 11:54:07 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17090 for ; Thu, 12 Feb 1998 11:56:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA08367 for ; Thu, 12 Feb 1998 11:54:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 11:49:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA07810 for ipp-outgoing; Thu, 12 Feb 1998 11:49:25 -0500 (EST) From: don@lexmark.com Message-Id: <199802121649.AA21389@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: walker@dazel.com Cc: Ipp@pwg.org, Jkm@Underscore.Com Date: Thu, 12 Feb 1998 11:48:43 -0500 Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Jim Walker said: >One final point about this ubiquity. It does not do us any good to >design something that nobody builds. I do not know much about the >history of TIPSI, but it seems a valid case in point. Although it >is not necessarily a "pretty" protocol, it at least seems to address >these issues of a host->device protocol (in a transport-independent >fashion, to boot!). But nobody built it (sorry, Don), so who cares? Been there, done that. Several of us, including many from outside Lexmark worked long and hard on this with IEEE Std 1284.1-1997 (aka TIPSI or NPAP) to create a robust device to printer submission and management protocol. An obviously uninformed executive from a two-letter printer company said when asked about NPAP, "I don't know why anyone would need it." The resultant adoption rate is history. I would love to have a widely adopted protocol for this function but I am not highly motivated to plow this ground again. Tell you what, when you guys can get the work all done, I'll implement it faster than anyone else can! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Thu Feb 12 12:04:47 1998 Delivery-Date: Thu, 12 Feb 1998 12:04:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA18346 for ; Thu, 12 Feb 1998 12:04:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17137 for ; Thu, 12 Feb 1998 12:07:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA09445 for ; Thu, 12 Feb 1998 12:04:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 11:57:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA08461 for ipp-outgoing; Thu, 12 Feb 1998 11:57:27 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059CCA@EXCHANGE> From: "Gordon, Charles" To: "'Turner, Randy'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 11:55:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I don't think restricting the set of notification messages is too much of a limitation. After all, all of the messages are generated by software. Therefore, they will be canned messages anyway. Defining a set of messages to support will not prevent us from adding new ones later. If an IPP client receives a new message type which it doesn't recognize, it can either display the English version of it (supplied by the IPP server), or simply tell the user that it received a message it doesn't understand. New messages won't be supported by old software, but this just gives users an incentive to buy new software from us :-). ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Thursday, February 12, 1998 11:44 AM > To: 'Gordon, Charles' > Cc: 'ipp@pwg.org' > Subject: RE: IPP> Notification Requirements > > > I thought this was what you meant. I just wanted to make it clear that > client-localization requires defining a strict set of possible > messages, > with an associated token or code so that the client knows how to look > up > the localized version of this message in a localization dictionary (or > catalog, or whatever). I wonder if absolutely restricting the set of > messages that can be sent from server to client is too constraining? > > Randy > > > -----Original Message----- > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > Sent: Thursday, February 12, 1998 7:36 AM > To: 'Turner, Randy'; ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > The simplest way would be to restrict IPP to a specific set of > notification messages. The localized version of the IPP client > would > have these messages translated into the local language. When > the IPP > client reads the message from the IPP server, it would determine > which > notification event occurred and produce the localized version > version of > the message for it. > > For a simple example, suppose IPP supports the following > notification > messages. > > 1. Print job %job-name% which was sent to you by %sender% was > printed > on printer %printer% on %date% %time%. > 2. Print job %job-name% which was sent to you by %sender% was > aborted > on %date% %time% because of errors on printer %printer%. > 3. Print job %job-name% which you sent to %receipient% has been > printed > on printer %printer% on %date% %time%. > > and so on.... > > The idea here is that we define a message for each type of event > which > IPP will send notification of. The strings can include tokens > like > %job-name% which will be replaced by the client with strings > which > represent the actual values assigned to them. > > When the IPP server sends a message, it sends it in a format > which the > IPP client can recognize. For example, suppose the IPP server > sends a > notification to a receipient that a job has been printed > (message 1 > above). The IPP server formats the message so that client > software can > recognize that it is a notification that event 1 happenned, and > sends > values for the %job-name%, %sender%, and other tokens. The IPP > client > retrieves the localized text for notification event 1 and > inserts the > values for the tokens into the message. The localized message > can now > be displayed to the user. > > Well written Windows programs are designed so that they can be > easily > localized. All text is stored in a seperate file which can be > localized > without changing the code. If I write a Windows program which > uses > English, I can send the 'resource' file (which contains all my > English > text strings) to some translation house and have them provide > localized > versions for all the languages I want to support. Localized IPP > clients > can be create in this fashion. I would assume that other > operating > systems also support localization one way or another. > > I know the above example is rather simple, but I think it shows > how > localization could be done. > > > ______________________________________________________________________ > __ > ________________________________ > Charles Gordon > Osicom Technologies, Inc. > cgordon@osicom.com > http://www.digprod.com > > > -----Original Message----- > > From: Turner, Randy [SMTP:rturner@sharplabs.com] > > Sent: Thursday, February 12, 1998 9:45 AM > > To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; > ipp@pwg.org > > Subject: RE: IPP> Notification Requirements > > > > > > Can you elaborate a little on the exact method for how a > client would > > apply localization to a server-generated message? > > > > Randy > > > > > > -----Original Message----- > > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > > Sent: Thursday, February 12, 1998 6:37 AM > > To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > > Subject: RE: IPP> Notification Requirements > > > > If localization of messages is a requirement (and it > should be), > > I would > > suggest that messages be localized by software on the > receiver's > > PC. > > This would work as follows: > > > > 1. IPP server sends message (by whatever means) to an > IPP > > client on the > > remote user's PC. This message would be formatted to be > easily > > machine > > readable. > > 2. Software on remote user's PC retrieves the message > and > > localizes it. > > 3. Localized message it displayed to user. > > > > The advantage in this approach is that the IPP server > does not > > need to > > support different languages and character sets. > Instead, IPP > > client > > software does this. Since the client software is on the > remote > > user's > > PC, the user would, presumably, have installed a > localized > > version of > > the software, and the PC will be setup with the correct > > character set. > > > > It will probably be desirable to make the original > message sent > > from the > > IPP server to the client human readable as well as > machine > > readable. > > This would allow users to read the message even if they > don't > > have IPP > > client software. This could be done by either > generating the > > message as > > English text (the defacto International standard > language) > > formatted to > > make parsing by software easy, or by generating a two > part > > message where > > one part is text and the other part is machine readable. > > > > > If email is used for notification messages (and it does > seem > > like a good > > choice), then the message from the IPP server could be > sent to a > > special > > mailbox setup at the remote site. The IPP client > software could > > be a > > specialized mail client which decodes the messages, > localizes > > them, and > > displays them to the user. If the user does not have > IPP client > > software, he would still be able to access the messages > with a > > standard > > mail client and read them in English. > > > > That's just a suggestion for how I would approach the > problem. > > The main > > point I am trying to make (which I am sure someone has > already > > made) is > > that the IPP server should not have to localize > notification > > messages. > > Localization should be done on the client side. > > > > > > > ______________________________________________________________________ > > __ > > ________________________________ > > Charles Gordon > > Osicom Technologies, Inc. > > cgordon@osicom.com > > http://www.digprod.com > > > > > -----Original Message----- > > > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > > > Sent: Wednesday, February 11, 1998 7:32 PM > > > To: Roger K Debry; ipp@pwg.org > > > Subject: Re: IPP> Notification Requirements > > > > > > Roger, > > > > > > One requirement, which we have discussed earlier, but > seems to > > have > > > been > > > forgotten lately, is the ability to request the human > readable > > > notifications in different langauges. > > > > > > E.g. I want to send a document for review to our > offices in > > Japan and > > > want > > > to have any notifications to my collegue in Tokyo in > Japanese, > > while I > > > want > > > to have my own notifications in Swedish :-) > > > > > > Can we create a scenario for this? > > > > > > Carl-Uno > > > > > > > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > > > >I have taken a pass at writing down a set of > notification > > > requirements. > > > >They are in the PDF file attached to this note. I'd > be glad > > to take > > > >comments and suggestions and turn this into a formal > > requirements > > > >document, if you all feel that this would be useful. > > > > > > > > > > > > > > > > > > > >Roger K deBry > > > >Senior Technical Staff Member > > > >Architecture and Technology > > > >IBM Printing Systems > > > >email: rdebry@us.ibm.com > > > >phone: 1-303-924-4080 > > > > > > > >Attachment Converted: > > > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > > > > > Carl-Uno Manros > > > Principal Engineer - Advanced Printing Standards - > Xerox > > Corporation > > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 12:29:00 1998 Delivery-Date: Thu, 12 Feb 1998 12:29:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA18822 for ; Thu, 12 Feb 1998 12:28:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17253 for ; Thu, 12 Feb 1998 12:31:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10231 for ; Thu, 12 Feb 1998 12:28:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 12:24:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA09613 for ipp-outgoing; Thu, 12 Feb 1998 12:24:21 -0500 (EST) Date: Thu, 12 Feb 1998 09:16:13 -0800 (Pacific Standard Time) From: Ron Bergman To: "Gordon, Charles" cc: "'Turner, Randy'" , "'ipp@pwg.org'" Subject: RE: IPP> Notification Requirements In-Reply-To: <6FCC2B3BA67BD111A47D0060089D2815059CCA@EXCHANGE> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I would suggest that each message be preceded by the message number so that the server need only look at this one piece. Ron Bergman Dataproducts Corp. On Thu, 12 Feb 1998, Gordon, Charles wrote: > I don't think restricting the set of notification messages is too much > of a limitation. After all, all of the messages are generated by > software. Therefore, they will be canned messages anyway. > > Defining a set of messages to support will not prevent us from adding > new ones later. If an IPP client receives a new message type which it > doesn't recognize, it can either display the English version of it > (supplied by the IPP server), or simply tell the user that it received a > message it doesn't understand. New messages won't be supported by old > software, but this just gives users an incentive to buy new software > from us :-). > ________________________________________________________________________ > ________________________________ > Charles Gordon > Osicom Technologies, Inc. > cgordon@osicom.com > http://www.digprod.com > > > -----Original Message----- > > From: Turner, Randy [SMTP:rturner@sharplabs.com] > > Sent: Thursday, February 12, 1998 11:44 AM > > To: 'Gordon, Charles' > > Cc: 'ipp@pwg.org' > > Subject: RE: IPP> Notification Requirements > > > > > > I thought this was what you meant. I just wanted to make it clear that > > client-localization requires defining a strict set of possible > > messages, > > with an associated token or code so that the client knows how to look > > up > > the localized version of this message in a localization dictionary (or > > catalog, or whatever). I wonder if absolutely restricting the set of > > messages that can be sent from server to client is too constraining? > > > > Randy > > > > > > -----Original Message----- > > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > > Sent: Thursday, February 12, 1998 7:36 AM > > To: 'Turner, Randy'; ipp@pwg.org > > Subject: RE: IPP> Notification Requirements > > > > The simplest way would be to restrict IPP to a specific set of > > notification messages. The localized version of the IPP client > > would > > have these messages translated into the local language. When > > the IPP > > client reads the message from the IPP server, it would determine > > which > > notification event occurred and produce the localized version > > version of > > the message for it. > > > > For a simple example, suppose IPP supports the following > > notification > > messages. > > > > 1. Print job %job-name% which was sent to you by %sender% was > > printed > > on printer %printer% on %date% %time%. > > 2. Print job %job-name% which was sent to you by %sender% was > > aborted > > on %date% %time% because of errors on printer %printer%. > > 3. Print job %job-name% which you sent to %receipient% has been > > printed > > on printer %printer% on %date% %time%. > > > > and so on.... > > > > The idea here is that we define a message for each type of event > > which > > IPP will send notification of. The strings can include tokens > > like > > %job-name% which will be replaced by the client with strings > > which > > represent the actual values assigned to them. > > > > When the IPP server sends a message, it sends it in a format > > which the > > IPP client can recognize. For example, suppose the IPP server > > sends a > > notification to a receipient that a job has been printed > > (message 1 > > above). The IPP server formats the message so that client > > software can > > recognize that it is a notification that event 1 happenned, and > > sends > > values for the %job-name%, %sender%, and other tokens. The IPP > > client > > retrieves the localized text for notification event 1 and > > inserts the > > values for the tokens into the message. The localized message > > can now > > be displayed to the user. > > > > Well written Windows programs are designed so that they can be > > easily > > localized. All text is stored in a seperate file which can be > > localized > > without changing the code. If I write a Windows program which > > uses > > English, I can send the 'resource' file (which contains all my > > English > > text strings) to some translation house and have them provide > > localized > > versions for all the languages I want to support. Localized IPP > > clients > > can be create in this fashion. I would assume that other > > operating > > systems also support localization one way or another. > > > > I know the above example is rather simple, but I think it shows > > how > > localization could be done. > > > > > > ______________________________________________________________________ > > __ > > ________________________________ > > Charles Gordon > > Osicom Technologies, Inc. > > cgordon@osicom.com > > http://www.digprod.com > > > > > -----Original Message----- > > > From: Turner, Randy [SMTP:rturner@sharplabs.com] > > > Sent: Thursday, February 12, 1998 9:45 AM > > > To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; > > ipp@pwg.org > > > Subject: RE: IPP> Notification Requirements > > > > > > > > > Can you elaborate a little on the exact method for how a > > client would > > > apply localization to a server-generated message? > > > > > > Randy > > > > > > > > > -----Original Message----- > > > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > > > Sent: Thursday, February 12, 1998 6:37 AM > > > To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > > > Subject: RE: IPP> Notification Requirements > > > > > > If localization of messages is a requirement (and it > > should be), > > > I would > > > suggest that messages be localized by software on the > > receiver's > > > PC. > > > This would work as follows: > > > > > > 1. IPP server sends message (by whatever means) to an > > IPP > > > client on the > > > remote user's PC. This message would be formatted to be > > easily > > > machine > > > readable. > > > 2. Software on remote user's PC retrieves the message > > and > > > localizes it. > > > 3. Localized message it displayed to user. > > > > > > The advantage in this approach is that the IPP server > > does not > > > need to > > > support different languages and character sets. > > Instead, IPP > > > client > > > software does this. Since the client software is on the > > remote > > > user's > > > PC, the user would, presumably, have installed a > > localized > > > version of > > > the software, and the PC will be setup with the correct > > > character set. > > > > > > It will probably be desirable to make the original > > message sent > > > from the > > > IPP server to the client human readable as well as > > machine > > > readable. > > > This would allow users to read the message even if they > > don't > > > have IPP > > > client software. This could be done by either > > generating the > > > message as > > > English text (the defacto International standard > > language) > > > formatted to > > > make parsing by software easy, or by generating a two > > part > > > message where > > > one part is text and the other part is machine readable. > > > > > > > > If email is used for notification messages (and it does > > seem > > > like a good > > > choice), then the message from the IPP server could be > > sent to a > > > special > > > mailbox setup at the remote site. The IPP client > > software could > > > be a > > > specialized mail client which decodes the messages, > > localizes > > > them, and > > > displays them to the user. If the user does not have > > IPP client > > > software, he would still be able to access the messages > > with a > > > standard > > > mail client and read them in English. > > > > > > That's just a suggestion for how I would approach the > > problem. > > > The main > > > point I am trying to make (which I am sure someone has > > already > > > made) is > > > that the IPP server should not have to localize > > notification > > > messages. > > > Localization should be done on the client side. > > > > > > > > > > > ______________________________________________________________________ > > > __ > > > ________________________________ > > > Charles Gordon > > > Osicom Technologies, Inc. > > > cgordon@osicom.com > > > http://www.digprod.com > > > > > > > -----Original Message----- > > > > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > > > > Sent: Wednesday, February 11, 1998 7:32 PM > > > > To: Roger K Debry; ipp@pwg.org > > > > Subject: Re: IPP> Notification Requirements > > > > > > > > Roger, > > > > > > > > One requirement, which we have discussed earlier, but > > seems to > > > have > > > > been > > > > forgotten lately, is the ability to request the human > > readable > > > > notifications in different langauges. > > > > > > > > E.g. I want to send a document for review to our > > offices in > > > Japan and > > > > want > > > > to have any notifications to my collegue in Tokyo in > > Japanese, > > > while I > > > > want > > > > to have my own notifications in Swedish :-) > > > > > > > > Can we create a scenario for this? > > > > > > > > Carl-Uno > > > > > > > > > > > > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > > > > >I have taken a pass at writing down a set of > > notification > > > > requirements. > > > > >They are in the PDF file attached to this note. I'd > > be glad > > > to take > > > > >comments and suggestions and turn this into a formal > > > requirements > > > > >document, if you all feel that this would be useful. > > > > > > > > > > > > > > > > > > > > > > > > >Roger K deBry > > > > >Senior Technical Staff Member > > > > >Architecture and Technology > > > > >IBM Printing Systems > > > > >email: rdebry@us.ibm.com > > > > >phone: 1-303-924-4080 > > > > > > > > > >Attachment Converted: > > > > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > > > > > > > > > Carl-Uno Manros > > > > Principal Engineer - Advanced Printing Standards - > > Xerox > > > Corporation > > > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > > > Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Thu Feb 12 12:44:20 1998 Delivery-Date: Thu, 12 Feb 1998 12:44:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19232 for ; Thu, 12 Feb 1998 12:44:20 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17319 for ; Thu, 12 Feb 1998 12:46:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA10859 for ; Thu, 12 Feb 1998 12:44:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 12:39:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10319 for ipp-outgoing; Thu, 12 Feb 1998 12:39:48 -0500 (EST) From: Harry Lewis To: Cc: , Roger K Debry , , Subject: RE: IPP> Notification Requirements Message-ID: <5030300017877805000002L052*@MHS> Date: Thu, 12 Feb 1998 12:46:00 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030300017877805" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030300017877805 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree. >The idea here is that we define a message for each type of >event which IPP will send notification of. I've attached a file which attempts to express requirements and corresponding message types. >I wonder if absolutely restricting the set of messages that can be sent from server to client is too constraining? Maybe, but a practical approach to content can alleviate most concerns. There are several ways to go about standardizing content. A seriously c= omplex route is to allow recipient to request specific content per notificatio= n type per registration (someone mentioned this on the call, today). A complex= method is to define content per notification type (ex. Job Complete events don= 't need to indicate the jobs position in the queue). A simpler approach is to d= efine a pragmatic set of useful attributes, fixed for all notifications, someti= mes having no valid value. The downside of a simpler approach is baggage which might to be carried= with notifications. In general, notification traffic should be reduced via p= roper registration, un-registration, registration "time-to-live", and filters= - not event content. We should strive for a useful set of content to be carri= ed with each event such as: event-type (see attached chart) number-of-intervening-jobs job-k-octets (if known) job-k-octets-processed job-impressions (if known) job-impressions-interpreted job-impressions-completed impressionsCompletedCurrentCopy sheetCompletedCopyNumber sheetCompletedDocumentNumber copiesRequested copyType outputDestination jobStateReasons1 Harry Lewis = --Boundary=_0.0_=5030300017877805 Content-Type: application/octet-stream; name=notification.pdf Content-Transfer-Encoding: base64 JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAxNjQ0DQovRmlsdGVyIC9MWldE ZWNvZGUNCj4+DQpzdHJlYW0NCoAMRBAoEcjODQUQiwIBeRynAjOcxARSxCIIIBsMRkIBuOY2cjLC DNFhAaRBCBmNhcNY3GRoLo2MpUMBoIBaNRuNxcM4/IQUZhVCBsMpWNowMZfGxiMxcMBxNpxOp4IJ BIqCChuNRcNpqMhhOhxT6XTaeLRiN4LPqBCKzW5rLphA6ZTpsNBhKqnVZ/V7CLhvLaRcbHdJvOZ3 PatFhgMRdT69YLFRBzRrNaKpaquMcXjaPSYHkspdrxiL3FsCN6NcKVNJXG8LUtJawUMhiOZhT5TL 7/crJNp5YJretltNsMqeNa/t95hKRRBrRuFV+JytVy7LmpVHsvidnPJ3qcDG5Zcdfh+3pdmOJfzx Bj8bYrn18t0YRxvX4M9g7LovN9NmHKdK4zq4pkpqavKvLMJQGSmBsxwZOKrqVBiyjaqIlLztknkG twGimQxAsKJsGLAo1DKrw2rbcK4vyYwmyjaO/E8Fw4EDkJ04z2xfEYaOc6EFAVFMHRs4y3R0F0RB bGMMP9ISnurELKBwrT2SaGjbPU9rkrDI8krOtLuBnK7Gq7CCYQlJEYMZJkgTFLCazFD6jSjEcStj FExyy3MWy7NUZStN8bOTHM6LNHqixnIM8pqlgcSNQslx/MNFwHF00ptKdESarUhoylSjTEogaLLU VEhm1Cj0+9tLpuHAYRVRIhCohAXiMGaBhAKiRgUGCB1fIazV+p9ehq2waWOEFjt6Kg2oRXtnqog4 FBbV4YBgjYqDHZ1cjuhAUCcJ4qCSIwkiGINxCeJwQCkIooiqJN2CaIonCoFIqDUhAi1nXgQWgKQj 22JV+hANV+yQjY718EAmhALYu16MihVerrNprX8Rpw/qfCEq9ZW2zVYWDWFiWNZAZWUo1mIRaimp pXNtAUFF5CmKYgiOItciyKAi3tfAFX1iQXThIsMYuFocKZVC9Y4hGPX5kFgahYcbZKmq7KZLOVWn aoYVvbNvCoKQgicKYk3QJ2e3zfYbYnZMHL8o2jRY7Wl47fde6lEdhYHYuhWQGoapeumtZZaya6/m Iiited63vtWg0YHFjWGrbfK04ON7tWgjBrXFdY/veRSHXtM1GgS7VzZt+cQLYUCIMo7DSMYyhAMI 2DKOQ6BSswZBuGYYBQMnYdkMog9v3PdpyGgY2+F4g92pcHBoFAoDkNI3Dp3FcjkMI4BSLoqCVbcl b8HNciJleuWxmGuIEKlugV1olDeMQQDmOA3jf24yBAOg3ggDg9Z7DuHdnqQoCgNT9ApBldmGkOwZ QyPJK8DIFAVQ3BrDcG8O4bn+v/CgGUNwZHrhne++F8aogZlPCo+hrbLX3PsW4Qh1oUw6BhdyCB6r 1w6QjegDJBgNoEP0hpDZ3QLSPA0Bu9SEEIg3Bng7DiAUO4mwlfEvwFqDQbuHhYr11gKH5v1eqG8M 5IA5hzh6RoGYKA0htgCGWMoaQ3huCGG+Njt3svQckj0FAcw0BlDKHR+0NQxhrghFQiyjjFkCiuVs lj530stcOzAFAYw3hwDzHOOsfwytpPSU1MSq2Tg3kcryFzL1vBsDCHOQEfI/SADeGYEEnFelmYPF qR61n1rekoGyVD2X+SUktLFxwCgqFXfbKZmMqgwyDkLMNJUiJPy0h/KNwpi5kOtgCG92cb4mw0kq HCQoLXlnPeoHKbUbg5wjieFCbwcJwQRfBFUs0iESG+K3Fmaj6pkTHffDJb4bw5BtdsCCL4IJMBwj tHANzyVixAgSGKg8dpNzxJQr9ABA5az5lK4iLj8Jyznm5E6gEOJ2zvifLJEdGYVy3a7MgFFEZNQR mc78rdF3yIehVCx1oQQxQZoDQOgoVHcBteuGGHccXdg2J5Q5+lPKAS+eSDgrIKAghuDzIGoztH/A gqc7mQtFAFAxnpIoxkPnO0rfjEGiAYQ3Ozf28kGM5Kq1XmU9mJ4Q62Vuq/CZadYimz1pvCmUcXGY TVfc/B1sCwzhplU9oM1I62VXle/2PrtQxBvge7sHJHngAtBa9AGYMyWAos9D0xYNbSWfrBLOsoMq zxbo2zCxIZbF2NDkCCx9t3bBsBBZMOllQw2XsysE5D07SlmtCDV5lxyNGLuNaqvkxZ/WKsY9m29u aCBPCFb0NwbA82gZPai5lybl2fd5c61MhpiTGmuCi6ltrcUjCI4pcrOI43eegUgHEFLx2iv5ea5t cb01gaAAogINCmVuZHN0cmVhbQ0KZW5kb2JqDQozIDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYg L1RleHQgXQ0KL0ZvbnQgPDwNCi9GMyA0IDAgUg0KL0Y1IDUgMCBSDQo+Pg0KL0V4dEdTdGF0ZSA8 PA0KL0dTMSA2IDAgUg0KPj4NCj4+DQplbmRvYmoNCjggMCBvYmoNCjw8DQovVHlwZSAvSGFsZnRv bmUNCi9IYWxmdG9uZVR5cGUgMQ0KL0hhbGZ0b25lTmFtZSAoRGVmYXVsdCkNCi9GcmVxdWVuY3kg NjANCi9BbmdsZSA0NQ0KL1Nwb3RGdW5jdGlvbiAvUm91bmQNCj4+DQplbmRvYmoNCjYgMCBvYmoN Cjw8DQovVHlwZSAvRXh0R1N0YXRlDQovU0EgZmFsc2UNCi9PUCBmYWxzZQ0KL0hUIC9EZWZhdWx0 DQo+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0K L05hbWUgL0YzDQovRW5jb2RpbmcgOSAwIFINCi9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQNCj4+ DQplbmRvYmoNCjUgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovTmFt ZSAvRjUNCi9FbmNvZGluZyA5IDAgUg0KL0Jhc2VGb250IC9IZWx2ZXRpY2ENCj4+DQplbmRvYmoN CjkgMCBvYmoNCjw8DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbIDAvZ3JhdmUvYWN1 dGUvY2lyY3VtZmxleC90aWxkZS9tYWNyb24vYnJldmUvZG90YWNjZW50L2RpZXJlc2lzDQovcmlu Zy9jZWRpbGxhL2h1bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24vZG90bGVzc2kvYnVsbGV0L2J1bGxl dA0KL2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxs ZXQNCi9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVs bGV0DQogMzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTI3L2J1bGxldC9idWxsZXQvYnVsbGV0L3F1 b3Rlc2luZ2xiYXNlL2Zsb3Jpbi9xdW90ZWRibGJhc2UNCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2Vy ZGJsL2NpcmN1bWZsZXgvcGVydGhvdXNhbmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UNCi9idWxs ZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0 L3F1b3RlZGJscmlnaHQNCi9idWxsZXQvZW5kYXNoL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nh cm9uL2d1aWxzaW5nbHJpZ2h0L29lDQovYnVsbGV0L2J1bGxldC9ZZGllcmVzaXMvc3BhY2UgMTY0 L2N1cnJlbmN5IDE2Ni9icm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodA0KL29yZGZlbWlu aW5lIDE3Mi9sb2dpY2Fsbm90L2h5cGhlbi9yZWdpc3RlcmVkL21hY3Jvbi9kZWdyZWUvcGx1c21p bnVzL3R3b3N1cGVyaW9yDQovdGhyZWVzdXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVy ZWQvY2VkaWxsYS9vbmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXINCi9vbmVo YWxmL3RocmVlcXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0Fk aWVyZXNpcy9BcmluZw0KL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRp ZXJlc2lzL0lncmF2ZS9JYWN1dGUNCi9JY2lyY3VtZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9P Z3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZQ0KL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xh c2gvVWdyYXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlDQovVGhvcm4vZ2Vy bWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMvYXJpbmcN Ci9hZS9jY2VkaWxsYS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNpcy9pZ3JhdmUv aWFjdXRlDQovaWNpcmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0ZS9v Y2lyY3VtZmxleC9vdGlsZGUNCi9vZGllcmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRl L3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUNCi90aG9ybi95ZGllcmVzaXMNCl0NCj4+DQpl bmRvYmoNCjEgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA3IDAgUg0KL1Jlc291cmNl cyAzIDAgUg0KL0NvbnRlbnRzIDIgMCBSDQovUm90YXRlIDkwDQo+Pg0KZW5kb2JqDQo3IDAgb2Jq DQo8PA0KL1R5cGUgL1BhZ2VzDQovS2lkcyBbMSAwIFJdDQovQ291bnQgMQ0KL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0NCj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9Q YWdlcyA3IDAgUg0KPj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5 OTgwMjEyMTAyOTIwKQ0KL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciAzLjAgZm9yIFdpbmRv d3MpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDEyDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDM3 MTIgMDAwMDAgbg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAxNzM5IDAwMDAwIG4NCjAwMDAw MDIwNjYgMDAwMDAgbg0KMDAwMDAwMjE3NiAwMDAwMCBuDQowMDAwMDAxOTg3IDAwMDAwIG4NCjAw MDAwMDM4MTIgMDAwMDAgbg0KMDAwMDAwMTg1NSAwMDAwMCBuDQowMDAwMDAyMjgxIDAwMDAwIG4N CjAwMDAwMDM5MDEgMDAwMDAgbg0KMDAwMDAwMzk1NyAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1Np emUgMTINCi9Sb290IDEwIDAgUg0KL0luZm8gMTEgMCBSDQovSUQgWzxjZmRhM2EzMTRmZTdkZDY5 OWM5ZGM1NDE5YTVhNzFiZj48Y2ZkYTNhMzE0ZmU3ZGQ2OTljOWRjNTQxOWE1YTcxYmY+XQ0KPj4N CnN0YXJ0eHJlZg0KNDA2NA0KJSVFT0YNCg== --Boundary=_0.0_=5030300017877805-- From ipp-owner@pwg.org Thu Feb 12 13:34:40 1998 Delivery-Date: Thu, 12 Feb 1998 13:34:41 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20591 for ; Thu, 12 Feb 1998 13:34:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17483 for ; Thu, 12 Feb 1998 13:37:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12350 for ; Thu, 12 Feb 1998 13:34:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 13:26:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11181 for ipp-outgoing; Thu, 12 Feb 1998 13:26:07 -0500 (EST) Message-ID: <34E33EB4.D9716BBD@underscore.com> Date: Thu, 12 Feb 1998 13:25:56 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Teleconference minutes for 11 Feb 98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The teleconference started at approximately 1pm PDT. Attendees included: Roger DeBry (IBM) Harry Lewis (IBM) Carl Kugler (IBM) Carl-Uno Manros (Xerox) Peter Zehler (Xerox) Scott Barnes (Xerox) Tom Hastings (Xerox) Swen Johnson (Xerox?) Jim Walker (DAZEL) Jay Martin (Underscore) The primary topic of the day was "Asynchronous Notifications". Carl-Uno proposed that a BOF be held at the upcoming IETF meetings as a way of starting the IPP v2.0 effort, in which async notifications would be part of that effort. The group believed there was no need to startup an following WG for IPP in order to advance the definitions for async notifications; instead, Internet Drafts (I-D's) could be published for such purposes. One fundamental goal of the group was that support of async notifications within IPP should NOT necessarily mandate the development of a new protocol. Instead, every effort will be made to leverage existing protocols and practices whenever and wherever possible. The group then walked through Roger's proposal submitted to the IPP DL. * The focus is on End-User only; no administrative nor operator requirements are to be considered, at least at this point. * A new pair of terms is needed to denote "Reliable" and "Unreliable" types of notifications, much in the same manner as the "Immediate"/"Delayed" types. * An additional term is needed to denote a notification comprising both "Human Consumable" and "Machine Consumable". * Requirement 6: The IPP Printer should be able to notify the client when the delivery of an Event to a target Event Recipient fails; no specific details were proposed, but the discussion revolved around the idea of having the client optionally supply an email address to be used by the IPP Printer to send such event delivery failure messages. * Need to show an additional scenario having multiple Event Recipients. Roger volunteered to be the Requirements document Editor, and committed to publishing the first official draft to the IPP list no later than Tuesday, February 17. The topic then changed over to the recent DL thread concerning the need for a more robust "host-to-device" printing protocol. It was pointed out that this discussion really transcends the IPP WG, and that in no way should the IPP Chairman feel compelled to manage this discussion. It was suggested that perhaps a new PWG project (or at least a new DL) be formed for this topic; in the meantime, the IPP DL will be used for convenience. Roger suggested that people raising issues with IPP for use in host to printer scenarios should indicate whether the problem is with the current IPP Model document or the current IPP protocol document. For the problems with the Model document, they may be resolvable by extending the Model, by, say, adding more Printer attributes and maybe a Set-Printer-Attributes operation? For problems that were with the protocol (mapping) document, the PWG might develop a second IPP protocol document for use in the host to printer connection whose semantics would be the same (extended) IPP Model document. This second IPP protocol mapping document would be a PWG standard, not an IETF standard, since the document deals with the host to printer connection only (and not the Internet). It was suggested that some printers might implement both IPP protocol mappings, if they wanted to be used across the Internet and in the host to printer connection. But with the same semantic model, such a dual implementation would not be a big burden. The teleconference ended at approximately 2:50pm PDT. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 13:36:15 1998 Delivery-Date: Thu, 12 Feb 1998 13:36:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20653 for ; Thu, 12 Feb 1998 13:36:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17489 for ; Thu, 12 Feb 1998 13:38:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12553 for ; Thu, 12 Feb 1998 13:36:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 13:27:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11418 for ipp-outgoing; Thu, 12 Feb 1998 13:27:49 -0500 (EST) Date: Thu, 12 Feb 1998 10:27:20 PST From: David_Kellerman@nls.com To: ipp@pwg.org Message-ID: <009C1B29.435C2EBA.4@nls.com> Subject: RE: IPP> Notification Requirements Sender: ipp-owner@pwg.org Randy Turner said: > I thought this was what you meant. I just wanted to make it clear that > client-localization requires defining a strict set of possible messages, > with an associated token or code so that the client knows how to look up > the localized version of this message in a localization dictionary (or > catalog, or whatever). I wonder if absolutely restricting the set of > messages that can be sent from server to client is too constraining? For one existing example along these lines, look at the Adobe Printer Description File specification. Part of the specification for a printer model is a complete list of messages generated by the printer, and the PDF can also provide translations for the messages. So the set of messages can be "relatively" restricted, rather than "absolutely." ;-) :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From ipp-owner@pwg.org Thu Feb 12 14:05:44 1998 Delivery-Date: Thu, 12 Feb 1998 14:05:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA21340 for ; Thu, 12 Feb 1998 14:05:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA17592 for ; Thu, 12 Feb 1998 14:08:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA13348 for ; Thu, 12 Feb 1998 14:05:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 14:00:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12726 for ipp-outgoing; Thu, 12 Feb 1998 14:00:01 -0500 (EST) Message-Id: <3.0.1.32.19980212085944.01216100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Feb 1998 08:59:44 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Notification across firewall vs not for our requirements doc Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org In our requirements we should treat whether a notification method works across a firewire or not as a propertiy of the method, rather than something that the requester specifies. This strategy is the same as we finally evolved for the URL for Printers for secure vs. non-secure. So the scenarios in the requirements document should indicate parenthetically the property of across firewire vs non-firewall, rather than an input from the requester. Also some methods may be usuable for both across firewall and not, such as e-mail and pagers, while other methods may only be used when they don't cross firewalls. Tom From ipp-owner@pwg.org Thu Feb 12 15:20:40 1998 Delivery-Date: Thu, 12 Feb 1998 15:20:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25046 for ; Thu, 12 Feb 1998 15:20:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA17885 for ; Thu, 12 Feb 1998 15:23:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14143 for ; Thu, 12 Feb 1998 15:18:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 14:55:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13522 for ipp-outgoing; Thu, 12 Feb 1998 14:55:48 -0500 (EST) Message-Id: <3.0.1.32.19980212115128.009c0dd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Feb 1998 11:51:28 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> Notification Requirements In-Reply-To: <6FCC2B3BA67BD111A47D0060089D2815059CC8@EXCHANGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Guys, I think you are making it too easy. There are a number of places that are multi-lingual and there is not necessarily ONE localiced language (Florida, California, Canada and Switzerland are concrete examples, not to mention the UN offices in New York or the EU offices i Brussels). So even if we encode all messages in some language independent way, we might still need to indicate in the messages in which language they should be displayed to a particular user. Carl-Uno At 07:36 AM 2/12/98 PST, Gordon, Charles wrote: >The simplest way would be to restrict IPP to a specific set of >notification messages. The localized version of the IPP client would >have these messages translated into the local language. When the IPP >client reads the message from the IPP server, it would determine which >notification event occurred and produce the localized version version of >the message for it. > >For a simple example, suppose IPP supports the following notification >messages. > >1. Print job %job-name% which was sent to you by %sender% was printed >on printer %printer% on %date% %time%. >2. Print job %job-name% which was sent to you by %sender% was aborted >on %date% %time% because of errors on printer %printer%. >3. Print job %job-name% which you sent to %receipient% has been printed >on printer %printer% on %date% %time%. > >and so on.... > >The idea here is that we define a message for each type of event which >IPP will send notification of. The strings can include tokens like >%job-name% which will be replaced by the client with strings which >represent the actual values assigned to them. > >When the IPP server sends a message, it sends it in a format which the >IPP client can recognize. For example, suppose the IPP server sends a >notification to a receipient that a job has been printed (message 1 >above). The IPP server formats the message so that client software can >recognize that it is a notification that event 1 happenned, and sends >values for the %job-name%, %sender%, and other tokens. The IPP client >retrieves the localized text for notification event 1 and inserts the >values for the tokens into the message. The localized message can now >be displayed to the user. > >Well written Windows programs are designed so that they can be easily >localized. All text is stored in a seperate file which can be localized >without changing the code. If I write a Windows program which uses >English, I can send the 'resource' file (which contains all my English >text strings) to some translation house and have them provide localized >versions for all the languages I want to support. Localized IPP clients >can be create in this fashion. I would assume that other operating >systems also support localization one way or another. > >I know the above example is rather simple, but I think it shows how >localization could be done. > >________________________________________________________________________ >________________________________ >Charles Gordon >Osicom Technologies, Inc. >cgordon@osicom.com >http://www.digprod.com > >> -----Original Message----- >> From: Turner, Randy [SMTP:rturner@sharplabs.com] >> Sent: Thursday, February 12, 1998 9:45 AM >> To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org >> Subject: RE: IPP> Notification Requirements >> >> >> Can you elaborate a little on the exact method for how a client would >> apply localization to a server-generated message? >> >> Randy >> >> >> -----Original Message----- >> From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] >> Sent: Thursday, February 12, 1998 6:37 AM >> To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org >> Subject: RE: IPP> Notification Requirements >> >> If localization of messages is a requirement (and it should be), >> I would >> suggest that messages be localized by software on the receiver's >> PC. >> This would work as follows: >> >> 1. IPP server sends message (by whatever means) to an IPP >> client on the >> remote user's PC. This message would be formatted to be easily >> machine >> readable. >> 2. Software on remote user's PC retrieves the message and >> localizes it. >> 3. Localized message it displayed to user. >> >> The advantage in this approach is that the IPP server does not >> need to >> support different languages and character sets. Instead, IPP >> client >> software does this. Since the client software is on the remote >> user's >> PC, the user would, presumably, have installed a localized >> version of >> the software, and the PC will be setup with the correct >> character set. >> >> It will probably be desirable to make the original message sent >> from the >> IPP server to the client human readable as well as machine >> readable. >> This would allow users to read the message even if they don't >> have IPP >> client software. This could be done by either generating the >> message as >> English text (the defacto International standard language) >> formatted to >> make parsing by software easy, or by generating a two part >> message where >> one part is text and the other part is machine readable. >> >> If email is used for notification messages (and it does seem >> like a good >> choice), then the message from the IPP server could be sent to a >> special >> mailbox setup at the remote site. The IPP client software could >> be a >> specialized mail client which decodes the messages, localizes >> them, and >> displays them to the user. If the user does not have IPP client >> software, he would still be able to access the messages with a >> standard >> mail client and read them in English. >> >> That's just a suggestion for how I would approach the problem. >> The main >> point I am trying to make (which I am sure someone has already >> made) is >> that the IPP server should not have to localize notification >> messages. >> Localization should be done on the client side. >> >> >> ______________________________________________________________________ >> __ >> ________________________________ >> Charles Gordon >> Osicom Technologies, Inc. >> cgordon@osicom.com >> http://www.digprod.com >> >> > -----Original Message----- >> > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> > Sent: Wednesday, February 11, 1998 7:32 PM >> > To: Roger K Debry; ipp@pwg.org >> > Subject: Re: IPP> Notification Requirements >> > >> > Roger, >> > >> > One requirement, which we have discussed earlier, but seems to >> have >> > been >> > forgotten lately, is the ability to request the human readable >> > notifications in different langauges. >> > >> > E.g. I want to send a document for review to our offices in >> Japan and >> > want >> > to have any notifications to my collegue in Tokyo in Japanese, >> while I >> > want >> > to have my own notifications in Swedish :-) >> > >> > Can we create a scenario for this? >> > >> > Carl-Uno >> > >> > >> > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: >> > >I have taken a pass at writing down a set of notification >> > requirements. >> > >They are in the PDF file attached to this note. I'd be glad >> to take >> > >comments and suggestions and turn this into a formal >> requirements >> > >document, if you all feel that this would be useful. >> > > >> > > >> > > >> > > >> > >Roger K deBry >> > >Senior Technical Staff Member >> > >Architecture and Technology >> > >IBM Printing Systems >> > >email: rdebry@us.ibm.com >> > >phone: 1-303-924-4080 >> > > >> > >Attachment Converted: >> > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" >> > > >> > Carl-Uno Manros >> > Principal Engineer - Advanced Printing Standards - Xerox >> Corporation >> > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> > Phone +1-310-333 8273, Fax +1-310-333 5514 >> > Email: manros@cp10.es.xerox.com > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 15:58:05 1998 Delivery-Date: Thu, 12 Feb 1998 15:58:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26156 for ; Thu, 12 Feb 1998 15:58:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18090 for ; Thu, 12 Feb 1998 16:00:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA15468 for ; Thu, 12 Feb 1998 15:55:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 15:28:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14265 for ipp-outgoing; Thu, 12 Feb 1998 15:28:41 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059CCC@EXCHANGE> From: "Gordon, Charles" To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> Notification Requirements Date: Thu, 12 Feb 1998 15:27:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I think you're missing something here. (One of us is anyway). If we send a notification message to a user, it is reasonable (I think) to expect that user to use a PC which supports a language he understands to read the message. The localization will be done by the IPP client software on that PC. Therefore the client software will also be localized to the user's language. So the IPP client software will generate a notification message in the user's language. The IPP server does not even have to know what language that is. As long as the user uses a PC with IPP software which has been setup to support his language, everything should work fine. In other words, the user who receives the message chooses the language the message is displayed in by selecting a PC with IPP software which has already been setup to support his language. ________________________________________________________________________ ________________________________ Charles Gordon Osicom Technologies, Inc. cgordon@osicom.com http://www.digprod.com > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, February 12, 1998 2:51 PM > To: ipp@pwg.org > Subject: RE: IPP> Notification Requirements > > Guys, > > I think you are making it too easy. > > There are a number of places that are multi-lingual and there is not > necessarily ONE localiced language (Florida, California, Canada and > Switzerland are concrete examples, not to mention the UN offices in > New > York or the EU offices i Brussels). > > So even if we encode all messages in some language independent way, we > might still need to indicate in the messages in which language they > should > be displayed to a particular user. > > Carl-Uno > > At 07:36 AM 2/12/98 PST, Gordon, Charles wrote: > >The simplest way would be to restrict IPP to a specific set of > >notification messages. The localized version of the IPP client would > >have these messages translated into the local language. When the IPP > >client reads the message from the IPP server, it would determine > which > >notification event occurred and produce the localized version version > of > >the message for it. > > > >For a simple example, suppose IPP supports the following notification > >messages. > > > >1. Print job %job-name% which was sent to you by %sender% was > printed > >on printer %printer% on %date% %time%. > >2. Print job %job-name% which was sent to you by %sender% was > aborted > >on %date% %time% because of errors on printer %printer%. > >3. Print job %job-name% which you sent to %receipient% has been > printed > >on printer %printer% on %date% %time%. > > > >and so on.... > > > >The idea here is that we define a message for each type of event > which > >IPP will send notification of. The strings can include tokens like > >%job-name% which will be replaced by the client with strings which > >represent the actual values assigned to them. > > > >When the IPP server sends a message, it sends it in a format which > the > >IPP client can recognize. For example, suppose the IPP server sends > a > >notification to a receipient that a job has been printed (message 1 > >above). The IPP server formats the message so that client software > can > >recognize that it is a notification that event 1 happenned, and sends > >values for the %job-name%, %sender%, and other tokens. The IPP > client > >retrieves the localized text for notification event 1 and inserts the > >values for the tokens into the message. The localized message can > now > >be displayed to the user. > > > >Well written Windows programs are designed so that they can be easily > >localized. All text is stored in a seperate file which can be > localized > >without changing the code. If I write a Windows program which uses > >English, I can send the 'resource' file (which contains all my > English > >text strings) to some translation house and have them provide > localized > >versions for all the languages I want to support. Localized IPP > clients > >can be create in this fashion. I would assume that other operating > >systems also support localization one way or another. > > > >I know the above example is rather simple, but I think it shows how > >localization could be done. > > > >_____________________________________________________________________ > ___ > >________________________________ > >Charles Gordon > >Osicom Technologies, Inc. > >cgordon@osicom.com > >http://www.digprod.com > > > >> -----Original Message----- > >> From: Turner, Randy [SMTP:rturner@sharplabs.com] > >> Sent: Thursday, February 12, 1998 9:45 AM > >> To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; > ipp@pwg.org > >> Subject: RE: IPP> Notification Requirements > >> > >> > >> Can you elaborate a little on the exact method for how a client > would > >> apply localization to a server-generated message? > >> > >> Randy > >> > >> > >> -----Original Message----- > >> From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > >> Sent: Thursday, February 12, 1998 6:37 AM > >> To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org > >> Subject: RE: IPP> Notification Requirements > >> > >> If localization of messages is a requirement (and it should be), > >> I would > >> suggest that messages be localized by software on the receiver's > >> PC. > >> This would work as follows: > >> > >> 1. IPP server sends message (by whatever means) to an IPP > >> client on the > >> remote user's PC. This message would be formatted to be easily > >> machine > >> readable. > >> 2. Software on remote user's PC retrieves the message and > >> localizes it. > >> 3. Localized message it displayed to user. > >> > >> The advantage in this approach is that the IPP server does not > >> need to > >> support different languages and character sets. Instead, IPP > >> client > >> software does this. Since the client software is on the remote > >> user's > >> PC, the user would, presumably, have installed a localized > >> version of > >> the software, and the PC will be setup with the correct > >> character set. > >> > >> It will probably be desirable to make the original message sent > >> from the > >> IPP server to the client human readable as well as machine > >> readable. > >> This would allow users to read the message even if they don't > >> have IPP > >> client software. This could be done by either generating the > >> message as > >> English text (the defacto International standard language) > >> formatted to > >> make parsing by software easy, or by generating a two part > >> message where > >> one part is text and the other part is machine readable. > >> > >> If email is used for notification messages (and it does seem > >> like a good > >> choice), then the message from the IPP server could be sent to a > >> special > >> mailbox setup at the remote site. The IPP client software could > >> be a > >> specialized mail client which decodes the messages, localizes > >> them, and > >> displays them to the user. If the user does not have IPP client > >> software, he would still be able to access the messages with a > >> standard > >> mail client and read them in English. > >> > >> That's just a suggestion for how I would approach the problem. > >> The main > >> point I am trying to make (which I am sure someone has already > >> made) is > >> that the IPP server should not have to localize notification > >> messages. > >> Localization should be done on the client side. > >> > >> > >> > ______________________________________________________________________ > >> __ > >> ________________________________ > >> Charles Gordon > >> Osicom Technologies, Inc. > >> cgordon@osicom.com > >> http://www.digprod.com > >> > >> > -----Original Message----- > >> > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> > Sent: Wednesday, February 11, 1998 7:32 PM > >> > To: Roger K Debry; ipp@pwg.org > >> > Subject: Re: IPP> Notification Requirements > >> > > >> > Roger, > >> > > >> > One requirement, which we have discussed earlier, but seems to > >> have > >> > been > >> > forgotten lately, is the ability to request the human readable > >> > notifications in different langauges. > >> > > >> > E.g. I want to send a document for review to our offices in > >> Japan and > >> > want > >> > to have any notifications to my collegue in Tokyo in Japanese, > >> while I > >> > want > >> > to have my own notifications in Swedish :-) > >> > > >> > Can we create a scenario for this? > >> > > >> > Carl-Uno > >> > > >> > > >> > At 08:22 AM 2/10/98 PST, Roger K Debry wrote: > >> > >I have taken a pass at writing down a set of notification > >> > requirements. > >> > >They are in the PDF file attached to this note. I'd be glad > >> to take > >> > >comments and suggestions and turn this into a formal > >> requirements > >> > >document, if you all feel that this would be useful. > >> > > > >> > > > >> > > > >> > > > >> > >Roger K deBry > >> > >Senior Technical Staff Member > >> > >Architecture and Technology > >> > >IBM Printing Systems > >> > >email: rdebry@us.ibm.com > >> > >phone: 1-303-924-4080 > >> > > > >> > >Attachment Converted: > >> > "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf" > >> > > > >> > Carl-Uno Manros > >> > Principal Engineer - Advanced Printing Standards - Xerox > >> Corporation > >> > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > >> > Phone +1-310-333 8273, Fax +1-310-333 5514 > >> > Email: manros@cp10.es.xerox.com > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 15:59:33 1998 Delivery-Date: Thu, 12 Feb 1998 15:59:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA26194 for ; Thu, 12 Feb 1998 15:59:33 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18104 for ; Thu, 12 Feb 1998 16:02:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA15833 for ; Thu, 12 Feb 1998 15:59:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 15:43:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA14730 for ipp-outgoing; Thu, 12 Feb 1998 15:43:34 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC26A@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> What would the world be like if the host to printer requirements set went to a different protocol. Date: Thu, 12 Feb 1998 11:45:46 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I apologize for not attending the teleconference - the minutes make interesting reading. If we decided that there would a separate group doing 'not LPD and SNMP' (NLS) then several things would happen in the IPP world:- 1. The notification debate would be greatly simplified. IPP does client notification in human readable form, the protocol itself does not carry the notification, merely the request that the receiver generates the notification, eg attributes notify-method=email, notify-events=all, notify-destination='paulmo@microsoft.com'. There would need to be some way that a client could ask a server what type of notifications it supports. 2. IPP would be liberated from the requirements that this stuff fit in a printer's NIC. 3. IPP can focus on adding value between the client and server (enumerate printers, redirect jobs, etc.) The NLS protocol then picks up the requirements for:- 1. Low level device discovery - a server hunting around for a new device. (A server is not going to do a Yahoo search!) 2. Discovery of device capabilities (in general, 'what can a PrinterRUs mega laser 40 do?' plus 'specifically what can this megalaser 40 do?'). Discovering how to exploit the published feature set. 3. The peer queuing issue gets addressed cleanly. 4. Notifications get sent asynchronously , in machine readable form to well defined sets of end points (subscriber model). 5. We can talk about transport neutral again. 6. We can have good, defined security. (I would do this by certificate passing, with the printer having a list of certificate issuing authorities it trusts - 'any friend of verisign's is a friend of mine'). 7. We dont care about tunneling though firewalls, etc. - that is IPP's job 8. managing device settings, resetting the printer, ..... I dont think software builders would have any problems with this model, we already have a two step internal model, app to print subsystem, print subsystem to hardware marking device. Hardware builders have a real problem - Which protocol do they put in a printer? Or maybe both. That in turn creates a problem for the s/w people because we need the h/w people to support NLS or else it is no use. From ipp-owner@pwg.org Thu Feb 12 16:24:18 1998 Delivery-Date: Thu, 12 Feb 1998 16:24:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA26675 for ; Thu, 12 Feb 1998 16:24:18 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18257 for ; Thu, 12 Feb 1998 16:26:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA17043 for ; Thu, 12 Feb 1998 16:24:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 16:13:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA16406 for ipp-outgoing; Thu, 12 Feb 1998 16:13:28 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Does the world need a robust host-to-device network Message-ID: <5030100017394307000002L072*@MHS> Date: Thu, 12 Feb 1998 15:16:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA26675 > For one thing, such a protocol would be one heck of a lot more > efficient than IPP-over-HTTP. Anytime you frame bulk data within > a transaction protocol, you lose bigtime in terms of performance. Then why is file transfer via HTTP typically faster than with FTP? Also, TCP does provide a mechanism for out-of-band messages within a single connection. (Not that HTTP makes any use of it, but telnet does.) "The asynchronous or "out-of-band" notification will allow the application to go into 'urgent mode', reading data from the TCP connection. This allows control commands to be sent to an application whose normal input buffers are full of unprocessed data." -Carl ipp-owner@pwg.org on 02/12/98 12:40:15 AM Please respond to ipp-owner@pwg.org @ internet To: rturner@sharplabs.com @ internet cc: ipp@pwg.org @ internet Subject: Re: IPP> Does the world need a robust host-to-device network Randy, > I'm curious how this host-to-device protocol for printing would differ > from IPP 1.0? Excellent question. Right off the top of my head... For one thing, such a protocol would be one heck of a lot more efficient than IPP-over-HTTP. Anytime you frame bulk data within a transaction protocol, you lose bigtime in terms of performance. The CPAP designers learned this many years ago; the implementation of an FTP-like side-band "data channel" is one of the big features of CPAP v2. Also note that IEEE 1284.1 (aka "TIPSI", aka "NPAP") added similar support for a separate data-only channel near the end of that protocol's development. In addition to the significant increase in performance, we found that implementing such a protocol was a lot easier in terms of structure and complexity. Always a nice win, to be sure. Another way the protocol would differ from IPP is in the area of async messages during the transaction. As the client submits a job, the server can inform the client of any number of events that occur during the transaction, such as device alerts and other things the client may (or may not, granted) be interested in. Using CPAP as an example of this kind of protocol, CPAP has the ability for the server to convey to the client that the client's job was terminated (either via the front panel, or by a remote management app communicating with the server). Furthermore, the "job kill" message to the client can include exactly WHO killed the job, thereby allowing the client to provide an excellent level of detail to the job submitter as to why the job failed. There's more I can say here, but this is at least a start. I anxiously await comments from others, particularly from you, Randy! I'd really like to get this kind of thread rolling. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 16:43:23 1998 Delivery-Date: Thu, 12 Feb 1998 16:43:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27203 for ; Thu, 12 Feb 1998 16:43:22 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18353 for ; Thu, 12 Feb 1998 16:46:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18613 for ; Thu, 12 Feb 1998 16:43:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 16:30:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA17270 for ipp-outgoing; Thu, 12 Feb 1998 16:30:05 -0500 (EST) Message-ID: <34E36B71.6D25C9C4@ibm.net> Date: Thu, 12 Feb 1998 16:36:49 -0500 From: Philip Thambidurai X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> host-to-device ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I have to agree with Paul's comments. Seems like many here have similar notions. Paul Moore wrote: > I concur completely. This observation is in diametric opposition to > the position stated by Paul Moore, namely, that IPP is being > targeted > as the "all-in-one" protocol for network printing in the future, > whether it be INTERnet or INTRAnet. > > You misunderstand me (Or I misunderstand you). I completely agree with this > thread about needing a robust host-to-device protocol. My main complaint > from day one has been that people are trying to make IPP into 'all things > for all people' and have failed because this cannot be done. This is still > my position and one that I still continue to make. I think that the group as > a whole IS targetting it as the 'all-in-one' solution (it re-affirmed this > at the last WG) - but I dont think it should be. > > I.e dont confuse my analysis of what the WG as a whole has decided IPP > should be with what I think is the right thing to do - they are > diametrically opposed. > > This ' all-in-one' approach has several bad effects > > 1. People are trying to cram stuff in that does not really fit > > 2. The is a lack of focus on what real value the IPP could have in its core > space (printing over the public internet) > > 3. Nobody will look at a device level protocol because 'we can make IPP do > that'. Hence we get into the wierd suggestion that device alerts should be > sent via email! > > Regarding the 'value' or otherwise of IPP. I can see some scenarios where it > will be genuinley useful > > - printing to service shops that have faster/more functional printers > - printing to your neighbors printer (simpler than sneakernet) > - printing when on the road (hotel business centre for example) > > But this is less value than the need I have for a protocol that addresses > the real, actual, support desk pain in the *ssing, end user confusing, money > draining problems that exist in corporates, small businesses and soon in > homes. I doubt that IPP can do it, but (and this is the one change of stance > here) I have decided to see if IPP COULD be pushed into doing it. Having > spent some cycles I am 40/60 (yes/no) on this. Even if it could do it it > would be a huge kludge but something is better than nothing. The other > alternative is to do a different protocol - which I am totally in favor of. > > This sounds like a topic for an Austin BOF. > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Wednesday, February 11, 1998 8:23 AM > > To: Philip Thambidurai > > Cc: ipp@pwg.org > > Subject: Re: IPP> Does the world need a robust host-to-device network > > > > Philip, > > > > Many thanks for your supporting comments. > > > > > In summary, two issues stand out to me: > > > > > > 1. It does not appear that IPP will have much or any impact on the > > > multitude of printing solutions in use today (for the Intranet). > > > > I concur completely. This observation is in diametric opposition to > > the position stated by Paul Moore, namely, that IPP is being targeted > > as the "all-in-one" protocol for network printing in the future, > > whether it be INTERnet or INTRAnet. > > > > Over the last few weeks, several people have contacted me privately > > asking me the same sort of question: > > > > "What (or who) on earth is IPP really good for, anyway?" > > > > This is a question that really needs to be answered, given the > > many people who believe IPP adds very, very little value in the > > Intranet (aka, enterprise) environment. Someone is supposed to > > be starting a thread for this kind of discussion Real Soon Now. > > > > > > > 2. Lack of a ***complete*** standard printing solution within the > > LAN > > > environment (Intranets included). Today we have to use proprietary > > > solutions. > > > > Exactly. Again, people's comments to me come out as: > > > > "When compared to existing (proprietary/defacto) network printing > > protocols, IPP adds so little that it does not provide the impetus > > to change existing infrastructures in the Intranet environment." > > > > Sure, we can certainly extend IPP in the future (and extend it, > > and extend it...), but one critical design flaw exists in IPP (IMHO) > > that prevents a clean and simple design: > > > > IPP is based on HTTP > > > > In the early days of IPP, these assumptions made HTTP the obvious > > choice for an INTERnet printing protocol: > > > > 1. We get a free "hole" through the firewall > > > > 2. We get to leverage external work on security models and related > > infrastructure so that we didn't have to do that ourselves > > > > 3. With support from browser vendors, "native" support for IPP > > could be shipped with all standard browsers, thereby offering > > the holy grail of "no client-side software installation" > > > > Sadly, one by one, these critical core assumptions have fallen. > > > > So, why did we stick with HTTP? Momentum within the group? > > (ie, "I already have time and code invested, and I don't > > want to throw it away") > > > > IMHO, the only real redeeming value of using HTTP at all > > is the ability to leverage common server-side program > > invocation services (ie, CGI). This appears, though, to > > only help server-side developers coding for "general purpose" > > servers, and not embedded environments. > > > > Comments are welcome and encouraged here. Feel free to flame > > as necessary... ;-) > > > > ...jay > > > > PS: I realize these comments should be directed to the IESG > > as part of the Last Call period, but I don't know how to > > post comments to the IESG. :-( > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Feb 12 16:44:31 1998 Delivery-Date: Thu, 12 Feb 1998 16:44:31 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27238 for ; Thu, 12 Feb 1998 16:44:31 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18360 for ; Thu, 12 Feb 1998 16:47:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18801 for ; Thu, 12 Feb 1998 16:44:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 16:31:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA17410 for ipp-outgoing; Thu, 12 Feb 1998 16:31:05 -0500 (EST) Message-ID: <34E36BC5.2F749F89@ibm.net> Date: Thu, 12 Feb 1998 16:38:13 -0500 From: Philip Thambidurai X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> host-to-device ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I don't think that people are ranting about IPP not being able to address intranets. In my opinion, if you assume that the IPP Requirements doc is an oracle, then the current Model and Protocol specs are just fine. Even the reluctance of Microsoft to endorse it wholeheartedly appears to be due to the XML and http method issues --- which are really quite trivial relative to the issues being raised here (although the objections might cause the IESG to reject the current submission). To put it very simply, will IPP (in future) allow a corporation to not require support for proprietary/defacto printing solutions such as those available from companies like HP, Novell, etc.? Will it be sufficient if my local network-printer supports ONLY IPP? Will IPP provide the same functionality provided by proprietary solutions? Will IPP address the issue of print servers and queues (as defined by Netware)? Why do network printers have to support an ever increasing number of protocols? And often pay a licensing fee for the protocols? The ranting really has nothing to do with Inter or Intra nets. Turner, Randy wrote: > There has been a lot of ranting about IPP not being able to address > intranets but I have not seen any "meat" to these complaints. I would > like to see valid technical reasons why IPP cannot be used in intranets > as well as internets. I am talking about IPP as specified in the IPP > model document and not a specific mapping such as the IPP over HTTP > document. I think my earlier comment about a host-to-device protocol > being just another mapping of the IPP model to a different transport > still stands. > > Randy From ipp-owner@pwg.org Thu Feb 12 16:55:39 1998 Delivery-Date: Thu, 12 Feb 1998 16:55:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27432 for ; Thu, 12 Feb 1998 16:55:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18432 for ; Thu, 12 Feb 1998 16:58:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA19468 for ; Thu, 12 Feb 1998 16:55:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 16:44:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18810 for ipp-outgoing; Thu, 12 Feb 1998 16:44:29 -0500 (EST) Date: Thu, 12 Feb 1998 13:57:09 -0800 (PST) From: papowell@astart.com Message-Id: <199802122157.NAA10022@astart4.astart.com> To: jkm@underscore.com, paulmo@microsoft.com Subject: RE: IPP> Consensus on sending our drafts to the IESG Cc: ipp@pwg.org Sender: ipp-owner@pwg.org > From ipp-owner@pwg.org Sun Feb 8 13:27:12 1998 > From: Paul Moore > To: "'Jay Martin'" > Cc: ipp@pwg.org > Subject: RE: IPP> Consensus on sending our drafts to the IESG > Date: Sun, 8 Feb 1998 12:48:42 -0800 > > The problem is that nobody wants to do the other thing! > > I saw two problems with two , potentially different, soultions (hence my > double vote). I rolled with what I saw as the simple solution (HTTP - > interesting that you percieve them the opposite way round) and proposed > something called SIMPLE web printing based on what we were building - that > just did job submission. That eventually evolved into what we have today. > > Now we move on to address the issues that were lurking in the background - > printer discovery, feature dicsovery , configuration discovery, managment, > notification, flow control, peer queuing,.... (things for s/w to printer > interface) and billing, quotas, access control, server managemnt, job > redirection, ... (things for client to print subsystem interface). > I just want to get down and build good stuff for users - I am trying to .... large section deleted for brevity - read the original posting please I agree with almost all of these comments, from BOTH sides. I also went along with what I saw, which after some careful analysis I decided was a less than perfect methodology, in order to foster group or general concensus. I have reluctantly come to the position that the development of this standard and protocol has been driven more by 'Corporate Politics' and 'Having an Industry Concensus' than by 'Technical Requirements'. Now before you think that this is a NEGATIVE statement, I want to clearly indicate that I am ALL FOR 'Having an Industry Concensus' and that if it takes 'Corporate Politics' to reach this, I am all for it. I may not like the fact that we have an elephant with the appearance of a camel (apologies to PERL fans), but at least we have something that stands a chance of becoming an industry wide standard, and appears to be at least as functional as the old LPR (RFC1179) protocol, and compatible with gatewaying to it. Which is really all that I was interested in :-) Patrick (" There is industry agreement, a standard, and a working prototype. Of course we don't use it, cause we didn't invent it and can't license it or patent it. ") Powell P.S. - any resemblance to the above statement and proprietary network protocols versus using TCP/IP is entirely coincidental, irrelevant, immaterial, and highly controversial. :-) From ipp-owner@pwg.org Thu Feb 12 17:08:35 1998 Delivery-Date: Thu, 12 Feb 1998 17:08:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27683 for ; Thu, 12 Feb 1998 17:08:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA18496 for ; Thu, 12 Feb 1998 17:11:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA20155 for ; Thu, 12 Feb 1998 17:08:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 16:57:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19540 for ipp-outgoing; Thu, 12 Feb 1998 16:57:35 -0500 (EST) Message-Id: <34E36FA4.39ECF3@dazel.com> Date: Thu, 12 Feb 1998 15:54:44 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: "Wagner, William" Cc: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? References: <6FCC2B3BA67BD111A47D0060089D281508AECA@EXCHANGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Wagner, William wrote: > > The arguments suggest that IPP cannot deal with both the intra and > internet, and with both printers and servers. These apprehensions had > been addressed over the past year, although perhaps not to your > satisfaction. I disagree; I believe that the arguments suggest that IPP will not be able to deal with all ends of the spectrum effectively. It is one thing if it is just meant to be a quick-and-dirty protocol to get print jobs over the internet. It is quite another if it is meant to be the next end-all-be-all protocol that covers all ends of the spectrum, from full-blown internet-connected print servers to departmental intranet-connected print devices. > ... > > > I have become more > > and more disillusioned with the comprimises that we make to try and > > satisfy both ends of the spectrum (embedded printers all the way up > > to fat print servers). Also, like some, I do not believe that HTTP > > has been the Holy Grail that we all thought it would be. > [Wagner, William] > Yes, there have been compromises (and some degree of excess), > but I suggest that an IPP compatible implementation embedded in a > printer is still quite feasible. Feasible or desirable? And, as we press on, trying to add more and more features and capabilities to satisfy the feature-hungry print servers, will it still be feasible? Or will we continue to make sacrifices so that we do not leave out the embedded printer market? You know, what has led me down this path is what I call "the embedded printer stick" that can be pulled out at any time to whack us application guys over the head. "No, we can't do that; it might take an extra 25K!" Well, those people are absolutely right to defend their turf. But at what cost? Once again, do we lose by trying to server two masters? > > The first is that most of the prints in the > > world go from a client to a print server, or process of some kind, > > and then to the printing device. There are very few (any?) cases of > > a client application talking directly to a printing device. > [Wagner, William] > This observation is open to interpretation. There is usually > something between the application and the printer, but that something > may be in the same physical device as the application or the printer. > So, from a network protocol point of view, there are quite a few > protocols that transfer a print job between a workstation and a printer. > > I say that this implies that there is no requirement Yes, there are "quite a few protocols that transfer a print job between a workstation and a printer"... and that is the problem! Look at all of the people that are calling for a host-to-device protocol; they are all people whose software (or firmware) has to drive print devices from a number of different manufacturers. Yes, the software people (DAZEL, Microsoft, Underscore, etc) and hardware bridge people (i-data) are saying that they would all like one complete robust standard whatever-to-print-device protocol. > > for a single protocol that solves both the client->server and > > server->printer cases. That was one of the things that we were trying > > to do with IPP. > [Wagner, William] > I think you are mistaken. From what I recall, IPP sought to > define a protocol between a client application and a logical printer. > That logical printer could very well have been an external server, in > which case the server to printer connection was not defined. Or, the > server could be embedded in the printer, in which case there was no > network connection involved. I do not believe that I am mistaken. I believe that you just said the same thing that I did. You are right when you say that IPP is a protocol to go from a client to a logical printer. And, you have described variability at one end of the connection; i.e., the logical printer can be a print server or the actual print hardware. But, remember that there is variability at the other end, too; i.e., the client that you mention can either be the true client that is generating the print request, or it can be a print server. So, we end up with a protocol that people think should be appropriate for client->printer, client->server, and server->printer. And, once again, it is the "server to printer connection" that many of us are talking about. We would like to have an industry standard way of driving print hardware in an enterprise environment. > > The second observation has to do with deployment. How many of us > > really believe that people are going to be hooking up raw printing > > hardware (i.e., printers) directly to the internet for people to > > print to? If an *inter*net printing protocol is going to be deployed, > > ya' gotta' believe that it is going to be on a high-powered print > > server/spooler of some kind. Although only a very small sample, I > > confirmed this with several system administrators (and a marketeer > > or two ;-). Once again, I think that this argues for separate > > requirements for the client->server and server->printer protocols. > [Wagner, William] I do not agree that users will not be hooking > up a printer intended to take jobs via the internet. Well, as I said it was a small sample. And all are allowed their subjective opinion. It is the opinion of myself and others that I talked to that, if *inter*net printing is going to be deployed, it will be done with a piece of software between the world and that printer. > And unless you are defining server in a functional rather than > physical sense, I would not agree that a separate sever must always be > present. And, if you prefer to think of IPP as a client to server > protocol, that is just fine, recognizing that a server may not > necessarily be what and where you are accustomed to see it. Huh? ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Thu Feb 12 18:18:44 1998 Delivery-Date: Thu, 12 Feb 1998 18:18:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28819 for ; Thu, 12 Feb 1998 18:18:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18797 for ; Thu, 12 Feb 1998 18:21:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21550 for ; Thu, 12 Feb 1998 18:18:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:06:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20706 for ipp-outgoing; Thu, 12 Feb 1998 18:06:06 -0500 (EST) Message-Id: <34E37F8E.A976B2B9@dazel.com> Date: Thu, 12 Feb 1998 17:02:38 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Cc: Jay Martin Subject: Re: IPP> Does the world need a robust host-to-device network References: <00040323.3036@okidata.com> <34E1D04F.2D40D4F8@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Jay Martin wrote: > > ... > > Exactly. Again, people's comments to me come out as: > > "When compared to existing (proprietary/defacto) network printing > protocols, IPP adds so little that it does not provide the impetus > to change existing infrastructures in the Intranet environment." I think that this is the nut. If a print hardware vendor is only going to embed *one* more protocol into their printer, would it be IPP? Is it enough of a good thing to build it? If you build it, will they come? To say it another way, is this *the* protocol that all of the print vendors are going to implement so that, now, I, an application writer, can migrate to this one protocol to drive all the latest and greatest print hardware. On the other hand, if you, Mr. printer vendor, are happy as a clam to keep embedding protocols until the cows come home, then it does not matter. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Thu Feb 12 18:21:18 1998 Delivery-Date: Thu, 12 Feb 1998 18:21:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28857 for ; Thu, 12 Feb 1998 18:21:18 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18810 for ; Thu, 12 Feb 1998 18:23:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21900 for ; Thu, 12 Feb 1998 18:21:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:11:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20974 for ipp-outgoing; Thu, 12 Feb 1998 18:11:38 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEDC@EXCHANGE> From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Thu, 12 Feb 1998 18:10:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Considering the depth of feeling about IPP inadequacy, I suggest that some attempt be made to more clearly identify the perceived problems... Is it because IPP does not address the published requirements or because the requirements were inadequate (or changed). It seems, for example, that Mr. Walker feels that IPP is not adequate for the Internet because too many compromises were made for the embedded implementation. Mr. Moore, on the other hand, seems to suggest that IPP may be fine for the internet but is inappropriate for an intranet. (because too many compromises were made). Jay seems to be just unhappy with IPP, suggesting perhaps that it is not good for anything (because to many compromises were made?) The positions point to at least four different protocols; Internet client to server; Intranet client to server, server to printer, and a client to printer. Is this what is necessary? Is it not possible to come up with a sufficiently extensible protocol to handle all of these? W. A. Wagner (Bill Wagner) OSICOM/DPI From jmp-owner@pwg.org Thu Feb 12 18:38:05 1998 Delivery-Date: Thu, 12 Feb 1998 18:38:05 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29063 for ; Thu, 12 Feb 1998 18:38:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18900 for ; Thu, 12 Feb 1998 18:40:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA23368 for ; Thu, 12 Feb 1998 18:37:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:34:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22329 for jmp-outgoing; Thu, 12 Feb 1998 18:29:32 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> Hotel reservations for the Hyatt Message-ID: <5040300012521536000002L062*@MHS> Date: Thu, 12 Feb 1998 18:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Earlier today (Thursday, 2/12), the Hyatt hotel mistakenly told some people I was holding a block of rooms that I would reserve on everyone's behalf. This misunderstanding has been corrected. Everyone who was so informed, should make their own reservation with the hotel under "Printer Working Group" per our original plan. The hotel phone number is 512-477-1234. Also, please continue to send me pings on your attendance at the meetings so we have the most accurate headcount possible for the meetings. Thanks... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Thu Feb 12 18:38:46 1998 Delivery-Date: Thu, 12 Feb 1998 18:38:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29084 for ; Thu, 12 Feb 1998 18:38:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18911 for ; Thu, 12 Feb 1998 18:41:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA23458 for ; Thu, 12 Feb 1998 18:38:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:24:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22037 for ipp-outgoing; Thu, 12 Feb 1998 18:24:34 -0500 (EST) Message-Id: <3.0.1.32.19980212152026.00b0bb30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Feb 1998 15:20:26 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Teleconference minutes for 11 Feb 98 In-Reply-To: <34E33EB4.D9716BBD@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Jay, A slight correction to the minutes. I am certain I never talked about starting an IPP v2.0 effort at this stage, I was suggesting that maybe the IETF Area Directors might prefer a separate little project on IPP Notifications, which would be complementary to IPP v1.0. Carl-Uno At 10:25 AM 2/12/98 PST, Jay Martin wrote: >The teleconference started at approximately 1pm PDT. >Attendees included: > >Roger DeBry (IBM) >Harry Lewis (IBM) >Carl Kugler (IBM) >Carl-Uno Manros (Xerox) >Peter Zehler (Xerox) >Scott Barnes (Xerox) >Tom Hastings (Xerox) >Swen Johnson (Xerox?) >Jim Walker (DAZEL) >Jay Martin (Underscore) > >The primary topic of the day was "Asynchronous Notifications". > >Carl-Uno proposed that a BOF be held at the upcoming IETF meetings as >a way of starting the IPP v2.0 effort, in which async notifications >would be part of that effort. The group believed there was no need to >startup an following WG for IPP in order to advance the definitions >for async notifications; instead, Internet Drafts (I-D's) could be >published for such purposes. > >One fundamental goal of the group was that support of async >notifications within IPP should NOT necessarily mandate the >development of a new protocol. Instead, every effort will be made to >leverage existing protocols and practices whenever and wherever >possible. > >The group then walked through Roger's proposal submitted to the IPP >DL. > > * The focus is on End-User only; no administrative nor operator > requirements are to be considered, at least at this point. > > * A new pair of terms is needed to denote "Reliable" and > "Unreliable" types of notifications, much in the same manner as > the "Immediate"/"Delayed" types. > > * An additional term is needed to denote a notification comprising > both "Human Consumable" and "Machine Consumable". > > * Requirement 6: The IPP Printer should be able to notify the client > when the delivery of an Event to a target Event Recipient fails; > no specific details were proposed, but the discussion revolved > around the idea of having the client optionally supply an email > address to be used by the IPP Printer to send such event delivery > failure messages. > > * Need to show an additional scenario having multiple Event > Recipients. > >Roger volunteered to be the Requirements document Editor, and >committed to publishing the first official draft to the IPP list no >later than Tuesday, February 17. > > >The topic then changed over to the recent DL thread concerning the >need for a more robust "host-to-device" printing protocol. It was >pointed out that this discussion really transcends the IPP WG, and >that in no way should the IPP Chairman feel compelled to manage this >discussion. It was suggested that perhaps a new PWG project (or at >least a new DL) be formed for this topic; in the meantime, the IPP DL >will be used for convenience. > >Roger suggested that people raising issues with IPP for use in host to >printer scenarios should indicate whether the problem is with the >current IPP Model document or the current IPP protocol document. > >For the problems with the Model document, they may be resolvable by >extending the Model, by, say, adding more Printer attributes and maybe >a Set-Printer-Attributes operation? > >For problems that were with the protocol (mapping) document, the PWG >might develop a second IPP protocol document for use in the host to >printer connection whose semantics would be the same (extended) IPP >Model document. This second IPP protocol mapping document would be a >PWG standard, not an IETF standard, since the document deals with the >host to printer connection only (and not the Internet). > >It was suggested that some printers might implement both IPP protocol >mappings, if they wanted to be used across the Internet and in the >host to printer connection. But with the same semantic model, such a >dual implementation would not be a big burden. > >The teleconference ended at approximately 2:50pm PDT. > > ...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 From ipp-owner@pwg.org Thu Feb 12 18:47:38 1998 Delivery-Date: Thu, 12 Feb 1998 18:47:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29295 for ; Thu, 12 Feb 1998 18:47:37 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18953 for ; Thu, 12 Feb 1998 18:50:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24599 for ; Thu, 12 Feb 1998 18:47:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:29:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22347 for ipp-outgoing; Thu, 12 Feb 1998 18:29:43 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> Hotel reservations for the Hyatt Message-ID: <5040300012521536000002L062*@MHS> Date: Thu, 12 Feb 1998 18:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Earlier today (Thursday, 2/12), the Hyatt hotel mistakenly told some people I was holding a block of rooms that I would reserve on everyone's behalf. This misunderstanding has been corrected. Everyone who was so informed, should make their own reservation with the hotel under "Printer Working Group" per our original plan. The hotel phone number is 512-477-1234. Also, please continue to send me pings on your attendance at the meetings so we have the most accurate headcount possible for the meetings. Thanks... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Thu Feb 12 18:50:39 1998 Delivery-Date: Thu, 12 Feb 1998 18:50:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29351 for ; Thu, 12 Feb 1998 18:50:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18975 for ; Thu, 12 Feb 1998 18:53:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA25004 for ; Thu, 12 Feb 1998 18:50:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:37:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA23239 for ipp-outgoing; Thu, 12 Feb 1998 18:37:00 -0500 (EST) Mime-Version: 1.0 Date: Thu, 12 Feb 1998 18:37:20 -0500 Message-ID: <4E3870C0.@xionics.com> From: RMcComiskie@xionics.com (Robert McComiskie) Subject: Re[2]: IPP> Does the world need a robust host-to-device netw To: ipp@pwg.org, walker@dazel.com Cc: Jay Martin Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Seems to me that applications care more about the printer driver API in the host OS rather than the protocol. The printer vendor will create the driver, the app writer just prints to the API. Bob. ********************************************************************* ** Bob McComiskie Voice: 781-229-7021 ** ** Product Line Manager Fax: 781-229-7119 ** ** Xionics Document Technologies, Inc ** ** 70 Blanchard Road rmccomiskie@xionics.com ** ** Burlington, MA 01803 USA http://www.xionics.com ** ********************************************************************* ______________________________ Reply Separator _________________________________ Subject: Re: IPP> Does the world need a robust host-to-device network Author: walker@dazel.com at Internet Date: 2/12/98 5:02 PM Jay Martin wrote: > > ... > > Exactly. Again, people's comments to me come out as: > > "When compared to existing (proprietary/defacto) network printing > protocols, IPP adds so little that it does not provide the impetus > to change existing infrastructures in the Intranet environment." I think that this is the nut. If a print hardware vendor is only going to embed *one* more protocol into their printer, would it be IPP? Is it enough of a good thing to build it? If you build it, will they come? To say it another way, is this *the* protocol that all of the print vendors are going to implement so that, now, I, an application writer, can migrate to this one protocol to drive all the latest and greatest print hardware. On the other hand, if you, Mr. printer vendor, are happy as a clam to keep embedding protocols until the cows come home, then it does not matter. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From pwg-owner@pwg.org Thu Feb 12 18:54:13 1998 Delivery-Date: Thu, 12 Feb 1998 18:54:14 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29415 for ; Thu, 12 Feb 1998 18:54:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18990 for ; Thu, 12 Feb 1998 18:56:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA25377 for ; Thu, 12 Feb 1998 18:54:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:43:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22304 for pwg-outgoing; Thu, 12 Feb 1998 18:29:21 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> Hotel reservations for the Hyatt Message-ID: <5040300012521536000002L062*@MHS> Date: Thu, 12 Feb 1998 18:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Earlier today (Thursday, 2/12), the Hyatt hotel mistakenly told some people I was holding a block of rooms that I would reserve on everyone's behalf. This misunderstanding has been corrected. Everyone who was so informed, should make their own reservation with the hotel under "Printer Working Group" per our original plan. The hotel phone number is 512-477-1234. Also, please continue to send me pings on your attendance at the meetings so we have the most accurate headcount possible for the meetings. Thanks... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Thu Feb 12 18:56:04 1998 Delivery-Date: Thu, 12 Feb 1998 18:56:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29470 for ; Thu, 12 Feb 1998 18:56:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19002 for ; Thu, 12 Feb 1998 18:58:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA25610 for ; Thu, 12 Feb 1998 18:56:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 18:43:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA23942 for ipp-outgoing; Thu, 12 Feb 1998 18:42:57 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEDD@EXCHANGE> From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> host-to-device ... Date: Thu, 12 Feb 1998 18:41:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org > -----Original Message----- > From: Philip Thambidurai [SMTP:pthambi@ibm.net] > > > I don't think that people are ranting about IPP not being able to > address intranets. > [Wagner, William] I certainly got the impression that some were suggesting that IPP was inappropriate for intranets. Others suggest that it is inadequate for Internets. And others, such as Phillip, observe that IPP is not the one ultimate protocol. Perhaps all are correct. And I agree that a be-all do-all protocol is not feasible (and indeed, it was never the objective of IPP). As to supporting multiple protocols, take a look at what we have today. TCP sockets (at various port numbers) , LPD (of various flavors), Apple PAP, DLC, NetBeui, NetWare Print Server, NetWare NPrinter, NetWare NDPS (all at various frame types), FTP and Telnet. Add JetSend, Salutation, EMail printing (POP3), HTTP and SNMP (the last two for management) etc. Hey, whats wrong with adding a couple more? W. A. Wagner (Bill Wagner) OSICOM/DPI From owner-ietf-ppp@merit.edu Thu Feb 12 18:56:07 1998 Delivery-Date: Thu, 12 Feb 1998 18:56:07 -0500 Return-Path: owner-ietf-ppp@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA29475 for ; Thu, 12 Feb 1998 18:56:06 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19005 for ; Thu, 12 Feb 1998 18:58:46 -0500 (EST) Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05522; Thu, 12 Feb 1998 18:47:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:45:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05480 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:45:49 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05473 for ; Thu, 12 Feb 1998 18:45:44 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA140; Thu, 12 Feb 1998 18:46:03 -0500 Message-ID: <34E3896E.319B8B9F@BayNetworks.com> Date: Thu, 12 Feb 1998 18:44:46 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: "Philip A. Prindeville" CC: vandys@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802122329.PAA18080@chaos.enteka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Philip A. Prindeville wrote: > [..] > > I think you are being naive. As you go up the ISO reference > model it gets easier to abstract things away because the lower > layers are designed to deal with such details. > > The news is: *we* are at the lower layer. These are the issues > that we have to concern ourselves with so that no one else will > have to. > Well, the TCP-like abstraction is certainly an ideal which we can't achieve at this level, as you point out. My point was that L2TP could be defined to attempt to contain the more physical-level characteristics of the link to the end with the actual physical connection (i.e. the LAC). If we changed L2TP to differentiate HDLC and non-HDLC sessions at the LNS, then the LNS would be able to satisfy the ACF handling for HDLC links; And for non-HDLC links the LNS would just not include ACCM or ACFC options, and not prepend the ACF on any packets it sent out (nor expect to receive them!). Then, as long as all of the PPP-over-X protocols can take care of framing at the LAC and simply forward rfc1661-style PPP frames between the LAC and LNS we are all set. I don't yet understand (which may be entirely my fault!) why this wouldn't be effective. If in the future some portion of PPP framing has to be known at the LNS then we can add in that functionality to the L2TP protocol at that time (fairly simply). Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 From ipp-owner@pwg.org Thu Feb 12 19:17:40 1998 Delivery-Date: Thu, 12 Feb 1998 19:17:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA29818 for ; Thu, 12 Feb 1998 19:17:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA19119 for ; Thu, 12 Feb 1998 19:20:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA26434 for ; Thu, 12 Feb 1998 19:17:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 19:08:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA25848 for ipp-outgoing; Thu, 12 Feb 1998 19:08:04 -0500 (EST) Message-Id: <3.0.1.32.19980212160358.0098e6c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Feb 1998 16:03:58 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> Does the world need a robust host-to-device network printing protocol? In-Reply-To: <6FCC2B3BA67BD111A47D0060089D281508AEDC@EXCHANGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 03:10 PM 2/12/98 PST, Wagner, William wrote: >Considering the depth of feeling about IPP inadequacy, I suggest that >some attempt be made to more clearly identify the perceived problems... >Is it because IPP does not address the published requirements or because >the requirements were inadequate (or changed). > >It seems, for example, that Mr. Walker feels that IPP is not adequate >for the Internet because too many compromises were made for the embedded >implementation. Mr. Moore, on the other hand, seems to suggest that IPP >may be fine for the internet but is inappropriate for an intranet. >(because too many compromises were made). Jay seems to be just unhappy >with IPP, suggesting perhaps that it is not good for anything (because >to many compromises were made?) > >The positions point to at least four different protocols; Internet >client to server; Intranet client to server, server to printer, and a >client to printer. Is this what is necessary? Is it not possible to come >up with a sufficiently extensible protocol to handle all of these? > >W. A. Wagner (Bill Wagner) >OSICOM/DPI > I want to remind you all that we stated as our intent when we started work on IPP V1.0, that we were trying to solve 80% of the problem in the first version, which means that we conciously left out a number of things to be resolved later. We also stated that we were trying to concentrate on solving the user to what-ever problem in our first version, leaving some of the device and management type problems for a future version. Also remember, that some of the intial reactions in the IETF was that we were trying to do far too MUCH in IPP V1.0, while now we seem to be hearing that there is too much missing. You cannot have your cake and eat it..... I do not buy the argument that HTTP is bad, even if you choose to use IPP to acces your print device. I think there is enough evidence from prototyping at that stage to show that it works pretty well. Some printer vendors started putting in HTTP in their printers to do configuration and management even before we started talking about using it for IPP. I would hope that the current IPP approach can be used as a common basis for developing both client to print server and print server to device communication, even though I agree that IPP V1.0 was developed to primarily support the former. If this results in an additional protocol optimized for print server to device, so be it. I expect that any printer that is aimed for shared use on the network would want to include the IPP server functionality anyway, so that leaves the discussion about how big a share of remaining printers would really need an additional simpler protocol that is optimized for the device. My 2 cents... Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 19:46:46 1998 Delivery-Date: Thu, 12 Feb 1998 19:46:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA00187 for ; Thu, 12 Feb 1998 19:46:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA19237 for ; Thu, 12 Feb 1998 19:49:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA27313 for ; Thu, 12 Feb 1998 19:46:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 19:37:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26715 for ipp-outgoing; Thu, 12 Feb 1998 19:37:33 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Carl-Uno Manros'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Thu, 12 Feb 1998 16:38:03 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I agree with Carl-Uno that we did what we said we were going to do. And I, for one, am optimistic about what we have done for both intranets and internets. We have a model and framework for printing, and outside of more advanced job management and async notifications (which we clearly knew from the get-go we wouldn't do for 1.0), we've got a very good printing solution. Randy -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Thursday, February 12, 1998 4:04 PM To: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network printing protocol? At 03:10 PM 2/12/98 PST, Wagner, William wrote: >Considering the depth of feeling about IPP inadequacy, I suggest that >some attempt be made to more clearly identify the perceived problems... >Is it because IPP does not address the published requirements or because >the requirements were inadequate (or changed). > >It seems, for example, that Mr. Walker feels that IPP is not adequate >for the Internet because too many compromises were made for the embedded >implementation. Mr. Moore, on the other hand, seems to suggest that IPP >may be fine for the internet but is inappropriate for an intranet. >(because too many compromises were made). Jay seems to be just unhappy >with IPP, suggesting perhaps that it is not good for anything (because >to many compromises were made?) > >The positions point to at least four different protocols; Internet >client to server; Intranet client to server, server to printer, and a >client to printer. Is this what is necessary? Is it not possible to come >up with a sufficiently extensible protocol to handle all of these? > >W. A. Wagner (Bill Wagner) >OSICOM/DPI > I want to remind you all that we stated as our intent when we started work on IPP V1.0, that we were trying to solve 80% of the problem in the first version, which means that we conciously left out a number of things to be resolved later. We also stated that we were trying to concentrate on solving the user to what-ever problem in our first version, leaving some of the device and management type problems for a future version. Also remember, that some of the intial reactions in the IETF was that we were trying to do far too MUCH in IPP V1.0, while now we seem to be hearing that there is too much missing. You cannot have your cake and eat it..... I do not buy the argument that HTTP is bad, even if you choose to use IPP to acces your print device. I think there is enough evidence from prototyping at that stage to show that it works pretty well. Some printer vendors started putting in HTTP in their printers to do configuration and management even before we started talking about using it for IPP. I would hope that the current IPP approach can be used as a common basis for developing both client to print server and print server to device communication, even though I agree that IPP V1.0 was developed to primarily support the former. If this results in an additional protocol optimized for print server to device, so be it. I expect that any printer that is aimed for shared use on the network would want to include the IPP server functionality anyway, so that leaves the discussion about how big a share of remaining printers would really need an additional simpler protocol that is optimized for the device. My 2 cents... Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 12 20:32:03 1998 Delivery-Date: Thu, 12 Feb 1998 20:32:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA01032 for ; Thu, 12 Feb 1998 20:32:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19937 for ; Thu, 12 Feb 1998 20:34:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA28308 for ; Thu, 12 Feb 1998 20:31:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 20:23:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27752 for ipp-outgoing; Thu, 12 Feb 1998 20:23:51 -0500 (EST) Message-Id: <3.0.1.32.19980212172259.01224100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Feb 1998 17:22:59 PST To: Harry Lewis , From: Tom Hastings Subject: Re: IPP> Re: Does the world need a robust host-to-device network prin Cc: , In-Reply-To: <5030300017793492000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I agree completely with Harry here. We need to build on IPP, not start anew. In fact to further the discussion on defining such a "robust host-to-device" network printing protocol (probably NOT across firewalls) and to test whether we can really build on IPP (as Harry and I advocate): People that are raising issues with IPP as the "robust host-to-device network printing protocol when not going across firewalls", please indicate whether the problem is with the current IPP Model document or the current IPP protocol document. For the problems with the Model document, they may be resolvable by extending the Model, by, say, adding more Printer attributes and maybe a Set-Printer-Attributes operation? And, of course, notification. For problems that were with the protocol (mapping) document, the PWG might develop a second IPP protocol document for use in the host to printer connection whose semantics would be the same (extended) IPP Model document. This second IPP protocol mapping document would be a PWG standard, not an IETF standard, since the document deals with the host to printer connection only (and not the Internet). NOTE that some printers would implement both IPP protocol mappings, if they wanted to be used across the Internet and in the host to printer connection. But with the same semantic model, such a dual implementation would not be a big burden. Tom At 16:04 02/10/1998 PST, Harry Lewis wrote: >If we were to address a new, standard, host-to-device printing protocol > >> Now if somebody wants to have a separate debate about writing a really >> robust protocol for interfacing to printers (and I mean the real hardware >> not some logical abstraction) then that will suit me fine. Lets start a new >> track and call it, say, NLS (Not LPD and SNMP). This is what I initially >> wanted to do but could not persuade enough people. > >in my opinion, it should be based on the set of attributes defined for IPP >and the resulting device protocol should be as closely correlated with IPP >as possible such that the mapping is very straight forward and simple. > >Harry Lewis > > From owner-ietf-ppp@merit.edu Thu Feb 12 20:48:36 1998 Delivery-Date: Thu, 12 Feb 1998 20:48:37 -0500 Return-Path: owner-ietf-ppp@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA01163 for ; Thu, 12 Feb 1998 20:48:36 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA20486 for ; Thu, 12 Feb 1998 20:51:17 -0500 (EST) Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA07081; Thu, 12 Feb 1998 20:28:51 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 20:26:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA07054 for ietf-ppp-outgoing; Thu, 12 Feb 1998 20:26:55 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA07050 for ; Thu, 12 Feb 1998 20:26:51 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA26290; Thu, 12 Feb 1998 17:26:49 -0800 Received: from localhost (rcs@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id RAA23567; Thu, 12 Feb 1998 17:27:11 -0800 Date: Thu, 12 Feb 1998 17:27:11 -0800 (PST) From: Rick Sewill X-Sender: rcs@flowpnt To: Richard Shea cc: "Philip A. Prindeville" , vandys@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com Subject: Re: LCP renegotiation In-Reply-To: <34E3896E.319B8B9F@BayNetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Richard, I think we should combine what you have been saying with what Brian Lloyd has been saying. I believe the LAC should be in charge of Link Layer functions, i.e., the LAC should tack on the ff03 on output to the client if HDLC, and remove the ff03 on input from the client if HDLC. Similarly, a LAC supporting PPP over ATM should pass the data between the client and LNS transparently if VC-Multiplexing is used; and should tack on/remove the fefe03cf if LLC-Multiplexing is used. The LAC should tell the LNS in an AVP what the LAC can do (if the LAC offers the LNS more than one choice) or will do (if the LAC offers the LNS only one choice). The LNS will negotiate with the client, and when it comes to link layer items, use the values recommended/required by the LAC. The LNS will tell the LAC in an AVP the link layer items that were agreed to and leave the dealing of link layer items to the LAC. This seems, IMHO, a reasonable way to resolve the questions of MRU size, ACCM, ACF, HDLC v.s. ADSL v.s. the next ppp protocol over whatever media, and resolve a substantial technical concern with L2TP. I will now run for cover in a bomb shelter while the tunneling begins. -Rick On Thu, 12 Feb 1998, Richard Shea wrote: > Philip A. Prindeville wrote: > > > [..] > > > > I think you are being naive. As you go up the ISO reference > > model it gets easier to abstract things away because the lower > > layers are designed to deal with such details. > > > > The news is: *we* are at the lower layer. These are the issues > > that we have to concern ourselves with so that no one else will > > have to. > > > > Well, the TCP-like abstraction is certainly an ideal which we can't > achieve at this level, as you point out. My point was that L2TP could > be defined to attempt to contain the more physical-level characteristics > of the link to the end with the actual physical connection (i.e. the > LAC). > > If we changed L2TP to differentiate HDLC and non-HDLC sessions at the > LNS, then the LNS would be able to satisfy the ACF handling for HDLC > links; And for non-HDLC links the LNS would just not include ACCM or > ACFC options, and not prepend the ACF on any packets it sent out (nor > expect to receive them!). Then, as long as all of the PPP-over-X > protocols can take care of framing at the LAC and simply forward > rfc1661-style PPP frames between the LAC and LNS we are all set. > > I don't yet understand (which may be entirely my fault!) why this > wouldn't be effective. > > If in the future some portion of PPP framing has to be known at the LNS > then we can add in that functionality to the L2TP protocol at that time > (fairly simply). > > Richard. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea rshea@BayNetworks.com > Bay Networks, Extranet Access 978-266-1011 x210 > From ipp-owner@pwg.org Thu Feb 12 23:40:38 1998 Delivery-Date: Thu, 12 Feb 1998 23:40:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA09667 for ; Thu, 12 Feb 1998 23:40:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA23757 for ; Thu, 12 Feb 1998 23:43:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA00681 for ; Thu, 12 Feb 1998 23:40:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Feb 1998 23:30:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA00036 for ipp-outgoing; Thu, 12 Feb 1998 23:30:41 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> host-to-device ... Message-ID: <5030300017907451000002L012*@MHS> Date: Thu, 12 Feb 1998 23:36:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id XAA09667 Someone is apparently addressing requirements with the following set of questions. This is a good approach... >Will it be sufficient if my local network-printer supports ONLY >IPP? >Will IPP provide the same functionality provided by proprietary >solutions? >Why do network printers have to support an ever increasing number >of protocols? And often pay a licensing fee for the protocols? I don't understand this (next) one, however, and how the context of Netware (specifically) applies to IPP requirements. >Will IPP address the issue of print servers and queues (as defined >by Netware)? Many systems define servers and queues. Are you suggesting IPP Should adapt to a Netware paradigm? I would think the other way around. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri Feb 13 03:00:35 1998 Delivery-Date: Fri, 13 Feb 1998 03:00:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA11066 for ; Fri, 13 Feb 1998 03:00:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA02321 for ; Fri, 13 Feb 1998 03:02:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA06549 for ; Fri, 13 Feb 1998 03:00:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 02:49:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA05504 for ipp-outgoing; Fri, 13 Feb 1998 02:49:31 -0500 (EST) Date: Thu, 12 Feb 1998 23:44:57 PST From: "Mitchell,Barbara" Subject: RE: IPP> Notification Requirements To: ipp-owner@pwg.org, ipp@pwg.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Fri, 13 Feb 1998 07:44:36 +0000 Priority: normal Hop-count: 2 Sender: ipp-owner@pwg.org Please take Jorg Thiry and Barbara Mitchell off this dl. Many thanks Barbara ---------- From: ipp-owner@pwg.org To: ipp@pwg.org Subject: RE: IPP> Notification Requirements Date: 12 February 1998 10:27 Randy Turner said: > I thought this was what you meant. I just wanted to make it clear that > client-localization requires defining a strict set of possible messages, > with an associated token or code so that the client knows how to look up > the localized version of this message in a localization dictionary (or > catalog, or whatever). I wonder if absolutely restricting the set of > messages that can be sent from server to client is too constraining? For one existing example along these lines, look at the Adobe Printer Description File specification. Part of the specification for a printer model is a complete list of messages generated by the printer, and the PDF can also provide translations for the messages. So the set of messages can be "relatively" restricted, rather than "absolutely." ;-) :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From ipp-owner@pwg.org Fri Feb 13 06:48:20 1998 Delivery-Date: Fri, 13 Feb 1998 06:48:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA12078 for ; Fri, 13 Feb 1998 06:48:19 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA09490 for ; Fri, 13 Feb 1998 06:50:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA16393 for ; Fri, 13 Feb 1998 06:48:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 06:32:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA15193 for ipp-outgoing; Fri, 13 Feb 1998 06:32:45 -0500 (EST) Message-ID: <34E42E45.24704188@ibm.net> Date: Fri, 13 Feb 1998 06:28:05 -0500 From: Philip Thambidurai Reply-To: pthambi@ibm.net X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org Subject: Re: IPP> host-to-device ... References: <5030300017907451000002L012*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry, That "someone" was me. Sorry if I forgot to sign. RE: Netware, I did not mean to imply that this effort should adapt to the "Netware paradigm". I did imply that Netware is widely used for printing, and that any new effort must address issues addressed by Netware and other proprietary protocols, in order to be accepted. Philip Thambidurai Okidata ------------------------------------------------------------------------------ Harry Lewis wrote: > Someone is apparently addressing requirements with the following set of > questions. This is a good approach... > > >Will it be sufficient if my local network-printer supports ONLY >IPP? > > >Will IPP provide the same functionality provided by proprietary > >solutions? > > >Why do network printers have to support an ever increasing number >of > protocols? And often pay a licensing fee for the protocols? > > I don't understand this (next) one, however, and how the context of Netware > (specifically) applies to IPP requirements. > > >Will IPP address the issue of print servers and queues (as defined > >by Netware)? > > Many systems define servers and queues. Are you suggesting IPP Should adapt to > a Netware paradigm? I would think the other way around. > > Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri Feb 13 06:50:02 1998 Delivery-Date: Fri, 13 Feb 1998 06:50:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA12103 for ; Fri, 13 Feb 1998 06:50:02 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA09494 for ; Fri, 13 Feb 1998 06:52:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA16630 for ; Fri, 13 Feb 1998 06:49:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 06:38:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA15688 for ipp-outgoing; Fri, 13 Feb 1998 06:38:22 -0500 (EST) Message-ID: <34E42F86.2C036E07@ibm.net> Date: Fri, 13 Feb 1998 06:33:26 -0500 From: Philip Thambidurai Reply-To: pthambi@ibm.net X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Tom Hastings Subject: Re: IPP> Re: Does the world need a robust host-to-device network prin References: <3.0.1.32.19980212172259.01224100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Yes, I think building on IPP should be considered and examined thoroughly before other efforts are started. Philip Thambidurai Tom Hastings wrote: > I agree completely with Harry here. We need to build on IPP, not start > anew. > > In fact to further the discussion on defining such a "robust host-to-device" > network printing protocol (probably NOT across firewalls) and to test > whether we can really build on IPP (as Harry and I advocate): > > People that are raising issues with IPP as the "robust host-to-device > network printing protocol when not going across firewalls", > please indicate whether the problem is with the current IPP Model document > or the current IPP protocol document. > > For the problems with the Model document, they may be resolvable by > extending the Model, by, say, adding more Printer attributes and maybe > a Set-Printer-Attributes operation? And, of course, notification. > > For problems that were with the protocol (mapping) document, the PWG might > develop a second IPP protocol document for use in the host to printer > connection whose semantics would be the same (extended) IPP Model document. > This second IPP protocol mapping document would be a PWG standard, not an > IETF standard, since the document deals with the host to printer connection > only (and not the Internet). > > NOTE that some printers would implement both IPP protocol mappings, if they > wanted to be used across the Internet and in the host to printer connection. > But with the same semantic model, such a dual implementation would not be > a big burden. > > Tom > > At 16:04 02/10/1998 PST, Harry Lewis wrote: > >If we were to address a new, standard, host-to-device printing protocol > > > >> Now if somebody wants to have a separate debate about writing a really > >> robust protocol for interfacing to printers (and I mean the real hardware > >> not some logical abstraction) then that will suit me fine. Lets start a new > >> track and call it, say, NLS (Not LPD and SNMP). This is what I initially > >> wanted to do but could not persuade enough people. > > > >in my opinion, it should be based on the set of attributes defined for IPP > >and the resulting device protocol should be as closely correlated with IPP > >as possible such that the mapping is very straight forward and simple. > > > >Harry Lewis > > > > From ipp-owner@pwg.org Fri Feb 13 10:36:15 1998 Delivery-Date: Fri, 13 Feb 1998 10:36:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20732 for ; Fri, 13 Feb 1998 10:36:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10423 for ; Fri, 13 Feb 1998 10:38:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA20804 for ; Fri, 13 Feb 1998 10:36:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 10:24:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19980 for ipp-outgoing; Fri, 13 Feb 1998 10:24:12 -0500 (EST) Content-return: allowed Date: Fri, 13 Feb 1998 07:20:04 PST From: "Zehler, Peter " Subject: IPP> Automated IPP printer installation To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org ALL, One of the requirements for IPP was "All necessary decompressing, unpacking, and other installation actions should occur without end-user interaction or intervention excepting initial approval by the end-user." I hope the time has come to start discussing this feature of IPP. I have created a new directory on the IPP site called "new_INST". In the directory I have placed a write up of this IPP extension. The write up is ID style. The url for it is "ftp://www.pwg.org/pub/pwg/ipp/new_INST/ ipp-printer-install-980213.pdf" Below is the quick "manager" level explanation. This is just a straw-man proposal to open discussions. Comments are welcome and encouraged. Automated printer installation is intended accommodate multiple client platforms, multiple drivers per printer and internationalization. Automated IPP printer installation takes advantage of a printer attribute that is a URL to a driver installer. I have changed the semantics slightly of this optional attribute to be a link to an IPP Installer object. Installer objects contain installer components. Installer components are executable images. They automate the installation of a printer driver, creation of a print queue or spooler, and any the installation or configuration of associated system components specific to a client OS. The installer components are provided by the printer manufacturer for target operating systems. The installer components could also be made available through an embedded web server or corporate homepage. The Installer object can be anywhere. It is a URI which can be preconfigured in printers to point back to a Manufacturer supported IPP Installer object or refer to the printer itself. A Manufacturer supported IPP Installer objects would contain installer components for all their printers. An embedded IPP Installer object would contain only the installer components for that printer. How it works. 1) User obtains IPP Printer URL.(word of mouth, search engine, LDAP, webpage link). 2) IPP protocol is native to client environment(future) or explicitly installed(providing "add printer" functionality where non exists). 3) End user begins client OS specific "add printer" feature entering in the URL of the target printer. 4) Client software sends IPP request to the printer object to retrieve the URL of the installer object and printer identification(supported PDL can also be retrieved). 5) Client software sends query request to Installer object providing printer identification. 6) Installer object returns the supported client OSs, languages, character sets, PDLs and the default PDL for that printer. The installer object also returns the date/time for the installer.(installer components are versioned, not individual subcomponents (i.e.drivers)) 7) Client software selects appropriate client OS, language, and character set(PDL can be specified or defaulted). 8) Client software send a request to retrieve installer component specifying printer identification as well as above information. 9) Installer object responds by downloading installer component. 10) Installer component is temporarily stored.(date/time stamp should be held for later comparison to detect new installer component) 11) Installer component is executed. This installs the printer in the client environment. 12) End user prints from application Note: IPP client environment can take advantage of information provided in #9 to automatically(or explicitly) update client. Note: TLS authentication can be used providing mutual authentication to insure installer component is legitimate. Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Fri Feb 13 10:39:05 1998 Delivery-Date: Fri, 13 Feb 1998 10:39:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA21306 for ; Fri, 13 Feb 1998 10:39:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10443 for ; Fri, 13 Feb 1998 10:41:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA21174 for ; Fri, 13 Feb 1998 10:39:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 10:28:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20238 for ipp-outgoing; Fri, 13 Feb 1998 10:28:37 -0500 (EST) Content-return: allowed Date: Fri, 13 Feb 1998 07:24:15 PST From: "Zehler, Peter " Subject: IPP> TES First draft of IPP Test Plan Outline To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org All, I need some feedback to continue working the IPP test plan. In Maui I said I would get the first draft out this week, so here it is. Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Fri Feb 13 11:50:32 1998 Delivery-Date: Fri, 13 Feb 1998 11:50:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA23966 for ; Fri, 13 Feb 1998 11:50:27 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10922 for ; Fri, 13 Feb 1998 11:53:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA22551 for ; Fri, 13 Feb 1998 11:50:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 11:38:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21937 for ipp-outgoing; Fri, 13 Feb 1998 11:38:37 -0500 (EST) Date: Fri, 13 Feb 1998 08:31:31 -0800 (Pacific Standard Time) From: Ron Bergman To: papowell@astart.com cc: ipp@pwg.org Subject: Re: IPP> MOD> A New View of Notification Requirements In-Reply-To: <199802130417.UAA10541@astart4.astart.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Patrict, I have tried to respond to some of your comments below. My intent in the original posting was to get people to stop thinking that all notifications need to pass through a firewall. I believe that some of these ideas have found their way into the recent document by Roger Debry. Roger's paper does provide significantly more detail on this subject. You certainly did point out some interesting area for further discussion, so I am copying the DL with this message. Ron Bergman Dataproducts Corp. On Thu, 12 Feb 1998 papowell@astart.com wrote: > Ron, I like your ideas, and have just a few > keyboard in cheek comments. These are not meant too seriously, > but do open some points for discussion. > > > From ipp-owner@pwg.org Mon Feb 9 09:26:56 1998 > > Date: Mon, 9 Feb 1998 08:39:39 -0800 (Pacific Standard Time) > > From: Ron Bergman > > To: ipp@pwg.org > > Subject: IPP> MOD> A New View of Notification Requirements > > > > A major point missing from the previously posted notification > > requirements concerns the location or intent of the user. I believe > > this to be the most important factor to be considered, and should > > minimize much of the discussion concerning firewalls. This analysis > > assumes, as in the previously posted requirements, that submission > > problems such as transmission errors and acceptance of the job are > > handled by the job submission protocol. > > > > REMOTE USER: > > > > - The remote user is always the submitter of the job. > > - A firewall may or may not exist between the remote user and the > > printer. > > - The document will not be directly retrieved by the remote user. > > Huh? Do you mean 'physically picked up'? I am missing something... Yes. One example is scenario #4 from Roger Debry's "Requirements Statement for IPP Notification". Here the user submits a job from a hotel room to be printed at a local Kinko's. He will retrieve the document at some point in time after it is printed, but the document is removed from the printer by a Kinko's employee and delivered to the user when he arrives at the store. > > > - The remote user does not require any notifications other than an > > indication that the job has completed. The remote user may desire > > Or not completed. Or completed with errors. Or is still printing > after so many minutes. > > This is a 'well, we need this option' type of problem that has led to > the current throwing up of hands and washing them of the problem. > (Neat trick that, washing your hands after throwing them up... > but I digress.) Completed with errors or not able to complete certainly should be part of the notification to a remote user only for conditions that he can resolve. For printer problems, not related to the data stream, this could be optional since he cannot fix any problems if is not physically close to the printer. > > > additional notifications, but since he is remote from the printer, > > he will be unable to perform any required actions. For simplicity, > > Say again? I am lost. I have two firewalls here, internally. > The printer (on the other side of the firewall for most folks here) > is right beside my office. And there is an EXTERNAL firewall on > our connection to the Big Bad Internet. This is a situation I did not anticipate. Does the internal firewall have the same protection characteristics as the external? I would guess that the internal firewall could be configured so that notification messages would pass through to known users. In this case, the user would be local. > > Also, some system administration types want to have their staff in > sites that are outside an internal firewall. Or inside an internal one. > > > I propose that we restrict notification to a remote user to job > > completion. > > Or that the printer is not working. And send some to the adminstrators > as well. Oh. Perhaps MULTIPLE administration sites if the first is down. > Sigh... The mind boggles at the wonderful possibilities... :-) In some cases other notifications may be required. A printer not working may be a good example if the job cannot be printed on another printer by local administration. > > > - The submitter does not require immediate notification of job > > completion. Again he may desire immediate notification but, since > > he is not the person that will retrieve the job, this should not be > > a high priority. > > Huh? Say what? I think you are confusing firewall, physical proximity, > and logical responsibility. I hope not! > > > > > LOCAL USER: > > > > - The local user will never encounter a firewall in the path to the > > printer. > > Nonsense. In fact, we have a firewall pointing INTO the engineering > group due to their habits of screwing up the network... :-). They would > get frosted if they could not print to the printer outside their local > network. See above. Your situation should be different than a user completely outside of the system. Or am I missing something? > > > - The local user may or may not be the submitter of the document to be > > printed. He is always the recipient of the document. > > Say what? I just picked up a report from the guys in engineering... and printed > one for him. :-( sigh... Helpful coworkers are beyond the scope of the analysis ;-) > > > - The local user should have the option of receiving all possible > > notifications regarding the progress of the job and any problems or > > errors encountered. Maintenance or support personnel may also > > receive problem and error notifications in addition to or instead > > of the local user. > > Ahh... but where are the maintenance and support personnel? On which > side of the firewall? Inside of an extenal firewall. There could be a situation where the maintenace personnel are outside of the firewall. In this situation, the firewall must be configured so that they can receive immediate notification. There will always be exceptions, but they will be known and can be defined in the configuration. The exceptions must not be dynamic. > > > - The local user requires prompt notification of job completion and > > possibly problems and error conditions. > > > > Since only the remote user must deal with a firewall and he does not > > require any notification other than job completion, the protocol > > requirements are greatly simplified. For the remote user, email > > notifications should be a perfect match. I have not seen any other > > methods proposed that everyone agrees are firewall *safe*. > > Make sure your spam filters are tuned up lads, I can see a new wave > of spam coming: > > mail from: printer@kinko.darkside.com > your job: &*()&*()(*&*()&&*() has just been completed. > > Perhaps we need to add some 'user authentication' to this as well? > Sigh. And what about folks whose email and network address are different? > > > > > Notification for the local user are open to any reasonable protocol, no > > firewall is ever encountered in this case. The is the area that will > > require the most effort to resolve the notification issue. > > I agree. This is because everbody who has tried to do a good job has > discovered that it is a HORRIBLE complex problem. > > So rather than do a poor job and get the blame, they rapidly retreat, > throwing up hands, etc etc > > > > > The model document should include the following attributes to support > > these requirements. > > > > 1. remote-notification-uri (Job Template Attribute) No job > > completion notification is returned to the remote user if this > > attribute is not included in the job submission request. > > 2. local-notification-uri (Job Template Attribute) No job > > notifications are returned to the local user if this attribute is > > not included in the job submission request. > > 3. Local-notification-types-requested (Job Template Attribute) An > > enum or bit map which defines the types of notifications > > requested. Includes job completion, job progress, job errors, > > printer errors, printer warnings, etc. > > 4. local-notification-types-default (Printer Description Attribute) > > 5. printer-service-notification-uri (Printer Description Attribute) > > All printer problems are reported to this URI. > > > > This is not intended to be a complete notification solution for IPP. My > > only intent is to minimize the discussion regarding firewalls. (This > > discussion (firewalls) appears to be making very little progress.) There > > is still a significant amount of work remaining to complete the IPP > > notification effort. > > > > Comments invited! > > > > > > Ron Bergman > > Dataproducts Corp. > > Thanks Ron. I am glad that SOMEBODY is still thinking about this. > > Patrick Powell > > From ipp-owner@pwg.org Fri Feb 13 12:54:13 1998 Delivery-Date: Fri, 13 Feb 1998 12:54:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA25660 for ; Fri, 13 Feb 1998 12:54:02 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11287 for ; Fri, 13 Feb 1998 12:56:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24415 for ; Fri, 13 Feb 1998 12:54:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 12:41:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23553 for ipp-outgoing; Fri, 13 Feb 1998 12:41:29 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC289@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Tom Hastings'" , Harry Lewis , jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> Re: Does the world need a robust host-to-device network prin Date: Fri, 13 Feb 1998 09:41:15 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Building a second protocol based on the model is the worst of both worlds:- - It is a separate completely non-interoperable protocol (being based on the same model means nothing in wire terms), would a printer do both? - It constrains the second protocol to only doing things that IPP can do. > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Thursday, February 12, 1998 5:23 PM > To: Harry Lewis; jkm@underscore.com > Cc: ipp@pwg.org; Paul Moore > Subject: Re: IPP> Re: Does the world need a robust host-to-device > network prin > > I agree completely with Harry here. We need to build on IPP, not start > anew. > > In fact to further the discussion on defining such a "robust > host-to-device" > network printing protocol (probably NOT across firewalls) and to test > whether we can really build on IPP (as Harry and I advocate): > > People that are raising issues with IPP as the "robust host-to-device > network printing protocol when not going across firewalls", > please indicate whether the problem is with the current IPP Model > document > or the current IPP protocol document. > > For the problems with the Model document, they may be resolvable by > extending the Model, by, say, adding more Printer attributes and maybe > a Set-Printer-Attributes operation? And, of course, notification. > > For problems that were with the protocol (mapping) document, the PWG might > > develop a second IPP protocol document for use in the host to printer > connection whose semantics would be the same (extended) IPP Model > document. > This second IPP protocol mapping document would be a PWG standard, not an > IETF standard, since the document deals with the host to printer > connection > only (and not the Internet). > > NOTE that some printers would implement both IPP protocol mappings, if > they > wanted to be used across the Internet and in the host to printer > connection. > But with the same semantic model, such a dual implementation would not be > a big burden. > > Tom > > > > At 16:04 02/10/1998 PST, Harry Lewis wrote: > >If we were to address a new, standard, host-to-device printing protocol > > > >> Now if somebody wants to have a separate debate about writing a really > >> robust protocol for interfacing to printers (and I mean the real > hardware > >> not some logical abstraction) then that will suit me fine. Lets start a > new > >> track and call it, say, NLS (Not LPD and SNMP). This is what I > initially > >> wanted to do but could not persuade enough people. > > > >in my opinion, it should be based on the set of attributes defined for > IPP > >and the resulting device protocol should be as closely correlated with > IPP > >as possible such that the mapping is very straight forward and simple. > > > >Harry Lewis > > > > From ipp-owner@pwg.org Fri Feb 13 13:01:01 1998 Delivery-Date: Fri, 13 Feb 1998 13:01:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA25857 for ; Fri, 13 Feb 1998 13:01:01 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11310 for ; Fri, 13 Feb 1998 13:03:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25089 for ; Fri, 13 Feb 1998 13:01:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 12:49:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23878 for ipp-outgoing; Fri, 13 Feb 1998 12:49:55 -0500 (EST) Date: Fri, 13 Feb 1998 12:49:13 -0500 (EST) From: Gail Zacharias To: ipp@pwg.org Subject: IPP> Clients and interoperability testing Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org I have tried playing with the IBM IPP client, but have run into some problems: . The client doesn't send the required 'request-id' field of the IPP header. . The client sends integers (e.g. 'copies' attribute value) as 1 byte, rather than 4. . The client doesn't send the 'printer-uri' required operation attribute. . The client doesn't accept the '100 Continue' HTTP response, which my Web server (Microsoft Personal Web Server, running an IPP server as a CGI script) seems to insist on sending. The last one is kinda a killer, since as far as I know there isn't anything I can do to change what the Web server is sending. I'm told that IBM is not really interested in updating their client at this point. Which brings me to the question, has anybody else out there written a test client that they're willing to do some interoperability testing with my server? Thanks, Gail --- gz@harlequin.com From ipp-owner@pwg.org Fri Feb 13 13:05:24 1998 Delivery-Date: Fri, 13 Feb 1998 13:05:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA26072 for ; Fri, 13 Feb 1998 13:05:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA11326 for ; Fri, 13 Feb 1998 13:08:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25497 for ; Fri, 13 Feb 1998 13:05:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 12:54:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24468 for ipp-outgoing; Fri, 13 Feb 1998 12:54:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" , "'Tom Hastings'" , Harry Lewis , jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> Re: Does the world need a robust host-to-device network prin Date: Fri, 13 Feb 1998 09:54:50 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I disagree. If you have a client-to-server mapping protocol and then a server-to-printer protocol, the gateway functions and semantics of the job that the original user submitted would encounter no loss of information and the gateway logic would be very straightforward. And besides, I think there's going to be a very (repeat very) fine line between the two anyway; the main difference probably being NOT using HTTP as a transport. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Friday, February 13, 1998 9:41 AM To: 'Tom Hastings'; Harry Lewis; jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> Re: Does the world need a robust host-to-device network prin Building a second protocol based on the model is the worst of both worlds:- - It is a separate completely non-interoperable protocol (being based on the same model means nothing in wire terms), would a printer do both? - It constrains the second protocol to only doing things that IPP can do. > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Thursday, February 12, 1998 5:23 PM > To: Harry Lewis; jkm@underscore.com > Cc: ipp@pwg.org; Paul Moore > Subject: Re: IPP> Re: Does the world need a robust host-to-device > network prin > > I agree completely with Harry here. We need to build on IPP, not start > anew. > > In fact to further the discussion on defining such a "robust > host-to-device" > network printing protocol (probably NOT across firewalls) and to test > whether we can really build on IPP (as Harry and I advocate): > > People that are raising issues with IPP as the "robust host-to-device > network printing protocol when not going across firewalls", > please indicate whether the problem is with the current IPP Model > document > or the current IPP protocol document. > > For the problems with the Model document, they may be resolvable by > extending the Model, by, say, adding more Printer attributes and maybe > a Set-Printer-Attributes operation? And, of course, notification. > > For problems that were with the protocol (mapping) document, the PWG might > > develop a second IPP protocol document for use in the host to printer > connection whose semantics would be the same (extended) IPP Model > document. > This second IPP protocol mapping document would be a PWG standard, not an > IETF standard, since the document deals with the host to printer > connection > only (and not the Internet). > > NOTE that some printers would implement both IPP protocol mappings, if > they > wanted to be used across the Internet and in the host to printer > connection. > But with the same semantic model, such a dual implementation would not be > a big burden. > > Tom > > > > At 16:04 02/10/1998 PST, Harry Lewis wrote: > >If we were to address a new, standard, host-to-device printing protocol > > > >> Now if somebody wants to have a separate debate about writing a really > >> robust protocol for interfacing to printers (and I mean the real > hardware > >> not some logical abstraction) then that will suit me fine. Lets start a > new > >> track and call it, say, NLS (Not LPD and SNMP). This is what I > initially > >> wanted to do but could not persuade enough people. > > > >in my opinion, it should be based on the set of attributes defined for > IPP > >and the resulting device protocol should be as closely correlated with > IPP > >as possible such that the mapping is very straight forward and simple. > > > >Harry Lewis > > > > From ipp-owner@pwg.org Fri Feb 13 14:56:06 1998 Delivery-Date: Fri, 13 Feb 1998 14:56:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA29857 for ; Fri, 13 Feb 1998 14:56:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11896 for ; Fri, 13 Feb 1998 14:58:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27491 for ; Fri, 13 Feb 1998 14:56:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 14:45:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA26833 for ipp-outgoing; Fri, 13 Feb 1998 14:44:58 -0500 (EST) Message-ID: <34E4A2AF.43A95DFC@underscore.com> Date: Fri, 13 Feb 1998 14:44:47 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> What ever happened to IEEE 1284.1 (aka TIPSI, aka NPAP)? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org [This is a resend of a message that got lost in distribution during the recent PWG server problems. The original message, however, did get stored in the IPP hypermail archives. This message, however, is slightly different from the hypermail version.] In the thread on "host-to-device" protocol, Jim Walker wrote: > One final point about this ubiquity. It does not do us any good to > design something that nobody builds. I do not know much about the > history of TIPSI, but it seems a valid case in point. Although it > is not necessarily a "pretty" protocol, it at least seems to address > these issues of a host->device protocol (in a transport-independent > fashion, to boot!). But nobody built it (sorry, Don), so who cares? I'd like to put this question on the table: What happened to IEEE 1284.1 (TIPSI) such that it was never implemented by a large number of printer vendors? A great number of companies (many of them *major* players) signed up and produced a very, very useful protocol. As Jim points out, TIPSI is a bit ugly in places, but it sure does do a decent job for a host-to-device network printing protocol. Here are the top 4 reasons (excuses?) I hear from vendors as to why they didn't adopt TIPSI: 1. Microsoft and HP pulled out of the effort quite late in the game, citing that "SNMP is the proper method for printer management"; therefore, if neither Microsoft nor HP adopt it, then I won't either. 2. Lexmark had an implementation completed as soon as the spec was completed, thereby getting a jump on the rest of the industry; as a result, we'd be starting off way behind them. 3. It's really only a proprietary protocol from Lexmark. 4. Without a freely available reference implementation, we really can't get rolling on adoption. Regarding Excuse #1, while it may be viewed that "SNMP is the One and Only True Way" to manage network devices such as network printers, the fact is that TIPSI was designed primarily for PRINTING and not MANAGEMENT. So, when Microsoft and HP walked away from TIPSI (then called "NPAP"), the two giants also walked away from the world's first honest attempt at an open protocol for network printing. Truly a shame. Perhaps we can cajole them into reconsidering... Regarding Excuse #2, Lexmark played the "game" the way it was supposed to be played, namely, work together with your competitors and partners for the common good, and implement your solution as quickly as you can for delivery to the marketplace. There was never any kind of "backroom discussions" that allowed Lexmark to get a lead on anyone else (trust me, I was watching! ;-). Lexmark just did their job. And they did it well. Moreover, once they found other players were not implementing the joint spec as quickly, they came in and put almost all of their own proprietary extensions on the table for inclusion into the formal spec. How many vendors do you see doing this, all in the name of getting a solid, robust specification adopted and deployed?? As for Excuse #3, well that's just par for the course. Since Lexmark was the only one to implement TIPSI, the rest of the world just labelled it as "proprietary", thinking that Lexmark just got the IEEE to rubber-stamp an already existing protocol developed by Lexmark internally. (I have personally heard this kind of comment over and over again at almost every customer site.) Now comes Excuse #4... Do folks really believe this is true? (I have heard this from multiple PWG participants, and they know it!) If a freely available reference implementation of TIPSI were to become available, would you adopt it? I'd really like to know, as my company would be interested in developing it. Funny, but I don't hear the same kind of "gotta have a free implementation" by those espousing IPP... What's different? (Just curious.) Incidentally, if anyone is interested in reviewing the TIPSI spec, please contact me. Since TIPSI is under IEEE control now, the normal mechanism is to contact the IEEE and request (and *pay* for) the IEEE 1284.1 specification. If you *are* interested in seeing the spec, please let me know and we can make some arrangements. If nothing else, TIPSI can serve as an *excellent* starting point for a network printing protocol, at least in terms of requirements. Also, for the record, here are pointers to the latest CPAP spec in various forms: ftp://ftp.pwg.org/pub/pwg/cpap/cpap.pdf ftp://ftp.pwg.org/pub/pwg/cpap/cpap.ps ftp://ftp.pwg.org/pub/pwg/cpap/cpap.ps.gz Both of these protocols have been "in the field" for several years now, so the lessons learned (and problems solved) by either/both of these protocols should not be dismissed during any discussions we might conduct for a "host-to-device" protocol. ...jay PS: In case anyone was wondering, Underscore is *not* a subsidiary of Lexmark International. In fact, in many respects, we are fierce competitors. We've just learned to cooperate, that's all. Credit always belongs to those who deserve it, in any case. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 15:12:33 1998 Delivery-Date: Fri, 13 Feb 1998 15:12:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA00220 for ; Fri, 13 Feb 1998 15:12:32 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11994 for ; Fri, 13 Feb 1998 15:15:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA28422 for ; Fri, 13 Feb 1998 15:12:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:01:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27634 for ipp-outgoing; Fri, 13 Feb 1998 15:01:07 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEEC@EXCHANGE> From: "Wagner, William" To: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Fri, 13 Feb 1998 14:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org I appreciate Carl-Uno's statement. (I also happen to agree) . Much of the traffic on the list of late has been negative to the extent that many observers who have not actively participated get the impression that IPP is beyond recovery. I know that people are more inclined to voice objections than support, but I think that some more supporting comments (rather than just defensive responses) might put the actual situation in better perspective. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, February 12, 1998 7:04 PM > To: ipp@pwg.org > Subject: RE: IPP> Does the world need a robust host-to-device > network printing protocol? > > > I want to remind you all that we stated as our intent when we started > work on IPP V1.0, that we were trying to solve 80% of the problem in > the first version, which means that we conciously left out a number of > things to be resolved later. > > We also stated that we were trying to concentrate on solving the user > to what-ever problem in our first version, leaving some of the device > and management type problems for a future version. > > Also remember, that some of the intial reactions in the IETF was that > we were trying to do far too MUCH in IPP V1.0, while now we seem to be > hearing that there is too much missing. > You cannot have your cake and eat it..... > > I do not buy the argument that HTTP is bad, even if you choose to > use IPP to acces your print device. I think there is enough evidence > from prototyping at that stage to show that it works pretty well. > Some printer vendors started putting in HTTP in their printers to > do configuration and management even before we started talking about > using it for IPP. > > I would hope that the current IPP approach can be used as a common > basis for developing both client to print server and print server to > device communication, even though I agree that IPP V1.0 was developed > to primarily support the former. If this results in an additional > protocol optimized for print server to device, so be it. I expect that > > any printer that is aimed for shared use on the network would want to > include the IPP server functionality anyway, so that leaves the > discussion about how big a share of remaining printers would really > need an additional simpler protocol that is optimized for the device. > > My 2 cents... > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 13 15:22:39 1998 Delivery-Date: Fri, 13 Feb 1998 15:22:39 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA00571 for ; Fri, 13 Feb 1998 15:22:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA12065 for ; Fri, 13 Feb 1998 15:25:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29038 for ; Fri, 13 Feb 1998 15:22:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:10:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28146 for ipp-outgoing; Fri, 13 Feb 1998 15:10:31 -0500 (EST) From: Harry Lewis To: Subject: RE: IPP> Re: Does the world need a robust host-to-device net Message-ID: <5030300017939786000002L062*@MHS> Date: Fri, 13 Feb 1998 15:16:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA00571 I agree with Randy but the diametric views being expressed have me concerned. On the concern that a printer will have to decide whether or not to do both - won't this be the case with any resolution other than just sticking with IPPv1 all around? On the concern that the Host-Printer protocol will be constrained to the features of IPP - what set of features does the printer protocol need that IPP does not need? Tom's idea was, if the IPP model is lacking, we need to identify the requirements and extend it. Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 02/13/98 11:37:59 AM Please respond to ipp-owner@pwg.org @ internet To: jkm@underscore.com @ internet, Harry Lewis/Boulder/IBM@ibmus, hastings@cp10.es.xerox.com @ internet, paulmo@microsoft.com @ internet cc: ipp@pwg.org @ internet Subject: RE: IPP> Re: Does the world need a robust host-to-device net I disagree. If you have a client-to-server mapping protocol and then a server-to-printer protocol, the gateway functions and semantics of the job that the original user submitted would encounter no loss of information and the gateway logic would be very straightforward. And besides, I think there's going to be a very (repeat very) fine line between the two anyway; the main difference probably being NOT using HTTP as a transport. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Friday, February 13, 1998 9:41 AM To: 'Tom Hastings'; Harry Lewis; jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> Re: Does the world need a robust host-to-device network prin Building a second protocol based on the model is the worst of both worlds:- - It is a separate completely non-interoperable protocol (being based on the same model means nothing in wire terms), would a printer do both? - It constrains the second protocol to only doing things that IPP can do. > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Thursday, February 12, 1998 5:23 PM > To: Harry Lewis; jkm@underscore.com > Cc: ipp@pwg.org; Paul Moore > Subject: Re: IPP> Re: Does the world need a robust host-to-device > network prin > > I agree completely with Harry here. We need to build on IPP, not start > anew. > > In fact to further the discussion on defining such a "robust > host-to-device" > network printing protocol (probably NOT across firewalls) and to test > whether we can really build on IPP (as Harry and I advocate): > > People that are raising issues with IPP as the "robust host-to-device > network printing protocol when not going across firewalls", > please indicate whether the problem is with the current IPP Model > document > or the current IPP protocol document. > > For the problems with the Model document, they may be resolvable by > extending the Model, by, say, adding more Printer attributes and maybe > a Set-Printer-Attributes operation? And, of course, notification. > > For problems that were with the protocol (mapping) document, the PWG might > > develop a second IPP protocol document for use in the host to printer > connection whose semantics would be the same (extended) IPP Model > document. > This second IPP protocol mapping document would be a PWG standard, not an > IETF standard, since the document deals with the host to printer > connection > only (and not the Internet). > > NOTE that some printers would implement both IPP protocol mappings, if > they > wanted to be used across the Internet and in the host to printer > connection. > But with the same semantic model, such a dual implementation would not be > a big burden. > > Tom > > > > At 16:04 02/10/1998 PST, Harry Lewis wrote: > >If we were to address a new, standard, host-to-device printing protocol > > > >> Now if somebody wants to have a separate debate about writing a really > >> robust protocol for interfacing to printers (and I mean the real > hardware > >> not some logical abstraction) then that will suit me fine. Lets start a > new > >> track and call it, say, NLS (Not LPD and SNMP). This is what I > initially > >> wanted to do but could not persuade enough people. > > > >in my opinion, it should be based on the set of attributes defined for > IPP > >and the resulting device protocol should be as closely correlated with > IPP > >as possible such that the mapping is very straight forward and simple. > > > >Harry Lewis > > > > From ipp-owner@pwg.org Fri Feb 13 15:49:18 1998 Delivery-Date: Fri, 13 Feb 1998 15:49:19 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01162 for ; Fri, 13 Feb 1998 15:49:18 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA12221 for ; Fri, 13 Feb 1998 15:51:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00876 for ; Fri, 13 Feb 1998 15:49:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:32:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29280 for ipp-outgoing; Fri, 13 Feb 1998 15:32:02 -0500 (EST) Message-ID: <34E4ADB2.F78ECE0F@underscore.com> Date: Fri, 13 Feb 1998 15:31:46 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Robert McComiskie CC: ipp@pwg.org, walker@dazel.com Subject: Re: IPP> Does the world need a robust host-to-device netw References: <4E3870C0.@xionics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob, > Seems to me that applications care more about the printer driver API > in the host OS rather than the protocol. The printer vendor will > create the driver, the app writer just prints to the API. Actually, most PWG members would rather say "the *platform* vendor will create the driver". Hence, the critical importance of getting such players as Microsoft on board (and *happy* ;-). When it comes to applications that need to "print", you're right, app writer's just print to the (platform-specific) print API. I don't believe that's at issue here at all. What *is* at issue is the "host-to-device" (aka "server-to-printer") protocol. And that's where platform-specific driver developers have specific concerns with regard to the viability of IPP as a suitable protocol. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jmp-owner@pwg.org Fri Feb 13 15:52:30 1998 Delivery-Date: Fri, 13 Feb 1998 15:52:30 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01321 for ; Fri, 13 Feb 1998 15:52:30 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA12248 for ; Fri, 13 Feb 1998 15:55:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01288 for ; Fri, 13 Feb 1998 15:52:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:45:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29646 for jmp-outgoing; Fri, 13 Feb 1998 15:39:50 -0500 (EST) From: Keith Carter To: Cc: , , , , Subject: JMP> Re: Hotel reservations for the Hyatt Message-ID: <5040300012564897000002L072*@MHS> Date: Fri, 13 Feb 1998 15:37:57 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Mabry wrote today (2/13): >Keith, > >How do you like your new job as travel agent? ;) > >Our travel dept tried to book me a room we have been told that the rate was "no >longer available", and mentioned something about all the rooms at that rate have >been "used up". This was tried yesterday. I just got off the phone myself, and >was told the same.... > >Any ideas what they are talking about? > >The rate I am being quoted is $165.00/night. Mabry, This job as travel agent is looking less appealing by the minute. I called the meeting coordinator at the Hyatt hotel who assured me they will fix this problem immediately. There are rooms available at the IBM rate. Please try again to make your reservation. Everyone, Anyone else who has encountered this problem, please try again to make your reservation. Sincerely, your travel agent, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Feb 13 16:00:41 1998 Delivery-Date: Fri, 13 Feb 1998 16:00:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01667 for ; Fri, 13 Feb 1998 16:00:41 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12328 for ; Fri, 13 Feb 1998 16:03:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02249 for ; Fri, 13 Feb 1998 16:00:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:40:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29660 for ipp-outgoing; Fri, 13 Feb 1998 15:40:00 -0500 (EST) From: Keith Carter To: Cc: , , , , Subject: IPP> Re: Hotel reservations for the Hyatt Message-ID: <5040300012564897000002L072*@MHS> Date: Fri, 13 Feb 1998 15:37:57 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Mabry wrote today (2/13): >Keith, > >How do you like your new job as travel agent? ;) > >Our travel dept tried to book me a room we have been told that the rate was "no >longer available", and mentioned something about all the rooms at that rate have >been "used up". This was tried yesterday. I just got off the phone myself, and >was told the same.... > >Any ideas what they are talking about? > >The rate I am being quoted is $165.00/night. Mabry, This job as travel agent is looking less appealing by the minute. I called the meeting coordinator at the Hyatt hotel who assured me they will fix this problem immediately. There are rooms available at the IBM rate. Please try again to make your reservation. Everyone, Anyone else who has encountered this problem, please try again to make your reservation. Sincerely, your travel agent, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Feb 13 16:03:24 1998 Delivery-Date: Fri, 13 Feb 1998 16:03:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01797 for ; Fri, 13 Feb 1998 16:03:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12347 for ; Fri, 13 Feb 1998 16:06:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02596 for ; Fri, 13 Feb 1998 16:03:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:44:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00104 for ipp-outgoing; Fri, 13 Feb 1998 15:43:49 -0500 (EST) Message-ID: <34E4B05A.6A5AA7F4@underscore.com> Date: Fri, 13 Feb 1998 15:43:06 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Wagner, William" CC: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network prin ting protocol? References: <6FCC2B3BA67BD111A47D0060089D281508AEDC@EXCHANGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bill, > Jay seems to be just unhappy > with IPP, suggesting perhaps that it is not good for anything (because > to many compromises were made?) Aw now, c'mon. I have pointed out several specific concerns I have with IPP--in the role of a host-to-device protocol--on this DL. Perhaps you've missed them? I think a lot off pro-IPP folks are perhaps missing the point, at least with regard to my concerns, and probably Paul Moore's concerns. Paul has repeatedly pointed out the problem of asymmetry of IPP-over-HTTP in the context of host-to-device support. This is a big concern for me, also (both of us being "driver" developers that need a good "host-to-device" protocol). The lack of symmetry in the protocol makes life unnecessarily difficult to develop robust, highly functional drivers. For example, during the job submission transaction with the printer, the driver needs to be able to asynchronously receive events from the printer that may cause a change in the transaction, or at least cause the driver to "pass along" information to the originator in a timely and reasonable simple manner (eg, "Paper out", "PDL error", etc.) IPP as currently defined (over HTTP) does not provide this kind of protocol interaction...at least not very easily. Or more specifically, not as easy as it should be when compared to similar protocols in the Internet. Hopefully Paul Moore will comment a bit about this, but at least this describes one of my concerns about IPP. Please don't say "Jay doesn't think IPP is good for anything". ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From pwg-owner@pwg.org Fri Feb 13 16:05:07 1998 Delivery-Date: Fri, 13 Feb 1998 16:05:07 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01885 for ; Fri, 13 Feb 1998 16:05:06 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12361 for ; Fri, 13 Feb 1998 16:07:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02793 for ; Fri, 13 Feb 1998 16:05:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:54:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29622 for pwg-outgoing; Fri, 13 Feb 1998 15:39:40 -0500 (EST) From: Keith Carter To: Cc: , , , , Subject: PWG> Re: Hotel reservations for the Hyatt Message-ID: <5040300012564897000002L072*@MHS> Date: Fri, 13 Feb 1998 15:37:57 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Mabry wrote today (2/13): >Keith, > >How do you like your new job as travel agent? ;) > >Our travel dept tried to book me a room we have been told that the rate was "no >longer available", and mentioned something about all the rooms at that rate have >been "used up". This was tried yesterday. I just got off the phone myself, and >was told the same.... > >Any ideas what they are talking about? > >The rate I am being quoted is $165.00/night. Mabry, This job as travel agent is looking less appealing by the minute. I called the meeting coordinator at the Hyatt hotel who assured me they will fix this problem immediately. There are rooms available at the IBM rate. Please try again to make your reservation. Everyone, Anyone else who has encountered this problem, please try again to make your reservation. Sincerely, your travel agent, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Feb 13 16:09:44 1998 Delivery-Date: Fri, 13 Feb 1998 16:09:45 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01999 for ; Fri, 13 Feb 1998 16:09:44 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12392 for ; Fri, 13 Feb 1998 16:12:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03446 for ; Fri, 13 Feb 1998 16:09:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 15:55:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01467 for ipp-outgoing; Fri, 13 Feb 1998 15:55:02 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEEE@EXCHANGE> From: "Wagner, William" To: "'Jay Martin'" Cc: ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Fri, 13 Feb 1998 15:53:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Jay, Thanks for the clarification. And I haven't missed your expressed concerns, which is where I sensed somewhat negative vibes v-v IPP. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, February 13, 1998 3:43 PM > To: Wagner, William > Cc: ipp@pwg.org > Subject: Re: IPP> Does the world need a robust host-to-device > network prin ting protocol? > > Bill, > > > Jay seems to be just unhappy > > with IPP, suggesting perhaps that it is not good for anything > (because > > to many compromises were made?) > > Aw now, c'mon. I have pointed out several specific concerns I > have with IPP--in the role of a host-to-device protocol--on this > DL. Perhaps you've missed them? > > I think a lot off pro-IPP folks are perhaps missing the point, > at least with regard to my concerns, and probably Paul Moore's > concerns. > > Paul has repeatedly pointed out the problem of asymmetry of > IPP-over-HTTP in the context of host-to-device support. This > is a big concern for me, also (both of us being "driver" > developers that need a good "host-to-device" protocol). > > The lack of symmetry in the protocol makes life unnecessarily > difficult to develop robust, highly functional drivers. For > example, during the job submission transaction with the printer, > the driver needs to be able to asynchronously receive events > from the printer that may cause a change in the transaction, > or at least cause the driver to "pass along" information to > the originator in a timely and reasonable simple manner (eg, > "Paper out", "PDL error", etc.) > > IPP as currently defined (over HTTP) does not provide this > kind of protocol interaction...at least not very easily. > Or more specifically, not as easy as it should be when > compared to similar protocols in the Internet. > > Hopefully Paul Moore will comment a bit about this, > but at least this describes one of my concerns about IPP. > Please don't say "Jay doesn't think IPP is good for anything". > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 16:16:27 1998 Delivery-Date: Fri, 13 Feb 1998 16:16:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA02289 for ; Fri, 13 Feb 1998 16:16:27 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12416 for ; Fri, 13 Feb 1998 16:19:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04153 for ; Fri, 13 Feb 1998 16:16:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 16:04:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02706 for ipp-outgoing; Fri, 13 Feb 1998 16:04:22 -0500 (EST) Message-ID: <34E4B538.1C0E1A2C@underscore.com> Date: Fri, 13 Feb 1998 16:03:52 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Wagner, William" CC: ipp@pwg.org Subject: IPP> Will vendors implement additional protocols beyond IPP? References: <6FCC2B3BA67BD111A47D0060089D281508AEDD@EXCHANGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bill, You wrote on the "host-to-device thread": > As to supporting multiple protocols, take a look at what we have today. > > [...] > > Hey, whats wrong with adding a couple more? You didn't tack on a "smiley face" on the end of that last sentence, so I don't know if you were joking or being serious. Either way, your comments point out yet another concern that Paul Moore and I share regarding concerns about IPP. And in many respects, this may be the *biggest* overall concern we have. That concern has to do with the fact that many printer vendors appear to be leaning toward the decision that "IPP is the *last* printing protocol we will implement in our printers". I say printer vendors "appear" to be saying that because explicit statements to that effect have not been posted on the IPP DL. Instead, they have been made to individuals on a private (yet not *confidential*) basis. And this is where I have BIG problems with moving forward with IPP as some folks would prefer. And I know Paul Moore shares this view (and has stated this *repeatedly* on the DL). The strong proponents for IPP have stated their intentions to move IPP to the "next level"...over HTTP. And this is specifically another problem some of us have with IPP today. If printer vendors want to implement IPP to satisfy the 0.01% of customer demand for "Internet Printing" (aka, Kinko's, quasi-Internet Fax, etc), then ok, go for it. Just don't come back and say: "Now that we can print to Kinko's, let's 'extend' IPP to include all the other capabilities needed by the driver folks to efficiently drive network printers in the intranet environment." Perhaps you now understand our concerns in this area? ...jay PS: I fully expect Randy Turner to (quite reasonably) come back with a response to the effect of "let's talk about IPP on a different transport", and that's great. We need to talk this out. I just didn't want to go down that path in this msg. ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 16:21:48 1998 Delivery-Date: Fri, 13 Feb 1998 16:21:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA02397 for ; Fri, 13 Feb 1998 16:21:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12436 for ; Fri, 13 Feb 1998 16:24:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04595 for ; Fri, 13 Feb 1998 16:21:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 16:09:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03452 for ipp-outgoing; Fri, 13 Feb 1998 16:09:47 -0500 (EST) From: don@lexmark.com Message-Id: <199802132109.AA04669@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Cc: jkm@underscore.com Date: Fri, 13 Feb 1998 16:08:23 -0500 Subject: Re: IPP> What ever happened to IEEE 1284.1 (aka TIPSI, aka NPAP)? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I've waited a long time to respond on this thread but after Jay Martin's excellent re-cap of Host-to-Device protocol development history, I feel the time is right. I known many of you hear me at various PWG meetings when an issue comes up that needs to be addressed, I often chime in with something like "TIPSI does that" or something to that effect. Many of you may think I am attempting to interject a little humor but the reality is that I'm being factual. Please don't be confused about the following and think it is coming from Geoff (from down-under) but the bottom line is that too many companies in the printer business are not listening to their customers! Get this right -- my customers never told me they wanted TIPSI in their printers. Maybe that's the problem with conjoint studies and focus groups -- we hear the words of the customers and don't really understand the root source of those words. We hear customers say they "want SNMP management for their printers" or some other technology. Why? Because that's what was on PC-Week, or InternetWeek or some other industry periodical they read last week. Does this mean they really want SNMP and think that it will solve all their printer management and job submission problems. No way! The customer is saying they want control and the only way they can say that so technical marketing people will listen is to say "SNMP." Maybe it is because of some internal religion. We too often filter what we hear based on the current religion. A few years ago SNMP was the religion. When we started IPP, HTTP was the religion. Now, maybe XML is the religion. It doesn't matter, the bottom line is that we are hearing but not listening. *** Warning self-serving horn tooting ahead *** Here's the bottom line: Customer's wanted control. Customer's wanted to know what was going on with their printers (instantly -- not some SNMP polling period away). Customers want GUI. Customers wanted ease of use. As a result of these needs, several of us began working on what started as Network Printing Alliance Protocol in 1991 and eventually became IEEE Std 1284.1-1997 last year. *** End of self-serving horn tooting *** I've seen several lists of requirements on this thread and have considered them seriously when compared to the attributes and features of TIPSI. With the exception of security, I believe TIPSI as it exists today meets the vast majority if not all of them. Do I think the industry needs a robust host to device protocol? My answer is no -- we already have one. If the rest of the printer companies of the world would deliver what their customer's needed and not just a clone of what HP has, we wouldn't be having this conversation and HP wouldn't have 60% market share. The bottom line is that we all had a choice. Many of you participated in the development of TIPSI but you and your companies decided not to develop and ship using it. Now you want to clear the slate and start this whole thing over again. Give me a break! I'm tired of re-inventing the wheel every couple of years. If the group "discovers" that TIPSI is a good starting point for a robust host to device protocol, it won't be a surprise to me. If there is a real effort (with HP and Microsoft in the boat) to add security and update the protocol, I'm all for it and I'll help lead the effort to open 1284.1 for revision. But if the decision is that we need to start all over again with another clean slate then good luck -- I'm really getting tired of this. Jay was right on. His list of 4 excuses was just that "excuses." Don Wright Product Manager, Strategic Alliances Lexmark International - and - Unashamed TIPSI Advocate From ipp-owner@pwg.org Fri Feb 13 17:17:10 1998 Delivery-Date: Fri, 13 Feb 1998 17:17:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA03487 for ; Fri, 13 Feb 1998 17:17:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12677 for ; Fri, 13 Feb 1998 17:19:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06224 for ; Fri, 13 Feb 1998 17:16:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 17:04:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05507 for ipp-outgoing; Fri, 13 Feb 1998 17:04:14 -0500 (EST) Message-Id: <34E4C2C0.2FAE4F19@dazel.com> Date: Fri, 13 Feb 1998 16:01:36 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Notification Requirements References: <6FCC2B3BA67BD111A47D0060089D2815059CC8@EXCHANGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org You know, I seem to be getting a little bit confused in this whole notification discussion. When people are talking about a specific set of notification messages, are they referring to the so-called "human-readable" or "machine-readable" representation. My take on it all is that, if we are to create a standard for IPP notifications, then we should... ... explicitly define the specific IPP events that would cause a notification to be generated. Various events have been discussed, including job completion, job progress, printer problems, and even more general object state transitions. ... explicitly define the information returned in the "machine- readable" representation. Personally, I feel that the most flexible, extensible, and useful means of doing this is to say that "the object is the notification". Specifically, if I subscribe for some sort of job notification, then the "machine-readable" representation for a resultant notification would be the actual job object itself (presumably in the same application/ipp representation that would be returned as the result of a GetJobAttributes request). The amount of information returned could be further limited by allowing the requested attributes to be specified (as in GetJobAttr's). ... be very vague about the information returned in the "human- readable" representation. I feel that it is appropriate to say that a "human-readable" represenation MAY be requested or returned (while the "machine-readable" MUST be returned), and to say that, if returned, that "human- readable" representation would be part of a multipart MIME encoding, and to even possibly go as far as to say something about character sets and encodings. But I think that it is going too far to standardize the specific "human-readable" text for each event. one man's opinion... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Fri Feb 13 17:30:39 1998 Delivery-Date: Fri, 13 Feb 1998 17:30:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA03730 for ; Fri, 13 Feb 1998 17:30:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12741 for ; Fri, 13 Feb 1998 17:33:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07074 for ; Fri, 13 Feb 1998 17:30:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 17:19:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06350 for ipp-outgoing; Fri, 13 Feb 1998 17:19:49 -0500 (EST) Message-ID: <34E4C6F5.82053DA7@underscore.com> Date: Fri, 13 Feb 1998 17:19:33 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: "'ipp@pwg.org'" Subject: Re: IPP> MS XML Proposal References: <5CEA8663F24DD111A96100805FFE6587030BC250@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, On page 7 there is an error in the 6.1 example on this line: 2 Ie, "job-impressions" should be "copies" (I think). Overall, I've got to say I like the looks of your XML proposal. I'm not sure how to read the fact that no one has posted any comments, either to your proposal or Bob Herriot's similar work. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 18:20:57 1998 Delivery-Date: Fri, 13 Feb 1998 18:20:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA04481 for ; Fri, 13 Feb 1998 18:20:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12836 for ; Fri, 13 Feb 1998 18:23:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA08866 for ; Fri, 13 Feb 1998 18:20:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 18:08:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07999 for ipp-outgoing; Fri, 13 Feb 1998 18:08:15 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC293@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> MS XML Proposal Date: Fri, 13 Feb 1998 15:08:04 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I left a few deliberate errors in there just to see if anybody did read it :-) > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, February 13, 1998 2:20 PM > To: Paul Moore > Cc: 'ipp@pwg.org' > Subject: Re: IPP> MS XML Proposal > > Paul, > > On page 7 there is an error in the 6.1 example on this line: > > 2 > > Ie, "job-impressions" should be "copies" (I think). > > Overall, I've got to say I like the looks of your XML proposal. > I'm not sure how to read the fact that no one has posted any > comments, either to your proposal or Bob Herriot's similar work. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 18:31:05 1998 Delivery-Date: Fri, 13 Feb 1998 18:31:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA04584 for ; Fri, 13 Feb 1998 18:31:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12879 for ; Fri, 13 Feb 1998 18:33:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA09544 for ; Fri, 13 Feb 1998 18:31:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 18:19:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08624 for ipp-outgoing; Fri, 13 Feb 1998 18:19:04 -0500 (EST) Message-ID: <34E4D4CC.50BF1994@underscore.com> Date: Fri, 13 Feb 1998 18:18:36 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: "'ipp@pwg.org'" Subject: Re: IPP> MS XML Proposal References: <5CEA8663F24DD111A96100805FFE6587030BC293@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, You've specified that no DTD is required, but that an implementation could use a DTD as it saw fit, etc. How then is the "official" specification of the IPP XML text supposed to be standardized? I would have thought that the use of a DTD would be good for this, even though *use* of the DTD by a client or server is not required for protocol interaction. Note that I am assuming a DTD is itself a useful document, not being very well versed in XML/DTD stuff. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 13 18:58:33 1998 Delivery-Date: Fri, 13 Feb 1998 18:58:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA04919 for ; Fri, 13 Feb 1998 18:58:33 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12920 for ; Fri, 13 Feb 1998 19:01:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10700 for ; Fri, 13 Feb 1998 18:58:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Feb 1998 18:47:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09984 for ipp-outgoing; Fri, 13 Feb 1998 18:47:28 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEF8@EXCHANGE> From: "Wagner, William" To: "'Jay Martin'" , "Wagner, William" Cc: ipp@pwg.org Subject: RE: IPP> Will vendors implement additional protocols beyond IPP? Date: Fri, 13 Feb 1998 18:46:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Jay, I didn't add a smiley face because it is not funny. The fact is that no printer OEM ever wants to drop any protocol or service. And since this is so, I would be less bothered about adding some additional protocols, if they are useful, then hearing continuing demands for NetBEUI (for example). I would love to drop LPD (fat chance) and would gladly add a nice, well defined, well behaved protocol. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, February 13, 1998 4:04 PM > To: Wagner, William > Cc: ipp@pwg.org > Subject: IPP> Will vendors implement additional protocols beyond > IPP? > > Bill, > > You wrote on the "host-to-device thread": > > > As to supporting multiple protocols, take a look at what we have > today. > > > > [...] > > > > Hey, whats wrong with adding a couple more? > > You didn't tack on a "smiley face" on the end of that last > sentence, so I don't know if you were joking or being serious. > ...... From ipp-owner@pwg.org Sun Feb 15 20:47:15 1998 Delivery-Date: Sun, 15 Feb 1998 20:47:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA10841 for ; Sun, 15 Feb 1998 20:47:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01047 for ; Sun, 15 Feb 1998 20:49:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA09821 for ; Sun, 15 Feb 1998 20:47:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 15 Feb 1998 20:40:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09296 for ipp-outgoing; Sun, 15 Feb 1998 20:39:57 -0500 (EST) X-Sender: spencerdr@vipmail.earthlink.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Feb 1998 20:38:37 -0500 To: ipp@pwg.org From: David R Spencer Subject: IPP> the *platform* vendor will create the driver Cc: Jay Martin Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA10841 Jay, I'm just an observer, but your comment here confuses me: >> Seems to me that applications care more about the printer driver API >> in the host OS rather than the protocol. The printer vendor will >> create the driver, the app writer just prints to the API. > >Actually, most PWG members would rather say "the *platform* vendor >will create the driver". Hence, the critical importance of getting >such players as Microsoft on board (and *happy* ;-). Some drivers need to incorporate RGB to CMYK color conversion, perhaps with multiple gamut intents, all dependent upon device-unique screening, ink colors, etc. etc. Unique features, such as PostScript allows in PPDs, must be included. These are product differentiators and potential competitive advantages. It therefore seems that the printer vendor should be responsible for driver development -- even if it is subcontracted -- not the platform vendor. Are you saying that the "driver" is only a shell and that the vendors can deal with everything through PPDs or their non-PostScript PDL equivalents? Even in that case, I recall one major vendor shipping an "obsolete" driver with his new machine because the "current" platform driver shell could not support his features/needs. Are the printer vendors active PWG members? What am I missing? Thanks, David Spencer ____________________________________________ David R. Spencer President Spencer & Associates Publishing, Ltd. Three Giffard Way, Melville, NY 11747-2310 1-516-367-6655 Fax: 1-516-367-2878 david@spencer.com http://www.spencer.com ____________________________________________ From ipp-owner@pwg.org Mon Feb 16 08:17:28 1998 Delivery-Date: Mon, 16 Feb 1998 08:17:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA21550 for ; Mon, 16 Feb 1998 08:17:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA01757 for ; Mon, 16 Feb 1998 08:20:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA23762 for ; Mon, 16 Feb 1998 08:17:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Feb 1998 08:08:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA23224 for ipp-outgoing; Mon, 16 Feb 1998 08:08:26 -0500 (EST) Content-return: allowed Date: Mon, 16 Feb 1998 04:59:22 PST From: "Zehler, Peter " Subject: IPP> TES First draft of IPP Test Plan Outline(resend) To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org All, I still need some feedback to continue working the IPP test plan. In Maui I said I would get the first draft out last week. (I don't remember saying I would actually post it) I have now uploaded the *.doc, *.pdf and *.htm versions. I tried to generate a text version. The results were not very readable. I'll have to work on that part. The URL is: "ftp://www.pwg.org/pub/pwg/ipp/new_TES/IPP-Test-Plan-980216.pdf" Sorry for the delay, Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Mon Feb 16 12:17:17 1998 Delivery-Date: Mon, 16 Feb 1998 12:17:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA00292 for ; Mon, 16 Feb 1998 12:17:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA02802 for ; Mon, 16 Feb 1998 12:19:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25700 for ; Mon, 16 Feb 1998 12:17:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Feb 1998 12:12:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25183 for ipp-outgoing; Mon, 16 Feb 1998 12:12:19 -0500 (EST) Content-return: allowed Date: Mon, 16 Feb 1998 09:10:50 PST From: "Zehler, Peter " Subject: Re: IPP> MS XML Proposal To: "Paul Moore (E-mail)" Cc: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" X-Priority: 3 Sender: ipp-owner@pwg.org Paul, Section 5.4 could be expanded to allow discrimination between "attribute not supported" and "attribute value not supported". "attribute value not supported": 300 ... "attribute not supported": ... ( another typo in addition to section 6.1: Section 5.3 has job-id instead of job-id) Pete Email: Peter.Zehler@usa.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 From ipp-owner@pwg.org Mon Feb 16 14:32:16 1998 Delivery-Date: Mon, 16 Feb 1998 14:32:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA04238 for ; Mon, 16 Feb 1998 14:32:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03365 for ; Mon, 16 Feb 1998 14:34:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27606 for ; Mon, 16 Feb 1998 14:32:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Feb 1998 14:27:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27093 for ipp-outgoing; Mon, 16 Feb 1998 14:27:16 -0500 (EST) Message-ID: <34E89303.E1944A09@underscore.com> Date: Mon, 16 Feb 1998 14:26:59 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: David R Spencer CC: ipp@pwg.org Subject: Re: IPP> the *platform* vendor will create the driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org David, Perhaps I should say "the platform vendor should create as many drivers as possible", rather than "the platform vendor should create the driver". Specifically, I was thinking in terms of the "port monitor" side of the driver, using Windows terminology. (That is, the part of the driver responsible for transmitting the print job to the printer, and handling all details of that transaction.) You're correct in pointing out the need for certain printer vendors (or their subcontractors) to develop special imaging components of the "driver". This part of the "driver" is not what I was referring to. ...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 -- ---------------------------------------------------------------------- David R Spencer wrote: > > Jay, > > I'm just an observer, but your comment here confuses me: > > >> Seems to me that applications care more about the printer driver API > >> in the host OS rather than the protocol. The printer vendor will > >> create the driver, the app writer just prints to the API. > > > >Actually, most PWG members would rather say "the *platform* vendor > >will create the driver". Hence, the critical importance of getting > >such players as Microsoft on board (and *happy* ;-). > > Some drivers need to incorporate RGB to CMYK color conversion, perhaps with multiple gamut intents, all dependent upon device-unique screening, ink colors, etc. etc. Unique features, such as PostScript allows in PPDs, must be included. These are product differentiators and potential competitive advantages. It therefore seems that the printer vendor should be responsible for driver development -- even if it is subcontracted -- not the platform vendor. > > Are you saying that the "driver" is only a shell and that the vendors can deal with everything through PPDs or their non-PostScript PDL equivalents? Even in that case, I recall one major vendor shipping an "obsolete" driver with his new machine because the "current" platform driver shell could not support his features/needs. > > Are the printer vendors active PWG members? > > What am I missing? > > Thanks, > David Spencer > > ____________________________________________ > David R. Spencer President > Spencer & Associates Publishing, Ltd. > Three Giffard Way, Melville, NY 11747-2310 > 1-516-367-6655 Fax: 1-516-367-2878 > david@spencer.com http://www.spencer.com > ____________________________________________ From ipp-owner@pwg.org Mon Feb 16 20:10:05 1998 Delivery-Date: Mon, 16 Feb 1998 20:10:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA12536 for ; Mon, 16 Feb 1998 20:10:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA04785 for ; Mon, 16 Feb 1998 20:12:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA28511 for ; Mon, 16 Feb 1998 20:09:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Feb 1998 20:05:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA27971 for ipp-outgoing; Mon, 16 Feb 1998 20:05:30 -0500 (EST) Message-Id: <3.0.1.32.19980216170121.00c95100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Feb 1998 17:01:21 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference - 980218 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Agenda for PWG IPP Phone Conference - 980218 We will continue our discussion of IPP Notifications from lat sweek. Look for a new requirements draft from Roger deBry. We will also discuss further about the requirements for an additional protocol (if we need one) that optimizes the server to device aspects of printing Peter Zehler would like to get some discussion going on how to download print drivers. We will get into this also if we find the time. The dial-in information is: Date: 2/18 Call-in: 1-608-250-1828 Access: 190148 Time: 4PM EST (1PM PST) Duration: 2.5 hours Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 17 09:57:17 1998 Delivery-Date: Tue, 17 Feb 1998 09:57:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA03047 for ; Tue, 17 Feb 1998 09:57:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA06540 for ; Tue, 17 Feb 1998 09:59:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA10902 for ; Tue, 17 Feb 1998 09:57:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 09:45:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA10347 for ipp-outgoing; Tue, 17 Feb 1998 09:45:48 -0500 (EST) From: Roger K Debry To: Subject: IPP> Notification Requirements Message-ID: <5030100017545030000002L002*@MHS> Date: Tue, 17 Feb 1998 09:44:10 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100017545030" Sender: ipp-owner@pwg.org --Boundary=_0.0_=5030100017545030 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have completed the second draft of the notification requirements stat= ement, hopefully having taken all of the comments from last week's call into account. H= owever, I could not contact the PWG ftp site this morning. I will keep trying throughout th= e day, but just in case I cannot, I have attached the PDF file here. I will post a message if = and when I can move the files to the ftp site. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 = --Boundary=_0.0_=5030100017545030 Content-Type: application/octet-stream; name=notify.pdf Content-Transfer-Encoding: base64 JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAxNzI4DQovRmlsdGVyIC9MWldE ZWNvZGUNCj4+DQpzdHJlYW0NCoAQioDQULyMMRBCCoZoIMRgLhgOBAMInCYfERAOYeMoQNxoNhcM xuICobYJFDPBCEWBALyOU4QZzmICKWJPJDHNyod4IWxQSScVCKUicRSoICIUiCRioKRaMhwNBiNx QUjeZzKchASxAKRkMxQZDKQjkeRSXSoSpuLRiLhjGhrJCJPRQPDIcjCZjoLTSZToZr4cDgLTcb72 MIedDwdB9ThkNRmMxxPyETRAQzecjhmTCdDSbzdZ7TBJFEK/ErZbrhcoIKCMZTEcjqYbLCRyORwK SoaoJbByLhxkRmIBaNhvwBqN4VcwULYuMIVPAVPiKeDgaTkZZmQTqZzqczpttxThjkhsNhQWygYa xCS7orVzanqhhcfOLvPxtYCopO9aKQyjiOrsDKNoyjcOiZjMzIQCSKAoBAJzDDSMw0jGzrPjcObd N45oZBcqDkoqKjmBQGMOLWtq3vq/YUBlFAFCoFTWhnGEZNaGkYQ/EKRtTFa4xI1oQCmKggioKoph AJ4jJIJAkySJoiiaJ8YKfEAcRE/sShrGCKR81cggUFAbR1K8RS/FkwhQKg0DSmYyDeMY6wNBAQTc EAwjdBsEKyNy/BaIi8L0FwQT2Ok+z/QK8wTPDshAO7MjWNI3DOEE4TlOlGDeMwQDoNAy0NRDwiLS lJjKrNJjPKsdywkctNaG8yx44kVTBEoqDCOY1hAIzMjHUAuJ+owjC4FIWTtRjaDLXNjzyMlkJnSA 5UlSgQDOOQ3jqOA50JCLDVBTzOhAw1Pq1a9s22EA2jCPM8DYOY30tNw6DkNIxDrQ9H0jVNVzNV0W ty3aCVZM9azTEtLznA9kpmJM+DlPy90UvVuX7WdXzEHMqoeuM0SBEqHTKG9W1o+mPtbh1D4hRNBW TRy70XS044VBCZjsMI2DTZ8Fq0MN1DCPA0jbOdx04OY0jxdTQU8mdnZ/doxVBbQyM6MoyWO7I4DY MNf6vcY5X7kcsxaGMT4EBUP7FHuDZPMQ3jFeA2L9qwQDFdtyKzmVMYXprwzzdrPQNbokvDO9JjCw VsDheuq07eLv1BlNRUBlumpm7IzKzA9f5/lQ05xsOSYxE0X7PtOSY9FsGDpeIxjTfNPQLcfYq1cM 9VzQoThPaVd0mEHFqu7I5253XQ7HNTyy7ksf7JHPTBdtXl1s1oqXjuTaT12IQTkOTszq8DOu/os8 DddvJZXiWW2PrVljnUAx0+Mdd+13QY50Fow7hemuQSFzFB0d0CBnJ4FUvbaWGFUyz1JvGX+8hLjz 3oupTCT57T52IgtKQ5VIYaAwpwDuUhAgY3WL1O0uNPR5DEAoL0HAFybgXBjDeC4PTPlghBDMvVC6 xVjmOKoG5CwLjChyDIHWIBflCrBCKHVxQZYdFdLYRwFDQw3BuNoGkFwbw9AuDCHU+BvXTvHZAmSC DqG2H7J8sE9brkKhjBAFJoUTQUtlLCtxSbKofBjiKeFYKSCaK5PCZiP0TUGHkKhCoOkLE3RWasHU EEe0khXO1H8N8gQUgui6h56DomyKxbOl6MryGAodi+2tkyLQghCSIUoIZTWzpWei6Mt7yoJIlBkD BkUZJSpqTYndhKmU7EzNAqBTaeAQPuPDMOXrfFHptfg44rDtFLHaDGvVqK7g2J4DmHAMsIpgKcZ8 n6D8FojBQXqghfkrZRojlo2aUUmWCy5RLOQwycQ3zXWCg4KCxVCT4l++RPBgmcoXM8aCAQZQ7Blm u8B1kMJrrhPChdPU1XIM7QYGRec1F8N0cXHWAtBHYwMnUa0GTpZ2wRk+iWcQdFCJsc0o1UDQw2Ge fY782ijHWINQesde54XtUbXWbU2j8HXzbDpEpnEBg2mbT8zWlynVPggCaG8sQbFj0fnRO6BstEax jne8xNU8qFz1fIs9PKdmHhma4uBeIRIQwjXaFMrIdkLHapWm1N7M5fPArkWJpsxQ6NVl9MN7R2UB IEUyhuq8r0WgyedSWXFXkSs8BAYUz0a0MGgctTQOUx5vJ6n5XAOVclf11VAGYOobJrzGfHPyZNTF JhjDYHUsQOqQOjMfLKk9IoxWOq69NMShbgIAsKdmw4ILJVlpSCCclHFq1gnoGy2ti5OW8lJZBIVw FQvouVOUz1zVsVhDYC8toMAdVQqlQisaQ0Cp5M8GOxCHZXSaTUVCW9vWD3XuBcm5c5rvTzoZeIiF 5bnUMSHNqNSFrLmhsTfKWjGquXVt8Ci7EbcEs4tK6up4U16B1hFEqYSnHtVRqnenAc9bopqBnLbB 70r72/uxZKCrD2I3buYpXEt0MFxgRpOxFM8EaUkIIUYghAQNCmVuZHN0cmVhbQ0KZW5kb2JqDQoz IDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMSA0IDAgUg0K Pj4NCi9FeHRHU3RhdGUgPDwNCi9HUzEgNSAwIFINCj4+DQo+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8 PA0KL0xlbmd0aCAyODE0DQovRmlsdGVyIC9MWldEZWNvZGUNCj4+DQpzdHJlYW0NCoAQioDQULyM MRBCCoZoIMRgLhgOBAMInCYfERAOYeMoQNxoNhcMxuICobYJFDPBCEWBALyOU4QZzmICKWJPJDHN yod4IWxQSScVCKUicRSoICIUiCRioKRaMhwNBiNxQUjeZzKchASxAKRkMxQZDKQjkeRSXSoSpuLR iLhjGhrJCJPRQPDIcjCZjoLTSZToZr4cDgLTcb72MIedDwdB9ThkNRmMxxPyETRAQzecjhmTCdDS bzdZ7TBJFEK/ErZbrhcoIKCMZTEcjqYbLCRyORwKSoaoJbByLhxkRmIBaNhvwBqN4VcwULYuMIVP AVPiKeDgaTkZZmQTqZzqczpttxThjkhsNhQWygYawIBkXdFaoKRhlCZJDObU9UMLj5xcGwaBkHLW AUFC2oo3TePm4aFPw34YvqiiKQe+qHBqFzkhA5SHvKkiTQKKYxjeOAywSgiDIRBqGouiUJIsiCJB sGS3OHDcaQ81rIxMBSKNSGAchq+oqOYFAZhpHcZhuHEMtSGLzpHIadOkFAqDQMoQDnEUSBAN4zBA Og0DSmbsjiOrsDKNoyjcOiZvAzs0TU8MxBAMzMhBNQyBA76sjmFwQJJMKZjIN4xjrNM1hBQbtBAw rwjCMi7u1MYyzLM9DzZHanhdJUMopKMChmGskU3JaRya1dPhQOcSDGNIzDSMcvjeEA4DkNNEUeNt bzEOi8DozKZztEass7YE/CQN47jKOyshYEFlToOo2DYPM7usMoxvDMEr0bV1YM6z43BBNIxjQMI3 TENo50zJNSorVIZhtUdOVMtq3v5AiwjLV43DLPNbywOrBMy8Muy/KwQTJMzs0vNq/Tpgg0BBgEwT nQdC0vWQQDFK4ysXPA0jENkr1/WlbVwMldXQ8FfWBdlSU7fKRXnd1T3xVNzzzYeWjkmYwpnZVphd l96XfIjJR3Ht7LfmQcx2g0GPugkKIrCa3PqjQXI4EEZN+6EcQLGdPKzlQ3jYq6zN3E6DvshcVxhq sXoxGUb66iCFQ+FAaBhpLiQPIEhSIqWaSZe0n3yJM5Jnfox0k2lq5KsV+SuMMsYfgw6bImeAMysS tZLjgQDDkWSVmMeRtpalrVrSWDyvhVLTimc6jlol3U9wQZcJer9rjVNu1eMdwNByw5DtWFF4Bc4Q CSKAoBAKY8vBNGh7U5t25jVIaBnvrUo57d8hpI/rahtsHavuOqazrbkoeHLhpK1sZoQJQ3jF6A6j FXQ6M8Nwzk0DcnkKocystPbYioBRDm4IugU3N+Zw32gufe2BvSonrNKd6+FeT1nsO8SccZfIQQQB oUM8tPCeoCFaDuGhWYc38v7Z8yZW54Q1P2Y08t5rzwoMncyHJPyVU5okZ68QNoYVqp2iKtVRrG0r h3DSxVcS23bPZcEDd3bfoMqpDmGFNLllCq2DotVQcRXlEzW2CCHcMysw/UCrRPkRIjJcK1ElRhho mAgKwVcvAcEwvCWnEoMptHXQyTXGuKZI3cGtBobmC8WF7u+cE058gRmotuAU1RFz6iNkIBqDEtoO EBvxbC1oED9X7hThfE9/r/wgmCDYt8zxoIDIpalAlFjcYGoxgeCCTsn5Qt5Bq3x6wVAVGtk7FdJr h1UhBXEGGV0sFwggC4Ch2i1ouBwZG6JjZnVyuime8KWIbguApWcGFbKt3/vEY4uYNiXmDQmgDChZ qz4+sShc/qJ8MVawzkO0aYzuoOMwg8qhIkNX7slhw86NEPI1qAcpN94a4o6RIjjEt0MTooSDi3F2 AkX4nxiDfGSZsZmERpkLD6fsiUCmQmQvaghrYgM+ohOFcccaKRKjs6GPIZ49x9DDH9RkgXPsIn3S d6qClNNFpUCgGr40FQYkevkGsFkFPlgRJgismmtEIfEQ9JcFEZnDCmtgOsYFqhEpCGFW8s3zNvIx AyW7dEO1dORBQGsG6nyOmUkQ5NLYspECMnaM4cKymbgIsFLzFVBJiUKHMOa4VnRngIwVLy/Q6B3M yGsECIg2mbX6mtoE9bNvLs4G0Oq6JwRNifCwOp4QzhvnRSmqUjEFQdkdS9AqYA5BvO6xJyqtQ3h4 iOVpV52Q70/DYn6EVHay0fUTWlgEdKdBlj1M6n1QFmG1DYbQrCzpqsemvNkFrog3B5mxOZEr1qku 3qlJK2tArbs3SJRhMK4gkmVBcEMJ4Tajm9ttUsG0wq8s2kga0GwMYDSVfOhB9L6H1kIXib8HDeH5 AuBo8yhQQ5XpxrZAiXMuK4y7wicDCiBUZI7mJgZ7lAWizJhAqlKqVw5pdsubRK9nLPJxS5FFhDpy +qIDm9JzIbZ6KwYkGmzrI2GyDhyyYwyhGzX9evfDAFTi10uvlgaqja8FNTfRJnB0mwQAzBkklKDe UZlxlMCAKS2A0nXw5JOWklsP1wbhXI4eZMzQUPO91w2L0iHGr9VGZcI4SrihWrNOcZ1pGeiK5mzZ oIXJpK05iokPAQUGT8EmiS51qvCsOwdOcTlpx3slFxK8QsZ0jddbJVINraEEttgRfOa5UT4f5OiA EAoUrODFa3UTiwyr+jqo4Nlx3pamx6z8MqfrAlavBkkMqzlXPMnlhh57JaiqO1doG9za8LwI1nlj AqBWLqGx08S39DCtPKY2d9W7rQ4G0Dov0OQXMygysQ8Hae1ouSD1tKnXL/tdgggHPOFYaZs2Djff bbprQb4C1lfDWiqY1TxjPudjM1borV1/Y9ftjlab03tvjMu+3kMTpIlfNebVW5wTWn56Ct3G47Sv pZK9r6f2I2xw9ApytB24BRotWboXR8LVntuoMgtGBs0cm9hObuYWUkHtvYlvA6WEDos5aFmFpJ5M KHKItQGPKsW0wiU3PgUA3oBe/Fu5F88uzfj9bXRUrsUYRRvGVZKzXPpE6IOc5Z407p6t+oC/emUl 3YsdZKy552Kpq2mpF/18g3xX25mvcFPk+iXT/ZBM3Qxn1Bs0EGz5rbSWcElgOuJtdKoM6IMdu+RR n05D2y0NyulsfECgJatw1hv5NvqQh4Q5wsDhpt0QbT43+yp5XKwCtx1/NaGIwzEoz63f3KtO88eD laZzwCG3cup6+2B6rf6/bVlZ6WVrsLE8eYy1RF65sYe1A3y39DinmkiRjrVqyM6kyHrKS9aKjiCv DK76Tn6KySbLqS7L6rLMKrYhIG437yysA/6Ur8LqTuiha4LyTcCtqWyBYirD7PECUCh+BvJJTFCY rn7b7/Dt4tyvY1qETVTdSc7gidQMqdidyxLtEDLl7ujmTTjkYOQzxQq7YOSyMHx+78UDaHcDpWgN B6Twx1Q64MYNYmZgTtQHDiUF7zKrZ8BVKwahhPLjTHQMy3bIj/7djakHrlkH7ubHR4QNyJaIR2kN Rcw8IMy06c40CNhK8J64TlQrqSZCqWoqQkJH4uKpYMUDw+bcKWoFp8QiBwCfxArCaA0QySz6J75+ D/ZfZXacKA0SCSwGkShIMSwFCPC6ini60KiQCQT77vD+Cjjvi5z/iMrqrxb0pOzaKbDfr1Se5/Z0 RTIkAHDCcVIHDtricGDQhIj1yG0NCkKEakJ0qO7qxnSZr4b9QzpZ6zLTb4JPKV4NZK4Npaqjo7IO hx5jUKyzRgUXSGbTKGxnMLby8ZkL8Zw1rrRiZgqiSMQ7QNbTbHhOb0ZZzfzIicz7Rn5jb6sDCU7g T7QIr7iFK8hPLlsDROJPwJsR0AaRBfIqLoLLJAsdAv0dZOchLXUhZysi8IDHUQIPMATyhVJJbP0B AFAHEAwBQowgggINCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9Q REYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMSA0IDAgUg0KL0YyIDEwIDAgUg0KL0YzIDExIDAgUg0K L0Y0IDEyIDAgUg0KPj4NCi9FeHRHU3RhdGUgPDwNCi9HUzEgNSAwIFINCj4+DQo+Pg0KZW5kb2Jq DQoxNCAwIG9iag0KPDwNCi9MZW5ndGggMjczNg0KL0ZpbHRlciAvTFpXRGVjb2RlDQo+Pg0Kc3Ry ZWFtDQqAEIqA0FC8jDEQQgqGaCDEYC4YDgQDCJwmHxEQDmHjKEDcaDYXDMbiAqG2CRQzwQhFgQC8 jlOEGc5iAiliTyQxzcqHeCFsUEknFQilInEUqCAiFIgkYqCkWjIcDQYjcUFI3mcynIQEsQCkZDMU GQykI5HkUl0qEqbi0Yi4YxoayQiT0UDwyHIwmY6C00mU6Ga+HA4C03G+9jCHnQ8HQfU4ZDUZjMcT 8hE0QEM3nI4ZkwnQ0m83We0wSRRCvxK2W64XKCCgjGUxHI6mGywkcjkcCkqGqCWwci4cZEZiAWjY b8AajeFXMFC2LjCFTwFT4ing4Gk5GWZkE6mc6nM6bbcU4Y5IbDYUFsoGGsCAZl3RWqCkbhwqGArf jEZRWKfn9o0FyOBA5S2hgHKSJMBSKJ21oZBckYnMMNIzDSMbOs+NwQCkMoxjS64yjcOjdN4+aEPs hqLokiiKIciCJBtBzywGGMCwOkrWhwG8RrWtq3hguIqOYFAcNy3aCQcG4cOS4kevOkcgtaII3DyE A3jMHQQCUN4xBAKY6jENo0jozw3DOmg3DIEAqjmrIWSzLcuy/MMxjTMoQCCwQ2QrC7QTdLUuQ3Ds PxDNzMzfQEOQ8vsQhAKA5DePA8hdHbmyRJSRwXIQcBzSiKNTH0gSEjVKIM+qSPu/z+Iytz/o2hDz hoiEgQSFEHIlCLPQpCzPNBDVE0G8IgqxENSIOhNTxRF1VRajEYLc4dYVlBDWhyGNKCoFVqBlSlLS XT8nNYBQUCCEA4UeM68DaEA7jRCo0BA7IxjKNI7O0EAy3rEKZ16MQyjQMI2DNKuBDoNAyhAwtcz3 XkM3jRUQDoFySYMED2YgEA2jDKg6DCNeDjmN424OMIx4ZSinwfS6KyhcQchnbmU29HrV5YFF+X9g GBSsEGC4Ph1gTcMzMju2k057hEJV1PkMjoN+eYpn9FvCOw0jCEGQZFio2DorI3QveuMDKMI3JmLg UaEOWT27TFwhQHIaZhJOZNVH+2jKPAwjaOA2DLNw4Ytp+fV/qQuBTQqtDiOoy8VwOkYVXcMBBtAQ DYzqs3gvw5L6O2ABAMWN6hweIUnI1K5jtmahyGtOyZulQ2oG1i1MhaCVTFdVv0jNXBAGuXIghVaQ dA9cQnhfIiLfI6DnYsTWQBVmRUivoBBZ0Zd6Gff2nlsddLbFqSLEm19aGNwZrKUqZ3o+hDYNg3jv OszDG0DwTEOuuXv5KZ4KzuK0POKYExJkTMEVNCak2FaQshkOYcFEhmSowl4rkH5ueY+xdtAOm1On ZWqJTjpTnAuLip9miQiHAwWKXFE4CnsFQPO60r4MkbHMg+YgiQVCcriC4DI4xXXSkGea7R57KQaI Hhmj8/bLEFw3XGlNq7HE0NFUa5pELlwmhJCE1orJ4WzBpBcGViRYmqLyiwHJ5ThWTg1IgcoGkGzW kOWtD0I0KHnQrBxC01JXwZnLN6c+GsSocw7eYseIBbUkxDOIc916CicGtT+r5eS9AyppbMHQvDZE xORDMo9dQVQ3BrMKHdpjTgoIgDI/CM0Ho0AwjVGxcRDltxwjlECOkdi2x4iPDKPki4cQ6JHIGFMh CoxEOfIaJEugUSNCmxyMkkQQNmCpJUOcl1eyZZCo2Uj8GeSiUevIOc0UyynRIC2VMq1MxtBgy+WE gj7yzBtC44S4Yix9NbH+XscIfn3mBIaIoNIanMiSa09Z7TMN6b4/ds1AWDhpJmeBkjHgyTgN7OMG Ma5yytBg3CdMKZ2TuBnGtlk8ZjT0h4iSH06iGxCmERCi6T5/TGMw+xyyaTMBwSpQNvZfmDtmcqeB q7Bi/MDBA/KmDXE0vypoCChUTaGyRogc2iVFG2kOdXRmOcIDERElqZGRNIIbTzl5SMglJZfxCNRM OdsxaurikbTagtOQUSUbHNFhjkpNRRDfNybyZlDV2rw/AFp4A3mCmY00y7Iab1EqbOJALKqKgoIc 7GqksrFy0QCZGlke6VTyl3ICe1JogyFpSYgGlHqW1pmOnAMIYjM1EmbW+aE0kMzUXVKNND8E3W0l KmUFrBg2BkTdXw7VeXD3Am7X6wFgmjNOCDaqZdDwUxnjTROVljpVQns9RuO5kZ+2YhpSGr8vnnT5 tDRc4daIlSNgSvJvkkrXVxthXSatuLbTWtrbq3lvriXCSqVpR1d7g1+vvNky7Y71VMufKi6NUGak OfAjx11UUDOys87YiqqUAICBpR1Z72laluIo8RpVc0NhnoVXBk1nZfopWXio5JEED4ZVijJG8rSH OsW/DvBaNFixro1YtuaoG2hJPCHMNAbw629gouUN9xQxN8ckoaUgIDvlZf006HJX8R4lKzleNbk4 IYhQwvtgS8oyBhTqzwPMDMxP4YgHNNydSxQMTQxdKzJ46JLsajSV6JM7kjhE3VmsyE5UKmiaBiSd 0M5RymVpjKVDs4kPA5dtGdsfOohIeXGzM9AaXoxSSON17JztuyR+eEubTUix3Z68Uh6VAzkTP9cQ QX2P+meGEODy8ESqulnkGNU9PSxnXqGdwNLLnN1NH678cMeXhpRqwxFHVw6wXHrPWut7WyNbGmlR ydWuBysTU+6aNLIa/1BCzUVWZ+alszd6zmntlyD2bEUyO0ZjIRDdW5DcB16kzasHN9p4cztYYOnp OczKGZNYOzvK4M8vvGV7kU8Ac8ubfwTuEqemcH45wafN2aqFWKqws7sGZjwXA2Vmg0txCMQcOQyE FMbmgxP2O1qnFKynbvTxagY93JOTYcRpB1Einkm44hIDKEzpc+vjhGa0JIUAoAgCeGINSHHlWtcm 3dvNN03NWXNtwEAaktuFvgupdi7nHQRaWxU7MFJsJsUZo0EC/2wGdkoGnmLXNcTh6TnkjilOk5/k SCgMM3a7tVtY+9grgQ2sSXJotjDGl1tjPDYTuXCd737YwZnhLBGDJsYr4RDtMWK8v7tzImZ2Q6B1 DlvdNLADQBn0oVDPFUQZZ7NJpXpWmzW+IXf1w2hngx5HNp2fMGhgQBJQysMrLAE3M9893BOoYw2B 1LExWJndOYcy8+yD0Ph0xLvaOlvqbJfY2M9pOjPnuPAN2TnAJxvDYJBuYkdXrLfCZ/R+mWKDEHu9 +006wcyAwWMeUoJAUuIQ/WZqDcDqDaX6DkBaSsL4imDkXymw7ADE7yN7AKOSIQ743GIJA0OU9y8D AsBaDXAeZKL9AwObBBA49oe4RJBZBEbbBJBMrua46qXMv8m6kiZPBi7443BjAQOYJ9AsqQb0OyuK DeBSBsBgBQbIPjAyORBC746BA/ClAO01BGS2L5COv+fnAi26XMpwDJB7Cu3CBm6PBhDNCENbBIDT C7CSbIBafkoJDHDLANDOjfDVDxDYXFDfDFDiDmrZDGCG9UOyRCpmSobNCKiqCEsTB8qi5HAJDXCy bayIDKL9EGqJESCdAXAatbEYitEfDMzyMjEnD5EqZrEvBTE0kiCIrvAWYhE7AYcvEWThEbFHDxFK /+AVCDFSSEpmL6DmBaOycSO0qJDvA3DO19CtFQ4zGAsCDyBaDozSDLGTCnEjA9F7EpGeNaCefsDg fsBaLEfoa8xOnDEgwWJFFPGVD6tODEr+Y4a5GIbEZBCeg9HShIMk4xADH1CqkUU+LeqiBpDSIIKM IIICDQplbmRzdHJlYW0NCmVuZG9iag0KMTUgMCBvYmoNCjw8DQovUHJvY1NldCBbL1BERiAvVGV4 dCBdDQovRm9udCA8PA0KL0YxIDQgMCBSDQovRjMgMTEgMCBSDQovRjQgMTIgMCBSDQovRjUgMTYg MCBSDQo+Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA1IDAgUg0KPj4NCj4+DQplbmRvYmoNCjE4IDAg b2JqDQo8PA0KL0xlbmd0aCAyNjcyDQovRmlsdGVyIC9MWldEZWNvZGUNCj4+DQpzdHJlYW0NCoAQ ioDQULyMMRBCCoZoIMRgLhgOBAMInCYfERAOYeMoQNxoNhcMxuICobYJFDPBCEWBALyOU4QZzmIC KWJPJDHNyod4IWxQSScVCKUicRSoICIUiCRioKRaMhwNBiNxQUjeZzKchASxAKRkMxQZDKQjkeRS XSoSpuLRiLhjGhrJCJPRQPDIcjCZjoLTSZToZr4cDgLTcb72MIedDwdB9ThkNRmMxxPyETRAQzec jhmTCdDSbzdZ7TBJFEK/ErZbrhcoIKCMZTEcjqYbLCRyORwKSoaoJbByLhxkRmIBaNhvwBqN4Vcw ULYuMIVPAVPiKeDgaTkZZmQTqZzqczpttxThjkhsNhQWygYawIBoXdFaoKRuHCoYCt+MRlFYp+f2 jQXI4EDlLaGAcpIkwFIonbWhktz9iSNo2jKMg0s6MoQCcww0jMNIxs6z7Qt2giDIQ+yGouiSKIoh yIIk5KIQPAkYwQ1oYqk3TeQU4i2reGC4io5gURuGUcxIIwaISkj7hnAIcOTHi3POkcgtbDTPQ7D7 PNAmY5jKNzwjoN4QDoNEMMLLEPRA0AQOyMY0uvL7wszMkzBBNEOTVLY3TaMs3zjMAuBlQaZvZOQQ DTPg5jqMY0BAMIQDuMI8zqzs6jLIzmyaqEoQXIUbhnTNNyekbUx9IEhTxLM1z42g5DSOztURCUKQ sOgyjZSgWUiNMy0TS4QDYNI216mY3jMEAxjfCU2DCMi7u0OdEjPXY5DeOrPDdak7r8O7MjXZLQKw 8EQ0yFtR061gFSGGgaVFJ0oVM1cq3WMI3DIEA4tnYQ6UpY4QS8OQ7Q8MoXXNdCR09GwaBrTKKXlH 91XYG1MoM+sloI/z+IzB6Mo2hAbBoi8gQSFEHPKEAojqMuV3xK88y1csRvnJMTgVFqMRWi0XBBGE DBBkORxrdcbhvTIqBVhbc5nhEohjKeJZfVc9pmO40Q9RzaTOw1uDHaLaDTXOAUPYcJwrC9c12MVs Ue7N85XloQDNOixWFWLajFSg52XDFE1uOWzVtTGZ3PeGE4lG4c3fTlSx7edU27b9HsFYWYtBXc6b mrQ2QurTsjpV4yjsMI2Bcmg2jDsNeTLgExbde18c1SQ5XwNNCz4Mo8DCNo4DZDF/31lkKYPwyK3p IYahhxdSadx7W1VPUQ4Nwmm4Vogahjh3m4j44YhrIuZ4tJSF4zjudY1AEBBqGzfuhoeTLdJOpejN g37uEApVxCwxd8ki8BuDmZsOQdGKpIfGfdnCKiKwJZ6cdn7632kKZK95ULM2Ho9ag90Gq7mmPFYg qhKyG2pohaq1dRrbUMN1VgVlCgIG8qPT6sIML/Ayq7S88ENzXl8Qqbuv5ZAcAwhjDWX5YxWlGm0i C391p2Xdq7Dur0NDxHGPGU+DVhsHYpwfYlEENZhQ7u+DIGdCaYFHr3T66APMNlGKOTKpaHhWYfLA eg5ZPjtgQHeiQmAMsLYnq+UU3xPoYW9huhm76KTzHrPIYpFh5kWnjmeQmsFYaxXTBGTo7l3bvYaq IWQmVraaY6J9T+X2MgaJBLBKuVhfCx1kOwjuaBDAaJAOaWAGRSau17SHXTBpo0jF4uOe4kJsqtUL p3hE/RPiHw3JohchiPD/1bwtTFM0EEbzshkV26JL6kUzKKUO/YrMMDswyhomR/8ATMh0BZLpw8Gm lo6abI5IQYk/BhO+hiTzbo7JoautpS7bpppahOr10wRzZzQj3Dt/UPU+r6OwrIMRhlHPBbjHNVkZ V8BhnZFRGwNXFS+caaqYJrZxv7f66Be06IBumCSsia0cZPTGlBRc7NDjskzDgtZrwcyZzTpyG+nZ M1lISDqG6ZAc5sxBUcl6njMkdOFinIlp7yqQPbhAuuOzqJCSqUQq2GNJkMVaDcVmXFPA6qvn8GYO obGxGZLFNebK9wWpiBal+hTdo4PTqe9VxANnswWqtX18COnxM2Y0+djr6SELtN+DlKjJWTlxfnKG cBWgqhupLIVDAVJzwCgI+GAzNoGM6gYz5A9jAXWOfe0+CqOoLpSONX2Dk8IPTAquCiyarFCtumtC 1gakKY1qXu7tOTpJzUps8o9Z9N3br4Wsthabci8ITW8HINbam2GFo3VIG0V7aRZttFuIUXowRim+ 54vxtY7U1DrQ8MjpgoU6WimRMdP6grhqJUaOlSJOVdDsG8NisZsQoBBUVZUAKUKJQpXo3tfHunne 1PJGxxsIoFOUknB870jsXfIfh8xFX0MfBAZIh5In3snBsCAJAdatGXS5iyzSGZjx0gKzVjDN0Usb tLA5A+JCQ2PwnR+11gXug3qpd+Rt4Xj25apNxrGBG/V2mkmOei4YAYshbC8NGMHcRmnuHImcBT9s 2Kg/EGSB5EmgVzjWA5DTgIGLjIl0wVEzKUwOHR1KfDCggdQo3BTB1NmSIRVI5Ty5f0iquT6Jktpy lOPQl9ZSFVtLGk6nabSYHTBFdQ6pb1a18ZVXsCCTDvH+r/UhivFuB1FuonLRZPbBi0HyqhIhxAN7 BlryUp8G9rcN5tw8fpjeIUAkIBmRxGhJUGluJGE2pWCsXZX1Y/3JlTkj42w7aOBeObTYj2Mz/ZDR CPNHaTuC7xpLa6IajjO3WToTtaq6rde8LZaaqxYHBPcLlKKQp+Ge6ZXbQZjxuY84BwqOLrzUWa0G 1oEZvBznFiUat2u3BAEkKAUDLrCTk6bZmfqxsHIeDkqGKdCSLyRodU7EjMbQxjq6EmfFJ0yytnhX +W8W6LxiolzTqNX3b1rL3IeEtwYaPnhw+9h8QWJxEDKvxwIJbJBiRIJoaQ8Qt2maDNlosc2k21jw EHSi2g46buDIWuLYJUU+DjI+5rwboeOEHPnUoW8sTY6jOxoOZJ8oi6zmmoebTlld3tPnfX+84Mzz p6XPHu9gwr2zs+t+h6+6Mf3pGw+uo3BcDfIC60mkUfzTYMsYw6Bz6vjfbCLOto0I4DTy/mUhnB8X nA/fibZ9qyT2VdRPkmnkBkkMrpbPd+9P0CjtwSg3hiBAFMOoYliB0WyGcmkZgqsBz4d88OoJyzTg Cn5DilA9FZTGnQNpmZPswpp9pQHoZuJfPjg14tUknqZBqRDC+REhKL+Ur35sMKct+BAGr4rBg5r+ IGD+b9zkjsjk7xLnz2jkx5w6YFD3L3xkz4D373QFAK6bpgAOD7QMwPK6JSDuTwL8yUidSGD4j4z5 D+75i6IIrLz6QNr6iajGL7EDRN8DgECWEG4OT9ZTT9pxAHDoUAT+boAFD8Jt0EDURWJMAmaWiNo8 MI5NxOEEcAAFsIJG7gr1rsZHcIZHzQykMBA5j3Bg0CI4cCsCcC0DD7MGsDqf0D7dTe8KD85XamME z475L5b/MFhfD6KcMF48EGL65McNL7bUSKArMHbWaXZT4HKv5HUKpJMIaYZs5W8HJt54RfEI8JiU 0J0NxEKUUKLjIEAkhq4mbuiah3J3pDxXpzArRYcVDLLhCp8R0K4t7x0WUIamJCZMoN6ValyhaOBZ KWRLzvBSkOb4sOsFMPD6BgMKcWSqQHLXgBSeLXI1rfyvcHp7oHL2YBQowgggIA0KZW5kc3RyZWFt DQplbmRvYmoNCjE5IDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwN Ci9GMSA0IDAgUg0KL0YyIDEwIDAgUg0KL0YzIDExIDAgUg0KL0Y0IDEyIDAgUg0KPj4NCi9FeHRH U3RhdGUgPDwNCi9HUzEgNSAwIFINCj4+DQo+Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwNCi9MZW5n dGggMzAwNg0KL0ZpbHRlciAvTFpXRGVjb2RlDQo+Pg0Kc3RyZWFtDQqAEIqA0FC8jDEQQgqGaCDE YC4YDgQDCJwmHxEQDmHjKEDcaDYXDMbiAqG2CRQzwQhFgQC8jlOEGc5iAiliTyQxzcqHeCFsUEkn FQilInEUqCAiFIgkYqCkWjIcDQYjcUFI3mcynIQEsQCkZDMUGQykI5HkUl0qEqbi0Yi4YxoayQiT 0UDwyHIwmY6C00mU6Ga+HA4C03G+9jCHnQ8HQfU4ZDUZjMcT8hE0QEM3nI4ZkwnQ0m83We0wSRRC vxK2W64XKCCgjGUxHI6mGywkcjkcCkqGqCWwci4cZEZiAWjYb8AajeFXMFC2LjCFTwFT4ing4Gk5 GWZkE6mc6nM6bbcU4Y5IbDYUFsoGGsCAal3RWrm1PVDC4+cXefjawFRSdroGYXPIGQUBorq2QJA4 YwIK40DKNwQDmOAyjGNIzDyNI3DOEAwhAwrPDMNIxs6z8IDKO0HjoFkOBAJQ3jEEApjqMQ2jSOjP Q0mg3DIEAqjmrIQDa77wjEMsODENkjDoN8IwnCsLhAOg0M6EA9KzJjMvi3sAqg5KKio5gULeGrdN 4BQaog5UDNSt77P4FA2szI0PwtEUSNBDkbjkNIxDqOjtBBIsIxTDg2NBDY7xsNEowdDzDTrEbPNB FY7wdCEpSpE9CDeMYxjqOQ5wE3bezQGE1S/MK3htMq1rbNq4zA1q3hvVgFS4HEvTY1dYumFEAwGF C42BBUCMwNs4wgsQ2DTFDajavw0DeMg5xWMoXDOFwQDKNowjSNkVyE8FAyMOY6sEzM/jJAS0PkFt by8/1UvHUb+uJV1d3kHNa3ekddTdXifV/BAUBtYgUYMKkHOyEA0pmwoQOyOI6uxbdCDMzNGSMJIo CgEAoT2N0/q07IxjLZkMw3KUjDhkDw4iOrtPDJYQDsMNljIzslUaNKxZDGw8hAN4zQ40N2S2F0up HeLWhkxFa1LU9/VhMNNZDiEKDS68UxWwqtZVI9vZ/oOh6+OY8vBbcoyZZVmSAMMTRRq2Z0xl2sa1 qwwpnl+YjLHguBRi45VqFuoBjA2lgUFGmhjp808Nez66m1oyjwMI2jhJMVwtjNtbjusK7u8OG0c8 MqDuzI17VnA8i4FNRTNwnHcPN+mhlWqKal2gYBnfekVxft73+5mAwFgaR2HYAkDeO9NDlFe3hBje O4/DORSDIeaZtnmc4YOiZjCMWwjpoGZ7ZZuic7Qjv5RzkJaxEO+hB8ysrNozm35VGmBgGnG1Nx7u VeAoDmGNByz1shJaGjZ+Qb1AIfQiuYzYcmZKNfck8vqPIBwFDKitjDZUnJ1fjBlirDCZoZZqzcED gUIhvWe4Nwrs4AtNTIvSF7kFXpvOy3lSbGUIQKDmtEOobEeHZQkaBHjc1Gsseq1diTMQQKJSk+gr IcmMBjiMjZErr1SOyfy4lpqq16O4eC5KLypnetJhsvhADxUFgoIk8hgbCSspGXCkRIyHQxhsbyTN oT0WOPpasnREKkUSkzUqiJRaI0IBmUMHdRkVDuyJMzBF7hTgbIERCdkO7Ng2KhBA8p5izQWJafu7 5eDujcw0i5ABML0HpAgiUyFIAbgyvxgcn9cTMzvG0ben9Iz8zax9a/IJOyklLhokgGdRaHZMhlk2 GwNi43AhlhdFxxDigYL6lU/5NcY03hhU6GUOCOENodlieENSL4tHNhrNcjgMHbxpeE0wGLjF6P4l ZGtYAOWDMGCCkFCiUw3MNDa9dcSgmWBvDszx+MKpgPsQ7MSQieIkLkRmjVG77I8l9aspVB7nJgP1 NHKWNE7kFv9ajN6AMfXoNVPDRJO6l0mIdgrCBHgTlHyDpiCAKTdqOHhDMt2Ts63Yzci64o8s8Z8x ecNGd388oyPEWAQ6fpXgagwBRHJhcdVxosWfARt9BIUsYUMiNZYen2BoDqtxCEVg3LlW4khOdOZi yFXXSNd0pmlO0BjDNM0YnI18jAmYKgKp6K0XoQY4ZCiGAKN+gsipFLHgyIyRshANAZqln4SU1oNC IIxZKG42hnw5q1IMQixhDSLkSIoRQhxECJHJIhPyzFmiSEmqZKmv7kJsg1spDEt9TlcquPOSNgCB Y2IEIRHCNoSUOUFDmjacjDEIBtaA0KQcd0dwPRpAqczLQQTpRhRWWDLUgBkeXMdIyU5oQHufdR9r llyIUU+z+UleaSu0abSh/9Kkw3oW4hlDhM2vznbdduPsVlPo/RWVgq5eA4BoTtNBoEtDaLZejE+X ragQBrMLI4NKx2+hpZyGxoFHrqtAnPNWo07iOX8m7YGAN4onremioKKzl0krpBA39jDm2VMLdHd9 F6SQ2utXGiM77OpfqcrWoS5zlonuofYnh0anysMhgPixU+LnbTbpTjJMK5buwTZXeDGkUFFtfYvN B5dEE9J8T8doHWXHH4ud5GGqF+n+WJCMXG1ICiQK4OC5Ar4NCJK8OcRAjAVCcuJC4DI/dpiDkJJJ Y0toNyolx0WYgyJ/D/aPBRThEFdU8U9dBT84lAHBg4PyDQGU/MXV+IIQbQGlyCaDBroU1Oh7NnM0 7o3UWkdJ5+tRrgBWmdNnEOeDO35zNQmt1IpCnYRXPEzBaoUNmrdX6xqODLSWlNbkL1ycjXhbSvxk 2DonYeknj7G0tuTZILtNA005s05ZOtRbTp1MYEAQc4p9lxqu8QLTwM5BbDkOZoNuA21hrK/ViEza 23jY3XW52kWZ3yc05+7DW7E3fxPSugdlb22Zow4avNouJ35qZCAVA8oT1XiFZ4ZMSJ/4bw/b5UNx cV3LoQ4evbM7PNaV3eGgTi7m6Cc/b0MdY3CeBmIulnlgWUuYgTKNBXThyDW+wM0VKCrRWe0SDFF7 vXliXjS8gc75dolkVpvN8MCnZoWG8762nK46Wtfd/E7gZzwzBf3qTiZQPNRXdENzJcM5Sgc6Z1CK 7nSKgdhFs+E8TAgKxmbt1QFvJGYxehogeUpPszU92A54ZFZ2hgmEr89uRIG0DDWpYKJNwKDqz6aN zvM4c626n0b3y9FZMKaBbPhZRPR0juBHiyw1x0aAj8MZ2Q6G0fIkw64Y3Urmc53YOgcE/dklh99G 3qtv7Oxhnu46eLrPyO06nhb3YFnaDd8kGR4fdqGXExgFMbUahzBaRCSSXU+Q3ABkR4Zs/e+YjuBA iaZgR4pg38R+bkSY/WW2qEhWvunadoMi/O9mboieUswy92Zm96wykUSiDKmgYYbIYUSMk2e+vKyK bS9K7m7SnUwyzIowRYnOvCRexqSk/I78z6TM9kv8NazYDezcUSRyM6DoT24EzpCBA01oXq9mK+sG 1qz+580E6U0MBmkuP43WJw4+3c6M9fC05K3u0YLe1BDE5YroomQg1Qay1U2y/W+g+k+o5y28784l Cw3G4tC46EBs5S2A47DaBQ5BDLCw9g2RDQ5OMQBi0S2hEO5bDgJo2u1XB2xycwL8moXoBa1c4dD3 A0t1D9C04u6C3RC8QM0VEM0dDG2LDM5I3o2W2CKnDZFfDc1LEs5g5k2y5oxGZzD04ghiBmm05FD+ NId8PPC6BsjIYO0pEY3kvwBxGZFsYKhiBo8BGRFPEDFVGZFa0Y480hDJGjDPFo5NFsjI5W1HDep3 DkdC1WhbE/FC50ncKk560DFRGauNELHFEPETHNFm3rDTEhFZEnFzHbF22rEw2zE0hZE45xHo27GI 9Y1hHy2RH3EE1+N7Fc3bFjEXHPIJEeOg6IXrITEqp24BCazk4HF+cuiIuiNAJnE2x2b7GG2+sxIw 3lI1FVH7I7H/ITICz9Gk0xHRIKOg43HZJS39F6SM2zAZJvInFFIqaYBpCEVa8GcU3s6g/QeGuQWA OG6uJ+veuioyRywE/WuwREu07KzLB0zRB6ZmjwWWUISopaQ0QylqZAQ2ky61BadRB8UWTwDC74r1 JzCuTOlXCKcSZwW8aADEbyYaWyjkW1LyloKy68MyoKdGwECFBQDODSrWvcdOiC+WDS+aSCaAo2UI Zmw8eXA+o/BoasxoYbCjGzD6AUKMIIICDQplbmRzdHJlYW0NCmVuZG9iag0KMjIgMCBvYmoNCjw8 DQovUHJvY1NldCBbL1BERiAvVGV4dCBdDQovRm9udCA8PA0KL0YxIDQgMCBSDQovRjMgMTEgMCBS DQovRjQgMTIgMCBSDQovRjUgMTYgMCBSDQo+Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA1IDAgUg0K Pj4NCj4+DQplbmRvYmoNCjI0IDAgb2JqDQo8PA0KL0xlbmd0aCAxODMwDQovRmlsdGVyIC9MWldE ZWNvZGUNCj4+DQpzdHJlYW0NCoAQioDQULyMMRBCCoZoIMRgLhgOBAMInCYfERAOYeMoQNxoNhcM xuICobYJFDPBCEWBALyOU4QZzmICKWJPJDHNyod4IWxQSScVCKUicRSoICIUiCRioKRaMhwNBiNx QUjeZzKchASxAKRkMxQZDKQjkeRSXSoSpuLRiLhjGhrJCJPRQPDIcjCZjoLTSZToZr4cDgLTcb72 MIedDwdB9ThkNRmMxxPyETRAQzecjhmTCdDSbzdZ7TBJFEK/ErZbrhcoIKCMZTEcjqYbLCRyORwK SoaoJbByLhxkRmIBaNhvwBqN4VcwULYuMIVPAVPiKeDgaTkZZmQTqZzqczpttxThjkhsNhQWygYa wIBsXdFauaMRqLhoMBpEvOLvPxtYBSKJ21oxjeNo4DYvwyhYEA5jeEA6DQzsGDQMoQDGMI3BA64x jWEA0vCOo4BAMw5QLB8KQ0OQ0jcOisw9DMKK0MQ6jSNgyRWM4XBAEAkvCNKZjTAzMjpDDwwhCQ5x Q7I7L6O8PDo3TeOa+oYOUGiKio5gUBk/MooJKkrOItq3hguMstbFQzjQ8IwjuMI8hBDAyBArDwxj C0CjaMsWJmMQww5B8HT1HQkwYOoxDbD8TwqOEVRYEA1DeMQQDvD40UXEY3jYNg30qNwzziOg6RVG cWjmHUvSmiEwwDLUuBzVKKNTMkzVcGoYVSKgVNax4Y1Sgy4oUhgFJAHAauDMQXK+GKJTO5rn2anI FBQLgZP9X6DoSklhraG6ori5yIBgGzh2dANpBQJzDDSMw0wuzzQBAKQyjGNLrz28IWwsNi+0fCU9 jPFYyqzHERuwNtUhaHD+BoGQcyxWwZWxYNtoJYtjuG1Kvhk/9wsRaLW2ra7doIgyEWEhoXW8GlwO eGzlp1dF1M9dt3s/DIijtfCZ31RsVvDAkDQRFuE4WG2G4fVteMhidtIXizkWRjQZo5jtoJxkNrJH bGT4qBVu2+4mXP/c7W5ndl3M7m6SDyOEK31IM9Ruzoy6LhmHYhpYaablFiajjK243jlnY8jAqXRk Wt5Igts77sGWbFcQa4fc2sWns+a7VeImQw7z2beEAjOyNwxjRu2j7xpVpseGtY2TWj/y2GobVSGd lWMkdZtXZyfBoFzyBkFEr+AFCurZ4NCjCNsXziEA0MMMo2BBEsTTlBk9zmMMU5/SFJUD5r45KI0r 76GSN5fpPYiXFY1jfaoZBkmbwMzCsV0wOlOwz5PljuzI1sFRWgt+xmSxFafwwkr4Lgag0BuDZvLq zkqpTADFK7ukyuxTq81nyLAypzOyZsOR4QzGZUwnovzBX9qhRaG5G6n3mIQQqG0zIbkcI6BAFNFY Y0KhJfeDJ5YZw3sFDeHVIyDoWhuKywmCaV3VOyNy4uJbr3dpaLyi0rShYMoQR+91SYc1DqJVFB1B aGEPBtbkGlugIDCs0bSvBDL/Q3Q9PCGRQUMQ6ulToG8N4ZEdBIU6GVnQckFw8fgDJOa/A1oVgO4s FsUYmmPVhFBVcFIpQXd4Ch0q9EOv2hgCCGQcoaQuDEGWEZ2UeAgLuGlnT35OnkBiDEFD6w3Pth6/ J/Epn8PXfqGZTC7UEPODCn1gaGYNotj4CAIKGQyhtDCjV8KqkqyUkeDZXEkpowVTHFM1sa20M2Xj FuLwZmar9hFCSLRMw4B1M0G8OYZVCKGUQoqTsxYuKUUtL1TSnFPKgM6qMNKpTtKokZI52K1lfOLV lNmSyrgbMScWrpXi5G+NeYu1JwJkXBnMcKyBabiSuuLIM+Rrzj2WriBo5Q5jZXLrrczG5eS9F7Tk OJJ5usjGjNIgelto9E2nt+WNRZZRwmrLio4tRrVH0pUhactxlTYXCn5bI5ZdNLI2trZyzumc9Ggo HQS6enE03W0gCMxSntFXAVBBmldwjV3DtZZHUl8dS2UsrpKYgj9Ua20rjZN5DIVG2ugmXM0NlXnU 0FPO66CytaIg3dq7c5MlbFHTeE7944KC4vEeMDF5CcXlzFYK9oNhtCsILq2ggPD21Hy+ndKdNyj5 coRlWg1PUZYzxpDMwMMiflALxnmiUM52Q5kzDeGaZ4LXbFQsfNOJ6Uoo2Jdjb17ikVJzBSfagOgc 53xenikZFE9LpT2QhPhTanbPqiVJESgMSpJxMsNJFKVCTVULV4DeatcKyLDrMskr9aqNVscRUdbF Iqe0kcjXZmCAKpOYqqvFea9V7qPX0nqwj6VnJbOVTy/Df79VpwPRuqVHsA1ya/U1yFT68MyqpXxt jbqZtxg7GholNm74UVcDeh19sRX5amDRct/aiYfwBWLAVTK6YFBgZLE7ZsUuaZwzpPlMwwqbQYkR FqDy8BuDmh9m4c8J05BkDcGeGGoU/rPfu/hvb/VucVXDIdc6nHPJFkmvU3cmTIvNP+9DPIyqNO1l leNpUEhky7I8j1iKFWRwtWFKRRiCEBANCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNSAwIG9iag0KPDwN Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0NCi9Gb250IDw8DQovRjEgNCAwIFINCi9GNCAxMiAwIFIN Ci9GNSAxNiAwIFINCj4+DQovRXh0R1N0YXRlIDw8DQovR1MxIDUgMCBSDQo+Pg0KPj4NCmVuZG9i ag0KMjYgMCBvYmoNCjw8DQovVHlwZSAvSGFsZnRvbmUNCi9IYWxmdG9uZVR5cGUgMQ0KL0hhbGZ0 b25lTmFtZSAoRGVmYXVsdCkNCi9GcmVxdWVuY3kgNjANCi9BbmdsZSA0NQ0KL1Nwb3RGdW5jdGlv biAvUm91bmQNCj4+DQplbmRvYmoNCjUgMCBvYmoNCjw8DQovVHlwZSAvRXh0R1N0YXRlDQovU0Eg ZmFsc2UNCi9PUCBmYWxzZQ0KL0hUIC9EZWZhdWx0DQo+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PA0K L1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YxDQovQmFzZUZvbnQgL1RpbWVz LVJvbWFuDQo+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAv VHlwZTENCi9OYW1lIC9GMg0KL0Jhc2VGb250IC9UaW1lcy1Cb2xkDQo+Pg0KZW5kb2JqDQoxMSAw IG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMw0KL0Jhc2VG b250IC9IZWx2ZXRpY2EtQm9sZA0KPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8DQovVHlwZSAvRm9u dA0KL1N1YnR5cGUgL1R5cGUxDQovTmFtZSAvRjQNCi9FbmNvZGluZyAyNyAwIFINCi9CYXNlRm9u dCAvVGltZXMtUm9tYW4NCj4+DQplbmRvYmoNCjE2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9T dWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0Y1DQovQmFzZUZvbnQgL1N5bWJvbA0KPj4NCmVuZG9iag0K MjcgMCBvYmoNCjw8DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbIDAvZ3JhdmUvYWN1 dGUvY2lyY3VtZmxleC90aWxkZS9tYWNyb24vYnJldmUvZG90YWNjZW50L2RpZXJlc2lzDQovcmlu Zy9jZWRpbGxhL2h1bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24vZG90bGVzc2kvZmkvZmwNCi9Mc2xh c2gvbHNsYXNoL1pjYXJvbi96Y2Fyb24vbWludXMgMzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTMw L3F1b3Rlc2luZ2xiYXNlDQovZmxvcmluL3F1b3RlZGJsYmFzZS9lbGxpcHNpcy9kYWdnZXIvZGFn Z2VyZGJsL2NpcmN1bWZsZXgvcGVydGhvdXNhbmQvU2Nhcm9uDQovZ3VpbHNpbmdsbGVmdC9PRSAx NDUvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQvYnVsbGV0 L2VuZGFzaA0KL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nhcm9uL2d1aWxzaW5nbHJpZ2h0L29l IDE1OS9ZZGllcmVzaXMgMTY0L2N1cnJlbmN5DQogMTY2L2Jyb2tlbmJhciAxNjgvZGllcmVzaXMv Y29weXJpZ2h0L29yZGZlbWluaW5lIDE3Mi9sb2dpY2Fsbm90L2h5cGhlbi9yZWdpc3RlcmVkL21h Y3Jvbg0KL2RlZ3JlZS9wbHVzbWludXMvdHdvc3VwZXJpb3IvdGhyZWVzdXBlcmlvci9hY3V0ZS9t dSAxODMvcGVyaW9kY2VudGVyZWQvY2VkaWxsYQ0KL29uZXN1cGVyaW9yL29yZG1hc2N1bGluZSAx ODgvb25lcXVhcnRlci9vbmVoYWxmL3RocmVlcXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNp cmN1bWZsZXgNCi9BdGlsZGUvQWRpZXJlc2lzL0FyaW5nL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1 dGUvRWNpcmN1bWZsZXgNCi9FZGllcmVzaXMvSWdyYXZlL0lhY3V0ZS9JY2lyY3VtZmxleC9JZGll cmVzaXMvRXRoL050aWxkZS9PZ3JhdmUNCi9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVy ZXNpcy9tdWx0aXBseS9Pc2xhc2gvVWdyYXZlL1VhY3V0ZQ0KL1VjaXJjdW1mbGV4L1VkaWVyZXNp cy9ZYWN1dGUvVGhvcm4vZ2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4DQovYXRp bGRlL2FkaWVyZXNpcy9hcmluZy9hZS9jY2VkaWxsYS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4 DQovZWRpZXJlc2lzL2lncmF2ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGls ZGUvb2dyYXZlDQovb2FjdXRlL29jaXJjdW1mbGV4L290aWxkZS9vZGllcmVzaXMvZGl2aWRlL29z bGFzaC91Z3JhdmUvdWFjdXRlDQovdWNpcmN1bWZsZXgvdWRpZXJlc2lzL3lhY3V0ZS90aG9ybi95 ZGllcmVzaXMNCl0NCj4+DQplbmRvYmoNCjEgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVu dCA2IDAgUg0KL1Jlc291cmNlcyAzIDAgUg0KL0NvbnRlbnRzIDIgMCBSDQo+Pg0KZW5kb2JqDQo3 IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNiAwIFINCi9SZXNvdXJjZXMgOSAwIFIN Ci9Db250ZW50cyA4IDAgUg0KPj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K L1BhcmVudCA2IDAgUg0KL1Jlc291cmNlcyAxNSAwIFINCi9Db250ZW50cyAxNCAwIFINCj4+DQpl bmRvYmoNCjE3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNiAwIFINCi9SZXNvdXJj ZXMgMTkgMCBSDQovQ29udGVudHMgMTggMCBSDQo+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwNCi9U eXBlIC9QYWdlDQovUGFyZW50IDYgMCBSDQovUmVzb3VyY2VzIDIyIDAgUg0KL0NvbnRlbnRzIDIx IDAgUg0KPj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA2IDAg Ug0KL1Jlc291cmNlcyAyNSAwIFINCi9Db250ZW50cyAyNCAwIFINCj4+DQplbmRvYmoNCjYgMCBv YmoNCjw8DQovVHlwZSAvUGFnZXMNCi9LaWRzIFsxIDAgUiA3IDAgUiAxMyAwIFIgMTcgMCBSIDIw IDAgUiAyMyAwIFJdDQovQ291bnQgNg0KL01lZGlhQm94IFswIDAgNjEyIDc5Ml0NCj4+DQplbmRv YmoNCjI4IDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdlcyA2IDAgUg0KPj4NCmVuZG9i ag0KMjkgMCBvYmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5OTgwMjE3MDc0MzA4KQ0KL1Byb2R1 Y2VyIChcMzc2XDM3N1wwMDBBXDAwMGNcMDAwclwwMDBvXDAwMGJcMDAwYVwwMDB0XDAwMCBcMDAw RFwwMDBpXDAwMHNcMDAwdFwwMDBpXDAwMGxcMDAwbFwwMDBlXDAwMHJcMDAwIFwwMDAzXDAwMC5c MDAwMFwwMDAxXDAwMCBcMDAwZlwwMDBvXDAwMHJcMDAwIFwwMDBXXDAwMGlcMDAwblwwMDBkXDAw MG9cMDAwd1wwMDBzKQ0KL0NyZWF0b3IgKFdpbmRvd3MgTlQgNC4wKQ0KL1RpdGxlIChVbnRpdGxl ZCBEb2N1bWVudCkNCj4+DQplbmRvYmoNCnhyZWYNCjAgMzANCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAxODAzNyAwMDAwMCBuDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDE4MjMgMDAwMDAg bg0KMDAwMDAxNjI4OSAwMDAwMCBuDQowMDAwMDE2MjEwIDAwMDAwIG4NCjAwMDAwMTg1NzcgMDAw MDAgbg0KMDAwMDAxODEyNSAwMDAwMCBuDQowMDAwMDAxOTI4IDAwMDAwIG4NCjAwMDAwMDQ4MjAg MDAwMDAgbg0KMDAwMDAxNjM3OSAwMDAwMCBuDQowMDAwMDE2NDY5IDAwMDAwIG4NCjAwMDAwMTY1 NjMgMDAwMDAgbg0KMDAwMDAxODIxMyAwMDAwMCBuDQowMDAwMDA0OTYxIDAwMDAwIG4NCjAwMDAw MDc3NzYgMDAwMDAgbg0KMDAwMDAxNjY3MiAwMDAwMCBuDQowMDAwMDE4MzA0IDAwMDAwIG4NCjAw MDAwMDc5MTggMDAwMDAgbg0KMDAwMDAxMDY2OSAwMDAwMCBuDQowMDAwMDE4Mzk1IDAwMDAwIG4N CjAwMDAwMTA4MTEgMDAwMDAgbg0KMDAwMDAxMzg5NiAwMDAwMCBuDQowMDAwMDE4NDg2IDAwMDAw IG4NCjAwMDAwMTQwMzggMDAwMDAgbg0KMDAwMDAxNTk0NyAwMDAwMCBuDQowMDAwMDE2MDc3IDAw MDAwIG4NCjAwMDAwMTY3NTggMDAwMDAgbg0KMDAwMDAxODcwMCAwMDAwMCBuDQowMDAwMDE4NzU2 IDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSAzMA0KL1Jvb3QgMjggMCBSDQovSW5mbyAyOSAw IFINCi9JRCBbPDYwNmZjMjhmMTM3ZGY2OTExZGE2YzA3NTcxMDdlY2VmPjw2MDZmYzI4ZjEzN2Rm NjkxMWRhNmMwNzU3MTA3ZWNlZj5dDQo+Pg0Kc3RhcnR4cmVmDQoxOTA2Mw0KJSVFT0YNCg== --Boundary=_0.0_=5030100017545030-- From ipp-owner@pwg.org Tue Feb 17 10:05:42 1998 Delivery-Date: Tue, 17 Feb 1998 10:05:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03380 for ; Tue, 17 Feb 1998 10:05:41 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA06596 for ; Tue, 17 Feb 1998 10:08:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA11517 for ; Tue, 17 Feb 1998 10:05:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 10:01:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10983 for ipp-outgoing; Tue, 17 Feb 1998 10:01:00 -0500 (EST) From: Roger K Debry To: Subject: IPP> suggested workplan - host to device protocol Message-ID: <5030100017545786000002L062*@MHS> Date: Tue, 17 Feb 1998 10:00:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA03380 In order to move the ball on the host to device discussion, I'd like to propose the following: Assertions: (1) IPP, as it is currently defined, is the correct protocol for client to server, across the Internet. (2) IPP, as it is currently defined, is the correct protocol for client to server, across an Intranet (3) IPP, as it is currently defined, is the correct protocol between a server and a printer which contains an imbedded server. Therefore, let's focus on the open issue: Do we need a different protocol between a print server and a "simple" printer? Requirements (largely from P. Moore's note) 1. Low level discovery 2. Discovery of device capabilities 3. Peer queuing 4. Machine readable asynchronous notifications 5. Security 6. Manage device settings 7. Transport neutral 8. PDL neutral 9. Capable of recovery - redriving the data stream if necessary 10. Reporting of device errors 11. Fast, wide delivery channel for print data Proposed Work Plan 1. Agree on the problem statement (we need to address server to simple printer case - the rest are okay with IPP as it stands) 2. Complete a requirements statement (as we did with IPP v1.0) that is complete and concrete - get away from hand waving 3. Use the current IPP Model and Semantics document plus the notifications work as the starting point. 4. Add new attributes or operations, as required, to meet requirements, or understand clearly why this will not work. 5. Define a new protocol mapping, if required, to meet server to device requirements Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Feb 17 10:31:16 1998 Delivery-Date: Tue, 17 Feb 1998 10:31:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA04173 for ; Tue, 17 Feb 1998 10:31:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA06757 for ; Tue, 17 Feb 1998 10:33:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA12165 for ; Tue, 17 Feb 1998 10:31:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 10:25:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA11631 for ipp-outgoing; Tue, 17 Feb 1998 10:25:56 -0500 (EST) From: don@lexmark.com Message-Id: <199802171525.AA13181@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 17 Feb 1998 10:23:46 -0500 Subject: IPP> Re: Suggested workplan - host to device protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Roger deBry said: >Assertions: > >(1) IPP, as it is currently defined, is the correct protocol > for client to server, across the Internet. > >(2) IPP, as it is currently defined, is the correct protocol > for client to server, across an Intranet > >(3) IPP, as it is currently defined, is the correct protocol > between a server and a printer which contains an > imbedded server. I can easily agree with Roger on #1 and #2. I think where the problem lies is with #3. I am not sure how broad the definition of "imbedded server" is? Does that mean imbedded IPP server or any server? All of my network printers today have available what we call an Internal Print Server which supports a wide range of protocols. Is that what you mean Roger? I don't think so. I think the definition needs to be "imbedded, spooling print server." And even then, I think we have lost a huge amount of control and status information that is available from TIPSI or even SNMP. Maybe we need to define some kind of passthrough for IPP that allows the control and status information for the down and dirty hardware to be retrieved and set through IPP?? Comments? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Feb 17 10:38:24 1998 Delivery-Date: Tue, 17 Feb 1998 10:38:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA04422 for ; Tue, 17 Feb 1998 10:38:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA06788 for ; Tue, 17 Feb 1998 10:41:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA12760 for ; Tue, 17 Feb 1998 10:38:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 10:33:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA12231 for ipp-outgoing; Tue, 17 Feb 1998 10:33:44 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> Re: Suggested workplan - host to device protocol Date: Tue, 17 Feb 1998 07:33:52 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I think Roger (correct if I'm wrong, Roger) meant that IPP, as currently defined, is the correct solution for server-to-printer protocol, IF the printer device already has an embedded web server, like would probably be used for overall management. And if this is the assertion, then I tend to agree with it, although it depends on what the exact *requirements* are for server-to-printer protocol. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Tuesday, February 17, 1998 7:24 AM To: ipp@pwg.org Subject: IPP> Re: Suggested workplan - host to device protocol Roger deBry said: >Assertions: > >(1) IPP, as it is currently defined, is the correct protocol > for client to server, across the Internet. > >(2) IPP, as it is currently defined, is the correct protocol > for client to server, across an Intranet > >(3) IPP, as it is currently defined, is the correct protocol > between a server and a printer which contains an > imbedded server. I can easily agree with Roger on #1 and #2. I think where the problem lies is with #3. I am not sure how broad the definition of "imbedded server" is? Does that mean imbedded IPP server or any server? All of my network printers today have available what we call an Internal Print Server which supports a wide range of protocols. Is that what you mean Roger? I don't think so. I think the definition needs to be "imbedded, spooling print server." And even then, I think we have lost a huge amount of control and status information that is available from TIPSI or even SNMP. Maybe we need to define some kind of passthrough for IPP that allows the control and status information for the down and dirty hardware to be retrieved and set through IPP?? Comments? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Feb 17 12:21:16 1998 Delivery-Date: Tue, 17 Feb 1998 12:21:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA06997 for ; Tue, 17 Feb 1998 12:21:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07742 for ; Tue, 17 Feb 1998 12:23:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA13571 for ; Tue, 17 Feb 1998 12:21:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 12:16:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13040 for ipp-outgoing; Tue, 17 Feb 1998 12:16:46 -0500 (EST) Date: Tue, 17 Feb 1998 09:21:58 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9802171721.AA04648@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rdebry@us.ibm.com Subject: Re: IPP> Notification Requirements Sender: ipp-owner@pwg.org HELP, Could you folks PLEASE stop sending PDF and Word files as enclosures (which should not be happening on an IETF-chartered working group list) and start regularly posting them to the PWG server and mailing a pointer? I've missed the context of a fair amount of discussion lately. Also, when PDF is the most 'neutral' format posted (and not flat text), some of us have great difficulties keeping up. Roger, I haven't even looked at my scratch file copy of your note yet, so maybe you sent a pointer. Please lighten up on the huge opaque enclosures. Some of us only get mail through a dial-up interface. Thanks, - Ira McDonald High North (consultant at Xerox) From ipp-owner@pwg.org Tue Feb 17 12:28:50 1998 Delivery-Date: Tue, 17 Feb 1998 12:28:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA07142 for ; Tue, 17 Feb 1998 12:28:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07782 for ; Tue, 17 Feb 1998 12:31:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA14156 for ; Tue, 17 Feb 1998 12:28:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 12:24:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13654 for ipp-outgoing; Tue, 17 Feb 1998 12:24:51 -0500 (EST) From: don@lexmark.com Message-Id: <199802171724.AA23295@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: imcdonal@eso.mc.xerox.com Cc: Ipp@pwg.org, Rdebry@Us.Ibm.Com Date: Tue, 17 Feb 1998 12:24:11 -0500 Subject: Re: IPP> Notification Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Sorry Ira, I disagree. I think attaching the file AND including a pointer to its location on the ftp server is the best approach. That way if you can look at it from your e-mail directly you can, otherwise you can retrieve it from the server. Almost all the e-mail software I am familiar with allows you to specify whether an attachment is downloaded or not when you get the mail. Don To: ipp%pwg.org@interlock.lexmark.com, rdebry%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Notification Requirements HELP, Could you folks PLEASE stop sending PDF and Word files as enclosures (which should not be happening on an IETF-chartered working group list) and start regularly posting them to the PWG server and mailing a pointer? I've missed the context of a fair amount of discussion lately. Also, when PDF is the most 'neutral' format posted (and not flat text), some of us have great difficulties keeping up. Roger, I haven't even looked at my scratch file copy of your note yet, so maybe you sent a pointer. Please lighten up on the huge opaque enclosures. Some of us only get mail through a dial-up interface. Thanks, - Ira McDonald High North (consultant at Xerox) From ipp-owner@pwg.org Tue Feb 17 12:59:07 1998 Delivery-Date: Tue, 17 Feb 1998 12:59:07 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA07510 for ; Tue, 17 Feb 1998 12:59:06 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08051 for ; Tue, 17 Feb 1998 13:01:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA14807 for ; Tue, 17 Feb 1998 12:59:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 12:55:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14306 for ipp-outgoing; Tue, 17 Feb 1998 12:55:13 -0500 (EST) From: Roger K Debry To: Subject: IPP> I-D ACTION:draft-cohen-http-ext-postal-00.txt Message-ID: <5030100017554054000002L042*@MHS> Date: Tue, 17 Feb 1998 12:53:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA07510 In case you did not notice this, Josh Cohen and a crowd of other Microsoft folks have published an Internet Draft on overloading POST. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/17/98 10:52 AM --------------------------- Carl Kugler 02/17/98 10:11 AM To: Steve Gebert/Boulder/IBM, Roger K Debry/Boulder/IBM, Harry Lewis/Boulder/IBM, Keith Carter/Austin/IBM cc: From: Carl Kugler/Boulder/IBM @ IBMUS Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt Have you seen Josh's new Internet-Draft? For those unfamiliar with the issue at hand, IPP, the Internet Printing Protocol, has submitted their protocol for last call which provides print functionality over HTTP. To encode the protocol, a binary protocol payload is transmitted as the body of a POST. ... Our recommendation is in part philosophical in that we believe that new methods are a more clean way to deal with new functionality. However, our most pressing reason is the security consequences of overloading POST. ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 02/17/98 10:08 AM --------------------------- scoya@cnri.reston.va.us on 02/17/98 06:32:54 AM Please respond to Internet-Drafts@ns.ietf.org @ internet To: IETF-Announce@ns.ietf.org @ internet cc: Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Don't Go Postal - An argument against improperly overloading the HTTP POST Method Author(s) : J. Cohen et al. Filename : draft-cohen-http-ext-postal-00.txt Pages : Date : 16-Feb-98 As time goes on, more and more groups are extending HTTP's functionality. In using HTTP, a decision is made to either use a new method name for new functionality or to overload an existing one such as POST. Our belief is that in most cases, overloading existing method names, with POST as a particularly troublesome example, is a bad idea. We, as a group of individuals, suggest that the default requirement for new HTTP functionality must be to create a new method name. 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-cohen-http-ext-postal-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-cohen-http-ext-postal-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. -------------------------------------------------------------------------------- ENCODING mime FILE /internet-drafts/draft-cohen-http-ext-postal-00.txt -------------------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 17 13:08:15 1998 Delivery-Date: Tue, 17 Feb 1998 13:08:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07678 for ; Tue, 17 Feb 1998 13:08:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08097 for ; Tue, 17 Feb 1998 13:10:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15898 for ; Tue, 17 Feb 1998 13:08:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:01:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14902 for ipp-outgoing; Tue, 17 Feb 1998 13:01:01 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Notification Requirements Message-ID: <5030100017554358000002L082*@MHS> Date: Tue, 17 Feb 1998 12:59:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA07678 Too bad the Hypermail archives don't do something useful with the attachments. ipp-owner@pwg.org on 02/17/98 10:27:07 AM Please respond to ipp-owner@pwg.org @ internet To: imcdonal@eso.mc.xerox.com @ internet cc: Roger K Debry/Boulder/IBM@ibmus, Ipp@pwg.org @ internet Subject: Re: IPP> Notification Requirements Sorry Ira, I disagree. I think attaching the file AND including a pointer to its location on the ftp server is the best approach. That way if you can look at it from your e-mail directly you can, otherwise you can retrieve it from the server. Almost all the e-mail software I am familiar with allows you to specify whether an attachment is downloaded or not when you get the mail. Don To: ipp%pwg.org@interlock.lexmark.com, rdebry%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Notification Requirements HELP, Could you folks PLEASE stop sending PDF and Word files as enclosures (which should not be happening on an IETF-chartered working group list) and start regularly posting them to the PWG server and mailing a pointer? I've missed the context of a fair amount of discussion lately. Also, when PDF is the most 'neutral' format posted (and not flat text), some of us have great difficulties keeping up. Roger, I haven't even looked at my scratch file copy of your note yet, so maybe you sent a pointer. Please lighten up on the huge opaque enclosures. Some of us only get mail through a dial-up interface. Thanks, - Ira McDonald High North (consultant at Xerox) From ipp-owner@pwg.org Tue Feb 17 13:17:24 1998 Delivery-Date: Tue, 17 Feb 1998 13:17:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07804 for ; Tue, 17 Feb 1998 13:17:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08153 for ; Tue, 17 Feb 1998 13:20:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17221 for ; Tue, 17 Feb 1998 13:17:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:05:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15511 for ipp-outgoing; Tue, 17 Feb 1998 13:05:20 -0500 (EST) Date: Tue, 17 Feb 1998 10:05:03 PST From: David_Kellerman@nls.com To: Ipp@pwg.org Message-ID: <009C1F13.FA8C103A.9@nls.com> Subject: Re: IPP> Notification Requirements (enclosures, non-text mail) Sender: ipp-owner@pwg.org Ira, Don, I belong to the mailer-impaired group, too. And I'd really appreciate keeping messages in flat text format (which I thought was the IETF idea). Sure, I can accomodate having the major documents in PDF format (either as attachments, or as pointers) -- they don't change that often, and I can appreciate the benefits. But the opaque enclosures really mess up the discussion threads (not only reading, but citing text in responses, searching, etc.). By the way, I heard the same complaint last week from a trade press editor who had tried to review the IPP mail for information on the working group activities. He found it very frustrating. Thanks, Ira, for bringing up this topic. :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From: don@lexmark.com To: imcdonal@eso.mc.xerox.com CC: Ipp@pwg.org, Rdebry@Us.Ibm.Com Date: Tue, 17 Feb 1998 12:24:11 -0500 Subject: Re: IPP> Notification Requirements Sorry Ira, I disagree. I think attaching the file AND including a pointer to its location on the ftp server is the best approach. That way if you can look at it from your e-mail directly you can, otherwise you can retrieve it from the server. Almost all the e-mail software I am familiar with allows you to specify whether an attachment is downloaded or not when you get the mail. Don To: ipp%pwg.org@interlock.lexmark.com, rdebry%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Notification Requirements HELP, Could you folks PLEASE stop sending PDF and Word files as enclosures (which should not be happening on an IETF-chartered working group list) and start regularly posting them to the PWG server and mailing a pointer? I've missed the context of a fair amount of discussion lately. Also, when PDF is the most 'neutral' format posted (and not flat text), some of us have great difficulties keeping up. Roger, I haven't even looked at my scratch file copy of your note yet, so maybe you sent a pointer. Please lighten up on the huge opaque enclosures. Some of us only get mail through a dial-up interface. Thanks, - Ira McDonald High North (consultant at Xerox) From ipp-owner@pwg.org Tue Feb 17 13:18:49 1998 Delivery-Date: Tue, 17 Feb 1998 13:18:54 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07871 for ; Tue, 17 Feb 1998 13:18:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08162 for ; Tue, 17 Feb 1998 13:21:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17417 for ; Tue, 17 Feb 1998 13:18:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:07:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15744 for ipp-outgoing; Tue, 17 Feb 1998 13:07:06 -0500 (EST) Message-ID: <8B57882C41A0D1118F7100805F9F68B507844B@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'ietf-http-ext@w3.org'" , "'http-wg@cuckoo.hpl.hp.com'" , "'ipp@pwg.org'" Subject: IPP> FW: I-D ACTION:draft-cohen-http-ext-postal-00.txt Date: Tue, 17 Feb 1998 10:06:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org -----Original Message----- From: Internet-Drafts@ns.ietf.org [mailto:Internet-Drafts@ns.ietf.org] Sent: Tuesday, February 17, 1998 4:10 AM To: IETF-Announce@ns.ietf.org Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Don't Go Postal - An argument against improperly overloading the HTTP POST Method Author(s) : J. Cohen et al. Filename : draft-cohen-http-ext-postal-00.txt Pages : Date : 16-Feb-98 As time goes on, more and more groups are extending HTTP's functionality. In using HTTP, a decision is made to either use a new method name for new functionality or to overload an existing one such as POST. Our belief is that in most cases, overloading existing method names, with POST as a particularly troublesome example, is a bad idea. We, as a group of individuals, suggest that the default requirement for new HTTP functionality must be to create a new method name. 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-cohen-http-ext-postal-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-cohen-http-ext-postal-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. ----- To: Subject: Date: Tue, 17 Feb 1998 10:06:31 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) begin 600 ATT25606.txt M0V]N=&5N="UT>7!E.B!M97-S86=E+V5X=&5R;F%L+6)O9'D[#0H)86-C97-S M+71Y<&4](FUA:6PM7!E.B!T97AT+W!L86EN#0I#;VYT M96YT+4E$.@D\,3DY.#`R,38Q-#$W,3,N22U$0&EE=&8N;W)G/@T*#0I%3D-/ M1$E.1R!M:6UE#0I&24Q%("]I;G1E'0M<&]S=&%L+3`P+G1X=`T* ` end begin 600 draft-cohen-http-ext-postal-00.url M6TEN=&5R;F5T4VAO, ipp@pwg.org Subject: RE: IPP> I-D ACTION:draft-cohen-http-ext-postal-00.txt Date: Tue, 17 Feb 1998 10:08:35 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org its not just microsoft. Scott lawrence from agranat systems, an embedded web server vendor is listed as a co-author as well. In addition, while they havent been listed as co-authors, inktomi (cache vendor), netscape, have voiced support for that argument. > -----Original Message----- > From: Roger K Debry [mailto:rdebry@us.ibm.com] > Sent: Tuesday, February 17, 1998 9:54 AM > To: ipp@pwg.org > Subject: IPP> I-D ACTION:draft-cohen-http-ext-postal-00.txt > > > In case you did not notice this, Josh Cohen and a crowd of other > Microsoft folks have published an Internet Draft on overloading POST. > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > > > ---------------------- Forwarded by Roger K Debry/Boulder/IBM > on 02/17/98 10:52 > AM --------------------------- > > > Carl Kugler > 02/17/98 10:11 AM > To: Steve Gebert/Boulder/IBM, Roger K Debry/Boulder/IBM, Harry > Lewis/Boulder/IBM, Keith Carter/Austin/IBM > cc: > From: Carl Kugler/Boulder/IBM @ IBMUS > Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt > > > Have you seen Josh's new Internet-Draft? > > For those unfamiliar with the issue at hand, IPP, the Internet > Printing Protocol, has submitted their protocol for last call which > provides print functionality over HTTP. To encode the protocol, a > binary protocol payload is transmitted as the body of a POST. > ... > Our recommendation is in part philosophical in that we believe that > new methods are a more clean way to deal with new functionality. > However, our most pressing reason is the security consequences of > overloading POST. > > ---------------------- Forwarded by Carl Kugler/Boulder/IBM > on 02/17/98 10:08 > AM --------------------------- > > > scoya@cnri.reston.va.us on 02/17/98 06:32:54 AM > Please respond to Internet-Drafts@ns.ietf.org @ internet > To: IETF-Announce@ns.ietf.org @ internet > cc: > Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Don't Go Postal - An argument against > improperly overloading the HTTP POST Method > Author(s) : J. Cohen et al. > Filename : draft-cohen-http-ext-postal-00.txt > Pages : > Date : 16-Feb-98 > > As time goes on, more and more groups are extending HTTP's > functionality. In > using HTTP, a decision is made to either use a new method name for new > functionality or to overload an existing one such as POST. > Our belief is that > in most cases, overloading existing method names, with POST > as a particularly > troublesome example, is a bad idea. We, as a group of > individuals, suggest > that the default requirement for new HTTP functionality must > be to create a new > method name. > > 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-cohen-http-ext-postal-00.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-cohen-http-ext-postal-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. > -------------------------------------------------------------- > ------------------ > ENCODING mime > FILE /internet-drafts/draft-cohen-http-ext-postal-00.txt > -------------------------------------------------------------- > ------------------ > > > > > > > > > From ipp-owner@pwg.org Tue Feb 17 13:25:13 1998 Delivery-Date: Tue, 17 Feb 1998 13:25:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08029 for ; Tue, 17 Feb 1998 13:25:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08202 for ; Tue, 17 Feb 1998 13:27:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18306 for ; Tue, 17 Feb 1998 13:25:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:19:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17440 for ipp-outgoing; Tue, 17 Feb 1998 13:19:01 -0500 (EST) From: don@lexmark.com Message-Id: <199802171818.AA27096@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: David_Kellerman@nls.com Cc: Ipp@pwg.org Date: Tue, 17 Feb 1998 13:18:02 -0500 Subject: Re: IPP> Notification Requirements (enclosures, non-text mail) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org My problem with embedding ASCII text is that from an e-mail perspective I have no control over whether of not the text is downloaded. If the text is a couple of pages then OK with e-mailing the entire model document around as ASCII text is flat unacceptable. If you are going to mail ASCII text around, please attach is and not include it so we have control over whether it is downloaded or not. Don To: Ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Notification Requirements (enclosures, non-text mail) Ira, Don, I belong to the mailer-impaired group, too. And I'd really appreciate keeping messages in flat text format (which I thought was the IETF idea). Sure, I can accomodate having the major documents in PDF format (either as attachments, or as pointers) -- they don't change that often, and I can appreciate the benefits. But the opaque enclosures really mess up the discussion threads (not only reading, but citing text in responses, searching, etc.). By the way, I heard the same complaint last week from a trade press editor who had tried to review the IPP mail for information on the working group activities. He found it very frustrating. Thanks, Ira, for bringing up this topic. :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From: don@lexmark.com To: imcdonal@eso.mc.xerox.com CC: Ipp@pwg.org, Rdebry@Us.Ibm.Com Date: Tue, 17 Feb 1998 12:24:11 -0500 Subject: Re: IPP> Notification Requirements Sorry Ira, I disagree. I think attaching the file AND including a pointer to its location on the ftp server is the best approach. That way if you can look at it from your e-mail directly you can, otherwise you can retrieve it from the server. Almost all the e-mail software I am familiar with allows you to specify whether an attachment is downloaded or not when you get the mail. Don To: ipp%pwg.org@interlock.lexmark.com, rdebry%us.ibm.com@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Notification Requirements HELP, Could you folks PLEASE stop sending PDF and Word files as enclosures (which should not be happening on an IETF-chartered working group list) and start regularly posting them to the PWG server and mailing a pointer? I've missed the context of a fair amount of discussion lately. Also, when PDF is the most 'neutral' format posted (and not flat text), some of us have great difficulties keeping up. Roger, I haven't even looked at my scratch file copy of your note yet, so maybe you sent a pointer. Please lighten up on the huge opaque enclosures. Some of us only get mail through a dial-up interface. Thanks, - Ira McDonald High North (consultant at Xerox) From ipp-owner@pwg.org Tue Feb 17 13:43:01 1998 Delivery-Date: Tue, 17 Feb 1998 13:43:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08356 for ; Tue, 17 Feb 1998 13:42:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08266 for ; Tue, 17 Feb 1998 13:45:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18962 for ; Tue, 17 Feb 1998 13:42:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:38:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18435 for ipp-outgoing; Tue, 17 Feb 1998 13:38:53 -0500 (EST) Message-Id: <3.0.1.32.19980217103435.00bea430@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Feb 1998 10:34:35 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - draft-ietf-grip-isp-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, This document contains a lot of useful information about how to implement security in general. Carl-Uno --- >To: IETF-Announce:; >Cc: grip-wg@uu.net >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-grip-isp-03.txt >Date: Tue, 17 Feb 1998 04:05:13 PST >Sender: scoya@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the G and R for Security Incident Processing Working Group of the IETF. > > Title : Security Expectations for Internet Service Providers > Author(s) : T. Killalea > Filename : draft-ietf-grip-isp-03.txt > Pages : 30 > Date : 16-Feb-98 > >The purpose of this document is to express the general Internet community's expectations of Internet Service Providers (ISPs) with respect to security. > >It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers. > >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-grip-isp-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-grip-isp-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-grip-isp-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. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 17 13:53:17 1998 Delivery-Date: Tue, 17 Feb 1998 13:53:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08531 for ; Tue, 17 Feb 1998 13:53:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08297 for ; Tue, 17 Feb 1998 13:55:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19588 for ; Tue, 17 Feb 1998 13:53:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 13:49:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19070 for ipp-outgoing; Tue, 17 Feb 1998 13:49:22 -0500 (EST) Message-Id: <3.0.1.32.19980217104437.00bee250@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Feb 1998 10:44:37 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> PRO - draft-cohen-http-ext-postal-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Josh Cohen has written his own little document arguing against the use of POST in general, but taking IPP as an example. Carl-Uno -- >To: IETF-Announce@ns.ietf.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt >Date: Tue, 17 Feb 1998 04:09:58 PST >Sender: scoya@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Don't Go Postal - An argument against > improperly overloading the HTTP POST Method > Author(s) : J. Cohen et al. > Filename : draft-cohen-http-ext-postal-00.txt > Pages : > Date : 16-Feb-98 > >As time goes on, more and more groups are extending HTTP's functionality. In using HTTP, a decision is made to either use a new method name for new functionality or to overload an existing one such as POST. Our belief is that in most cases, overloading existing method names, with POST as a particularly troublesome example, is a bad idea. We, as a group of individuals, suggest that the default requirement for new HTTP functionality must be to create a new method name. > >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-cohen-http-ext-postal-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-cohen-http-ext-postal-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. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 17 14:54:51 1998 Delivery-Date: Tue, 17 Feb 1998 14:54:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA09853 for ; Tue, 17 Feb 1998 14:54:49 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA08819 for ; Tue, 17 Feb 1998 14:57:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21507 for ; Tue, 17 Feb 1998 14:54:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 14:47:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20403 for ipp-outgoing; Tue, 17 Feb 1998 14:46:54 -0500 (EST) From: Roger K Debry To: Subject: IPP> Notification Requirements Document Message-ID: <5030100017559159000002L092*@MHS> Date: Tue, 17 Feb 1998 14:45:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA09853 The subject document has now been posted to the PWG ftp site. It can be found at: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/notify-req-00.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/notify-req-00.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/notify-req-00.txt Carl-Uno had suggested a new directory, but I had already moved the files to this location when I got his voice-mail. I guess we can create a new directory later on. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Tue Feb 17 17:01:12 1998 Delivery-Date: Tue, 17 Feb 1998 17:01:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA11996 for ; Tue, 17 Feb 1998 17:01:12 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09732 for ; Tue, 17 Feb 1998 17:03:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22375 for ; Tue, 17 Feb 1998 17:00:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 16:55:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21832 for ipp-outgoing; Tue, 17 Feb 1998 16:55:01 -0500 (EST) Message-ID: <34EA072C.DED4B08@underscore.com> Date: Tue, 17 Feb 1998 16:54:52 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> Recent IETF drafts of interest to IPP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The IETF has just announced the publication of a rash of documents, several of which might have direct bearing to IPP, or at least be of interest to many IPP participants. I have included a summary of those documents below, derived from the official IETF announcement messages. ...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 -- ---------------------------------------------------------------------- Title : Preferred Language Tag Author(s) : M. Blanchet Filename : draft-blanchet-preflang-00.txt Pages : Date : 16-Feb-98 This memo defines a new tag which will help users and servers to determine the best language in their communications. For example, error messages coming from SMTP servers or HTTP servers can use this tag to send those error messages in the preferred language for the user. ftp://ftp.ietf.org/internet-drafts/draft-blanchet-preflang-00.txt ---------------------------------------------------------------------- Title : Language Tagging in Unicode Plain Text Author(s) : G. Adams, K. Whistler Filename : draft-whistler-plane14-00.txt Pages : 13 Date : 16-Feb-98 This document proposed a mechanism for language tagging in [UNICODE] plain text. A set of special-use tag characters on Plane 14 of [ISO10646] (accessible through UTF-8, UTF-16, and UCS-4 encoding forms) are proposed for encoding to enable the spelling out of ASCII-based string tags using characters which can be strictly separated from ordinary text content characters in ISO10646 (or UNICODE). ftp://ftp.ietf.org/internet-drafts/draft-whistler-plane14-00.txt ---------------------------------------------------------------------- Title : MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : N. Shelness, A. Hopmann, J. Palme Filename : draft-ietf-mhtml-rev-05.txt Pages : 27 Date : 16-Feb-98 HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object)and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e- mail message, it is necessary to:- a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document does both. It a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies two MIME content-headers (Content-Base and Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi- resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 13. ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-rev-05.txt ---------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate HTML Documents (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-09.txt Pages : 20 Date : 16-Feb-98 The memo ''MIME Encapsulation of Aggregate HTML Documents (MHTML)'' (draft-ietf-mhtml-rev-02.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-info-09.txt ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 17 17:06:57 1998 Delivery-Date: Tue, 17 Feb 1998 17:06:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA12065 for ; Tue, 17 Feb 1998 17:06:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09756 for ; Tue, 17 Feb 1998 17:09:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22979 for ; Tue, 17 Feb 1998 17:06:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 17:02:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22439 for ipp-outgoing; Tue, 17 Feb 1998 17:02:55 -0500 (EST) Message-ID: <34EA08EC.273BCC81@underscore.com> Date: Tue, 17 Feb 1998 17:02:20 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: IPP Mailing List Subject: Re: IPP> MS XML Proposal References: <5CEA8663F24DD111A96100805FFE6587030BC293@red-msg-51.dns.microsoft.com> <199802172129.NAA27875@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Bob, > I believe it is the DTD (plus extensions) that makes the XML approach > superior to the binary encoding. Without the DTD, XML is still slightly > better than the binary encoding, but probably not enough better to win more > converts. Many of us believe that a special-purpose binary encoding (eg, IPP) is *highly* undesirable under almost *any* circumstance. Recall that at the June '96 IPP meeting (Nashua), a majority of people were dead-set against a binary encoding of *any* kind, much less a special- purpose one designed for a single application (ie, IPP). Since XML is essentially a text-based encoding, I'd bet we'd see a lot more "converts" than you might think. ...jay PS: I've posted this reply (and your complete message) to the IPP list, as I suspected you forgot to cc: the IPP DL. My apologies if this was not your intention. ;-) ---------------------------------------------------------------------- -- 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 -- ---------------------------------------------------------------------- Robert Herriot wrote: > > I believe it is the DTD (plus extensions) that makes the XML approach > superior to the binary encoding. Without the DTD, XML is still slightly > better than the binary encoding, but probably not enough better to win more > converts. For the DTD to work, it really needs the Schema rules from the > "XML Data" document plus a few enhancements that I will propose. With such, > I believe that it is possible to define something that addresses all (or > nearly all) of what Section 15.3 in the model document does. I hope to send > out some examples in the next few days. Note, I still don't think that > printer vendors would implement a general parser with DTD embedded. Rather > they would use the DTD to direct their hand coding of their parser and > validator. > > Bob Herriot > > At 03:18 PM 2/13/98 , you wrote: > >Paul, > > > >You've specified that no DTD is required, but that an > >implementation could use a DTD as it saw fit, etc. > > > >How then is the "official" specification of the IPP > >XML text supposed to be standardized? I would have > >thought that the use of a DTD would be good for this, > >even though *use* of the DTD by a client or server is > >not required for protocol interaction. > > > >Note that I am assuming a DTD is itself a useful document, > >not being very well versed in XML/DTD stuff. > > > > ...jay > > > >---------------------------------------------------------------------- > >-- JK Martin | Email: jkm@underscore.com -- > >-- Underscore, Inc. | Voice: (603) 889-7000 -- > >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > >-- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > >---------------------------------------------------------------------- > > From ipp-owner@pwg.org Tue Feb 17 17:18:49 1998 Delivery-Date: Tue, 17 Feb 1998 17:18:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA12215 for ; Tue, 17 Feb 1998 17:18:49 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09823 for ; Tue, 17 Feb 1998 17:21:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23862 for ; Tue, 17 Feb 1998 17:18:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 17:13:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23074 for ipp-outgoing; Tue, 17 Feb 1998 17:12:56 -0500 (EST) Message-ID: <34EA0B5F.2C8D1D48@underscore.com> Date: Tue, 17 Feb 1998 17:12:47 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: don@lexmark.com Subject: Re: IPP> Re: Suggested workplan - host to device protocol References: <199802171525.AA13181@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I agree with Don. Moreover, I think its time we in the PWG started to talk about varying *classes* of "printers" (ie, embedded network hosts that image jobs on media). All too many times people want to lump all kinds of printers into one *giant* class, expecting the full range of capabilities to be POSSIBLE in all types of printers...including the $195 varieties sold at Wal-Mart et al. (This is where enterprise- level printing software vendors such as Jim Walker of DAZEL get serious heartburn.) IMHO, those printer vendors wanting to ship a "be-all, end-all" product in the marketplace should do just that, if they desire. However, at the same time, those vendors should *not* be saying things like "We can standardize on that function because it would require too much RAM/ROM in the printer, thereby increasing the product's price beyond its targeted price point." Low-level host-to-device (aka "server-to-printer") protocols such as TIPSI and CPAP allow even very low cost printers to provide high degrees of capabilities without having to significantly increase the internal software footprint. Let's "Stop the Insanity!" with respect to "One Size Fits All". ...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 -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > Roger deBry said: > > >Assertions: > > > >(1) IPP, as it is currently defined, is the correct protocol > > for client to server, across the Internet. > > > >(2) IPP, as it is currently defined, is the correct protocol > > for client to server, across an Intranet > > > >(3) IPP, as it is currently defined, is the correct protocol > > between a server and a printer which contains an > > imbedded server. > > I can easily agree with Roger on #1 and #2. I think where > the problem lies is with #3. I am not sure how broad the > definition of "imbedded server" is? Does that mean imbedded > IPP server or any server? All of my network printers today > have available what we call an Internal Print Server which > supports a wide range of protocols. Is that what you mean > Roger? I don't think so. I think the definition needs to > be "imbedded, spooling print server." And even then, I think > we have lost a huge amount of control and status information > that is available from TIPSI or even SNMP. Maybe we need > to define some kind of passthrough for IPP that allows > the control and status information for the down and dirty > hardware to be retrieved and set through IPP?? > > Comments? > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From ipp-owner@pwg.org Tue Feb 17 17:25:01 1998 Delivery-Date: Tue, 17 Feb 1998 17:25:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA12389 for ; Tue, 17 Feb 1998 17:25:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09873 for ; Tue, 17 Feb 1998 17:27:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA24776 for ; Tue, 17 Feb 1998 17:25:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 17:17:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23649 for ipp-outgoing; Tue, 17 Feb 1998 17:17:11 -0500 (EST) From: Harry Lewis To: , Cc: Subject: Re: IPP> MS XML Proposal Message-ID: <5030300018066406000002L062*@MHS> Date: Tue, 17 Feb 1998 17:22:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA12389 Yet, in January 1998, an overwhelming majority expressed their desire to move ahead with IPP, as defined. >Many of us believe that a special-purpose binary encoding (eg, IPP) >is *highly* undesirable under almost *any* circumstance. Recall >that at the June '96 IPP meeting (Nashua), a majority of people were >dead-set against a binary encoding of *any* kind, much less a special- >purpose one designed for a single application (ie, IPP). Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Feb 17 17:28:16 1998 Delivery-Date: Tue, 17 Feb 1998 17:28:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA12545 for ; Tue, 17 Feb 1998 17:28:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09882 for ; Tue, 17 Feb 1998 17:30:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25205 for ; Tue, 17 Feb 1998 17:28:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 17:23:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24454 for ipp-outgoing; Tue, 17 Feb 1998 17:22:58 -0500 (EST) Message-ID: <34EA0DB5.D98D2A9C@underscore.com> Date: Tue, 17 Feb 1998 17:22:45 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Re: Suggested workplan - host to device protocol References: <199802171525.AA13181@interlock2.lexmark.com> <34EA0B5F.2C8D1D48@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Oops... This clause in my last posting had a typo that might confuse folks: > ...those vendors should *not* be saying > things like "We can standardize on that function because it > would require too much RAM/ROM in the printer, thereby increasing > the product's price beyond its targeted price point." Of course, I *meant* to say: ...those vendors should *not* be saying things like "We can't..." ^^^^^ Sorry about that. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Feb 17 22:44:35 1998 Delivery-Date: Tue, 17 Feb 1998 22:45:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA17717 for ; Tue, 17 Feb 1998 22:44:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA10813 for ; Tue, 17 Feb 1998 22:47:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29859 for ; Tue, 17 Feb 1998 22:44:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Feb 1998 22:40:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29352 for ipp-outgoing; Tue, 17 Feb 1998 22:40:18 -0500 (EST) Date: Tue, 17 Feb 1998 19:45:28 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9802180345.AA05058@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> Notification Requirements [fractured text file] Sender: ipp-owner@pwg.org Hi Roger, When I pulled down the '.txt' version of your IPP notification requirements (THANK YOU for posting a '.txt' version!), I found that it suffered from the same creeping illness that afflicts Tom Hastings' MS Word to '.txt' files - to whit, LOTS of lines spit out in fragments with CR (carriage return) and more text and CR and finally LF (linefeed/newline). A year ago, I wrote a tool for Tom (DOS command line, but source is available - it's ANSI C) called 'overx' to fold these overstrike lines into real flat text. I just used it to fixup your posting, but don't have the password to post to PWG server, so I'll hope Tom reads this note and moves it from a Xerox server (call me Tom) to the PWG server. Before fixups, the longest line before a LF was 181 characters. After fixups, the longest line was 72 characters (hey, follows the IETF style guidelines - good work!). Recently, I found a bug in 'overx' and posted new version internally here in Xerox. Tom can post the new one to the PWG site. Tom's latests PWG Job Mon MIB v1.0 needed the repaired 'overx' to get the SMIC 'mstrip' tool to work right, so it is worthwhile to get the latest executable on the PWG servers. If anyone is really interested in source to 'overx' (and siblings 'strip' [removes controls and graphics], 'cscan' [character counts, including all controls, DEL, and graphics], and 'maxln' [counts lines longer than a specified 'fence' column]), please send me mail - if I post them to the PWG server, I'll have to support them, and religious fanatics will no doubt criticize them for being written in ANSI/ISO C (old, bad language) and not Java (new, cool language)... Cheers, - Ira McDonald From jmp-owner@pwg.org Wed Feb 18 04:31:50 1998 Delivery-Date: Wed, 18 Feb 1998 04:31:50 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA24996 for ; Wed, 18 Feb 1998 04:31:49 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11363 for ; Wed, 18 Feb 1998 04:34:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA11410 for ; Wed, 18 Feb 1998 04:31:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 04:27:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA10591 for jmp-outgoing; Wed, 18 Feb 1998 04:25:19 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , jmp@pwg.org, pwg@pwg.org, rbergma@dpc.com Cc: "'ipp@pwg.org'" Subject: JMP> RE: PWG> Charter: Traps for use with the Job Monitoring MIB Date: Wed, 18 Feb 1998 01:25:41 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org I'm assuming with the addition of traps for the job monitoring MIB, as well as the existing printer MIB traps (alerts), and our desire to include printer MIB alerts, as well as job notifications to IPP, we now have a completely redundant, overlapping solution set ;) ;) Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Tuesday, February 17, 1998 8:00 PM To: jmp@pwg.org; pwg@pwg.org; rbergma@dpc.com Subject: Re: PWG> Charter: Traps for use with the Job Monitoring MIB Hi Ron, Would you consider having a telecon during the upcoming PWG meeting in March, to widen the participation on the Job Mon MIB traps project discussion? All of the key people at Xerox who have participated in Xerox (private) specification of job monitoring traps and trap registration methods are unable to attend in March (I know - I've been checking with them). Thanks for pushing this IMPORTANT issue along. As the first PWG standard and NOT an IETF standard, I believe the PWG Job Mon MIB has a unique opportunity to address domain-specific traps sensibly and MUCH more quickly than could be done for an IETF 'standards track' document. To stimultate discussion, my two cents on trap registration 1) SNMPv3 carries way to much security baggage, to be a good trap registration method 2) There AREN'T any other IETF 'standards track' trap registration methods 3) A PWG standardized solution for the PWG Job Mon MIB could also EASILY be a PWG standardized solution for the IETF/PWG Printer MIB (different OID subtree) 4) A PWG standardized solution could EASILY be SNMP version independent (ie, SNMPv1, SNMPv1Secure[obsolete], SNMPv2Historic[RFC144x series], SNMPv2[RFC 190x series], and SNMPv3 [RFC227x series, last month]) Cheers, - Ira McDonald From ipp-owner@pwg.org Wed Feb 18 04:34:59 1998 Delivery-Date: Wed, 18 Feb 1998 04:35:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA25011 for ; Wed, 18 Feb 1998 04:34:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11370 for ; Wed, 18 Feb 1998 04:37:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA11852 for ; Wed, 18 Feb 1998 04:34:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 04:25:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA10604 for ipp-outgoing; Wed, 18 Feb 1998 04:25:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , jmp@pwg.org, pwg@pwg.org, rbergma@dpc.com Cc: "'ipp@pwg.org'" Subject: IPP> RE: PWG> Charter: Traps for use with the Job Monitoring MIB Date: Wed, 18 Feb 1998 01:25:41 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I'm assuming with the addition of traps for the job monitoring MIB, as well as the existing printer MIB traps (alerts), and our desire to include printer MIB alerts, as well as job notifications to IPP, we now have a completely redundant, overlapping solution set ;) ;) Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Tuesday, February 17, 1998 8:00 PM To: jmp@pwg.org; pwg@pwg.org; rbergma@dpc.com Subject: Re: PWG> Charter: Traps for use with the Job Monitoring MIB Hi Ron, Would you consider having a telecon during the upcoming PWG meeting in March, to widen the participation on the Job Mon MIB traps project discussion? All of the key people at Xerox who have participated in Xerox (private) specification of job monitoring traps and trap registration methods are unable to attend in March (I know - I've been checking with them). Thanks for pushing this IMPORTANT issue along. As the first PWG standard and NOT an IETF standard, I believe the PWG Job Mon MIB has a unique opportunity to address domain-specific traps sensibly and MUCH more quickly than could be done for an IETF 'standards track' document. To stimultate discussion, my two cents on trap registration 1) SNMPv3 carries way to much security baggage, to be a good trap registration method 2) There AREN'T any other IETF 'standards track' trap registration methods 3) A PWG standardized solution for the PWG Job Mon MIB could also EASILY be a PWG standardized solution for the IETF/PWG Printer MIB (different OID subtree) 4) A PWG standardized solution could EASILY be SNMP version independent (ie, SNMPv1, SNMPv1Secure[obsolete], SNMPv2Historic[RFC144x series], SNMPv2[RFC 190x series], and SNMPv3 [RFC227x series, last month]) Cheers, - Ira McDonald From pwg-owner@pwg.org Wed Feb 18 04:40:27 1998 Delivery-Date: Wed, 18 Feb 1998 04:40:27 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA25043 for ; Wed, 18 Feb 1998 04:40:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11379 for ; Wed, 18 Feb 1998 04:43:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA12405 for ; Wed, 18 Feb 1998 04:40:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 04:33:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA10581 for pwg-outgoing; Wed, 18 Feb 1998 04:25:14 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , jmp@pwg.org, pwg@pwg.org, rbergma@dpc.com Cc: "'ipp@pwg.org'" Subject: RE: PWG> Charter: Traps for use with the Job Monitoring MIB Date: Wed, 18 Feb 1998 01:25:41 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pwg@pwg.org I'm assuming with the addition of traps for the job monitoring MIB, as well as the existing printer MIB traps (alerts), and our desire to include printer MIB alerts, as well as job notifications to IPP, we now have a completely redundant, overlapping solution set ;) ;) Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Tuesday, February 17, 1998 8:00 PM To: jmp@pwg.org; pwg@pwg.org; rbergma@dpc.com Subject: Re: PWG> Charter: Traps for use with the Job Monitoring MIB Hi Ron, Would you consider having a telecon during the upcoming PWG meeting in March, to widen the participation on the Job Mon MIB traps project discussion? All of the key people at Xerox who have participated in Xerox (private) specification of job monitoring traps and trap registration methods are unable to attend in March (I know - I've been checking with them). Thanks for pushing this IMPORTANT issue along. As the first PWG standard and NOT an IETF standard, I believe the PWG Job Mon MIB has a unique opportunity to address domain-specific traps sensibly and MUCH more quickly than could be done for an IETF 'standards track' document. To stimultate discussion, my two cents on trap registration 1) SNMPv3 carries way to much security baggage, to be a good trap registration method 2) There AREN'T any other IETF 'standards track' trap registration methods 3) A PWG standardized solution for the PWG Job Mon MIB could also EASILY be a PWG standardized solution for the IETF/PWG Printer MIB (different OID subtree) 4) A PWG standardized solution could EASILY be SNMP version independent (ie, SNMPv1, SNMPv1Secure[obsolete], SNMPv2Historic[RFC144x series], SNMPv2[RFC 190x series], and SNMPv3 [RFC227x series, last month]) Cheers, - Ira McDonald From ipp-owner@pwg.org Wed Feb 18 09:21:25 1998 Delivery-Date: Wed, 18 Feb 1998 09:21:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA29733 for ; Wed, 18 Feb 1998 09:21:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12038 for ; Wed, 18 Feb 1998 09:24:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA14007 for ; Wed, 18 Feb 1998 09:21:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 09:13:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA13466 for ipp-outgoing; Wed, 18 Feb 1998 09:13:29 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 18 Feb 1998 07:04:29 -0700 From: "Craig Whittle" To: ipp@pwg.org Subject: RE: IPP> Re: Suggested workplan - host to device protocol Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA29733 It appears as if this thread is the beginnings of yet another print protocol. I would argue in favor of using existing protocols "TIPSI or even SNMP," as suggested by Don or at least leverage their strengths. I believe the protocol could be the same between client and server and client and printer. IPP is a simple solution for Internet job submission but it doesn't address the complexities of printer management that TIPSI or SNMP do. Is it the objective of the PWG to grow IPP to include printer management capabilities like TIPSI or SNMP and richer job control like DPA? I would hope that over time there would be a convergence of protocols that meets the needs of embedded devices as well as the need of hosts to servers, perhaps in a single protocol. **CW Craig T. Whittle cwhittle@novell.com >>> "Turner, Randy" 02/17/98 08:33AM >>> I think Roger (correct if I'm wrong, Roger) meant that IPP, as currently defined, is the correct solution for server-to-printer protocol, IF the printer device already has an embedded web server, like would probably be used for overall management. And if this is the assertion, then I tend to agree with it, although it depends on what the exact *requirements* are for server-to-printer protocol. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Tuesday, February 17, 1998 7:24 AM To: ipp@pwg.org Subject: IPP> Re: Suggested workplan - host to device protocol Roger deBry said: >Assertions: > >(1) IPP, as it is currently defined, is the correct protocol > for client to server, across the Internet. > >(2) IPP, as it is currently defined, is the correct protocol > for client to server, across an Intranet > >(3) IPP, as it is currently defined, is the correct protocol > between a server and a printer which contains an > imbedded server. I can easily agree with Roger on #1 and #2. I think where the problem lies is with #3. I am not sure how broad the definition of "imbedded server" is? Does that mean imbedded IPP server or any server? All of my network printers today have available what we call an Internal Print Server which supports a wide range of protocols. Is that what you mean Roger? I don't think so. I think the definition needs to be "imbedded, spooling print server." And even then, I think we have lost a huge amount of control and status information that is available from TIPSI or even SNMP. Maybe we need to define some kind of passthrough for IPP that allows the control and status information for the down and dirty hardware to be retrieved and set through IPP?? Comments? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Feb 18 13:23:06 1998 Delivery-Date: Wed, 18 Feb 1998 13:23:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA05903 for ; Wed, 18 Feb 1998 13:23:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13437 for ; Wed, 18 Feb 1998 13:25:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15129 for ; Wed, 18 Feb 1998 13:23:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 13:18:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14615 for ipp-outgoing; Wed, 18 Feb 1998 13:18:16 -0500 (EST) From: don@lexmark.com Message-Id: <199802181817.AA25337@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Cc: jkm@underscore.com Date: Wed, 18 Feb 1998 13:17:07 -0500 Subject: IPP> Host-to-Printer Protocol Goals Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Just to level set us all, I have extracted the scope, purpose and introduction sections from a late draft of the IEEE 1284-1-1997 Transport Independent Printer System Interface standard. Remember, this was originally written 2 or 3 years ago, mostly before a printer MIB existed. While things have changed a little since then, the assumptions and goals are, I think, still valid. Try to read this in a printer politics neutral frame-of-mind (I said TRY) and I think you will agree, there are significant merits which should be considered. --------------------- Scope This project will develop a standard protocol for the control of printers. This protocol will be independent of the underlying data stream or page description language used to create the printed page. This protocol will be usable by all classes of printers. This project is limited to management and control of printers and will not include management or control of printing system or subsystems. Purpose There is currently no defined, independent standard for controlling printers. Each vendor builds some control into the underlying page description language or data stream. Without an independent, openly defined protocol, applications and operating systems cannot automatically determine the type of printer being addressed. This protocol will provide a minimum implementation subset which will allow automatic identification and configuration of printers and vendor extensibility to provide for growth and product differentiation. Introduction This standard defines a protocol for communications between a host and printer. Its intent is to provide standard methodology for software developers, computer vendors, and printer manufacturers that facilitate the orderly exchange of information between printers and host computers. The specification defines a minimum set of functions that permit meaningful data exchange. Thus, this standard establishes a foundation upon which compatible applications, computers, and printers can be developed, without compromising a particular organization's desire for design innovation. The following objectives accompany this specification: 1. Simplify the printer driver development process by defining a standard set of command/response transactions between the host computer and printer. 2. Accelerate the development of communicating printers by providing a robust protocol that can be implemented in phases ranging from basic to extended functionality. 3. Ease customers' printing problems (especially over networks) by accelerating the availability of communicating printers and compatible host software. 4. Assist software developers in minimizing time to market by establishing a base set of functions that insure a minimum level of communications between the host and printer. 5. Facilitate the creation of powerful network print management software by defining transactions that work across a wide range of printers. 6. Enable the creation of standard control/communications firmware that can be included in many peripheral devices. 7. Create a standard methodology for host and printer communications that is independent of the transport mechanism used between devices. 8. Enhance the management of printers in networks by providing a mechanism for printers to readily provide their status and configuration to the host application. 9. Permit design innovation by providing flexibility within the specification for printer manufacturers to include extensions to the original set of guidelines. 10. Insure cross-platform host-to-printer communications by creating an operating system-independent set of guidelines. 11. The resultant protocol is PDL independent with the capability of a printer to support multiple PDLs, all active at the same time, if desired. The Current Situation Local area networks are increasingly becoming the most popular means of interconnecting devices within a corporation. With costs per connection coming down, this trend shows no sign of abating. As networks grow larger, more computers and printers will be interconnected. Any weaknesses in network printing will only be magnified as more devices are made to communicate. The absence of feedback from existing printers causes many problems in today's network environment. For example, a user could be submitting a job to a remote printer. If that printer is low on toner, most printers today do not have the capability to inform users about this condition. Additionally, if the job is large, the user risks having to wait until the job is finished before finding out that the output is incorrect. The resulting waste of paper, toner, and time could be significant when calculated over a period of time on a large network. Standardized feedback information from a printer would solve this problem. By the use of this standard, when a printer recognizes a condition that would prevent it from accurately printing a job, it can send a standardized message to a host computer that is monitoring network printing. Upon receipt of this message, the host could then send a message to the user who submitted the job informing him of the error condition. The user could then redirect a job to a more appropriate printer or undertake action to correct the defect at the target printer. When projected over a period of time and a large number of network users, the resulting monetary savings could be substantial. The example shown above is just one of many error conditions that could occur when printing either on a standalone computer or over a network. By using this standard format for exchanging information between the printer and host, software vendors, network suppliers, and printer manufacturers will now be able to greatly improve the efficiency of network printing. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Feb 18 13:49:35 1998 Delivery-Date: Wed, 18 Feb 1998 13:49:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA06248 for ; Wed, 18 Feb 1998 13:49:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13617 for ; Wed, 18 Feb 1998 13:52:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15752 for ; Wed, 18 Feb 1998 13:49:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 13:45:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15252 for ipp-outgoing; Wed, 18 Feb 1998 13:45:40 -0500 (EST) From: Harry Lewis To: , Subject: RE: IPP> Re: Suggested workplan - host to device protocol Message-ID: <5030300018108618000002L082*@MHS> Date: Wed, 18 Feb 1998 13:50:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA06248 Craig, >I believe the protocol could be the same between client and server and client and printer. >IPP is a simple solution for Internet job submission but it doesn't address the >complexities of printer management that TIPSI or SNMP do. IPP defines a PRINTER OBJECT and a JOB OBJECT. IPP has the following operations - PrintJob (Request/Response) - (Submit single doc job with data. Unsupportted attributes returned.) - PrintURI ("Pull" printing) - ValidateJob - (Like PrintJob w/no data. Validate operations prior to submission.) - CreateJob - (Setup for multi document job) - SendDocument (Request/Response) - SendURI - GetJob (Request/Response) - When shopping for the shortest print queue - CancelJob (Request/Response) - Probably the best feature of all - GetPrinterAttributes (Request/Response) - Granted, a cumbersome intersection with the Printer MIB which (in my opinion) could possibly be strengthened or dilluted dependint on the tug-of-war between "in-band" and "side-channel" camps. - GetJobAttributes - A way to check job progress. Again, overlapping the Job MIB but, fortunately, correlated and potentially reconcilable. Notification is the next big feature to be tackled by IPP (analogous to "Jobs" in the Printer MIB, notification was counciously pared from the IPPv1 scope in order to make progress). What complexitis of printer management are you referring to which are currently missing from IPP? Is it conceivable that these may fall nicely into the realm of notification? Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 02/18/98 07:16:30 AM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: RE: IPP> Re: Suggested workplan - host to device protocol It appears as if this thread is the beginnings of yet another print protocol. I would argue in favor of using existing protocols "TIPSI or even SNMP," as suggested by Don or at least leverage their strengths. I believe the protocol could be the same between client and server and client and printer. IPP is a simple solution for Internet job submission but it doesn't address the complexities of printer management that TIPSI or SNMP do. Is it the objective of the PWG to grow IPP to include printer management capabilities like TIPSI or SNMP and richer job control like DPA? I would hope that over time there would be a convergence of protocols that meets the needs of embedded devices as well as the need of hosts to servers, perhaps in a single protocol. **CW Craig T. Whittle cwhittle@novell.com >>> "Turner, Randy" 02/17/98 08:33AM >>> I think Roger (correct if I'm wrong, Roger) meant that IPP, as currently defined, is the correct solution for server-to-printer protocol, IF the printer device already has an embedded web server, like would probably be used for overall management. And if this is the assertion, then I tend to agree with it, although it depends on what the exact *requirements* are for server-to-printer protocol. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Tuesday, February 17, 1998 7:24 AM To: ipp@pwg.org Subject: IPP> Re: Suggested workplan - host to device protocol Roger deBry said: >Assertions: > >(1) IPP, as it is currently defined, is the correct protocol > for client to server, across the Internet. > >(2) IPP, as it is currently defined, is the correct protocol > for client to server, across an Intranet > >(3) IPP, as it is currently defined, is the correct protocol > between a server and a printer which contains an > imbedded server. I can easily agree with Roger on #1 and #2. I think where the problem lies is with #3. I am not sure how broad the definition of "imbedded server" is? Does that mean imbedded IPP server or any server? All of my network printers today have available what we call an Internal Print Server which supports a wide range of protocols. Is that what you mean Roger? I don't think so. I think the definition needs to be "imbedded, spooling print server." And even then, I think we have lost a huge amount of control and status information that is available from TIPSI or even SNMP. Maybe we need to define some kind of passthrough for IPP that allows the control and status information for the down and dirty hardware to be retrieved and set through IPP?? Comments? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Feb 18 19:09:15 1998 Delivery-Date: Wed, 18 Feb 1998 19:09:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA10836 for ; Wed, 18 Feb 1998 19:09:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15129 for ; Wed, 18 Feb 1998 19:11:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA17895 for ; Wed, 18 Feb 1998 19:09:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 19:03:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17371 for ipp-outgoing; Wed, 18 Feb 1998 19:03:55 -0500 (EST) Message-Id: <3.0.1.32.19980218154935.00c48840@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 18 Feb 1998 15:49:35 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - New Time for Weekly PWG IPP Phone Conferences Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org In today's phone conference the East Coasters brought up the subject of having to spend evenings to attend the weekly phone conferences. The suggestion is to move the time from Wednesdays at 1 pm PST, 4 pm EST to Wednesdays 10 am PST and 1 pm EST. Does anybody who usually attend the phone conferences have a problem with this change? I expect to use the new time in next week's conference unless there are a lot of dissenters. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 18 21:25:10 1998 Delivery-Date: Wed, 18 Feb 1998 21:25:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA11970 for ; Wed, 18 Feb 1998 21:25:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15410 for ; Wed, 18 Feb 1998 21:27:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA18966 for ; Wed, 18 Feb 1998 21:25:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Feb 1998 21:19:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA18414 for ipp-outgoing; Wed, 18 Feb 1998 21:19:40 -0500 (EST) Message-Id: <3.0.1.32.19980218181502.0090dd20@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 18 Feb 1998 18:15:02 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Austin Agenda for PWG IPP Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Following up on my home work assignment from the phone conference earlier today, I have just spoken to Paul Moore. He confirmed that he will be in Austin for the discussion of the Universal Print Driver on the Tuesday evening and will stay on Wednesday, but cannot stay for the Thursday part of the IPP meeting. He expressed a preference for discussing the host to device subject while he is around, so I am planning to put that on the Wednesday afternoon agenda. We will then have Notifications, Testing and discussions about other possible extensions to IPP V1.0 on Thursday. Hope this is OK for the rest of you? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 19 10:43:54 1998 Delivery-Date: Thu, 19 Feb 1998 10:43:54 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA24447 for ; Thu, 19 Feb 1998 10:43:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA17027 for ; Thu, 19 Feb 1998 10:46:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA01528 for ; Thu, 19 Feb 1998 10:43:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 10:34:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA00996 for ipp-outgoing; Thu, 19 Feb 1998 10:34:31 -0500 (EST) From: Roger K Debry To: Subject: IPP> Updated notification requirements document posted Message-ID: <5030100017654734000002L042*@MHS> Date: Thu, 19 Feb 1998 10:32:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA24447 I have posted the updates to the updates to the requirements document which reflect the discussion in yesterday's telecon. The text version has been sent to the IETF to be issued as an Internet Draft. The documents are at: ftp.pwg.org/pub/pwg/ipp/new_NOT/IPP-notify-980219.txt ftp.pwg.org/pub/pwg/ipp/new_NOT/IPP-notify-980219.pdf ftp.pwg.org/pub/pwg/ipp/new_NOT/IPP-notify-980219.doc Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu Feb 19 11:54:05 1998 Delivery-Date: Thu, 19 Feb 1998 11:54:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25172 for ; Thu, 19 Feb 1998 11:54:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA17507 for ; Thu, 19 Feb 1998 11:56:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA02575 for ; Thu, 19 Feb 1998 11:54:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 11:48:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA02061 for ipp-outgoing; Thu, 19 Feb 1998 11:48:51 -0500 (EST) From: don@lexmark.com Message-Id: <199802191648.AA18246@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 19 Feb 1998 10:25:54 -0500 Subject: IPP> ADM - New Time for Weekly PWG IPP Phone Conferences Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the details on next week's conference call. Remember this one will be at 1PM EST, 10AM PST!! Date: 2/25 Call-in: 1-608-250-1828 Access: 190148 Time: 1PM EST (10AM PST) Duration: 2.5 hours ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ---------------------- Forwarded by Don Wright on 02/19/98 10:24 AM --------------------------- From: cmanros%cp10.es.xerox.com@interlock.lexmark.com on 02/18/98 03:49 PM PST To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> ADM - New Time for Weekly PWG IPP Phone Conferences In today's phone conference the East Coasters brought up the subject of having to spend evenings to attend the weekly phone conferences. The suggestion is to move the time from Wednesdays at 1 pm PST, 4 pm EST to Wednesdays 10 am PST and 1 pm EST. Does anybody who usually attend the phone conferences have a problem with this change? I expect to use the new time in next week's conference unless there are a lot of dissenters. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 19 17:12:32 1998 Delivery-Date: Thu, 19 Feb 1998 17:12:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28155 for ; Thu, 19 Feb 1998 17:12:31 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA19001 for ; Thu, 19 Feb 1998 17:15:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04975 for ; Thu, 19 Feb 1998 17:12:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 17:07:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04443 for ipp-outgoing; Thu, 19 Feb 1998 17:07:15 -0500 (EST) From: Roger K Debry To: Subject: IPP> Use of POST Method in HTTP Message-ID: <5030100017677867000002L072*@MHS> Date: Thu, 19 Feb 1998 17:05:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA28155 An Internet Draft on this subject has been posted to ftp://pwg@ftp.pwg.org/pub/pwg/ipp/new_PRO/ draft-debry-http-usepost-00.txt Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu Feb 19 17:57:18 1998 Delivery-Date: Thu, 19 Feb 1998 17:57:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28472 for ; Thu, 19 Feb 1998 17:57:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA19163 for ; Thu, 19 Feb 1998 17:59:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06152 for ; Thu, 19 Feb 1998 17:57:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 17:48:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05092 for ipp-outgoing; Thu, 19 Feb 1998 17:48:40 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" Subject: IPP> Early ping for april meeting Date: Thu, 19 Feb 1998 14:48:51 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org The April meeting of the PWG will be in Portland, OR and is scheduled for April 6-10. The meeting location is tentatively planned for the new Embassy Suites Hotel in downtown. The conference rate will be $135.00 per night with a daily meeting room fee of about $35.00. I'm assuming the daily meeting breakdown would be Mon,Tues: PWG1394 WG Weds/Thurs: PWG/IPP WG Fri: Host MIB, UPD, Other business As an alternative meeting location, Sharp could host the meeting at our site, which is about a 25-minute drive from downtown Portland. If Sharp hosts the meeting, then there would be no meeting room fee, and we could provide lunch on whatever days the group wanted. Including our normal break snacks. You would of course be on your own for lodging. You could either stay in downtown Portland and drive each day, or we have 3 or 4 hotels within 10 - 15 minute drive of the Sharp campus. One of the hotels is new (The Heathman Lodge) and is really a nice place. Its about 10 or so minutes away. What I am interested in knowing is who would be attending the meeting in Portland, in general, and secondly, at which location you would prefer to meet (Embassy Suites/downtown or Sharp). It doesn't really make much difference to me either way, although it might be somewhat less expensive for folks flying in to meet at Sharp. Also I would like to know which meetings you would be attending and if you want to meet in town, I would need to know if you would be staying at the hotel. Thanks! Randy From pwg-owner@pwg.org Thu Feb 19 17:59:19 1998 Delivery-Date: Thu, 19 Feb 1998 17:59:20 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA28504 for ; Thu, 19 Feb 1998 17:59:19 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19174 for ; Thu, 19 Feb 1998 18:01:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06372 for ; Thu, 19 Feb 1998 17:59:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 17:53:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05085 for pwg-outgoing; Thu, 19 Feb 1998 17:48:36 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" Subject: PWG> Early ping for april meeting Date: Thu, 19 Feb 1998 14:48:51 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pwg@pwg.org The April meeting of the PWG will be in Portland, OR and is scheduled for April 6-10. The meeting location is tentatively planned for the new Embassy Suites Hotel in downtown. The conference rate will be $135.00 per night with a daily meeting room fee of about $35.00. I'm assuming the daily meeting breakdown would be Mon,Tues: PWG1394 WG Weds/Thurs: PWG/IPP WG Fri: Host MIB, UPD, Other business As an alternative meeting location, Sharp could host the meeting at our site, which is about a 25-minute drive from downtown Portland. If Sharp hosts the meeting, then there would be no meeting room fee, and we could provide lunch on whatever days the group wanted. Including our normal break snacks. You would of course be on your own for lodging. You could either stay in downtown Portland and drive each day, or we have 3 or 4 hotels within 10 - 15 minute drive of the Sharp campus. One of the hotels is new (The Heathman Lodge) and is really a nice place. Its about 10 or so minutes away. What I am interested in knowing is who would be attending the meeting in Portland, in general, and secondly, at which location you would prefer to meet (Embassy Suites/downtown or Sharp). It doesn't really make much difference to me either way, although it might be somewhat less expensive for folks flying in to meet at Sharp. Also I would like to know which meetings you would be attending and if you want to meet in town, I would need to know if you would be staying at the hotel. Thanks! Randy From ipp-owner@pwg.org Thu Feb 19 18:09:04 1998 Delivery-Date: Thu, 19 Feb 1998 18:09:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28591 for ; Thu, 19 Feb 1998 18:09:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19209 for ; Thu, 19 Feb 1998 18:11:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA07398 for ; Thu, 19 Feb 1998 18:09:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 18:00:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06456 for ipp-outgoing; Thu, 19 Feb 1998 18:00:49 -0500 (EST) Message-Id: <199802192300.PAA17650@barley.adnc.com> X-Sender: lstein@pop3.fapo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Feb 1998 14:58:12 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" From: Larry Stein Subject: IPP> Re: P1394> Early ping for april meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Randy, Thanks for setting this up. I vote for meeting at Sharp. Will be there for 1394PWG. -Larry At 2/19/98 02:48 PM , Turner, Randy wrote: > >The April meeting of the PWG will be in Portland, OR and is scheduled >for April 6-10. The meeting location is tentatively planned for the new >Embassy Suites Hotel in downtown. The conference rate will be $135.00 >per night with a daily meeting room fee of about $35.00. I'm assuming >the daily meeting breakdown would be > >Mon,Tues: PWG1394 WG Weds/Thurs: PWG/IPP WG Fri: Host MIB, UPD, >Other business > >As an alternative meeting location, Sharp could host the meeting at our >site, which is about a 25-minute drive from downtown Portland. If Sharp >hosts the meeting, then there would be no meeting room fee, and we could >provide lunch on whatever days the group wanted. Including our normal >break snacks. You would of course be on your own for lodging. You could >either stay in downtown Portland and drive each day, or we have 3 or 4 >hotels within 10 - 15 minute drive of the Sharp campus. One of the >hotels is new (The Heathman Lodge) and is really a nice place. Its about >10 or so minutes away. > >What I am interested in knowing is who would be attending the meeting in >Portland, in general, and secondly, at which location you would prefer >to meet (Embassy Suites/downtown or Sharp). It doesn't really make much >difference to me either way, although it might be somewhat less >expensive for folks flying in to meet at Sharp. Also I would like to >know which meetings you would be attending and if you want to meet in >town, I would need to know if you would be staying at the hotel. > >Thanks! > >Randy > *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pwg-owner@pwg.org Thu Feb 19 18:11:47 1998 Delivery-Date: Thu, 19 Feb 1998 18:11:48 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28614 for ; Thu, 19 Feb 1998 18:11:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19219 for ; Thu, 19 Feb 1998 18:14:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA07777 for ; Thu, 19 Feb 1998 18:11:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 18:08:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06449 for pwg-outgoing; Thu, 19 Feb 1998 18:00:45 -0500 (EST) Message-Id: <199802192300.PAA17650@barley.adnc.com> X-Sender: lstein@pop3.fapo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Feb 1998 14:58:12 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" From: Larry Stein Subject: PWG> Re: P1394> Early ping for april meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pwg@pwg.org Randy, Thanks for setting this up. I vote for meeting at Sharp. Will be there for 1394PWG. -Larry At 2/19/98 02:48 PM , Turner, Randy wrote: > >The April meeting of the PWG will be in Portland, OR and is scheduled >for April 6-10. The meeting location is tentatively planned for the new >Embassy Suites Hotel in downtown. The conference rate will be $135.00 >per night with a daily meeting room fee of about $35.00. I'm assuming >the daily meeting breakdown would be > >Mon,Tues: PWG1394 WG Weds/Thurs: PWG/IPP WG Fri: Host MIB, UPD, >Other business > >As an alternative meeting location, Sharp could host the meeting at our >site, which is about a 25-minute drive from downtown Portland. If Sharp >hosts the meeting, then there would be no meeting room fee, and we could >provide lunch on whatever days the group wanted. Including our normal >break snacks. You would of course be on your own for lodging. You could >either stay in downtown Portland and drive each day, or we have 3 or 4 >hotels within 10 - 15 minute drive of the Sharp campus. One of the >hotels is new (The Heathman Lodge) and is really a nice place. Its about >10 or so minutes away. > >What I am interested in knowing is who would be attending the meeting in >Portland, in general, and secondly, at which location you would prefer >to meet (Embassy Suites/downtown or Sharp). It doesn't really make much >difference to me either way, although it might be somewhat less >expensive for folks flying in to meet at Sharp. Also I would like to >know which meetings you would be attending and if you want to meet in >town, I would need to know if you would be staying at the hotel. > >Thanks! > >Randy > *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From pwg-owner@pwg.org Thu Feb 19 20:21:36 1998 Delivery-Date: Thu, 19 Feb 1998 20:21:36 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA29311 for ; Thu, 19 Feb 1998 20:21:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19609 for ; Thu, 19 Feb 1998 20:24:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA09503 for ; Thu, 19 Feb 1998 20:21:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 20:17:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08683 for pwg-outgoing; Thu, 19 Feb 1998 20:14:33 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pwg@pwg.org'" Subject: PWG> UPD meeting Date: Thu, 19 Feb 1998 17:14:47 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-pwg@pwg.org I have one of our printer driver guys that wants to come JUST for the discussion on UPD. But I really need to able to tell him a firm agenda for this meeting in Austin. Is there a final decision on when the UPD meeting will be held? Thanx R. From ipp-owner@pwg.org Thu Feb 19 20:22:09 1998 Delivery-Date: Thu, 19 Feb 1998 20:22:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA29320 for ; Thu, 19 Feb 1998 20:22:08 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19612 for ; Thu, 19 Feb 1998 20:24:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA09583 for ; Thu, 19 Feb 1998 20:22:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Feb 1998 20:14:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08671 for ipp-outgoing; Thu, 19 Feb 1998 20:14:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'pwg@pwg.org'" Subject: IPP> UPD meeting Date: Thu, 19 Feb 1998 17:14:47 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I have one of our printer driver guys that wants to come JUST for the discussion on UPD. But I really need to able to tell him a firm agenda for this meeting in Austin. Is there a final decision on when the UPD meeting will be held? Thanx R. From jmp-owner@pwg.org Fri Feb 20 09:36:15 1998 Delivery-Date: Fri, 20 Feb 1998 09:36:15 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10783 for ; Fri, 20 Feb 1998 09:36:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA20982 for ; Fri, 20 Feb 1998 09:38:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA21578 for ; Fri, 20 Feb 1998 09:36:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 09:31:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA20714 for jmp-outgoing; Fri, 20 Feb 1998 09:27:59 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> IPP> UPD meeting Message-ID: <5040300012861326000002L062*@MHS> Date: Fri, 20 Feb 1998 09:24:55 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org >I have one of our printer driver guys that wants to come JUST for the >discussion on UPD. But I really need to able to tell him a firm agenda >for this meeting in Austin. Is there a final decision on when the UPD >meeting will be held? > >Thanx > >R. Ok, here's a stake in the lake. The UPD meeting will be 7:00PM-10:00PM CST on Tuesday, March 3. The meeting is in the Texas 5 meeting room. For directions to the room, look at the meeting board in the lobby or ask the hotel desk. I am recruiting a chair for the meeting who can then drive the agenda. I understand Paul Moore of Microsoft will discuss their Universal Print Driver at this meeting. Is there a UPD mailing list? Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From pwg-owner@pwg.org Fri Feb 20 09:40:48 1998 Delivery-Date: Fri, 20 Feb 1998 09:40:48 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10840 for ; Fri, 20 Feb 1998 09:40:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA21007 for ; Fri, 20 Feb 1998 09:43:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA22239 for ; Fri, 20 Feb 1998 09:40:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 09:35:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA20694 for pwg-outgoing; Fri, 20 Feb 1998 09:27:50 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> IPP> UPD meeting Message-ID: <5040300012861326000002L062*@MHS> Date: Fri, 20 Feb 1998 09:24:55 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org >I have one of our printer driver guys that wants to come JUST for the >discussion on UPD. But I really need to able to tell him a firm agenda >for this meeting in Austin. Is there a final decision on when the UPD >meeting will be held? > >Thanx > >R. Ok, here's a stake in the lake. The UPD meeting will be 7:00PM-10:00PM CST on Tuesday, March 3. The meeting is in the Texas 5 meeting room. For directions to the room, look at the meeting board in the lobby or ask the hotel desk. I am recruiting a chair for the meeting who can then drive the agenda. I understand Paul Moore of Microsoft will discuss their Universal Print Driver at this meeting. Is there a UPD mailing list? Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Feb 20 09:41:10 1998 Delivery-Date: Fri, 20 Feb 1998 09:41:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10849 for ; Fri, 20 Feb 1998 09:41:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA21010 for ; Fri, 20 Feb 1998 09:43:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA22291 for ; Fri, 20 Feb 1998 09:41:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 09:28:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA20730 for ipp-outgoing; Fri, 20 Feb 1998 09:28:11 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> UPD meeting Message-ID: <5040300012861326000002L062*@MHS> Date: Fri, 20 Feb 1998 09:24:55 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org >I have one of our printer driver guys that wants to come JUST for the >discussion on UPD. But I really need to able to tell him a firm agenda >for this meeting in Austin. Is there a final decision on when the UPD >meeting will be held? > >Thanx > >R. Ok, here's a stake in the lake. The UPD meeting will be 7:00PM-10:00PM CST on Tuesday, March 3. The meeting is in the Texas 5 meeting room. For directions to the room, look at the meeting board in the lobby or ask the hotel desk. I am recruiting a chair for the meeting who can then drive the agenda. I understand Paul Moore of Microsoft will discuss their Universal Print Driver at this meeting. Is there a UPD mailing list? Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From jmp-owner@pwg.org Fri Feb 20 10:11:40 1998 Delivery-Date: Fri, 20 Feb 1998 10:11:40 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11143 for ; Fri, 20 Feb 1998 10:11:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21106 for ; Fri, 20 Feb 1998 10:14:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA24600 for ; Fri, 20 Feb 1998 10:11:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 10:01:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22438 for jmp-outgoing; Fri, 20 Feb 1998 09:52:35 -0500 (EST) Message-ID: <34ED98A0.8278E4F7@underscore.com> Date: Fri, 20 Feb 1998 09:52:16 -0500 From: "Jeffrey D. Schnitzer" Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Carter CC: p1394@pwg.org, pwg@pwg.org, fin@pwg.org, jmp@pwg.org, ipp@pwg.org, upd@pwg.org Subject: JMP> UPD mailing list (was IPP> UPD meeting) References: <5040300012861326000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Keith Carter asked: > > Is there a UPD mailing list? > The UPD mailing list is . To add yourself to the list, send mail to with the following as the body of the message: subscribe upd end The list has been in place since May'97, but there was little traffic on it. It's hypermail archive is at: http://www.pwg.org/hypermail/upd /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From jmp-owner@pwg.org Fri Feb 20 10:15:07 1998 Delivery-Date: Fri, 20 Feb 1998 10:15:08 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11180 for ; Fri, 20 Feb 1998 10:15:07 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21112 for ; Fri, 20 Feb 1998 10:17:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA25017 for ; Fri, 20 Feb 1998 10:15:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 10:05:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22596 for jmp-outgoing; Fri, 20 Feb 1998 09:54:12 -0500 (EST) From: Keith Carter To: , , , , Subject: JMP> Meeting room information for PWG meeting in Austin on 3/2-6 Message-ID: <5040300012862927000002L072*@MHS> Date: Fri, 20 Feb 1998 09:51:32 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Print gurus, The meeting room charge is $30 per person per day. When you check in at the Hyatt hotel, please inform the hotel person that you are with the "IBM Printer Working Group" and ask for the form to specify meeting room charges. Specify your total charges for the week (number of meeting days you will attend x $30) on the form, sign it, and return it to the hotel person. This charge will then be added to your hotel bill. For those who are not staying at the hotel, the chair of each PWG meeting will ask you to complete the form and return it to them with a check payable to the "Hyatt". There will be no charge for the UPD meeting on the evening of March 3 since we are using the same room as the 1394 working group. The meeting rooms by day are as follows: March 2-5 Texas 5 March 6 Foothills 1 Directions to these rooms should be on the meeting board in the lobby under "IBM Printer Working Group" or ask the hotel desk. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Fri Feb 20 10:17:09 1998 Delivery-Date: Fri, 20 Feb 1998 10:17:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11193 for ; Fri, 20 Feb 1998 10:17:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21123 for ; Fri, 20 Feb 1998 10:19:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA25289 for ; Fri, 20 Feb 1998 10:17:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 09:52:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22430 for ipp-outgoing; Fri, 20 Feb 1998 09:52:28 -0500 (EST) Message-ID: <34ED98A0.8278E4F7@underscore.com> Date: Fri, 20 Feb 1998 09:52:16 -0500 From: "Jeffrey D. Schnitzer" Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Carter CC: p1394@pwg.org, pwg@pwg.org, fin@pwg.org, jmp@pwg.org, ipp@pwg.org, upd@pwg.org Subject: UPD mailing list (was IPP> UPD meeting) References: <5040300012861326000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Keith Carter asked: > > Is there a UPD mailing list? > The UPD mailing list is . To add yourself to the list, send mail to with the following as the body of the message: subscribe upd end The list has been in place since May'97, but there was little traffic on it. It's hypermail archive is at: http://www.pwg.org/hypermail/upd /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From ipp-owner@pwg.org Fri Feb 20 10:19:00 1998 Delivery-Date: Fri, 20 Feb 1998 10:19:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11204 for ; Fri, 20 Feb 1998 10:18:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21133 for ; Fri, 20 Feb 1998 10:21:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA25544 for ; Fri, 20 Feb 1998 10:18:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 09:55:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22654 for ipp-outgoing; Fri, 20 Feb 1998 09:54:41 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> Meeting room information for PWG meeting in Austin on 3/2-6 Message-ID: <5040300012862927000002L072*@MHS> Date: Fri, 20 Feb 1998 09:51:32 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Print gurus, The meeting room charge is $30 per person per day. When you check in at the Hyatt hotel, please inform the hotel person that you are with the "IBM Printer Working Group" and ask for the form to specify meeting room charges. Specify your total charges for the week (number of meeting days you will attend x $30) on the form, sign it, and return it to the hotel person. This charge will then be added to your hotel bill. For those who are not staying at the hotel, the chair of each PWG meeting will ask you to complete the form and return it to them with a check payable to the "Hyatt". There will be no charge for the UPD meeting on the evening of March 3 since we are using the same room as the 1394 working group. The meeting rooms by day are as follows: March 2-5 Texas 5 March 6 Foothills 1 Directions to these rooms should be on the meeting board in the lobby under "IBM Printer Working Group" or ask the hotel desk. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From pwg-owner@pwg.org Fri Feb 20 10:20:35 1998 Delivery-Date: Fri, 20 Feb 1998 10:20:35 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11216 for ; Fri, 20 Feb 1998 10:20:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21137 for ; Fri, 20 Feb 1998 10:23:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA25796 for ; Fri, 20 Feb 1998 10:20:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 10:09:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22482 for pwg-outgoing; Fri, 20 Feb 1998 09:52:59 -0500 (EST) Message-ID: <34ED98A0.8278E4F7@underscore.com> Date: Fri, 20 Feb 1998 09:52:16 -0500 From: "Jeffrey D. Schnitzer" Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Carter CC: p1394@pwg.org, pwg@pwg.org, fin@pwg.org, jmp@pwg.org, ipp@pwg.org, upd@pwg.org Subject: PWG> UPD mailing list (was IPP> UPD meeting) References: <5040300012861326000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pwg@pwg.org Keith Carter asked: > > Is there a UPD mailing list? > The UPD mailing list is . To add yourself to the list, send mail to with the following as the body of the message: subscribe upd end The list has been in place since May'97, but there was little traffic on it. It's hypermail archive is at: http://www.pwg.org/hypermail/upd /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From pwg-owner@pwg.org Fri Feb 20 10:22:12 1998 Delivery-Date: Fri, 20 Feb 1998 10:22:12 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA11231 for ; Fri, 20 Feb 1998 10:22:11 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21144 for ; Fri, 20 Feb 1998 10:24:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA26015 for ; Fri, 20 Feb 1998 10:22:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 10:17:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22524 for pwg-outgoing; Fri, 20 Feb 1998 09:53:25 -0500 (EST) From: Keith Carter To: , , , , Subject: PWG> Meeting room information for PWG meeting in Austin on 3/2-6 Message-ID: <5040300012862927000002L072*@MHS> Date: Fri, 20 Feb 1998 09:51:32 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Print gurus, The meeting room charge is $30 per person per day. When you check in at the Hyatt hotel, please inform the hotel person that you are with the "IBM Printer Working Group" and ask for the form to specify meeting room charges. Specify your total charges for the week (number of meeting days you will attend x $30) on the form, sign it, and return it to the hotel person. This charge will then be added to your hotel bill. For those who are not staying at the hotel, the chair of each PWG meeting will ask you to complete the form and return it to them with a check payable to the "Hyatt". There will be no charge for the UPD meeting on the evening of March 3 since we are using the same room as the 1394 working group. The meeting rooms by day are as follows: March 2-5 Texas 5 March 6 Foothills 1 Directions to these rooms should be on the meeting board in the lobby under "IBM Printer Working Group" or ask the hotel desk. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From jmp-owner@pwg.org Fri Feb 20 13:18:17 1998 Delivery-Date: Fri, 20 Feb 1998 13:18:17 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12954 for ; Fri, 20 Feb 1998 13:18:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA22214 for ; Fri, 20 Feb 1998 13:20:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28035 for ; Fri, 20 Feb 1998 13:18:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 13:14:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27342 for jmp-outgoing; Fri, 20 Feb 1998 13:10:49 -0500 (EST) Message-Id: <3.0.1.32.19980220095629.010bf100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Feb 1998 09:56:29 PST To: ipp@pwg.org, jmp@pwg.org, pmp@pwg.org From: Tom Hastings Subject: JMP> I've uploaded newest Ira McDonald's tools for producing IETF txt files Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: jmp-owner@pwg.org Ira has updated his tools, including fixing a bug, to: ftp://ftp.pwg.org/pub/pwg/tools/cscan.exe ftp://ftp.pwg.org/pub/pwg/tools/maxln.exe ftp://ftp.pwg.org/pub/pwg/tools/overx.exe ftp://ftp.pwg.org/pub/pwg/tools/strip.exe ftp://ftp.pwg.org/pub/pwg/tools/readme.txt These help in producing .txt files that follow IETF rules for ASCII files, with no special characters, and no lines longer than 72 characters. Here is the readme.txt file: Hi folks, Thursday (29 January 1998) The following files are in '/pub/pwg/tools/ (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility Each of the programs has a -h option which explains the command line. Sometimes, MIBs produced with MS-WORD cannot be successfully stripped of headers and footers. The fix is to run my text utility 'overx', which folds line fragemnts from overstrike lines (fragments end in single carriage returns, without a following linefeed/newline) to combine them into a single canonical line - the 'generic text driver' with some or all versions of MS Word yields such overstrike lines when used with Tom's styles - I wrote 'overx' last year, to help Tom out - these latest Job Mon files caused me to find and fix a small bug in 'overx'. Ira McDonald, outside consultant to Xerox Corp. From pmp-owner@pwg.org Fri Feb 20 13:19:05 1998 Delivery-Date: Fri, 20 Feb 1998 13:19:06 -0500 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12972 for ; Fri, 20 Feb 1998 13:19:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA22225 for ; Fri, 20 Feb 1998 13:21:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28156 for ; Fri, 20 Feb 1998 13:19:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 13:16:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27384 for pmp-outgoing; Fri, 20 Feb 1998 13:11:16 -0500 (EST) Message-Id: <3.0.1.32.19980220095629.010bf100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Feb 1998 09:56:29 PST To: ipp@pwg.org, jmp@pwg.org, pmp@pwg.org From: Tom Hastings Subject: PMP> I've uploaded newest Ira McDonald's tools for producing IETF txt files Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: pmp-owner@pwg.org Ira has updated his tools, including fixing a bug, to: ftp://ftp.pwg.org/pub/pwg/tools/cscan.exe ftp://ftp.pwg.org/pub/pwg/tools/maxln.exe ftp://ftp.pwg.org/pub/pwg/tools/overx.exe ftp://ftp.pwg.org/pub/pwg/tools/strip.exe ftp://ftp.pwg.org/pub/pwg/tools/readme.txt These help in producing .txt files that follow IETF rules for ASCII files, with no special characters, and no lines longer than 72 characters. Here is the readme.txt file: Hi folks, Thursday (29 January 1998) The following files are in '/pub/pwg/tools/ (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility Each of the programs has a -h option which explains the command line. Sometimes, MIBs produced with MS-WORD cannot be successfully stripped of headers and footers. The fix is to run my text utility 'overx', which folds line fragemnts from overstrike lines (fragments end in single carriage returns, without a following linefeed/newline) to combine them into a single canonical line - the 'generic text driver' with some or all versions of MS Word yields such overstrike lines when used with Tom's styles - I wrote 'overx' last year, to help Tom out - these latest Job Mon files caused me to find and fix a small bug in 'overx'. Ira McDonald, outside consultant to Xerox Corp. From ipp-owner@pwg.org Fri Feb 20 13:20:49 1998 Delivery-Date: Fri, 20 Feb 1998 13:20:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12982 for ; Fri, 20 Feb 1998 13:20:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA22236 for ; Fri, 20 Feb 1998 13:23:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28388 for ; Fri, 20 Feb 1998 13:20:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 13:11:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27363 for ipp-outgoing; Fri, 20 Feb 1998 13:11:01 -0500 (EST) Message-Id: <3.0.1.32.19980220095629.010bf100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Feb 1998 09:56:29 PST To: ipp@pwg.org, jmp@pwg.org, pmp@pwg.org From: Tom Hastings Subject: IPP> I've uploaded newest Ira McDonald's tools for producing IETF txt files Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Ira has updated his tools, including fixing a bug, to: ftp://ftp.pwg.org/pub/pwg/tools/cscan.exe ftp://ftp.pwg.org/pub/pwg/tools/maxln.exe ftp://ftp.pwg.org/pub/pwg/tools/overx.exe ftp://ftp.pwg.org/pub/pwg/tools/strip.exe ftp://ftp.pwg.org/pub/pwg/tools/readme.txt These help in producing .txt files that follow IETF rules for ASCII files, with no special characters, and no lines longer than 72 characters. Here is the readme.txt file: Hi folks, Thursday (29 January 1998) The following files are in '/pub/pwg/tools/ (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility Each of the programs has a -h option which explains the command line. Sometimes, MIBs produced with MS-WORD cannot be successfully stripped of headers and footers. The fix is to run my text utility 'overx', which folds line fragemnts from overstrike lines (fragments end in single carriage returns, without a following linefeed/newline) to combine them into a single canonical line - the 'generic text driver' with some or all versions of MS Word yields such overstrike lines when used with Tom's styles - I wrote 'overx' last year, to help Tom out - these latest Job Mon files caused me to find and fix a small bug in 'overx'. Ira McDonald, outside consultant to Xerox Corp. From ipp-owner@pwg.org Fri Feb 20 17:16:46 1998 Delivery-Date: Fri, 20 Feb 1998 17:16:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA18077 for ; Fri, 20 Feb 1998 17:16:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23644 for ; Fri, 20 Feb 1998 17:19:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00537 for ; Fri, 20 Feb 1998 17:16:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Feb 1998 17:11:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29963 for ipp-outgoing; Fri, 20 Feb 1998 17:11:38 -0500 (EST) Message-Id: <1.5.4.16.19980220171209.297f1f7e@Digital-Controls.Com> X-Sender: rich.gray@Digital-Controls.Com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipp@pwg.org From: Rich.Gray@Digital-Controls.Com (Rich Gray) Subject: IPP> Notification Parameter: Time Limit Date: Fri, 20 Feb 1998 17:51:14 -0500 Sender: ipp-owner@pwg.org If I may offer a suggestion: INTERNET DRAFT Roger K deBry IBM Corporation February 19, 1998 ... 127 2.9 Notification Events 128 129 Any of the following constitute events that a Job Submitting End User 130 can specify notifications be sent for. Notifications are sent to an 131 end user only for that end user's job, or for events that affect the 132 processing of that end user's job. 133 134 - Any standard Printer MIB alert (i.e. device events that impact the 135 end user's job) 136 - Job Received (transition from Unknown to Pending or Pending-held) 137 - Job Started (Transition from Pending to Processing) 138 - Page Complete (Page is stacked) 139 - Collated Copy Complete (last sheet of collated copy is stacked) 140 - Job Complete (transition from Processing or Processing-stopped to 141 Completed) 142 - Job aborted (transition from Pending, Pending-held, Processing, 143 or Processing-stopped to Aborted) 144 - Job canceled (transition from Pending, Pending-held, Processing, 145 or Processing-held to Canceled) - The job has not ended (Completed, Aborted, Canceled, etc.) by the user's specified time limit. The resulting notification will inform the notification recipient(s) of the current status of the job but will in no other way affect the job. ... 4.6 I submit a job to a printer in the datacenter. I don't care about any intermediate states the job goes through (such as the fact that the printer ran out of paper and the attendant had to reload it.) I just wish to know that my job has completed successfully (or failed) in a timely manner. If the job does not complete in an hour, I wish to know what is wrong why so I can call the datacenter and complain. I submit the print job with the following attributes: - Notification Recipient - me - Notification Type - immediate - Notification Events - job complete or Time Limit( now + 1 hour ) expired Rich Richard B. Gray, Sr. Software Egr. | Tel: 513/746-8118 ext. 2405 Digital Controls Corporation | Fax: 513/743-8575 305 South Pioneer Blvd. | Net: rich.gray@digital-controls.com Springboro OH 45066-1100, USA | http://www.digital-controls.com From ipp-owner@pwg.org Sun Feb 22 09:48:10 1998 Delivery-Date: Sun, 22 Feb 1998 09:48:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02058 for ; Sun, 22 Feb 1998 09:48:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA00455 for ; Sun, 22 Feb 1998 09:50:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23664 for ; Sun, 22 Feb 1998 09:48:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Feb 1998 09:37:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22470 for ipp-outgoing; Sun, 22 Feb 1998 09:37:47 -0500 (EST) Date: Sun, 22 Feb 1998 23:37:21 +0900 (JST) Message-Id: <199802221437.XAA04248@smtp.dtinet.or.jp> From: Nagasaka Fumio To: "Turner, Randy" Cc: "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" Subject: IPP> Re: PWG> Early ping for april meeting In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.23 Sender: ipp-owner@pwg.org Dear Randy I am going to attend the April meeting, and prefer Embassy Suites/downtown. ----- Fumio Nagasaka EPSON Software Development Laboratory Inc., TEL: +81 268 25-4111 // FAX: +81 268 25-4627 HomePage = http://www.venus.dti.ne.jp/~fumiona/ From pwg-owner@pwg.org Sun Feb 22 09:48:16 1998 Delivery-Date: Sun, 22 Feb 1998 09:48:16 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02063 for ; Sun, 22 Feb 1998 09:48:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA00458 for ; Sun, 22 Feb 1998 09:50:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23679 for ; Sun, 22 Feb 1998 09:48:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Feb 1998 09:42:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22455 for pwg-outgoing; Sun, 22 Feb 1998 09:37:37 -0500 (EST) Date: Sun, 22 Feb 1998 23:37:21 +0900 (JST) Message-Id: <199802221437.XAA04248@smtp.dtinet.or.jp> From: Nagasaka Fumio To: "Turner, Randy" Cc: "'ipp@pwg.org'" , "'pwg@pwg.org'" , "'p1394@pwg.org'" Subject: Re: PWG> Early ping for april meeting In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.23 Sender: owner-pwg@pwg.org Dear Randy I am going to attend the April meeting, and prefer Embassy Suites/downtown. ----- Fumio Nagasaka EPSON Software Development Laboratory Inc., TEL: +81 268 25-4111 // FAX: +81 268 25-4627 HomePage = http://www.venus.dti.ne.jp/~fumiona/ From ipp-owner@pwg.org Mon Feb 23 20:49:00 1998 Delivery-Date: Mon, 23 Feb 1998 20:49:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA01492 for ; Mon, 23 Feb 1998 20:49:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05816 for ; Mon, 23 Feb 1998 20:51:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA10328 for ; Mon, 23 Feb 1998 20:48:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Feb 1998 20:41:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09802 for ipp-outgoing; Mon, 23 Feb 1998 20:41:26 -0500 (EST) Message-Id: <3.0.1.32.19980223173640.00c4a3b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Feb 1998 17:36:40 PST To: ietf@ns.ietf.org From: Carl-Uno Manros Subject: IPP> IETF Proceedings on CD-ROM Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Eureka! I just got a set of IETF proceeedings on CD-ROM. Great news, I can use this as preparation for the upcoming meeting in LA! But wait a second, there is something not quite right here... What I got are the proceeedings from IETF39 in Munich! No 7+ months after the meeting was held, and less than 3 months after IETF40. At least all the stuff is there in a handy format! But wait a second, what happened to my IPP presentation material that I delivered in both hard copy and electronic format? It says Slides: Not received! What happens with the presentation materials that we dutifully deliver? What is wrong with this picture? Has anybody heard about Internet time? Even ISO and ITU are faster than this, but they do not do yet deliver it in fancy HTML format... Seems that the CD-ROMs are for people who want to store historic data in stuffy libraries, but are pretty useless to anybody who tries to follow the actual IETF proceedings. My 2 cents, Carl-Uno Manros Co-Chair IETF IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From owner-ietf-outbound.10 Mon Feb 23 20:46:46 1998 Delivery-Date: Mon, 23 Feb 1998 20:50:36 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id UAA01445 for ietf-outbound.10@ietf.org; Mon, 23 Feb 1998 20:45:02 -0500 (EST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id UAA01398 for ; Mon, 23 Feb 1998 20:41:20 -0500 (EST) Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <52431(4)>; Mon, 23 Feb 1998 17:41:17 PST Received: from garfield.cp10.es.xerox.com (garfield.cp10.es.xerox.com [13.240.104.48]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id RAA24349; Mon, 23 Feb 1998 17:40:11 -0800 (PST) Received: from cpq5100-26 (cpq5100-26 [13.240.120.68]) by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id RAA07968; Mon, 23 Feb 1998 17:35:31 -0800 (PST) Message-Id: <3.0.1.32.19980223173640.00c4a3b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Feb 1998 17:36:40 PST To: ietf@ns.ietf.org From: Carl-Uno Manros Subject: IETF Proceedings on CD-ROM Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Eureka! I just got a set of IETF proceeedings on CD-ROM. Great news, I can use this as preparation for the upcoming meeting in LA! But wait a second, there is something not quite right here... What I got are the proceeedings from IETF39 in Munich! No 7+ months after the meeting was held, and less than 3 months after IETF40. At least all the stuff is there in a handy format! But wait a second, what happened to my IPP presentation material that I delivered in both hard copy and electronic format? It says Slides: Not received! What happens with the presentation materials that we dutifully deliver? What is wrong with this picture? Has anybody heard about Internet time? Even ISO and ITU are faster than this, but they do not do yet deliver it in fancy HTML format... Seems that the CD-ROMs are for people who want to store historic data in stuffy libraries, but are pretty useless to anybody who tries to follow the actual IETF proceedings. My 2 cents, Carl-Uno Manros Co-Chair IETF IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From adm Tue Feb 24 11:03:43 1998 Delivery-Date: Tue, 24 Feb 1998 11:09:15 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA21509 for ietf-123-outbound.10@ietf.org; Tue, 24 Feb 1998 11:02:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20994; Tue, 24 Feb 1998 10:55:23 -0500 (EST) Message-Id: <199802241555.KAA20994@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-framework-03.txt Date: Tue, 24 Feb 1998 10:55:23 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Framework for IP Performance Metrics Author(s) : G. Almes, M. Mathis, J. Mahdavi, V. Paxson Filename : draft-ietf-ippm-framework-03.txt Pages : 38 Date : 23-Feb-98 The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Performance Metrics Working Group (IPPM) of the Transport Area. 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-ippm-framework-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-framework-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippm-framework-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: <19980223153232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980223153232.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Feb 24 21:29:56 1998 Delivery-Date: Tue, 24 Feb 1998 21:29:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA11111 for ; Tue, 24 Feb 1998 21:29:55 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10354 for ; Tue, 24 Feb 1998 21:32:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA26975 for ; Tue, 24 Feb 1998 21:29:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Feb 1998 21:23:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA26445 for ipp-outgoing; Tue, 24 Feb 1998 21:23:13 -0500 (EST) Message-Id: <3.0.1.32.19980224181805.00b4d210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Feb 1998 18:18:05 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference - 980225 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference - 980225 We will run a phone conference this Wednesday, please remember the new time! I want to follow up on some of the home work assignments and to go over what we want to dicuss next week in Austin. Here are the details on the conference call. This one will be at 1PM EST, 10AM PST!! Date: 2/25 Call-in: 1-608-250-1828 Access: 190148 Time: 1PM EST (10AM PST) Duration: 2.5 hours Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Feb 24 21:55:24 1998 Delivery-Date: Tue, 24 Feb 1998 21:55:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA11300 for ; Tue, 24 Feb 1998 21:55:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA10422 for ; Tue, 24 Feb 1998 21:57:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA27606 for ; Tue, 24 Feb 1998 21:55:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Feb 1998 21:51:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27095 for ipp-outgoing; Tue, 24 Feb 1998 21:51:12 -0500 (EST) Message-ID: <34F385CC.96BFB44F@cisco.com> Date: Tue, 24 Feb 1998 18:45:32 -0800 From: Dan Wing Organization: cisco Systems, Inc. X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: "'ipp@pwg.org'" Subject: IPP> Email-based Notification and Internationalization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org The thread on email-based notification has been interesting, but as Larry has pointed out, the problems of internationalization have been solved with DSNs (RFCs 1891-1894, especially 1894) and MDNs (draft-ietf-receipt-mdn-08.txt). The purposes of MDNs, from the Internet Draft: (a) Inform human beings of the disposition of messages after succcessful delivery, in a manner which is largely independent of human language; (b) Allow mail user agents to keep track of the disposition of messages sent, by associating returned MDNs with earlier message transmissions; (c) Convey disposition notification requests and disposition notifications between Internet Mail and "foreign" mail systems via a gateway; (d) Allow "foreign" notifications to be tunneled through a MIME- capable message system and back into the original messaging system that issued the original notification, or even to a third messaging system; (e) Allow language-independent, yet reasonably precise, indications of the disposition of a message to be delivered. RFC1894 or draft-ietf-receipt-mdn-08.txt would both be reasonable starting points to create a notification format that is useful for IPP and follows the requirements of draft-ietf-ipp-not-00.txt. -Dan Wing From ipp-owner@pwg.org Wed Feb 25 10:27:02 1998 Delivery-Date: Wed, 25 Feb 1998 10:27:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA28691 for ; Wed, 25 Feb 1998 10:27:01 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA11869 for ; Wed, 25 Feb 1998 10:29:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10171 for ; Wed, 25 Feb 1998 10:27:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 10:17:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09615 for ipp-outgoing; Wed, 25 Feb 1998 10:17:19 -0500 (EST) Message-Id: <199802251517.KAA28046@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-not-00.txt Date: Wed, 25 Feb 1998 10:17:03 -0500 Sender: ipp-owner@pwg.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 : Requirements for IPP Notifications Author(s) : R. deBry Filename : draft-ietf-ipp-not-00.txt Pages : 8 Date : 24-Feb-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). 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-not-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-not-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: <19980225093724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-not-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-not-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225093724.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Feb 25 10:49:28 1998 Delivery-Date: Wed, 25 Feb 1998 10:53:48 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA29781 for ietf-123-outbound.10@ietf.org; Wed, 25 Feb 1998 10:47:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA28046; Wed, 25 Feb 1998 10:17:05 -0500 (EST) Message-Id: <199802251517.KAA28046@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-not-00.txt Date: Wed, 25 Feb 1998 10:17:03 -0500 Sender: cclark@cnri.reston.va.us --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 : Requirements for IPP Notifications Author(s) : R. deBry Filename : draft-ietf-ipp-not-00.txt Pages : 8 Date : 24-Feb-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). 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-not-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-not-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: <19980225093724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-not-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-not-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225093724.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Feb 25 10:58:19 1998 Delivery-Date: Wed, 25 Feb 1998 10:58:19 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA00386 for ; Wed, 25 Feb 1998 10:58:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA12062 for ; Wed, 25 Feb 1998 11:00:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10858 for ; Wed, 25 Feb 1998 10:58:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 10:53:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10317 for ipp-outgoing; Wed, 25 Feb 1998 10:53:08 -0500 (EST) Message-Id: <3.0.1.32.19980225075230.01223270@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Feb 1998 07:52:30 PST To: Rich.Gray@digital-controls.com (Rich Gray), ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Notification Parameter: Time Limit In-Reply-To: <1.5.4.16.19980220171209.297f1f7e@Digital-Controls.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Sounds like a good extension to IPP and another notification event. A couple of questions: 1. We would need to add a "time-limit" attribute to IPP that the requester can supply. Probably should be a delta in some units like minutes or hours. Which? 2. Probably should be a job-template attribute so that there could be a "time-limit-default" that the administrator could configure, and the "time-limit-supported" would be a range. 3. I assume from your description that the job is not deleted when it exceeds the time-limit, correct? So it is just part of ISO DPA's job-discard-time attribute. Tom At 14:51 02/20/1998 PST, Rich Gray wrote: >If I may offer a suggestion: > > > INTERNET DRAFT Roger K deBry > IBM Corporation > February 19, 1998 >... > > 127 2.9 Notification Events > 128 > 129 Any of the following constitute events that a Job Submitting End User > 130 can specify notifications be sent for. Notifications are sent to an > 131 end user only for that end user's job, or for events that affect the > 132 processing of that end user's job. > 133 > 134 - Any standard Printer MIB alert (i.e. device events that impact the > 135 end user's job) > 136 - Job Received (transition from Unknown to Pending or Pending-held) > 137 - Job Started (Transition from Pending to Processing) > 138 - Page Complete (Page is stacked) > 139 - Collated Copy Complete (last sheet of collated copy is stacked) > 140 - Job Complete (transition from Processing or Processing-stopped to > 141 Completed) > 142 - Job aborted (transition from Pending, Pending-held, Processing, > 143 or Processing-stopped to Aborted) > 144 - Job canceled (transition from Pending, Pending-held, Processing, > 145 or Processing-held to Canceled) > > - The job has not ended (Completed, Aborted, Canceled, etc.) by the >user's > specified time limit. The resulting notification will inform the > notification recipient(s) of the current status of the job but will > in no other way affect the job. > >... > >4.6 I submit a job to a printer in the datacenter. I don't care about any > intermediate states the job goes through (such as the fact that the printer > ran out of paper and the attendant had to reload it.) I just wish to know > that my job has completed successfully (or failed) in a timely manner. > > If the job does not complete in an hour, I wish to know what is wrong > why so I can call the datacenter and complain. > > I submit the print job with the following attributes: > > - Notification Recipient - me > - Notification Type - immediate > - Notification Events - job complete > or Time Limit( now + 1 hour ) expired > > >Rich > >Richard B. Gray, Sr. Software Egr. | Tel: 513/746-8118 ext. 2405 >Digital Controls Corporation | Fax: 513/743-8575 >305 South Pioneer Blvd. | Net: rich.gray@digital-controls.com >Springboro OH 45066-1100, USA | http://www.digital-controls.com > > > From adm Wed Feb 25 11:28:34 1998 Delivery-Date: Wed, 25 Feb 1998 11:31:12 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA02293 for ietf-123-outbound.10@ietf.org; Wed, 25 Feb 1998 11:27:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27983; Wed, 25 Feb 1998 10:16:55 -0500 (EST) Message-Id: <199802251516.KAA27983@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-deflate-02.txt Date: Wed, 25 Feb 1998 10:16:49 -0500 Sender: cclark@cnri.reston.va.us --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 Using DEFLATE Author(s) : R. Pereira Filename : draft-ietf-ippcp-deflate-02.txt Pages : 6 Date : 24-Feb-98 This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. 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-deflate-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippcp-deflate-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-deflate-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980224155106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-deflate-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-deflate-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980224155106.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Feb 25 14:18:00 1998 Delivery-Date: Wed, 25 Feb 1998 14:18:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA07556 for ; Wed, 25 Feb 1998 14:17:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13443 for ; Wed, 25 Feb 1998 14:20:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12116 for ; Wed, 25 Feb 1998 14:17:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 14:13:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11572 for ipp-outgoing; Wed, 25 Feb 1998 14:13:30 -0500 (EST) Message-Id: <3.0.1.32.19980225110809.00c1b6f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Feb 1998 11:08:09 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-v11-spec-rev-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, HTTP 1.1 bug fixes. Carl-Uno >To: IETF-Announce@ns.ietf.org >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-v11-spec-rev-02.txt >Date: Wed, 25 Feb 1998 07:17:43 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group >of the IETF. > > Title : Hypertext Transfer Protocol -- HTTP/1.1 > Author(s) : J. Mogul, T. Berners-Lee, L. Masinter, P. Leach, > R. Fielding, H. Nielsen, J. Gettys > Filename : draft-ietf-http-v11-spec-rev-02.txt > Pages : 155 > Date : 24-Feb-98 > >The Hypertext Transfer Protocol (HTTP) is an application-level protocol >for distributed, collaborative, hypermedia information systems. It is a >generic, stateless, protocol which can be used for many tasks, such as >name servers and distributed object management systems, through >extension of its request methods. A feature of HTTP is the typing and >negotiation of data representation, allowing systems to be built >independently of the data being transferred. > >HTTP has been in use by the World-Wide Web global information initiative >since 1990. This specification defines the protocol referred to as >''HTTP/1.1'', and is an update to RFC2068 [33]. > >At the time of this revision's submission, there were no known outstanding >technical or editorial issues. The HTTP/1.1 issues list, along with >many representations of this specification including Postscript, Microsoft >word, with and without change bars, with or without gzip compression >can be found at http://www.w3.org/Protocols/HTTP/Issues/. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-v11-spec-rev-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-02.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-http-v11-spec-rev-02.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 25 16:29:38 1998 Delivery-Date: Wed, 25 Feb 1998 16:29:39 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA10052 for ; Wed, 25 Feb 1998 16:29:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14127 for ; Wed, 25 Feb 1998 16:32:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13197 for ; Wed, 25 Feb 1998 16:29:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 16:24:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12656 for ipp-outgoing; Wed, 25 Feb 1998 16:23:55 -0500 (EST) Message-Id: <3.0.1.32.19980225131844.00c58ad0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Feb 1998 13:18:44 PST To: , From: Carl-Uno Manros Subject: IPP> Re: 41st IETF-LOS ANGELES, CA: WORKING GROUP SCHEDULING Cc: agenda@ns.ietf.org, ipp@pwg.org In-Reply-To: <199801271810.NAA11098@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Keith & Harald, Here is my official request for an IPP slot in Los Angeles. Carl-Uno --- At 10:10 AM 1/27/98 PST, you wrote: >Scheduling requests for ALL Working Groups and BOFs is currently >taking place. The cut-off for requesting slots is Monday, >March 9 at 5:00 ET. > a. Working Group or BOF name. Include proposed BOF title - 35 > or fewer characters please, and acronym - 8 characters max.); Internet Printing Protocol WG (ipp) > > b. Area under which Working Group (or BOF) appears; Applications > c. Conflicts you wish to avoid, please be as specific as possible. > You will be notified of any conflicts which arise. Conflicts > should then be resolved by the Chairs and the final outcome > sent to: agenda@ietf.org IFAX, HTTP (or closely related), TLS > > d. Expected Attendance (attendance figures from 40th IETF > will be sent at a later time); 40 - 50 > e. Any special requests. (i.e., do you want your session > multicast - mbone slots cannot always be guaranteed; > special seating arrangements). NONE >2. Tuesday will have one-hour sessions. If your working group > or BOF needs to meet for one hour or less it will be scheduled > on Tuesday. Please indicate on your request if you will need > a one-hour session. Requests for two contiguous one-hour > sessions will not be addressed until all one-hour requests > have been accommodated. Prefer one 2 hour slot on Wednesday or Thursday >=============== >1. Applications: The AD's for the Applications Area will be > creating an area track. Groups will not be reflected on > the Agenda until a complete track is submitted to the > Secretariat by the AD. > , Proposed IPP Agenda =================== 1) Review any comments from the IESG concerning the following 5 WG drafts that have been proposed for publication as RFCs: o Internet Printing Protocol/1.0: Protocol Specification as a Proposed Standard. o Internet Printing Protocol/1.0: Model and Semantics as a Proposed Standard. o Requirements for an Internet Printing Protocol as an Informational RFC. o Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol as an Informational RFC. o Mapping between LPD and IPP Protocols as an Informational RFC. 2) Review and discuss proposed requirements for IPP Notifications and entertain proposals for possible existing standarization efforts on which IPP Notifications could be built. o Requirements for IPP Notifications 3) Discuss how to make sure that the generic Directory attributes from the IPP Model & Semantics documents gets mapped to LDAP and SLP 4) Discuss any other future work on IPP ----- Regards, Carl-Uno Manros Co-chair IETF IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 25 17:38:55 1998 Delivery-Date: Wed, 25 Feb 1998 17:38:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA11834 for ; Wed, 25 Feb 1998 17:38:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14557 for ; Wed, 25 Feb 1998 17:41:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14076 for ; Wed, 25 Feb 1998 17:38:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 17:34:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13543 for ipp-outgoing; Wed, 25 Feb 1998 17:34:26 -0500 (EST) Message-Id: <34F49BC8.3FDE007E@dazel.com> Date: Wed, 25 Feb 1998 16:31:36 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Dan Wing Cc: ipp@pwg.org Subject: Re: IPP> Email-based Notification and Internationalization References: <34F385CC.96BFB44F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Dan Wing wrote: > > The thread on email-based notification has been interesting, but as > Larry has pointed out, the problems of internationalization have been > solved with DSNs (RFCs 1891-1894, especially 1894) and MDNs > (draft-ietf-receipt-mdn-08.txt). > > ... I may be a bit dense, but I am having a hard time seeing how MDNs solve the notification problems that we have been discussing. If the answer is simply to use the same idea of a multipart/report MIME type, where one part is human readable, and the other part is machine readable, that is fine. However, if the suggestion is to use the message/disposition-notification MIME type, it just does not work for me. curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Feb 25 17:43:39 1998 Delivery-Date: Wed, 25 Feb 1998 17:43:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA11921 for ; Wed, 25 Feb 1998 17:43:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14577 for ; Wed, 25 Feb 1998 17:46:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14699 for ; Wed, 25 Feb 1998 17:43:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 17:39:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14134 for ipp-outgoing; Wed, 25 Feb 1998 17:39:16 -0500 (EST) Date: Wed, 25 Feb 1998 14:38:29 -0800 From: Dan Wing To: walker@dazel.com CC: IPP@pwg.org Message-Id: <980225143829.20232d21@Cisco.COM> Subject: Re: IPP> Email-based Notification and Internationalization Sender: ipp-owner@pwg.org >I may be a bit dense, but I am having a hard time seeing how MDNs >solve the notification problems that we have been discussing. If >the answer is simply to use the same idea of a multipart/report >MIME type, where one part is human readable, and the other part is >machine readable, that is fine. That's what I had in mind. A half day of cutting and pasting the MDN I-D and RFC1891 could create something quite useful for IPP notifications. >However, if the suggestion is to >use the message/disposition-notification MIME type, it just does >not work for me. Agreed: message/disposition-notification isn't appropriate for IPP notifications. -Dan Wing From ipp-owner@pwg.org Wed Feb 25 17:55:20 1998 Delivery-Date: Wed, 25 Feb 1998 17:55:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA12298 for ; Wed, 25 Feb 1998 17:55:18 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14622 for ; Wed, 25 Feb 1998 17:57:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15389 for ; Wed, 25 Feb 1998 17:55:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 17:51:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14856 for ipp-outgoing; Wed, 25 Feb 1998 17:51:16 -0500 (EST) Message-Id: <34F49FAE.FF8F226E@dazel.com> Date: Wed, 25 Feb 1998 16:48:14 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Tom Hastings Cc: Rich Gray , ipp@pwg.org Subject: Re: IPP> Notification Parameter: Time Limit References: <3.0.1.32.19980225075230.01223270@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom Hastings wrote: > > Sounds like a good extension to IPP and another notification event. > > A couple of questions: > > 1. We would need to add a "time-limit" attribute to IPP that the requester > can supply. Probably should be a delta in some units like minutes > or hours. Which? Actually, with a 32-bit integer data type, I would think that seconds is a mighty fine granularity. > 2. Probably should be a job-template attribute so that there could > be a "time-limit-default" that the administrator could configure, > and the "time-limit-supported" would be a range. Agreed. > 3. I assume from your description that the job is not deleted when it > exceeds the time-limit, correct? So it is just part of ISO DPA's > job-discard-time attribute. Actually, it sounds more like job-deadline-time attribute. If you recall your ISO 10175, This attribute specifies the calendar date and time of day by which the user desires the print-job to be completed. This attribute is treated as a scheduling hint only. If the specified deadline time arrives before completion of the job, the server shall generate the error-past-deadline event for the job, but the current-job-state shall not be changed. ... For me, this brings up the whole issue of work that we thought long and hard over in the DPA discussions, that we seem to be leaving behind. I will be the first to admit that a lot of complexity made its way into the DPA. However, there is also a lot of wisdom that made it in, as well. In this particular area, the whole idea of job-deadline-time, job-discard-time, and job-retention-period are flexible and useful ideas. Anyone want to dredge up their copy of ISO 10175 and pull out their favorite ideas that ought to be carried forward in this new printing protocol? ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Feb 25 18:21:51 1998 Delivery-Date: Wed, 25 Feb 1998 18:21:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13627 for ; Wed, 25 Feb 1998 18:21:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA14744 for ; Wed, 25 Feb 1998 18:24:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16124 for ; Wed, 25 Feb 1998 18:21:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 18:17:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15571 for ipp-outgoing; Wed, 25 Feb 1998 18:17:53 -0500 (EST) Message-Id: <3.0.1.32.19980225151242.0098d520@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Feb 1998 15:12:42 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Meeting in Austin - Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The next IPP meeting is soon upon us and as usual we have been polishing on the Agenda for the meeting, last time in today's phone conference. Here is the result: PWG IPP Meeting in Austin - Agenda ================================== Wednesday, March 3rd - Starting at 1 pm --------------------------------------- Discuss overall printing scenarios and role of host-to-device protocol - Scenario and architecture figures for discussion, Roger deBry and Tom Hastings. - TIPSI presentation, Don Wright. - CPAP presentation, Jay Martin. General discussion about the need for a separate host-to-device protocol and whether any of the existing solutions are sufficient, or could be used after proper extensions. Thursday, March 4th - Starting at 8:30 am ----------------------------------------- IPP Notifications - Discuss content of Requirements document produced by Roger deBry. - Presentation of FAX solution using DSNs and MDNs, Randy Turner. - Presentation of SNMPv3 approach, Randy Turner. Discuss pros and cons of current approaches vs. a new protocol. Directory Mappings for IPP attributes - How an LDAP mapping could be made, Scott Isaacson. - How an SLP mapping could be made, Scott Isaacson. Discuss approach on how to get proper mappings of IPP attributes into LDAP and SLP. Thursday, March 4 - Starting at 1 pm ------------------------------------ Discuss any further IPP extensions that we want to start working on. Review status of the inter-operability testing activities. - Present and discuss proposed plan, Peter Zehler Last minute preparations for the IETF IPP meeting in Los Angeles. NOTE 1: For those not in the phone cnference. We have got word back from Keith Moore that the IESG will not have made a decision about the IPP drafts ij time for our Austin meeting. NOTE 2: Do not forget about the separate meeting on Universal Print Driver on Tuesday evening! Looking forward to see you in Austin, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 25 20:04:20 1998 Delivery-Date: Wed, 25 Feb 1998 20:04:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15281 for ; Wed, 25 Feb 1998 20:04:20 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15013 for ; Wed, 25 Feb 1998 20:06:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17103 for ; Wed, 25 Feb 1998 20:04:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 19:59:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA16547 for ipp-outgoing; Wed, 25 Feb 1998 19:59:33 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 25 Feb 1998 17:26:25 -0700 From: "Scott Isaacson" To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM - PWG IPP Meeting in Austin - Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA15281 Carl-Uno, I thought that I had two more agenda items: - Review the list of "typos" and "minor technical clarifications" that need to be made to the Model document - Review the "other" nofitication efforts (Java Event serivces, CORBA, the Open Group) Also, if the group is interested I could give a short presentation on the event/notification mechanism for NDPS. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Carl-Uno Manros 02/25 4:12 PM >>> The next IPP meeting is soon upon us and as usual we have been polishing on the Agenda for the meeting, last time in today's phone conference. Here is the result: PWG IPP Meeting in Austin - Agenda ================================== Wednesday, March 3rd - Starting at 1 pm --------------------------------------- Discuss overall printing scenarios and role of host-to-device protocol - Scenario and architecture figures for discussion, Roger deBry and Tom Hastings. - TIPSI presentation, Don Wright. - CPAP presentation, Jay Martin. General discussion about the need for a separate host-to-device protocol and whether any of the existing solutions are sufficient, or could be used after proper extensions. Thursday, March 4th - Starting at 8:30 am ----------------------------------------- IPP Notifications - Discuss content of Requirements document produced by Roger deBry. - Presentation of FAX solution using DSNs and MDNs, Randy Turner. - Presentation of SNMPv3 approach, Randy Turner. Discuss pros and cons of current approaches vs. a new protocol. Directory Mappings for IPP attributes - How an LDAP mapping could be made, Scott Isaacson. - How an SLP mapping could be made, Scott Isaacson. Discuss approach on how to get proper mappings of IPP attributes into LDAP and SLP. Thursday, March 4 - Starting at 1 pm ------------------------------------ Discuss any further IPP extensions that we want to start working on. Review status of the inter-operability testing activities. - Present and discuss proposed plan, Peter Zehler Last minute preparations for the IETF IPP meeting in Los Angeles. NOTE 1: For those not in the phone cnference. We have got word back from Keith Moore that the IESG will not have made a decision about the IPP drafts ij time for our Austin meeting. NOTE 2: Do not forget about the separate meeting on Universal Print Driver on Tuesday evening! Looking forward to see you in Austin, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Feb 25 21:43:28 1998 Delivery-Date: Wed, 25 Feb 1998 21:43:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16645 for ; Wed, 25 Feb 1998 21:43:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15164 for ; Wed, 25 Feb 1998 21:46:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA18077 for ; Wed, 25 Feb 1998 21:43:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 21:37:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA17516 for ipp-outgoing; Wed, 25 Feb 1998 21:37:39 -0500 (EST) Date: Wed, 25 Feb 1998 18:42:51 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9802260242.AA06837@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org, pwg@pwg.org Subject: IPP> Sources and Binaries of Ira's text tools Sender: ipp-owner@pwg.org Copies To: pwg@pwg.org ipp@pwg.org hastings@cp10.es.xerox.com Hi folks, Wednesday (25 February 1998) Since several people have asked privately for these in the last week, I just posted the source and MSDOS executables (16-bit versions, built with Mix Power C compiler) of my text tools to the PWG FTP Server in: ftp://ftp.pwg.org/pub/mib/tools Each of these text tools will display a synopsis (usage notes), if invoked without command line arguments (they all require at least one filename) - these usage notes are appended to the end of this note. Each of these text tools will compile on most any C compiler on most any platform. If you use an ANSI/ISO compliant C compiler, they autodetect '__STDC__' and their declarations use full ANSI C function prototypes. 'cscan', 'overx', and 'strip' use BINARY access via 'fread()'. 'maxln' uses TEXT access via 'fgets()'. If you compile for MSDOS (or any other target where text lines are stored in binary files with CR/LF as line terminators, rather than stand-alone LF), define 'OSMSDOS' as a symbol on your command line (to get proper counting/output of line terminators). As Jay Martin suggested, I hereby state that these text tools are provided on an 'as is' basis (although bug reports are very welcome). Cheers, - Ira McDonald (High North Inc, outside consultant at Xerox) ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ The following files are in '/pub/pwg/tools' (Documentation): rel_0225.txt - this release note The following files are in '/pub/pwg/tools' (ANSI C sources): cscan.c - Character Scan Utility maxln.c - Maximum Line Length Scan Utility overx.c - Overstrike Merge Utility strip.c - Control Character Strip Utility The following files are in '/pub/pwg/tools' (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility ------------------------------------------------------------------------ USAGE ------------------------------------------------------------------------ Usage: cscan [-v] filename ... -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: cscan -v myfile.txt >myfile.log (scan 'myfile.txt', verbose log output to file 'myfile.log') 'cscan' is a utility to count print/control/graphic chars Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: maxln [-nn] [-v] filename ... -nn Fence column - longest desired line length (decimal number, defaults to column 72) -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: maxln -72 -v myfile.txt >myfile.log (fence in column 72, verbose log output to file 'myfile.log') 'maxln' is a utility to detect overlength lines in text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: overx [-cdgv] filename ... filename = < file_root.file_ext > -c Replace each control char with a space (' ') else, replace control char with a dot ('.') -d Replace each DEL char with a space (' ') else, replace DEL char with a dot ('.') -g Replace each graphic char with a space (' ') else, replace graphic char with a dot ('.') -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: overx -v myfile.txt >myfile.log (merge 'myfile.txt', verbose log to file 'myfile.log', new merged version to 'myfile.out') Note: The 'overx' result is written to 'file_root.out' 'overx' is a utility to merge overstrike lines in text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: strip [-ftv] filename ... filename = < file_root.file_ext > -f Replace each FORMFEED with one SPACE else, copy each FORMFEED 'as is' -t Replace each TAB with one SPACE else, copy each TAB 'as is' -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: strip -v myfile.txt >myfile.log (strip 'myfile.txt', verbose log to file 'myfile.log', new 'stripped' version to 'myfile.out') Note: The 'stripped' result is written to 'file_root.out' 'strip' is a utility to remove control characters from text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ From pwg-owner@pwg.org Wed Feb 25 21:47:56 1998 Delivery-Date: Wed, 25 Feb 1998 21:48:00 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA16695 for ; Wed, 25 Feb 1998 21:47:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15174 for ; Wed, 25 Feb 1998 21:50:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA18483 for ; Wed, 25 Feb 1998 21:47:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Feb 1998 21:44:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA17524 for pwg-outgoing; Wed, 25 Feb 1998 21:37:45 -0500 (EST) Date: Wed, 25 Feb 1998 18:42:51 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9802260242.AA06837@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org, pwg@pwg.org Subject: PWG> Sources and Binaries of Ira's text tools Sender: owner-pwg@pwg.org Copies To: pwg@pwg.org ipp@pwg.org hastings@cp10.es.xerox.com Hi folks, Wednesday (25 February 1998) Since several people have asked privately for these in the last week, I just posted the source and MSDOS executables (16-bit versions, built with Mix Power C compiler) of my text tools to the PWG FTP Server in: ftp://ftp.pwg.org/pub/mib/tools Each of these text tools will display a synopsis (usage notes), if invoked without command line arguments (they all require at least one filename) - these usage notes are appended to the end of this note. Each of these text tools will compile on most any C compiler on most any platform. If you use an ANSI/ISO compliant C compiler, they autodetect '__STDC__' and their declarations use full ANSI C function prototypes. 'cscan', 'overx', and 'strip' use BINARY access via 'fread()'. 'maxln' uses TEXT access via 'fgets()'. If you compile for MSDOS (or any other target where text lines are stored in binary files with CR/LF as line terminators, rather than stand-alone LF), define 'OSMSDOS' as a symbol on your command line (to get proper counting/output of line terminators). As Jay Martin suggested, I hereby state that these text tools are provided on an 'as is' basis (although bug reports are very welcome). Cheers, - Ira McDonald (High North Inc, outside consultant at Xerox) ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ The following files are in '/pub/pwg/tools' (Documentation): rel_0225.txt - this release note The following files are in '/pub/pwg/tools' (ANSI C sources): cscan.c - Character Scan Utility maxln.c - Maximum Line Length Scan Utility overx.c - Overstrike Merge Utility strip.c - Control Character Strip Utility The following files are in '/pub/pwg/tools' (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility ------------------------------------------------------------------------ USAGE ------------------------------------------------------------------------ Usage: cscan [-v] filename ... -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: cscan -v myfile.txt >myfile.log (scan 'myfile.txt', verbose log output to file 'myfile.log') 'cscan' is a utility to count print/control/graphic chars Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: maxln [-nn] [-v] filename ... -nn Fence column - longest desired line length (decimal number, defaults to column 72) -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: maxln -72 -v myfile.txt >myfile.log (fence in column 72, verbose log output to file 'myfile.log') 'maxln' is a utility to detect overlength lines in text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: overx [-cdgv] filename ... filename = < file_root.file_ext > -c Replace each control char with a space (' ') else, replace control char with a dot ('.') -d Replace each DEL char with a space (' ') else, replace DEL char with a dot ('.') -g Replace each graphic char with a space (' ') else, replace graphic char with a dot ('.') -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: overx -v myfile.txt >myfile.log (merge 'myfile.txt', verbose log to file 'myfile.log', new merged version to 'myfile.out') Note: The 'overx' result is written to 'file_root.out' 'overx' is a utility to merge overstrike lines in text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ Usage: strip [-ftv] filename ... filename = < file_root.file_ext > -f Replace each FORMFEED with one SPACE else, copy each FORMFEED 'as is' -t Replace each TAB with one SPACE else, copy each TAB 'as is' -v Verbose log output mode (HINT - redirect verbose log output to a file) Ex: strip -v myfile.txt >myfile.log (strip 'myfile.txt', verbose log to file 'myfile.log', new 'stripped' version to 'myfile.out') Note: The 'stripped' result is written to 'file_root.out' 'strip' is a utility to remove control characters from text files Copyright (c) 1998 by Ira E McDonald (High North Inc) ------------------------------------------------------------------------ From ipp-owner@pwg.org Thu Feb 26 07:30:42 1998 Delivery-Date: Thu, 26 Feb 1998 07:30:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA29228 for ; Thu, 26 Feb 1998 07:30:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA15955 for ; Thu, 26 Feb 1998 07:33:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA02408 for ; Thu, 26 Feb 1998 07:30:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 07:20:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA01853 for ipp-outgoing; Thu, 26 Feb 1998 07:20:03 -0500 (EST) Mime-Version: 1.0 Date: Thu, 26 Feb 1998 07:16:40 -0500 Message-ID: <00045942.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re[2]: IPP> ADM - PWG IPP Meeting in Austin - Agenda To: ipp@pwg.org, "Scott Isaacson" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Scott, I would certainly appreciate a presentation on event-notification in NDPS, and the other ones (Java event services, CORBA events) Philip ______________________________ Reply Separator _________________________________ Subject: Re: IPP> ADM - PWG IPP Meeting in Austin - Agenda Author: "Scott Isaacson" at INTERNET Date: 2/25/98 5:26 PM Carl-Uno, I thought that I had two more agenda items: - Review the list of "typos" and "minor technical clarifications" that need to be made to the Model document - Review the "other" nofitication efforts (Java Event serivces, CORBA, the Open Group) Also, if the group is interested I could give a short presentation on the event/notification mechanism for NDPS. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Carl-Uno Manros 02/25 4:12 PM >>> The next IPP meeting is soon upon us and as usual we have been polishing on the Agenda for the meeting, last time in today's phone conference. Here is the result: PWG IPP Meeting in Austin - Agenda ================================== Wednesday, March 3rd - Starting at 1 pm --------------------------------------- Discuss overall printing scenarios and role of host-to-device protocol - Scenario and architecture figures for discussion, Roger deBry and Tom Hastings. - TIPSI presentation, Don Wright. - CPAP presentation, Jay Martin. General discussion about the need for a separate host-to-device protocol and whether any of the existing solutions are sufficient, or could be used after proper extensions. Thursday, March 4th - Starting at 8:30 am ----------------------------------------- IPP Notifications - Discuss content of Requirements document produced by Roger deBry. - Presentation of FAX solution using DSNs and MDNs, Randy Turner. - Presentation of SNMPv3 approach, Randy Turner. Discuss pros and cons of current approaches vs. a new protocol. Directory Mappings for IPP attributes - How an LDAP mapping could be made, Scott Isaacson. - How an SLP mapping could be made, Scott Isaacson. Discuss approach on how to get proper mappings of IPP attributes into LDAP and SLP. Thursday, March 4 - Starting at 1 pm ------------------------------------ Discuss any further IPP extensions that we want to start working on. Review status of the inter-operability testing activities. - Present and discuss proposed plan, Peter Zehler Last minute preparations for the IETF IPP meeting in Los Angeles. NOTE 1: For those not in the phone cnference. We have got word back from Keith Moore that the IESG will not have made a decision about the IPP drafts ij time for our Austin meeting. NOTE 2: Do not forget about the separate meeting on Universal Print Driver on Tuesday evening! Looking forward to see you in Austin, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 26 08:20:45 1998 Delivery-Date: Thu, 26 Feb 1998 08:20:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA29688 for ; Thu, 26 Feb 1998 08:20:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA16088 for ; Thu, 26 Feb 1998 08:23:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA03196 for ; Thu, 26 Feb 1998 08:20:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 08:16:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA02669 for ipp-outgoing; Thu, 26 Feb 1998 08:16:13 -0500 (EST) Mime-Version: 1.0 Date: Thu, 26 Feb 1998 08:12:18 -0500 Message-ID: <00045977.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) Subject: Re: IPP> ADM - PWG IPP Meeting in Austin - Agenda To: ipp@pwg.org, Carl-Uno Manros Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org Carl-Uno, The IPP agenda indicates that the meeting starts only at 1pm on Wednesday (instead of the usual morning start). Is that correct? Philip Thambidurai ______________________________ Reply Separator _________________________________ Subject: IPP> ADM - PWG IPP Meeting in Austin - Agenda Author: Carl-Uno Manros at INTERNET Date: 2/25/98 3:12 PM The next IPP meeting is soon upon us and as usual we have been polishing on the Agenda for the meeting, last time in today's phone conference. Here is the result: PWG IPP Meeting in Austin - Agenda ================================== Wednesday, March 3rd - Starting at 1 pm --------------------------------------- Discuss overall printing scenarios and role of host-to-device protocol - Scenario and architecture figures for discussion, Roger deBry and Tom Hastings. - TIPSI presentation, Don Wright. - CPAP presentation, Jay Martin. General discussion about the need for a separate host-to-device protocol and whether any of the existing solutions are sufficient, or could be used after proper extensions. Thursday, March 4th - Starting at 8:30 am ----------------------------------------- IPP Notifications - Discuss content of Requirements document produced by Roger deBry. - Presentation of FAX solution using DSNs and MDNs, Randy Turner. - Presentation of SNMPv3 approach, Randy Turner. Discuss pros and cons of current approaches vs. a new protocol. Directory Mappings for IPP attributes - How an LDAP mapping could be made, Scott Isaacson. - How an SLP mapping could be made, Scott Isaacson. Discuss approach on how to get proper mappings of IPP attributes into LDAP and SLP. Thursday, March 4 - Starting at 1 pm ------------------------------------ Discuss any further IPP extensions that we want to start working on. Review status of the inter-operability testing activities. - Present and discuss proposed plan, Peter Zehler Last minute preparations for the IETF IPP meeting in Los Angeles. NOTE 1: For those not in the phone cnference. We have got word back from Keith Moore that the IESG will not have made a decision about the IPP drafts ij time for our Austin meeting. NOTE 2: Do not forget about the separate meeting on Universal Print Driver on Tuesday evening! Looking forward to see you in Austin, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 26 08:33:44 1998 Delivery-Date: Thu, 26 Feb 1998 08:33:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA29926 for ; Thu, 26 Feb 1998 08:33:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA16131 for ; Thu, 26 Feb 1998 08:36:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA03851 for ; Thu, 26 Feb 1998 08:33:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 08:29:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA03311 for ipp-outgoing; Thu, 26 Feb 1998 08:29:36 -0500 (EST) From: don@lexmark.com Message-Id: <199802261329.AA05731@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 26 Feb 1998 08:28:40 -0500 Subject: IPP> Presentation on TIPSI for the Austin Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Since I always complain when people wait until the night before the meeting to post their presentation, I thought I'd set the right example. I have placed a PDF copy of my presentation on TIPSI which I will make at the Austin meeting on the Lexmark ftp server as: ftp://ftp.lexmark.com/pub/ieee/1284.1/pwg12841.pdf This server also contains other information on IEEE Std 1284.1-1997. This particular set of charts is an updated version of a presentation I gave a year or so ago at the IEEE 1284 Implementors Forum. I have updated the standard's name, status, etc. Since this is not a PWG project (at least not now) but rather an IEEE project, I think leaving in on the 1284.1 server is best. To Ira and others: I am sorry, this is a PDF of my Freelance charts and as such there are lots of pictures and such which simply don't translate to ASCII text. There is no text version. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Thu Feb 26 10:47:01 1998 Delivery-Date: Thu, 26 Feb 1998 10:47:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA07233 for ; Thu, 26 Feb 1998 10:46:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA16818 for ; Thu, 26 Feb 1998 10:49:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA05451 for ; Thu, 26 Feb 1998 10:46:58 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 10:40:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04728 for ipp-outgoing; Thu, 26 Feb 1998 10:39:59 -0500 (EST) Message-Id: <1.5.4.32.19980226153929.0072878c@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, 26 Feb 1998 07:39:29 -0800 To: "Scott Isaacson" , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM - PWG IPP Meeting in Austin - Agenda Sender: ipp-owner@pwg.org Scott, You are right. Please add these two items to the agenda for Thursday. Carl-Uno At 05:26 PM 2/25/98 -0700, you wrote: >Carl-Uno, > >I thought that I had two more agenda items: > >- Review the list of "typos" and "minor technical clarifications" that need to be made to the Model document > >- Review the "other" nofitication efforts (Java Event serivces, CORBA, the Open Group) > >Also, if the group is interested I could give a short presentation on the event/notification mechanism for NDPS. > >Scott > >************************************************************ >Scott A. Isaacson >Corporate Architect >Novell Inc., M/S PRV-C-121 >122 E 1700 S, Provo, UT 84606 >voice: (801) 861-7366, (800) 453-1267 x17366 >fax: (801) 861-2517 >email: sisaacson@novell.com >web: http://www.novell.com >************************************************************ > > >>>> Carl-Uno Manros 02/25 4:12 PM >>> >The next IPP meeting is soon upon us and as usual we have been polishing on >the Agenda for the meeting, last time in today's phone conference. > >Here is the result: > >PWG IPP Meeting in Austin - Agenda >================================== > >Wednesday, March 3rd - Starting at 1 pm >--------------------------------------- > >Discuss overall printing scenarios and role of host-to-device protocol > >- Scenario and architecture figures for discussion, Roger deBry and Tom >Hastings. >- TIPSI presentation, Don Wright. >- CPAP presentation, Jay Martin. > >General discussion about the need for a separate host-to-device protocol >and whether any of the existing solutions are sufficient, or could be used >after proper extensions. > >Thursday, March 4th - Starting at 8:30 am >----------------------------------------- > >IPP Notifications > >- Discuss content of Requirements document produced by Roger deBry. >- Presentation of FAX solution using DSNs and MDNs, Randy Turner. >- Presentation of SNMPv3 approach, Randy Turner. > >Discuss pros and cons of current approaches vs. a new protocol. > >Directory Mappings for IPP attributes > >- How an LDAP mapping could be made, Scott Isaacson. >- How an SLP mapping could be made, Scott Isaacson. > >Discuss approach on how to get proper mappings of IPP attributes into LDAP >and SLP. > >Thursday, March 4 - Starting at 1 pm >------------------------------------ > >Discuss any further IPP extensions that we want to start working on. > >Review status of the inter-operability testing activities. > >- Present and discuss proposed plan, Peter Zehler > >Last minute preparations for the IETF IPP meeting in Los Angeles. > >NOTE 1: For those not in the phone cnference. We have got word back from >Keith Moore that the IESG will not have made a decision about the IPP >drafts ij time for our Austin meeting. > >NOTE 2: Do not forget about the separate meeting on Universal Print Driver >on Tuesday evening! > >Looking forward to see you in Austin, > >Carl-Uno > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > > From ipp-owner@pwg.org Thu Feb 26 10:51:05 1998 Delivery-Date: Thu, 26 Feb 1998 10:51:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA07520 for ; Thu, 26 Feb 1998 10:51:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA16857 for ; Thu, 26 Feb 1998 10:53:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA05889 for ; Thu, 26 Feb 1998 10:51:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 10:44:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA05141 for ipp-outgoing; Thu, 26 Feb 1998 10:44:35 -0500 (EST) Message-Id: <1.5.4.32.19980226154455.00984898@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, 26 Feb 1998 07:44:55 -0800 To: pthambid@okidata.com (Philip Thambidurai) From: Carl-Uno Manros Subject: Re: IPP> ADM - PWG IPP Meeting in Austin - Agenda Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Philip, Yes this is correct, the Wednesday morning slot is for overall PWG matters rather than IPP. Carl-Uno At 08:12 AM 2/26/98 -0500, you wrote: > Carl-Uno, > > The IPP agenda indicates that the meeting starts only at 1pm on > Wednesday (instead of the usual morning start). Is that correct? > > Philip Thambidurai > > >______________________________ Reply Separator _________________________________ >Subject: IPP> ADM - PWG IPP Meeting in Austin - Agenda >Author: Carl-Uno Manros at INTERNET >Date: 2/25/98 3:12 PM > > >The next IPP meeting is soon upon us and as usual we have been polishing on >the Agenda for the meeting, last time in today's phone conference. > >Here is the result: > >PWG IPP Meeting in Austin - Agenda >================================== > >Wednesday, March 3rd - Starting at 1 pm >--------------------------------------- > >Discuss overall printing scenarios and role of host-to-device protocol > >- Scenario and architecture figures for discussion, Roger deBry and Tom >Hastings. >- TIPSI presentation, Don Wright. >- CPAP presentation, Jay Martin. > >General discussion about the need for a separate host-to-device protocol >and whether any of the existing solutions are sufficient, or could be used >after proper extensions. > >Thursday, March 4th - Starting at 8:30 am >----------------------------------------- > >IPP Notifications > >- Discuss content of Requirements document produced by Roger deBry. >- Presentation of FAX solution using DSNs and MDNs, Randy Turner. >- Presentation of SNMPv3 approach, Randy Turner. > >Discuss pros and cons of current approaches vs. a new protocol. > >Directory Mappings for IPP attributes > >- How an LDAP mapping could be made, Scott Isaacson. >- How an SLP mapping could be made, Scott Isaacson. > >Discuss approach on how to get proper mappings of IPP attributes into LDAP >and SLP. > >Thursday, March 4 - Starting at 1 pm >------------------------------------ > >Discuss any further IPP extensions that we want to start working on. > >Review status of the inter-operability testing activities. > >- Present and discuss proposed plan, Peter Zehler > >Last minute preparations for the IETF IPP meeting in Los Angeles. > >NOTE 1: For those not in the phone cnference. We have got word back from >Keith Moore that the IESG will not have made a decision about the IPP >drafts ij time for our Austin meeting. > >NOTE 2: Do not forget about the separate meeting on Universal Print Driver >on Tuesday evening! > >Looking forward to see you in Austin, > >Carl-Uno > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Thu Feb 26 12:21:30 1998 Delivery-Date: Thu, 26 Feb 1998 12:21:31 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA11347 for ; Thu, 26 Feb 1998 12:21:30 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17383 for ; Thu, 26 Feb 1998 12:24:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06955 for ; Thu, 26 Feb 1998 12:21:26 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 12:16:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06416 for ipp-outgoing; Thu, 26 Feb 1998 12:16:10 -0500 (EST) Message-Id: <3.0.1.32.19980226090942.00cd8a10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Feb 1998 09:09:42 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-luotonen-web-proxy-tunneling-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >To: IETF-Announce@ns.ietf.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-luotonen-web-proxy-tunneling-00.txt >Date: Thu, 26 Feb 1998 06:26:42 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Tunneling TCP based protocols through Web proxy servers > Author(s) : A. Luotonen > Filename : draft-luotonen-web-proxy-tunneling-00.txt > Pages : 9 > Date : 25-Feb-98 > > This document specifies a generic tunneling mechanism for TCP based > protocols through Web proxy servers. This tunneling mechanism was > initially introduced for the SSL protocol [SSL] to allow secure Web > traffic to pass through firewalls, but its utility is not limited to > SSL. Earlier drafts of this specification were titled ''Tunneling SSL > through Web Proxy Servers'' . > Implementations of this tunneling feature are commonly referred to as > ''SSL tunneling'', although, again, it can be used for tunneling any > TCP based protocol. > > A wide variety of existing client and proxy server implementations > conform to this specification. The purpose of this specification is > to describe the current practice, to propose some good practices for > implementing this specification, and to document the security > considerations that are involved with this protocol. > >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-luotonen-web-proxy-tunneling-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-luotonen-web-proxy-tunneling-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > 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-luotonen-web-proxy-tunneling-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. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Feb 26 13:01:57 1998 Delivery-Date: Thu, 26 Feb 1998 13:01:58 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12363 for ; Thu, 26 Feb 1998 13:01:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17555 for ; Thu, 26 Feb 1998 13:04:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA07911 for ; Thu, 26 Feb 1998 13:01:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 12:56:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07370 for ipp-outgoing; Thu, 26 Feb 1998 12:56:47 -0500 (EST) Message-Id: <3.0.1.32.19980226094039.0096ce80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Feb 1998 09:40:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Universal Print Driver session in Austin on Tuesday night Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi all, I have just spoken to Don Wright about who chairs the UPD meeting. Don will, so that issue is settled. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From adm Thu Feb 26 13:49:04 1998 Delivery-Date: Thu, 26 Feb 1998 13:52:18 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA13526 for ietf-123-outbound.10@ietf.org; Thu, 26 Feb 1998 13:47:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02332; Thu, 26 Feb 1998 09:26:41 -0500 (EST) Message-Id: <199802261426.JAA02332@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-lzs-04.txt Date: Thu, 26 Feb 1998 09:26:37 -0500 Sender: cclark@cnri.reston.va.us --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 Using LZS Author(s) : R. Friend, R. Monsour Filename : draft-ietf-ippcp-lzs-04.txt Pages : 7 Date : 25-Feb-98 This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. 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-lzs-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippcp-lzs-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-lzs-04.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: <19980225141035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-lzs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-lzs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225141035.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Feb 26 13:53:32 1998 Delivery-Date: Thu, 26 Feb 1998 13:56:27 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA13750 for ietf-123-outbound.10@ietf.org; Thu, 26 Feb 1998 13:52:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02689; Thu, 26 Feb 1998 09:29:47 -0500 (EST) Message-Id: <199802261429.JAA02689@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ippcp@external.cisco.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-deflate-03.txt Date: Thu, 26 Feb 1998 09:29:47 -0500 Sender: cclark@cnri.reston.va.us --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 Using DEFLATE Author(s) : R. Pereira Filename : draft-ietf-ippcp-deflate-03.txt Pages : 6 Date : 25-Feb-98 This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. 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-deflate-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippcp-deflate-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-deflate-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: <19980225155359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-deflate-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-deflate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225155359.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Thu Feb 26 14:09:11 1998 Delivery-Date: Thu, 26 Feb 1998 14:09:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA14537 for ; Thu, 26 Feb 1998 14:09:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA17863 for ; Thu, 26 Feb 1998 14:11:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09039 for ; Thu, 26 Feb 1998 14:09:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Feb 1998 14:03:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08334 for ipp-outgoing; Thu, 26 Feb 1998 14:02:54 -0500 (EST) Content-return: allowed Date: Thu, 26 Feb 1998 11:01:37 PST From: "Caruso, Angelo " Subject: RE: IPP> Universal Print Driver session in Austin on Tuesday nigh t To: "'Carl-Uno Manros'" , ipp@pwg.org, "'upd@pwg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain X-Priority: 3 Sender: ipp-owner@pwg.org By the way, a week or so ago I made a request that someone please set up a dial in number for the UPD session. Is anyone else interested in that but me? Thanks, Angelo -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Thursday, February 26, 1998 12:41 PM To: ipp@pwg.org Subject: IPP> Universal Print Driver session in Austin on Tuesday night Hi all, I have just spoken to Don Wright about who chairs the UPD meeting. Don will, so that issue is settled. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 27 20:32:21 1998 Delivery-Date: Fri, 27 Feb 1998 20:32:22 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA26114 for ; Fri, 27 Feb 1998 20:32:20 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA24467 for ; Fri, 27 Feb 1998 20:34:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA01140 for ; Fri, 27 Feb 1998 20:32:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 27 Feb 1998 20:24:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00390 for ipp-outgoing; Fri, 27 Feb 1998 20:24:54 -0500 (EST) Message-ID: <01BD43A3.FFB19400.robertt@vcd.hp.com> From: Bob Taylor Reply-To: "robertt@vcd.hp.com" To: "'Caruso, Angelo '" , "'Carl-Uno Manros'" , "ipp@pwg.org" , "'upd@pwg.org'" Subject: RE: UPD> RE: IPP> Universal Print Driver session in Austin on Tuesday nigh t Date: Fri, 27 Feb 1998 17:20:22 -0800 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 I'd probably be interested in a dial-in for this. thanks, Bob --------------------------------------------------- Bob Taylor | Hewlett-Packard Vancouver Printer Division | mailto:robertt@vcd.hp.com | phone: 360.212.2625/T212.2625 | fax: 360.212.4154/T212.4154 | --------------------------------------------------- On Thursday, February 26, 1998 11:02 AM, Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com] wrote: > By the way, a week or so ago I made a request that someone please set up > a dial in number for the UPD session. Is anyone else interested in that > but me? > > Thanks, > Angelo > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, February 26, 1998 12:41 PM > To: ipp@pwg.org > Subject: IPP> Universal Print Driver session in Austin on > Tuesday night > > Hi all, > > I have just spoken to Don Wright about who chairs the UPD > meeting. > > Don will, so that issue is settled. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Feb 27 21:22:26 1998 Delivery-Date: Fri, 27 Feb 1998 21:22:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA26636 for ; Fri, 27 Feb 1998 21:22:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24540 for ; Fri, 27 Feb 1998 21:25:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA01863 for ; Fri, 27 Feb 1998 21:22:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 27 Feb 1998 21:17:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01305 for ipp-outgoing; Fri, 27 Feb 1998 21:17:32 -0500 (EST) From: Keith Carter To: , , Subject: IPP> Chair for UPD meeting on March 3 Message-ID: <5040300012880950000002L002*@MHS> Date: Fri, 20 Feb 1998 15:01:07 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org UPDers, Don Wright has graciously agreed to chair the UPD meeting on the evening of March 3. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From pwg-owner@pwg.org Fri Feb 27 21:27:05 1998 Delivery-Date: Fri, 27 Feb 1998 21:27:05 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA26751 for ; Fri, 27 Feb 1998 21:27:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24546 for ; Fri, 27 Feb 1998 21:29:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA02231 for ; Fri, 27 Feb 1998 21:27:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 27 Feb 1998 21:24:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01313 for pwg-outgoing; Fri, 27 Feb 1998 21:17:38 -0500 (EST) From: Keith Carter To: , , Subject: PWG> Chair for UPD meeting on March 3 Message-ID: <5040300012880950000002L002*@MHS> Date: Fri, 20 Feb 1998 15:01:07 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org UPDers, Don Wright has graciously agreed to chair the UPD meeting on the evening of March 3. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From ipp-owner@pwg.org Sat Feb 28 14:12:50 1998 Delivery-Date: Sat, 28 Feb 1998 14:12:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA12900 for ; Sat, 28 Feb 1998 14:12:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA25707 for ; Sat, 28 Feb 1998 14:14:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA15278 for ; Sat, 28 Feb 1998 14:11:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 13:59:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14525 for ipp-outgoing; Sat, 28 Feb 1998 13:59:36 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> Call in number for Universal Print Driver session in Austin Message-ID: <5040300013215763000002L032*@MHS> Date: Sat, 28 Feb 1998 13:55:53 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org UPDers, I've been out and just caught up with the email from Angelo Caruso and Bob Taylor requesting a call in number for the UPD meeting on March 4 at 7:00PM CST. I'll followup and inform you accordingly. Don Wright will chair the UPD meeting. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From jmp-owner@pwg.org Sat Feb 28 15:39:02 1998 Delivery-Date: Sat, 28 Feb 1998 15:39:03 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13705 for ; Sat, 28 Feb 1998 15:39:01 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25792 for ; Sat, 28 Feb 1998 15:41:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16525 for ; Sat, 28 Feb 1998 15:38:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 15:33:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15571 for jmp-outgoing; Sat, 28 Feb 1998 15:29:33 -0500 (EST) From: Keith Carter To: , , , , , , Harry Lewis , , , Subject: JMP> PING list for PWG meetings Message-ID: <5040300013216590000002L002*@MHS> Date: Sat, 28 Feb 1998 15:25:20 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: jmp-owner@pwg.org Attached is the current ping list for the PWG meetings. I did not request pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is interested, please show up at the Texas 5 meeting room. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PWG PING LIST AS OF 2/28/98 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Shivaun Albright HP 3/4-5 Y 3/3 3/5 Carlos Becerra HP 3/6 Y 3/5 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Marvin Heffler IBM 3/4-5 N - - - - Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Stephen Holmstead HP 3/2-3 Y 3/1 3/3 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 Takashi Isoda Canon 3/2-3 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Peter Michalek Shinesoft 3/4-5 N - - - - Paul Moore Microsoft 3/4 Y 3/3 3/4 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Yuji Sasaki - - - - 3/2-5 N - - - - Kris Schoff HP 3/4-5 ? ? ? Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Confirmed Attendance by Date P1394 P1394 IPP IPP JMP/FIN 3/2 3/3 3/4 3/5 3/6 20 21 32 29 14 Additional people who might attend. I do not know which meetings they will attend. Mike Fenelon Microsoft ? ? ? ? ? Shockey JRL Systems ? N - - - - From ipp-owner@pwg.org Sat Feb 28 15:42:46 1998 Delivery-Date: Sat, 28 Feb 1998 15:42:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13726 for ; Sat, 28 Feb 1998 15:42:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25802 for ; Sat, 28 Feb 1998 15:45:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA17058 for ; Sat, 28 Feb 1998 15:42:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 15:29:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15591 for ipp-outgoing; Sat, 28 Feb 1998 15:29:45 -0500 (EST) From: Keith Carter To: , , , , , , Harry Lewis , , , Subject: IPP> PING list for PWG meetings Message-ID: <5040300013216590000002L002*@MHS> Date: Sat, 28 Feb 1998 15:25:20 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: ipp-owner@pwg.org Attached is the current ping list for the PWG meetings. I did not request pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is interested, please show up at the Texas 5 meeting room. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PWG PING LIST AS OF 2/28/98 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Shivaun Albright HP 3/4-5 Y 3/3 3/5 Carlos Becerra HP 3/6 Y 3/5 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Marvin Heffler IBM 3/4-5 N - - - - Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Stephen Holmstead HP 3/2-3 Y 3/1 3/3 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 Takashi Isoda Canon 3/2-3 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Peter Michalek Shinesoft 3/4-5 N - - - - Paul Moore Microsoft 3/4 Y 3/3 3/4 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Yuji Sasaki - - - - 3/2-5 N - - - - Kris Schoff HP 3/4-5 ? ? ? Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Confirmed Attendance by Date P1394 P1394 IPP IPP JMP/FIN 3/2 3/3 3/4 3/5 3/6 20 21 32 29 14 Additional people who might attend. I do not know which meetings they will attend. Mike Fenelon Microsoft ? ? ? ? ? Shockey JRL Systems ? N - - - - From pwg-owner@pwg.org Sat Feb 28 15:44:37 1998 Delivery-Date: Sat, 28 Feb 1998 15:44:37 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA13732 for ; Sat, 28 Feb 1998 15:44:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25805 for ; Sat, 28 Feb 1998 15:47:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA17218 for ; Sat, 28 Feb 1998 15:44:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 15:37:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15552 for pwg-outgoing; Sat, 28 Feb 1998 15:29:23 -0500 (EST) From: Keith Carter To: , , , , , , Harry Lewis , , , Subject: PWG> PING list for PWG meetings Message-ID: <5040300013216590000002L002*@MHS> Date: Sat, 28 Feb 1998 15:25:20 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-pwg@pwg.org Attached is the current ping list for the PWG meetings. I did not request pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is interested, please show up at the Texas 5 meeting room. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PWG PING LIST AS OF 2/28/98 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Shivaun Albright HP 3/4-5 Y 3/3 3/5 Carlos Becerra HP 3/6 Y 3/5 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Marvin Heffler IBM 3/4-5 N - - - - Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Stephen Holmstead HP 3/2-3 Y 3/1 3/3 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 Takashi Isoda Canon 3/2-3 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Peter Michalek Shinesoft 3/4-5 N - - - - Paul Moore Microsoft 3/4 Y 3/3 3/4 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Yuji Sasaki - - - - 3/2-5 N - - - - Kris Schoff HP 3/4-5 ? ? ? Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Confirmed Attendance by Date P1394 P1394 IPP IPP JMP/FIN 3/2 3/3 3/4 3/5 3/6 20 21 32 29 14 Additional people who might attend. I do not know which meetings they will attend. Mike Fenelon Microsoft ? ? ? ? ? Shockey JRL Systems ? N - - - - From jmp-owner@pwg.org Sat Feb 28 17:41:19 1998 Delivery-Date: Sat, 28 Feb 1998 17:41:24 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA14563 for ; Sat, 28 Feb 1998 17:41:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25941 for ; Sat, 28 Feb 1998 17:43:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA18600 for ; Sat, 28 Feb 1998 17:41:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 17:36:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17686 for jmp-outgoing; Sat, 28 Feb 1998 17:32:20 -0500 (EST) Message-ID: <01BD4455.2A126740@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: JMP> RE: PWG> PING list for PWG meetings Date: Sat, 28 Feb 1998 14:28:39 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 102 TEXT Sender: jmp-owner@pwg.org Keith: Unfortunately, due to my being sick with the flu, I will have to cancel my trip to Austin... --Mark **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Saturday, February 28, 1998 12:25 PM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Attached is the current ping list for the PWG meetings. I did not request > pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is > interested, please show up at the Texas 5 meeting room. > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 > > PWG PING LIST AS OF 2/28/98 > > Name Company PWG Hyatt? Arrive Depart > > Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 > Shivaun Albright HP 3/4-5 Y 3/3 3/5 > Carlos Becerra HP 3/6 Y 3/5 3/6 > Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 > Brian Batchelder HP 3/2-3 Y 3/1 3/4 > Alan Berkema HP 3/2-3 N - - - - > Keith Carter IBM 3/4-5 N - - - - > Roger deBry IBM 3/4-5 Y 3/3 3/5 > Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 > Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 > Lee Farrell Canon 3/2-6 Y 3/1 3/6 > Richard Hart Digital 3/4-6 Y 3/3 3/6 > Tom Hastings XEROX 3/4-6 Y 3/3 3/6 > Marvin Heffler IBM 3/4-5 N - - - - > Bob Herriot SUN 3/4-5 Y 3/3 3/6 > Osamu Hirata Canon 3/2-3 Y 3/1 3/4 > Stephen Holmstead HP 3/2-3 Y 3/1 3/3 > Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 > Takashi Isoda Canon 3/2-3 Y 3/1 3/5 > Scott Isaacson Novell 3/4-5 Y 3/3 3/5 > David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 > Greg LeClair EPSON 3/2-4 Y 3/1 3/4 > Harry Lewis IBM 3/4-6 Y 3/3 3/6 > Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 > Jay Martin Underscore 3/4-5 Y 3/3 3/6 > Peter Michalek Shinesoft 3/4-5 N - - - - > Paul Moore Microsoft 3/4 Y 3/3 3/4 > Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 > Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 > Bob Pentecost HP 3/4-6 Y 3/3 3/6 > Yuji Sasaki - - - - 3/2-5 N - - - - > Kris Schoff HP 3/4-5 ? ? ? > Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 > Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 > Greg Shue HP 3/2-3 Y 3/1 3/3 > Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 > Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 > Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 > Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 > Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 > Jim Walker DAZEL 3/4-6 N - - - - > Don Wright Lexmark 3/2-6 Y 3/1 3/6 > Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 > Peter Zehler XEROX 3/4-5 Y 3/3 3/6 > > > PWG Meeting Confirmed Attendance by Date > > P1394 P1394 IPP IPP JMP/FIN > 3/2 3/3 3/4 3/5 3/6 > 20 21 32 29 14 > > Additional people who might attend. I do not know which meetings they will > attend. > > Mike Fenelon Microsoft ? ? ? ? > ? Shockey JRL Systems ? N - - - - From ipp-owner@pwg.org Sat Feb 28 17:45:24 1998 Delivery-Date: Sat, 28 Feb 1998 17:45:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA14609 for ; Sat, 28 Feb 1998 17:45:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25949 for ; Sat, 28 Feb 1998 17:48:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19132 for ; Sat, 28 Feb 1998 17:45:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 17:33:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17752 for ipp-outgoing; Sat, 28 Feb 1998 17:33:08 -0500 (EST) Message-ID: <01BD4455.2A126740@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: IPP> RE: PWG> PING list for PWG meetings Date: Sat, 28 Feb 1998 14:28:39 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 102 TEXT Sender: ipp-owner@pwg.org Keith: Unfortunately, due to my being sick with the flu, I will have to cancel my trip to Austin... --Mark **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Saturday, February 28, 1998 12:25 PM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Attached is the current ping list for the PWG meetings. I did not request > pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is > interested, please show up at the Texas 5 meeting room. > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 > > PWG PING LIST AS OF 2/28/98 > > Name Company PWG Hyatt? Arrive Depart > > Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 > Shivaun Albright HP 3/4-5 Y 3/3 3/5 > Carlos Becerra HP 3/6 Y 3/5 3/6 > Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 > Brian Batchelder HP 3/2-3 Y 3/1 3/4 > Alan Berkema HP 3/2-3 N - - - - > Keith Carter IBM 3/4-5 N - - - - > Roger deBry IBM 3/4-5 Y 3/3 3/5 > Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 > Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 > Lee Farrell Canon 3/2-6 Y 3/1 3/6 > Richard Hart Digital 3/4-6 Y 3/3 3/6 > Tom Hastings XEROX 3/4-6 Y 3/3 3/6 > Marvin Heffler IBM 3/4-5 N - - - - > Bob Herriot SUN 3/4-5 Y 3/3 3/6 > Osamu Hirata Canon 3/2-3 Y 3/1 3/4 > Stephen Holmstead HP 3/2-3 Y 3/1 3/3 > Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 > Takashi Isoda Canon 3/2-3 Y 3/1 3/5 > Scott Isaacson Novell 3/4-5 Y 3/3 3/5 > David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 > Greg LeClair EPSON 3/2-4 Y 3/1 3/4 > Harry Lewis IBM 3/4-6 Y 3/3 3/6 > Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 > Jay Martin Underscore 3/4-5 Y 3/3 3/6 > Peter Michalek Shinesoft 3/4-5 N - - - - > Paul Moore Microsoft 3/4 Y 3/3 3/4 > Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 > Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 > Bob Pentecost HP 3/4-6 Y 3/3 3/6 > Yuji Sasaki - - - - 3/2-5 N - - - - > Kris Schoff HP 3/4-5 ? ? ? > Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 > Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 > Greg Shue HP 3/2-3 Y 3/1 3/3 > Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 > Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 > Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 > Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 > Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 > Jim Walker DAZEL 3/4-6 N - - - - > Don Wright Lexmark 3/2-6 Y 3/1 3/6 > Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 > Peter Zehler XEROX 3/4-5 Y 3/3 3/6 > > > PWG Meeting Confirmed Attendance by Date > > P1394 P1394 IPP IPP JMP/FIN > 3/2 3/3 3/4 3/5 3/6 > 20 21 32 29 14 > > Additional people who might attend. I do not know which meetings they will > attend. > > Mike Fenelon Microsoft ? ? ? ? > ? Shockey JRL Systems ? N - - - - From pwg-owner@pwg.org Sat Feb 28 17:47:10 1998 Delivery-Date: Sat, 28 Feb 1998 17:47:10 -0500 Return-Path: pwg-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA14618 for ; Sat, 28 Feb 1998 17:47:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25955 for ; Sat, 28 Feb 1998 17:49:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19327 for ; Sat, 28 Feb 1998 17:47:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 17:42:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17716 for pwg-outgoing; Sat, 28 Feb 1998 17:32:42 -0500 (EST) Message-ID: <01BD4455.2A126740@mark@mtesoft.com> From: "Mark T. Edmead" Reply-To: "mark@mtesoft.com" To: "'Keith Carter'" , "p1394@pwg.org" , "pwg@pwg.org" , "fin@pwg.org" , "jmp@pwg.org" , "ipp@pwg.org" Subject: RE: PWG> PING list for PWG meetings Date: Sat, 28 Feb 1998 14:28:39 -0800 Organization: MTE Software, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 Encoding: 102 TEXT Sender: owner-pwg@pwg.org Keith: Unfortunately, due to my being sick with the flu, I will have to cancel my trip to Austin... --Mark **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Saturday, February 28, 1998 12:25 PM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Attached is the current ping list for the PWG meetings. I did not request > pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is > interested, please show up at the Texas 5 meeting room. > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 > > PWG PING LIST AS OF 2/28/98 > > Name Company PWG Hyatt? Arrive Depart > > Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 > Shivaun Albright HP 3/4-5 Y 3/3 3/5 > Carlos Becerra HP 3/6 Y 3/5 3/6 > Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 > Brian Batchelder HP 3/2-3 Y 3/1 3/4 > Alan Berkema HP 3/2-3 N - - - - > Keith Carter IBM 3/4-5 N - - - - > Roger deBry IBM 3/4-5 Y 3/3 3/5 > Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 > Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 > Lee Farrell Canon 3/2-6 Y 3/1 3/6 > Richard Hart Digital 3/4-6 Y 3/3 3/6 > Tom Hastings XEROX 3/4-6 Y 3/3 3/6 > Marvin Heffler IBM 3/4-5 N - - - - > Bob Herriot SUN 3/4-5 Y 3/3 3/6 > Osamu Hirata Canon 3/2-3 Y 3/1 3/4 > Stephen Holmstead HP 3/2-3 Y 3/1 3/3 > Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 > Takashi Isoda Canon 3/2-3 Y 3/1 3/5 > Scott Isaacson Novell 3/4-5 Y 3/3 3/5 > David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 > Greg LeClair EPSON 3/2-4 Y 3/1 3/4 > Harry Lewis IBM 3/4-6 Y 3/3 3/6 > Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 > Jay Martin Underscore 3/4-5 Y 3/3 3/6 > Peter Michalek Shinesoft 3/4-5 N - - - - > Paul Moore Microsoft 3/4 Y 3/3 3/4 > Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 > Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 > Bob Pentecost HP 3/4-6 Y 3/3 3/6 > Yuji Sasaki - - - - 3/2-5 N - - - - > Kris Schoff HP 3/4-5 ? ? ? > Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 > Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 > Greg Shue HP 3/2-3 Y 3/1 3/3 > Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 > Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 > Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 > Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 > Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 > Jim Walker DAZEL 3/4-6 N - - - - > Don Wright Lexmark 3/2-6 Y 3/1 3/6 > Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 > Peter Zehler XEROX 3/4-5 Y 3/3 3/6 > > > PWG Meeting Confirmed Attendance by Date > > P1394 P1394 IPP IPP JMP/FIN > 3/2 3/3 3/4 3/5 3/6 > 20 21 32 29 14 > > Additional people who might attend. I do not know which meetings they will > attend. > > Mike Fenelon Microsoft ? ? ? ? > ? Shockey JRL Systems ? N - - - - From ipp-owner@pwg.org Sat Feb 28 20:15:11 1998 Delivery-Date: Sat, 28 Feb 1998 20:15:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA15593 for ; Sat, 28 Feb 1998 20:15:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26075 for ; Sat, 28 Feb 1998 20:17:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20828 for ; Sat, 28 Feb 1998 20:15:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 28 Feb 1998 20:08:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20092 for ipp-outgoing; Sat, 28 Feb 1998 20:08:44 -0500 (EST) Date: Sat, 28 Feb 1998 17:14:08 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803010114.AA07747@snorkel.eso.mc.xerox.com> To: Angelo.Caruso@usa.xerox.com, carterk@us.ibm.com, don@lexmark.com, ipp@pwg.org, robertt@vcd.hp.com, upd@pwg.org Subject: Re: IPP> Call in number for Universal Print Driver session in Austin Sender: ipp-owner@pwg.org Hi Keith, Thanks - Ill circulate this within Xerox and see if any of our driver people can join in. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc From ipp-owner@pwg.org Mon Mar 2 12:52:11 1998 Delivery-Date: Mon, 02 Mar 1998 12:52:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA08748 for ; Mon, 2 Mar 1998 12:52:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04021 for ; Mon, 2 Mar 1998 12:54:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23196 for ; Mon, 2 Mar 1998 12:51:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Mar 1998 12:46:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22661 for ipp-outgoing; Mon, 2 Mar 1998 12:46:33 -0500 (EST) Message-Id: <3.0.1.32.19980302094131.00b95da0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Mar 1998 09:41:31 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Suggested Apps track for Los Angeles Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harald has now put out a tentative agenda for the Application Area. The IPP is scheduled for 1:00 pm to 3:00 pm on the Wednesday. Carl-Uno >X-Sender: hta@dokka.kvatro.no >Date: Sun, 1 Mar 1998 01:44:25 PST >To: wg-chairs@apps.ietf.org >From: Harald Tveit Alvestrand >Subject: Suggested Apps track for Los Angeles >Cc: agenda@ietf.org, directorate@apps.ietf.org >Sender: owner-wg-chairs@dokka.kvatro.no > >I've now gone through the request I've received for Los Angeles. >It seems that there are a lot missing; I'm pretty sure I've seen some >that aren't included. Signs of a disorganized mind.... > >Please resend everything not included ASAP; there's not much time left! >Agenda: this time it seems as if only a few slots will be doubled, >even when I tentatively schedule what I think should be scheduled. > >The URL is http://www.apps.ietf.org/apps/track-la-mar98.html. >Mind the instructions!!!!!!!!!!!!!!!! > > Harald A > > > > > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 2 13:37:55 1998 Delivery-Date: Mon, 02 Mar 1998 13:37:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA11443 for ; Mon, 2 Mar 1998 13:37:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04249 for ; Mon, 2 Mar 1998 13:40:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23952 for ; Mon, 2 Mar 1998 13:37:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Mar 1998 13:33:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23391 for ipp-outgoing; Mon, 2 Mar 1998 13:33:18 -0500 (EST) Message-Id: <3.0.1.32.19980302101809.009c8d50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Mar 1998 10:18:09 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Protocol Action: An Extensible Message Format for Message Disposition Notifications to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >To: IETF-Announce:; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: receipt@cs.utk.edu >From: The IESG >Subject: Protocol Action: An Extensible Message Format for Message Disposition > Notifications to Proposed Standard >Date: Mon, 2 Mar 1998 08:44:03 PST >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'An Extensible Message Format >for Message Disposition Notifications' >as a Proposed Standard. This document is the product of the Receipt >Notifications for Internet Mail Working Group. The IESG contact >persons are Harald Alvestrand and Keith Moore. > > >Technical Summary > > This memo defines a MIME content-type that may be used by a mail > user agent (UA) or electronic mail gateway to report the disposition > of a message after it has been sucessfully delivered to a recipient > ("receipt report" or "read report"). > > Other WGs may also be using this for delivering information about > automated processing of messages, for instance in the EDI context. > > >Working Group Summary > The working group came to consensus on the document as written; > it is believed that any kind of on-reading notification involves > serious tradeoffs, especially with regard to privacy; the WG > believes that the current document is a reasonable approach. > >Protocol Quality > > The document was reviewed for the IESG by Harald Alvestrand > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 2 17:14:39 1998 Delivery-Date: Mon, 02 Mar 1998 17:14:39 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19627 for ; Mon, 2 Mar 1998 17:14:38 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05405 for ; Mon, 2 Mar 1998 17:17:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26225 for ; Mon, 2 Mar 1998 17:14:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Mar 1998 17:10:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25676 for ipp-outgoing; Mon, 2 Mar 1998 17:09:59 -0500 (EST) Message-Id: <199803022208.OAA13763@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Mar 1998 14:11:03 -0800 To: Keith Carter , From: Robert Herriot Subject: Re: IPP> Call in number for UPD meeting on March 3 In-Reply-To: <5040300013270834000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Is the meeting at 7pm or 6:30pm? Don and the pwg web site think that the meeting is at 6:30pm CST. Keith's email now and in the past has said 7pm CST I prefer 7pm, but 6:30 is OK too. We just need a definitive statement. Bob Herriot At 01:22 PM 3/2/98 , Keith Carter wrote: >The call in number for the UPD meeting at 7:00PM CST on Tuesday, March 3 is as >follows: > >Phone = 1-800-369-1883 >Passcode = 24427 (the call is unattended so enter the passcode when prompted to >do so) > >There are 10 lines reserved for the call. > >Unfortunately, I will not be able to attend the UPD meeting so whomever is at >the meeting please dial the above number and passcode on the phone in the >meeting room. > >Have a super day, > >Keith Carter >Senior Software Engineer >IBM Network Computing Software Division in Austin, Texas >internet email: carterk@us.ibm.com >Notes email: Keith Carter/Austin/IBM@IBMUS >phone: 512-838-2155 >tie-line: 678-2155 >fax: 512-838-0169 > From ipp-owner@pwg.org Mon Mar 2 17:56:04 1998 Delivery-Date: Mon, 02 Mar 1998 17:56:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA21298 for ; Mon, 2 Mar 1998 17:56:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05671 for ; Mon, 2 Mar 1998 17:58:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26973 for ; Mon, 2 Mar 1998 17:56:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Mar 1998 17:50:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26436 for ipp-outgoing; Mon, 2 Mar 1998 17:50:26 -0500 (EST) Message-Id: <34FB37A1.B9C8EA40@pogo.wv.tek.com> Date: Mon, 02 Mar 1998 14:50:09 -0800 From: Chuck Adams Organization: Tektronix, Inc. X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Call in number for UPD meeting on March 3 References: <199803022208.OAA13763@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Robert Herriot wrote: > > Is the meeting at 7pm or 6:30pm? I prefer 7pm also. Chuck Adams Tektronix, Inc. > > Don and the pwg web site think that the meeting is at 6:30pm CST. > Keith's email now and in the past has said 7pm CST > > I prefer 7pm, but 6:30 is OK too. We just need a definitive statement. > > Bob Herriot > > At 01:22 PM 3/2/98 , Keith Carter wrote: > >The call in number for the UPD meeting at 7:00PM CST on Tuesday, March 3 > is as > >follows: > > > >Phone = 1-800-369-1883 > >Passcode = 24427 (the call is unattended so enter the passcode when prompted > to > >do so) > > > >There are 10 lines reserved for the call. > > > >Unfortunately, I will not be able to attend the UPD meeting so whomever is at > >the meeting please dial the above number and passcode on the phone in the > >meeting room. > > > >Have a super day, > > > >Keith Carter > >Senior Software Engineer > >IBM Network Computing Software Division in Austin, Texas > >internet email: carterk@us.ibm.com > >Notes email: Keith Carter/Austin/IBM@IBMUS > >phone: 512-838-2155 > >tie-line: 678-2155 > >fax: 512-838-0169 > > From ipp-owner@pwg.org Mon Mar 2 22:54:49 1998 Delivery-Date: Mon, 02 Mar 1998 22:54:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA01275 for ; Mon, 2 Mar 1998 22:54:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA06416 for ; Mon, 2 Mar 1998 22:57:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29829 for ; Mon, 2 Mar 1998 22:54:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Mar 1998 22:49:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29275 for ipp-outgoing; Mon, 2 Mar 1998 22:49:50 -0500 (EST) Message-Id: <199803030348.TAA14312@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Mar 1998 19:51:24 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO A Definition of IPP using an XML schema Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id WAA01275 I have downloaded a document in which I have defined the XML encoding of IPP using an XML schema. This schema covers most of section 15.3 in the model document and in particular defines the following · The structure with regard to the attribute groups · Which attribute groups are mandatory or optional in each operation · Which operation attributes are mandatory, optional for the client and optional to implement · Which job and printer attributes are mandatory, optional for the sender, and optional to implement · Which attributes must be implemented as a group. · What types and values are allowed for each attribute · Which types must be explicitly typed for an attribute. · The order or lack of order of various components. The document has comments in blue and is meant to illustrate what is possible with XML. I have downloaded the documents to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. The documents are named: Ipp-xml-shema-980302-6.doc MS Word 6 Ipp-xml-shema-980302.doc MS Word 97 Ipp-xml-shema-980302.html HTML Ipp-xml-shema-980302.prn PostScript From ipp-owner@pwg.org Tue Mar 3 18:48:43 1998 Delivery-Date: Tue, 03 Mar 1998 18:48:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13847 for ; Tue, 3 Mar 1998 18:48:42 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA10749 for ; Tue, 3 Mar 1998 18:51:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA17122 for ; Tue, 3 Mar 1998 18:48:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Mar 1998 18:43:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16559 for ipp-outgoing; Tue, 3 Mar 1998 18:43:15 -0500 (EST) From: Carl Kugler To: Subject: IPP> Need clarification: Job Template Attributes: Optional or n Message-ID: <5030100018137864000002L042*@MHS> Date: Tue, 3 Mar 1998 18:42:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA13847 Section 15.3.4.3, "Validate the presence of a single occurrence of required Operation attributes", shows Job Template attributes as (M*) for Print-Job, Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDATORY attributes that an IPP object MUST support, but that a client may omit in a request or an IPP object may omit in a response. The reader is referred to Section 4.2, where it says "Support for Job Template attributes by a Printer ob ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though support for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED that if the device behind a Printer object is capable of realizing any feature or function that corresponds to an IPP attribute and some associated value, th en that implementation SHOULD support that IPP attribute and value." Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I missing something? From ipp-owner@pwg.org Tue Mar 3 19:16:23 1998 Delivery-Date: Tue, 03 Mar 1998 19:16:23 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14117 for ; Tue, 3 Mar 1998 19:16:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10806 for ; Tue, 3 Mar 1998 19:18:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA17852 for ; Tue, 3 Mar 1998 19:16:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 3 Mar 1998 19:12:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17306 for ipp-outgoing; Tue, 3 Mar 1998 19:12:26 -0500 (EST) Message-Id: <3.0.1.32.19980303155013.01167610@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Mar 1998 15:50:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> Slides for IPP meeting: printer system configurations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've down-loaded the slides that Roger and I put together as an action item to facilitate the discussion on host-to-device protocol and notification on Wed. Its in: ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.ppt ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.pdf I'm bringing 30 copies on hard copy and one set of tranparencies. Tom From ipp-owner@pwg.org Wed Mar 4 18:40:29 1998 Delivery-Date: Wed, 04 Mar 1998 18:40:30 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA19244 for ; Wed, 4 Mar 1998 18:40:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15060 for ; Wed, 4 Mar 1998 18:42:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05760 for ; Wed, 4 Mar 1998 18:39:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 4 Mar 1998 18:29:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05166 for ipp-outgoing; Wed, 4 Mar 1998 18:29:33 -0500 (EST) Message-Id: <34FDE3C4.3427@hprnd.rose.hp.com> Date: Wed, 04 Mar 1998 15:29:08 -0800 From: Van Dang Organization: Hewlett-Packard Co. X-Mailer: Mozilla 3.03 (X11; I; HP-UX B.10.20 9000/780) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Need clarification: Job Template Attributes: Optional or n References: <5030100018137864000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl Kugler wrote: > > Section 15.3.4.3, "Validate the presence of a single occurrence of required > Operation attributes", shows Job Template attributes as (M*) for Print-Job, > Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDATORY > attributes that an IPP object MUST support, but that a client may omit in a > request or an IPP object may omit in a response. The reader is referred to > Section 4.2, where it says "Support for Job Template attributes by a Printer ob > ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though support > for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED > that if the device behind a Printer object is capable of realizing any feature > or function that corresponds to an IPP attribute and some associated value, th > en that implementation SHOULD support that IPP attribute and value." > Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I missing > something? I had the same question when I was going over the document. Perhaps Section 15.3.4.3 should indicate that the Job Template Attributes are (O*) instead of (M*) since the attribute group itself is OPTIONAL. From ipp-owner@pwg.org Thu Mar 5 16:58:31 1998 Delivery-Date: Thu, 05 Mar 1998 16:58:31 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA16211 for ; Thu, 5 Mar 1998 16:58:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA19106 for ; Thu, 5 Mar 1998 17:01:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22298 for ; Thu, 5 Mar 1998 16:58:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 5 Mar 1998 16:48:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21724 for ipp-outgoing; Thu, 5 Mar 1998 16:48:11 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Message-ID: <5030100018210342000002L022*@MHS> Date: Thu, 5 Mar 1998 16:46:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA16211 Tom- > Why are there attributes that have both 'type4 keyword' and 'name' > (and hence 'nameWithLanguage) data types? I think that this is a new, different question, and a good one. Aren't these the only attributes for which a multi-valued attribute instance may have a mixture of its defined attribute syntaxes? If true, collapsing the redundant '(type4 keyword | name)' to 'name', would allow one attribute syntax tag to apply to a whole attribute, even a multi-valued one. It would also make life easier for implementers trying to use strong typing. -Carl hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM Please respond to hastings@cp10.es.xerox.com @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo At 14:06 02/02/1998 PST, Carl Kugler wrote: >Attributes with type 4 keywords also allow the 'name' attribute syntax for >administrator defined names. Keywords SHALL be in U.S. English, but attributes >that are indicated to have the 'name' attribute syntax also automatically have >the 'nameWithLanguage' attribute syntax. > >So in general, attributes with type 4 keywords can use the Language Override >Mechanism? Correct, but because the 13 attributes that have 'type 4 keyword' data type, also have the 'name' data type: +-------------------+----------------------+----------------------+ | job-hold-until | job-hold-until- |job-hold-until- | | (type4 keyword | | default | supported | | name) | (type4 keyword | |(1setOf | | | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ | job-sheets | job-sheets-default |job-sheets-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ +-------------------+----------------------+----------------------+ | media | media-default | media-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| | | | | | | | media-ready | | | |(1setOf | | | | type4 keyword | name)| +-------------------+----------------------+----------------------+ not just because they have the 'type 4 keyword' data type. But we thought that if an administrator is making up names (which is what type 4 keywords are), that an implementation may want to be simple and treat them as names in the language that the administrator is using or may want to be more complex and allow the administrator to define keywords that clients can localize into various languages. Sounds like something for the FAQ: Why are there attributes that have both 'type4 keyword' and 'name' (and hence 'nameWithLanguage) data types? Tom > > -Carl > > From owner-ietf-outbound.10 Fri Mar 6 04:50:28 1998 Delivery-Date: Fri, 06 Mar 1998 04:55:55 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id EAA01908 for ietf-outbound.10@ietf.org; Fri, 6 Mar 1998 04:50:02 -0500 (EST) Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA01883 for ; Fri, 6 Mar 1998 04:48:16 -0500 (EST) Received: from sweetpea (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.8.7/8.6.4.287) with SMTP id EAA27574; Fri, 6 Mar 1998 04:43:09 -0500 (EST) Message-ID: <34FFF09E.622C@comet.columbia.edu> Date: Fri, 06 Mar 1998 04:48:31 -0800 From: "Andrew T.Campbell" Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research, Columbia University X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net, tccc@IEEE.ORG, opensig-announce@ctr.columbia.edu, pin@iss.nus.sg, hipparch@sophia.inria, multicomm@cc.bellcore.com, ietf@ns.ietf.org, ion@nexen.com CC: campbell@ctr.columbia.edu Subject: OPENARCH'98 advance registration *deadline* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Won't to make the network as programmable as the PC! Then OPENARCH is for you .... OPENARCH'98: First IEEE Conference on Open Architectures and Network Programming For advance registration see: https://secure.computer.org/conf/infocom/register.htm Note that the deadline for the conference is MARCH 10, 1998. For the technical program see: http://comet.columbia.edu/comet/activities/openarch/program.html OPENARCH'98 is sponsored by the IEEE Communications Society and will be co-located and organized in conjunction with INFOCOM'98. From ipp-owner@pwg.org Fri Mar 6 15:10:04 1998 Delivery-Date: Fri, 06 Mar 1998 15:10:04 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA21559 for ; Fri, 6 Mar 1998 15:09:53 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA23043 for ; Fri, 6 Mar 1998 15:12:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA07771 for ; Fri, 6 Mar 1998 15:09:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Mar 1998 14:59:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07181 for ipp-outgoing; Fri, 6 Mar 1998 14:59:44 -0500 (EST) Message-Id: <3.0.1.32.19980306115206.0097ba10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Mar 1998 11:52:06 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> NOT - [ENP] Justification -- Why ENP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, Just to call your attention to the fact that the WebDAV group seems to be on the verge of inventing a new notification mechanism. Scott, are you aware of this? Carl-Uno >Resent-Date: Thu, 5 Mar 1998 10:12:03 PST >Resent-Message-Id: <199803051812.NAA12027@www19.w3.org> >X-Authentication-Warning: www10.w3.org: Host inet-gw.indy.tce.com [157.254.232.6] claimed to be tcemail.indy.tce.com >From: Fisher Mark >To: "'Ron Daniel Jr.'" , "'Jim Whitehead'" , > "'Josh Cohen'" , > "'Masinter Larry'" , > "'Surendra Reddy'" , > "'Markus Fleck'" >Cc: "'w3c-dist-auth'" >Date: Thu, 5 Mar 1998 10:11:33 PST >Resent-To: >Subject: [ENP] Justification -- Why ENP? >Resent-From: w3c-dist-auth@w3.org >X-Mailing-List: archive/latest/1620 >X-Loop: w3c-dist-auth@w3.org >Sender: w3c-dist-auth-request@w3.org >Resent-Sender: w3c-dist-auth-request@w3.org > >First, thanks to all of you who expressed an interest in ENP. I've been >buried with other projects, so I am just now coming back to this. Below >is a very rough draft of a paragraph I plan to put near the front of the >ENP draft, explaining why there should be yet another event notification >protocol. > >Surendra Reddy has offered to co-edit the draft with me, and I gladly >accept his offer. Surendra -- I suggest that we go off-line and discuss >the request part of the protocol, then once we are happy with that, we >will bring it to the rest of the WebDAV working group, or a separate >working group if others feel that ENP is way beyond the bounds of what >WebDAV should itself cover, as I think it probably is. > >All -- I will look into hosting the (potential) ENP working group >mailing list (TCE has never done that before, to my knowledge). >========================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN >"Browser Torture Specialist, First Class" > > > >*** Why ENP? >There are several different network event notification protocols already >-- CORBA Event Services, X Window System events, SGAP, BSCW, etc. -- so >why should there be another event notification protocol? In two words >-- size and decentralization: >* Size is an issue, as the 2 most popular network event notification >protocols -- CORBA Event Services and X Window System events -- under >their current codebases require dragging along all of their other >services. This code bloat makes it impractical to use network event >notification services in lightweight and embedded-systems applications. >* Centralization is an issue, as centralized network event notification >servers are only needed when there are multiple recipients of event >notifications and/or multiple disjoint event types for notifications >(i.e. multiple event types on a server to be notified about). > >ENP is a lightweight network event notification protocol that can be >used either by itself (when there is one notification requester and one >major event type) or as part of a centralized network event notification >service (where there are multiple event notification requesters and >multiple major event types). > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Mar 6 19:41:31 1998 Delivery-Date: Fri, 06 Mar 1998 19:41:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA08998 for ; Fri, 6 Mar 1998 19:41:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA24356 for ; Fri, 6 Mar 1998 19:43:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09525 for ; Fri, 6 Mar 1998 19:41:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Mar 1998 19:36:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08992 for ipp-outgoing; Fri, 6 Mar 1998 19:36:39 -0500 (EST) Message-Id: <199803070031.QAA18149@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Mar 1998 16:34:19 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Cc: In-Reply-To: <5030100018210342000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA08998 I agree with you that there is some confusion here, particularly where the document says "An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation." [ line 2248, section 4.2.3]. Our intent was to allow an administrator to add new values locally. I have always assumed that a GUI would convert the standard keywords into some localized word or phrase, but that a GUI would display values created by an administrator as is (to keep things simple). Attributes that allow new administator values need to distinguish between those values that should be converted and those that should not. But the statement in the model document leaves me confused because it says that an administrator can call a new value a keyword or a name, and that some implementation may not support both ways. This makes me think that one of these choices needs to be removed from the standard. The solution should be one of the two below. o We eliminate the concept of type 4 keywords, and let "name" be the way administrators make extensions. We should encourage GUIs to localize keywords and display names as is. All attributes whose values are type 4 keywords currently have "name" as an alternate type. So we change their type to "type 3 keyword | name" o We eliminate "name" from the attributes that are "type 4 keyword | name" and let a language be associated with keywords. We encourage GUIs to leave keywords as is if they aren't in the localization table. I like the first option best. It still leaves two data types for some attributes, but it is better than allowing a language with keywords when most have no language associated with them. Bob Herriot At 01:46 PM 3/5/98 , Carl Kugler wrote: >Tom- > >> Why are there attributes that have both 'type4 keyword' and 'name' >> (and hence 'nameWithLanguage) data types? > >I think that this is a new, different question, and a good one.  Aren't these >the only attributes for which a multi-valued attribute instance may have a >mixture of its defined attribute syntaxes? > >If true, collapsing the redundant '(type4 keyword | name)' to 'name', would >allow one attribute syntax tag to apply to a whole attribute, even a >multi-valued one. It would also make life easier for implementers trying to use >strong typing. > >  -Carl > > > >hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM >Please respond to hastings@cp10.es.xerox.com @ internet >To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus >cc: >Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo > > >At 14:06 02/02/1998 PST, Carl Kugler wrote: >>Attributes with type 4 keywords also allow the 'name' attribute syntax for >>administrator defined names.  Keywords SHALL be in U.S. English, but >attributes >>that are indicated to have the 'name' attribute syntax also automatically >have >>the 'nameWithLanguage' attribute syntax. >> >>So in general, attributes with type 4 keywords can use the Language Override >>Mechanism? > >Correct, but because the 13 attributes that have 'type 4 keyword' data type, >also have the 'name' data type: > >  +-------------------+----------------------+----------------------+ >  | job-hold-until    | job-hold-until-      |job-hold-until-       | >  | (type4 keyword |  |  default             | supported            | >  |    name)          |  (type4 keyword |    |(1setOf               | >  |                   |    name)             | type4 keyword | name)| >  +-------------------+----------------------+----------------------+ >  | job-sheets        | job-sheets-default   |job-sheets-supported  | >  | (type4 keyword |  | (type4 keyword |     |(1setOf               | >  |    name)          |    name)             | type4 keyword | name)| >  +-------------------+----------------------+----------------------+ > >  +-------------------+----------------------+----------------------+ >  | media             | media-default        | media-supported      | >  | (type4 keyword |  | (type4 keyword |     |(1setOf               | >  |    name)          |    name)             | type4 keyword | name)| >  |                   |                      |                      | >  |                   |                      | media-ready          | >  |                   |                      |(1setOf               | >  |                   |                      | type4 keyword | name)| >  +-------------------+----------------------+----------------------+ > >not just because they have the 'type 4 keyword' data type.  But we >thought that if an administrator is making up names (which is what >type 4 keywords are), that an implementation may want to be simple >and treat them as names in the language that the administrator is >using or may want to be more complex and allow the administrator to >define keywords that clients can localize into various languages. > >Sounds like something for the FAQ: > >Why are there attributes that have both 'type4 keyword' and 'name' >(and hence 'nameWithLanguage) data types? > >Tom > >> >>  -Carl >> >> > From ipp-owner@pwg.org Fri Mar 6 21:46:58 1998 Delivery-Date: Fri, 06 Mar 1998 21:46:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA13456 for ; Fri, 6 Mar 1998 21:46:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24736 for ; Fri, 6 Mar 1998 21:49:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA10461 for ; Fri, 6 Mar 1998 21:46:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 6 Mar 1998 21:42:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09941 for ipp-outgoing; Fri, 6 Mar 1998 21:42:25 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC369@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> MS requirements for UPD Date: Fri, 6 Mar 1998 18:42:09 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org At the Austin UPD session I was asked if I could post the MS requirements for our Unidrive 5 product. Sadly I cannot find any - this is not unusual inside MS - we make it up as we go along :-) From ipp-owner@pwg.org Mon Mar 9 12:24:59 1998 Delivery-Date: Mon, 09 Mar 1998 12:24:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA02716 for ; Mon, 9 Mar 1998 12:24:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03291 for ; Mon, 9 Mar 1998 12:27:32 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15495 for ; Mon, 9 Mar 1998 12:24:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 12:20:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14941 for ipp-outgoing; Mon, 9 Mar 1998 12:20:05 -0500 (EST) From: Harry Lewis To: Cc: Roger K Debry Subject: IPP> Notification content Message-ID: <5030300018795096000002L062*@MHS> Date: Mon, 9 Mar 1998 12:26:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA02716 In Austin, I think we discussed the IPP notification requirement that any attribute may be requested during registration for a given event. I think the requirement stems from the notion that notification content should just "mimic" the response to a query. But this is probably unrealistic. A query/response is synchronous - during which, the "agent's" job is to gather the requested information and package the response. With notifications, you pre-register for asynchronous events. It would be a much greater burden on the agent, whether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type of event! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Mar 9 12:40:10 1998 Delivery-Date: Mon, 09 Mar 1998 12:40:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03420 for ; Mon, 9 Mar 1998 12:40:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03358 for ; Mon, 9 Mar 1998 12:42:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16144 for ; Mon, 9 Mar 1998 12:40:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 12:34:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15589 for ipp-outgoing; Mon, 9 Mar 1998 12:34:31 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Harry Lewis'" , ipp@pwg.org Cc: Roger K Debry Subject: RE: IPP> Notification content Date: Mon, 9 Mar 1998 09:34:30 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I seem to remember there was some concensus towards the end of the discussion that two items needed to be defined: 1. What events cause a notification to be generated, and 2. What parameters get transmitted along with the event notification. I emphasized at the meeting that the parameters that are transmitted along with a particular event are "standardized" (fixed) in a standards-track document. If a client needs to know more about the particular event, the client can subsequently issue an IPP request or possibly an SNMP request depending upon the original event. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Monday, March 09, 1998 9:27 AM To: ipp@pwg.org Cc: Roger K Debry Subject: IPP> Notification content In Austin, I think we discussed the IPP notification requirement that any attribute may be requested during registration for a given event. I think the requirement stems from the notion that notification content should just "mimic" the response to a query. But this is probably unrealistic. A query/response is synchronous - during which, the "agent's" job is to gather the requested information and package the response. With notifications, you pre-register for asynchronous events. It would be a much greater burden on the agent, whether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type of event! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Mar 9 12:46:30 1998 Delivery-Date: Mon, 09 Mar 1998 12:46:31 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03734 for ; Mon, 9 Mar 1998 12:46:30 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03392 for ; Mon, 9 Mar 1998 12:49:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16768 for ; Mon, 9 Mar 1998 12:46:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 12:42:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16208 for ipp-outgoing; Mon, 9 Mar 1998 12:41:59 -0500 (EST) Message-Id: <3.0.1.32.19980309085553.00c72650@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Mar 1998 08:55:53 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-fielding-uri-syntax-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno -- >To: IETF-Announce:; >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-fielding-uri-syntax-02.txt >Date: Mon, 9 Mar 1998 07:43:40 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Uniform Resource Identifiers (URI): Generic Syntax > Author(s) : T. Berners-Lee, L. Masinter, R. Fielding > Filename : draft-fielding-uri-syntax-02.txt > Pages : 26 > Date : 06-Mar-98 > > A Uniform Resource Identifier (URI) is a compact string of characters > for identifying an abstract or physical resource. This document > defines the general syntax of URIs, including both absolute and > relative forms, and guidelines for their use; it revises and replaces > the generic definitions in RFC 1738 and RFC 1808. > >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-fielding-uri-syntax-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-fielding-uri-syntax-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 9 12:51:25 1998 Delivery-Date: Mon, 09 Mar 1998 12:51:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA03940 for ; Mon, 9 Mar 1998 12:51:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03442 for ; Mon, 9 Mar 1998 12:53:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA17411 for ; Mon, 9 Mar 1998 12:51:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 12:45:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16688 for ipp-outgoing; Mon, 9 Mar 1998 12:45:49 -0500 (EST) From: Harry Lewis To: Subject: RE: IPP> Notification content Message-ID: <5030300018796328000002L082*@MHS> Date: Mon, 9 Mar 1998 12:52:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA03940 Yes, thank you Randy. We went on, at the JMP meeting, to discuss this quite at length. I am preparing the JMP minutes for distribution today or tomorrow. I will cross post a reference (if that's still allowed). Harry Lewis - IBM Printing Systems rturner@sharplabs.com on 03/09/98 10:34:27 AM Please respond to rturner@sharplabs.com @ internet To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Roger K Debry/Boulder/IBM@ibmus Subject: RE: IPP> Notification content I seem to remember there was some concensus towards the end of the discussion that two items needed to be defined: 1. What events cause a notification to be generated, and 2. What parameters get transmitted along with the event notification. I emphasized at the meeting that the parameters that are transmitted along with a particular event are "standardized" (fixed) in a standards-track document. If a client needs to know more about the particular event, the client can subsequently issue an IPP request or possibly an SNMP request depending upon the original event. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Monday, March 09, 1998 9:27 AM To: ipp@pwg.org Cc: Roger K Debry Subject: IPP> Notification content In Austin, I think we discussed the IPP notification requirement that any attribute may be requested during registration for a given event. I think the requirement stems from the notion that notification content should just "mimic" the response to a query. But this is probably unrealistic. A query/response is synchronous - during which, the "agent's" job is to gather the requested information and package the response. With notifications, you pre-register for asynchronous events. It would be a much greater burden on the agent, whether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type of event! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Mar 9 13:32:08 1998 Delivery-Date: Mon, 09 Mar 1998 13:32:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07829 for ; Mon, 9 Mar 1998 13:32:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03648 for ; Mon, 9 Mar 1998 13:34:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19726 for ; Mon, 9 Mar 1998 13:29:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 13:16:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17815 for ipp-outgoing; Mon, 9 Mar 1998 13:15:59 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 09 Mar 1998 11:15:02 -0700 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> Notification - Austin presentation posted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA07829 I have posted the presentation that I did for the Austin meeting. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification-980304.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification-980304.ppt These are PDF and PowerPoint 97 formats respectively. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Mon Mar 9 13:49:36 1998 Delivery-Date: Mon, 09 Mar 1998 13:49:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08833 for ; Mon, 9 Mar 1998 13:49:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03760 for ; Mon, 9 Mar 1998 13:52:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19366 for ; Mon, 9 Mar 1998 13:26:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 13:14:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17572 for ipp-outgoing; Mon, 9 Mar 1998 13:14:14 -0500 (EST) Message-ID: <35043164.9123B8D5@underscore.com> Date: Mon, 09 Mar 1998 13:13:56 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org, Sense mailing list Subject: Re: IPP> Notification content References: <5030300018795096000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry, I agree with your observations entirely. And these concerns are *exactly* why SENSE was designed to _not_ support any kind of filtering, so as to ease the burden on the SENSE server (which is the "agent" in your text below). ...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 -- ---------------------------------------------------------------------- Harry Lewis wrote: > > In Austin, I think we discussed the IPP notification requirement that any > attribute may be requested during registration for a given event. I think the > requirement stems from the notion that notification content should just "mimic" > the response to a query. But this is probably unrealistic. A query/response is > synchronous - during which, the "agent's" job is to gather the requested > information and package the response. With notifications, you pre-register for > asynchronous events. It would be a much greater burden on the agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants which > notifications, but also what information they requested with each type of event! > > Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Mar 9 13:52:27 1998 Delivery-Date: Mon, 09 Mar 1998 13:52:28 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09050 for ; Mon, 9 Mar 1998 13:52:27 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03776 for ; Mon, 9 Mar 1998 13:55:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19602 for ; Mon, 9 Mar 1998 13:28:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 13:15:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17664 for ipp-outgoing; Mon, 9 Mar 1998 13:14:56 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 09 Mar 1998 11:12:45 -0700 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> Directory - Austin presentation posted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09050 I have posted the presentation that I did for the Austin meeting. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping-980304.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping-980304.ppt These are PDF and PowerPoint 97 formats respectively. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Mon Mar 9 13:55:07 1998 Delivery-Date: Mon, 09 Mar 1998 13:55:07 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09178 for ; Mon, 9 Mar 1998 13:55:07 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03805 for ; Mon, 9 Mar 1998 13:57:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20748 for ; Mon, 9 Mar 1998 13:55:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 13:49:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19997 for ipp-outgoing; Mon, 9 Mar 1998 13:48:58 -0500 (EST) From: Harry Lewis To: Cc: , Subject: Re: IPP> Notification content Message-ID: <5030300018799170000002L002*@MHS> Date: Mon, 9 Mar 1998 13:55:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09178 Jay, with a generic event broker, like SENSE, I can understand how filtering could get out of hand. For the specific case of Job events, however, I am actually advocating an EVENT TYPE filter. In my note, I was trying to point out that allowing arbitrary CONTENT per event type is probably out of scope From ipp-owner@pwg.org Mon Mar 9 13:59:20 1998 Delivery-Date: Mon, 09 Mar 1998 13:59:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09294 for ; Mon, 9 Mar 1998 13:59:20 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03824 for ; Mon, 9 Mar 1998 14:01:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA21272 for ; Mon, 9 Mar 1998 13:59:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 9 Mar 1998 13:53:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20564 for ipp-outgoing; Mon, 9 Mar 1998 13:53:41 -0500 (EST) Message-Id: <3.0.1.32.19980309101423.011811a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Mar 1998 10:14:23 PST To: Van Dang , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Need clarification: Job Template Attributes: Optional or Mandatory? In-Reply-To: <34FDE3C4.3427@hprnd.rose.hp.com> References: <5030100018137864000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Yes, it is a mistake in section 15.3.4.3. The M* should be O*, since Job Template attributes are not MANDATORY for a Printer to support (just recommended if the device supports the feature). This was agreed at the IPP meeting as well as being a typo that will be fixed by the editor, Scott Isaacson, in consultation with the RFC editor as the document becomes an RFC. Since the notation also refers to section 4.2 which refers to section 12.2.3 which recommends that a Printer object support a Job Template attribute that a device realizes, we could introduce the notation "R" for recommended in section 15.3.4.3. We don't want to mis-lead implementors that are using section 153.4.3 as a check list. Or we could just change section 15.3.4.3 (4 times): Group 2: Job Template Attributes (M) Job Template attributes (M*) (see section 4.2) to: Group 2: Job Template Attributes (M) Job Template attributes (O*) (recommended, see section 4.2) Please send any other discrepancies or contradictions like this to the e-mail list so that we can fix them as the document becomes an RFC. Thanks, Tom At 15:29 03/04/1998 PST, Van Dang wrote: >Carl Kugler wrote: >> >> Section 15.3.4.3, "Validate the presence of a single occurrence of required >> Operation attributes", shows Job Template attributes as (M*) for Print-Job, >> Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDATORY >> attributes that an IPP object MUST support, but that a client may omit in a >> request or an IPP object may omit in a response. The reader is referred to >> Section 4.2, where it says "Support for Job Template attributes by a Printer ob >> ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though support >> for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED >> that if the device behind a Printer object is capable of realizing any feature >> or function that corresponds to an IPP attribute and some associated value, th >> en that implementation SHOULD support that IPP attribute and value." >> Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I missing >> something? > >I had the same question when I was going over the document. Perhaps >Section 15.3.4.3 should indicate that the Job Template Attributes are >(O*) instead of (M*) since the attribute group itself is OPTIONAL. > > From jmp-owner@pwg.org Tue Mar 10 11:22:54 1998 Delivery-Date: Tue, 10 Mar 1998 11:22:55 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25193 for ; Tue, 10 Mar 1998 11:22:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07605 for ; Tue, 10 Mar 1998 11:25:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA09791 for ; Tue, 10 Mar 1998 11:22:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 11:19:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09360 for jmp-outgoing; Tue, 10 Mar 1998 11:17:09 -0500 (EST) From: Harry Lewis To: Cc: Subject: JMP> Austin JMP (trap) minutes Message-ID: <5030300018837125000002L052*@MHS> Date: Tue, 10 Mar 1998 11:23:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: jmp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA25193 I have uploaded the meeting minutes for the March meeting in Austin. ftp://ftp.pwg.org/pub/pwg/jmp/minutes/jmp-0398.pdf The file is also available in HTML. IPP Notification folks may want to review item (3) under the "Job MIB trap topics" section. Here you will find a list of Notification Types (called trap types for JMP) and a table of Notification content, per type. This should be useful for IPP notification, as well. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Mar 10 11:33:52 1998 Delivery-Date: Tue, 10 Mar 1998 11:33:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25772 for ; Tue, 10 Mar 1998 11:33:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07694 for ; Tue, 10 Mar 1998 11:36:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA10212 for ; Tue, 10 Mar 1998 11:33:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 11:17:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09368 for ipp-outgoing; Tue, 10 Mar 1998 11:17:15 -0500 (EST) From: Harry Lewis To: Cc: Subject: IPP> Austin JMP (trap) minutes Message-ID: <5030300018837125000002L052*@MHS> Date: Tue, 10 Mar 1998 11:23:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA25772 I have uploaded the meeting minutes for the March meeting in Austin. ftp://ftp.pwg.org/pub/pwg/jmp/minutes/jmp-0398.pdf The file is also available in HTML. IPP Notification folks may want to review item (3) under the "Job MIB trap topics" section. Here you will find a list of Notification Types (called trap types for JMP) and a table of Notification content, per type. This should be useful for IPP notification, as well. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Mar 10 14:12:13 1998 Delivery-Date: Tue, 10 Mar 1998 14:12:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA01395 for ; Tue, 10 Mar 1998 14:12:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA08842 for ; Tue, 10 Mar 1998 14:14:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12033 for ; Tue, 10 Mar 1998 14:11:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 14:06:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11507 for ipp-outgoing; Tue, 10 Mar 1998 14:06:48 -0500 (EST) From: don@lexmark.com Message-Id: <199803101906.AA27408@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 10 Mar 1998 14:06:24 -0500 Subject: IPP> March Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Here are the meeting minutes from the March Meeting in Austin. I have also posted these to the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0398.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0398.pdf ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ----------------------------------------------------------------- Internet Printing Project Meeting Minutes March 4/5, 1998 Austin, Texas The meeting started on March 4, 1998 at 1:00 PM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: - Randy Turner - Sharp - Ron Bergman - DataProducts - Peter Zehler - Xerox - Lee Farrell - Canon - Bob Pentecost - HP - Kris Schoff - HP - Don Wright - Lexmark - Tom Hastings - Xerox - Carl-Uno Manros - Xerox - Bob Herriot - Sun - Henrik Holst - I-Data - Harry Lewis - IBM - Paul Moore - Microsoft - Jim Walker - Dazel - Scott Isaacson - Novell - Shivaun Albright - HP - Mabry Dozier - QMS - Yuji Sasaki - JCI - Marvin Heffler - IBM - Roger deBry- IBM - Lloyd Young - Lexmark - Bill Wagner - Osicom/DPI - Brian Batchelder - HP - Chuck Adams - Tektronix - David Kellerman - Northlake Software - Keith Carter - IBM - Philip Thambidurai - Okidata - Praveen Kanipakam - Sharp - Peter Michaleu - Shinesoft - Bob Broecolo - Kodak Carl-Uno Manros reviewed the agenda for the day. Carl-Uno announced that Scott Isaacson will be presenting an overview of IPP at WWW7 in Brisbane in April. DEVICE-TO-PRINTER PROTOCOL -------------------------- Roger deBry presented the "Print Systems Configuration" document which provides a framework of the various configurations of print systems. This document is available in PDF and PPT versions on the PWG FTP server as ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.pdf and as ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.ppt. There was significant discussion over the usage and arrangement of various terminologies (e.g. what is a server versus client.) The group discussed the need for a host-to-printer protocol. Should IPP evolve upwards to provide the functionality of a robust host-to-printer protocol? Does something new need to be created or does something already exist? How much similarity does there need to be between a client-to-server protocol (like IPP) and the device-to-printer protocol. Paul Moore led and others created a list of the deficiencies in IPP as a host-to-printer protocol: 1) IPP is asymmetrical: No way for the printer to generate an alert. 2) Today there is no peer conflict resolution in IPP. How does an IPP printer resolve being asked to print by two clients. 3) There is no way for the printer to solicit data from the client. For example to throttle data transfers. 4) The current security model might be too complex for printer devices. 5) Not transport neutral, depends on HTTP. 6) Fairly heavy duty. 7) No way to move data backwards. 8) No separate channel for control while data is being printed. 9) Detailed configuration and status not available. 10) Feature set of IPP was constrained to support low-end printer implementations. 11) No accounting outside of device. 12) No resource server 13) The data representation may not be sophisticated enough. Don Wright presented an overview of IEEE Std. 1284.1-1997 to the group as an example of an existing standard for device-to-printer protocol. This presentation is available at ftp://ftp.lexmark.com/pub/ieee/1284.1/pwg12841.pdf. Due to the absence of Jay Martin, David Kellerman and Tom Hastings briefly highlighted the characteristics and capabilities of CPAP. CPAP version 1 was released as an Informational RFC. The CPAP version 2 draft is available on the PWG ftp server. The CPAP specification is available at ftp://ftp.pwg.org/pub/pwg/cpap/cpap.pdf The group discussed the possible courses of action on the device-to- printer protocol. Possibilities include: 1) Enhancing IPP, adding access to MIB objects, etc. 2) Mapping an enhanced IPP to raw TCP/IP 3) adopting/modifying an existing device-to-printer protocol 4) A version of IPP for devices that supports a subset of IPP plus device control specific additions Randy Turner plans to put out a document that adds some of the desired control functionality and maps it to TCP/IP rather than using HTTP. Don Wright will do a comparison of the IPP attributes and TIP/SI. Scott Isaacson and Tom Hastings will investigate using an IPP follow-on (aka IPP') to access the MIB in the printer. TESTING ------- Peter Zehler presented and overview of the testing and verification plan. This document is available on the PWG server as ftp://www.pwg.org/pub/pwg/ipp/new_TES/IPP-Test-Plan-980216.pdf Several work items were identified that could be added to the test plan: -- Test of error codes - boundary conditions - unsupported operations, etc. - bad syntax Peter Zehler will be collecting experience information from the test cycle that could be included as implementation experience. No significant changes were made to the plan based upon discussion. The group discussed the need for some tools that could make the testing and interoperation verification easier. For example, a special "DIFF" that ignored things like the job id, submission time, etc. Another tool that would be useful would be a print formatter that would take the binary data and convert it into something more human readable. Right now, the traces are stored on the ftp server as simply an binary files containing the wire transactions. The meeting recessed at 6:00 PM. The meeting resumed at 8:35 on March 5, 1997. Carl-Uno reviewed the agenda for the day. The first topic of discussion was notification. NOTIFICATION ------------ Roger deBry discussed the requirements of IPP notifications ID which is available on the PWG ftp server as ftp.pwg.org/pub/pwg/ipp/new_NOT/IPP- notify-980219.txt. It was pointed out that a delivery means might have different quality of service levels. For example a notification like an SNMP trap might have two qualities of service levels, one that sends the trap just once and another that continues to retry until the requestor receives it. Roger will update the document. The group discussed the issues of security in the notification space and the possibility of intercepting notification as a way to get around IPP security that would prevent someone from looking at the printers job queue. Roger will submit an update of the Notification Requirements document to the IETF before March 13th in order to be discussed at the LA IETF meeting. Randy Turner reviewed the notification work being done in the IFAX/EMAIL working group. First Randy reviewed the existing "delivery status notification" (DSN) and "message disposition notification" (MDN) processes that are used by e-mail (SMTP) today. It had been proposed on the mailing list that IPP use MDN's for IPP job complete notifications. If we were to use something like the multi-part disposition-notification we would need to include in the machine-readable section information to identify the language of any text strings. DSN's are described in RFCs 1891-1894 (especially 1894) and MDN's in draft-ietf-receipt-mdn-08.txt. Randy Turner next reviewed SNMP traps. SNMPv1 traps were unreliable and had not standard way to specify trap destination. In SNMPv3, there are some additions to traps called "informs." Traps are still unreliable in v3 but a standard way to specify destinations for both traps and informs were added. SNMPv3 "informs" can be reliable. Both "informs" and traps can be secure. SNMPv3 added a Target MIB that specifies destination for traps and "informs": - names - transport domain (upd/ip, tcp/ip, ipx, etc.) - transport address (depends on domain) - message processing model (V1, V2, V2C, V3) - security method (e.g. TLS) - security level (e.g. RC2) - security name ("fred") - timeout - retry count This is all documented in RFC2273. RFC1908 talks about interoperation between SNMPv3 and SNMPv1. Additionally, the Notification MIB allows the agent to store what traps and informs are sent to which destinations. The group discussed a number of possible ways to use these concepts for notification; however, no direction was set. Scott Isaacson then reviewed several other notification schemes. His slides will be posted to the PWG ftp server (ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification- 980304.pdf). The presentation covered: - OMG -> IDL and CORBA based - The Open Group - Java - NPDS (uses RPC -- RFC1831/1832) The group discussed what the IETF would be receptive to in this notification area. SNMPv3 and other means are available out of devices but it doesn't address the scalability issue, i.e. how do a large number of clients get information about a large numbers of printers. The concept discussed is that of an event delivery channel that would collect events from printers and distribute them to interested clients. In the Novell NDPS implementation, registration for events get sent to the printer and forwarded on to the "channel" which distributes the events. Conceptually, IPP could be used as the registration means and a different protocol could be used to delivery the notification back to the registered client. Harry Lewis showed a presentation covering IBM's concepts of JOB MIB Traps. Harry Lewis will be posting this presentation in the PWG ftp server in the JMP directory tree. DIRECTORY Scott Isaacson presented material on the issues of mapping of IPP attributes to a directory schema. This material will be posted to the ftp server(ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping- 980304.pdf). Scott compared the original IPP schema proposal with SLP and what would be capable using LDAP. Scott will get back with Pete St. Pierre, who wrote the SLP printer mapping, and point out the inconsistencies between IPP and the SLP printer mapping. MODEL DOCUMENT Scott reviewed a number of comments made to the DL about the model document. There were no technical changes made; several typos were identified and clarified. The new name for the IPP Protocol Document will be "Internet Printing Protocol/1.0: Encoding and Transport". ACTION ITEMS: * Tom Hastings and Roger deBry will be doing some work on dictionary syntax. * Tom Hastings will be doing some work on improving the document object and document object attributes for a future version of IPP. * Steve Zilles will write a proposal for adding font support to IPP. OTHER ISSUES Peter Zehler has done some work on Automatic Printer Installation. He presented an overview of his thoughts and work in this area. This work has been written up and posted on the PWG ftp server as ftp://www.pwg.org/pub/pwg/ipp/new_INST/ipp-printer-install-980213.pdf. There was a lot of discussion about how this could be used. There was a reluctance to add anything to the IPP protocol but rather to create an informational RFC or a "best practices" document that would describe how the features of IPP could be used to do automatic driver installation. Tom Hastings has written a paper Early Binding Defaulting which was posted to the mailing list ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer- defaulting.pdf as well as ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer- defaulting.txt. After some discussion about boundary conditions and printer cascading effects, Tom will update the document and re-post it to the mailing list. The results of this proposal are probably a significant change to the model and would probably need to be a "Model" change. IPP has a two hour time slot at the LA IETF meeting on Wednesday, April 1, 1998 from 1PM until 3PM. Any documents to be discussed need to be sent to the IETF editor by 3/13. The next IPP meeting (outside the LA IETF meeting) will be held April 8/9 in Portland, Or. Details are available from http://www.pwg.org/chair. The meeting adjourned at 5:10PM From ipp-owner@pwg.org Tue Mar 10 14:30:15 1998 Delivery-Date: Tue, 10 Mar 1998 14:30:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA01846 for ; Tue, 10 Mar 1998 14:29:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA08948 for ; Tue, 10 Mar 1998 14:32:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA12675 for ; Tue, 10 Mar 1998 14:29:33 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 14:25:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12134 for ipp-outgoing; Tue, 10 Mar 1998 14:25:12 -0500 (EST) Message-Id: <3.0.1.32.19980310111925.0121a4d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 11:19:25 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Conference Call - 980311 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Conference Call - 980311 We will hold a conference call tomorrow as usual. Sorry for the late announcement, which was due to some confusion about who was setting up the call. I have just done that now, see the details below. I expect us to do some follow-up of the homework assignments from last week's meeting in Austin and to discuss how we should best organize the work on some of the new subjects, in particular on IPP Notifications and on the host-to-device subjects. Don will try to get the minutes out later today. I would also like to check up on getting an Implementor's Guide document started and also discuss a bit further about the interest to plan for a multi-vendor demo in the autumn. The phone-in information is: Date and Time: March 11, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 402-331-6491 (For Xerox participants 8*535-5000) Pass code: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 10 15:29:21 1998 Delivery-Date: Tue, 10 Mar 1998 15:29:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA03102 for ; Tue, 10 Mar 1998 15:29:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09374 for ; Tue, 10 Mar 1998 15:31:50 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13377 for ; Tue, 10 Mar 1998 15:29:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 15:25:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12818 for ipp-outgoing; Tue, 10 Mar 1998 15:25:10 -0500 (EST) Message-Id: <3.0.1.32.19980310122336.011dcbc0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 12:23:36 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Slides for IPP meeting: printer system configurations In-Reply-To: <3.0.1.32.19980303155013.01167610@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org The correct directory was new_REQ, not new_RAT, for our host-to-device discussion: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.ppt ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.pdf At 15:50 03/03/1998 PST, Tom Hastings wrote: >I've down-loaded the slides that Roger and I put together as an >action item to facilitate the discussion on host-to-device protocol >and notification on Wed. > >Its in: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.ppt >ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.pdf > >I'm bringing 30 copies on hard copy and one set of tranparencies. > >Tom > > From ipp-owner@pwg.org Tue Mar 10 16:04:21 1998 Delivery-Date: Tue, 10 Mar 1998 16:04:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA04137 for ; Tue, 10 Mar 1998 16:04:21 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09586 for ; Tue, 10 Mar 1998 16:06:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA14054 for ; Tue, 10 Mar 1998 16:04:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Mar 1998 15:59:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13504 for ipp-outgoing; Tue, 10 Mar 1998 15:59:31 -0500 (EST) Message-Id: <3.0.1.32.19980310125409.009ff100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 12:54:09 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> 41st IETF-LOS ANGELES: IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org >X-Sender: mbeaulie@ietf.org >Date: Tue, 10 Mar 1998 11:57:56 PST >To: Carl-Uno Manros >From: Marcia Beaulieu >Subject: 41st IETF-LOS ANGELES: IPP >Cc: , > >This is to confirm one session for IPP as follows: > > Wednesday, April 1 at 1300-1500 (opposite dhc, pint, vrrp, mboned) > >Thanks, > >Marcia > > >********************************************************************** >Marcia Beaulieu >Meeting Coordinator >Voice: 703-620-8990 ext. 210 >Fax: 703-758-5913 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Mar 11 09:49:09 1998 Delivery-Date: Wed, 11 Mar 1998 09:49:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26993 for ; Wed, 11 Mar 1998 09:49:08 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12220 for ; Wed, 11 Mar 1998 09:51:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA25791 for ; Wed, 11 Mar 1998 09:49:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 09:38:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25234 for ipp-outgoing; Wed, 11 Mar 1998 09:37:54 -0500 (EST) Message-Id: <199803111437.JAA26480@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-dhcp-option-00.txt Date: Wed, 11 Mar 1998 09:37:44 -0500 Sender: ipp-owner@pwg.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 : DHCP Option for Internet Printing Protocol Services Author(s) : R. Turner Filename : draft-ietf-ipp-dhcp-option-00.txt Pages : 3 Date : 10-Mar-98 This document defines a new DHCP option for automatic configuration of Internet Printing Protocol (IPP)[1] services to potential clients. Services. This new option provides an IPP client with enough configuration information to initiate a session with an IPP server without manual configuration of the client, and without existing directory services. 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-dhcp-option-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-dhcp-option-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-dhcp-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Mar 11 10:02:59 1998 Delivery-Date: Wed, 11 Mar 1998 10:02:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27335 for ; Wed, 11 Mar 1998 10:02:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA12314 for ; Wed, 11 Mar 1998 10:05:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA26390 for ; Wed, 11 Mar 1998 10:02:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 09:59:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25864 for ipp-outgoing; Wed, 11 Mar 1998 09:59:04 -0500 (EST) From: Roger K Debry To: Subject: IPP> New notification requirements document posted Message-ID: <5030100018373836000002L062*@MHS> Date: Wed, 11 Mar 1998 09:58:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA27335 I have posted the updated requirements document for notifications. They can be found at - - ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ draft-ietf-ipp-not-01.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ draft-ietf-ipp-not-01.txt Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Mar 11 11:02:04 1998 Delivery-Date: Wed, 11 Mar 1998 11:02:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA29595 for ; Wed, 11 Mar 1998 11:02:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA12674 for ; Wed, 11 Mar 1998 11:04:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA27186 for ; Wed, 11 Mar 1998 11:02:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 10:57:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA26661 for ipp-outgoing; Wed, 11 Mar 1998 10:57:12 -0500 (EST) Message-ID: <3506B44D.C7229912@underscore.com> Date: Wed, 11 Mar 1998 10:57:01 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> Public concerns regarding the use of XML in standards efforts Content-Type: multipart/mixed; boundary="------------AF19E378F4F264900FC5F48E" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------AF19E378F4F264900FC5F48E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is a message just posted to the ACAP DL. (ACAP is the IETF WG for "Application Configuration Access Protocol", an effort I have been monitoring for quite some time with regard to SENSE.) This group is now considering whether to incorporate XML in ACAP, having all the same kinds of interest/concern the IPP WG has shown. These words are very disturbing. Unless anyone has any objections, I'd like to post related messages on this ACAP thread to the IPP DL so that others don't have to monitor the ACAP DL themselves. Please note that I am *not* against using XML; in fact, I find it rather interesting for IPP and other protocol efforts. I just want to make sure we have both eyes open should we pursue XML at this stage. ...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 -- ---------------------------------------------------------------------- --------------AF19E378F4F264900FC5F48E Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id WAA04160 for ; Tue, 10 Mar 1998 22:26:06 -0500 (EST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.5/8.8.2) id WAA16996; Tue, 10 Mar 1998 22:05:12 -0500 (EST) Received: via switchmail for ietf-acap+@andrew.cmu.edu; Tue, 10 Mar 1998 22:05:11 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 10 Mar 1998 22:03:23 -0500 (EST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by po5.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id WAA17471 for ; Tue, 10 Mar 1998 22:03:15 -0500 (EST) Received: from cambyses.cyrusoft.com (cambyses.cyrusoft.com [206.31.218.198]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id WAA17678; Tue, 10 Mar 1998 22:02:27 -0500 (EST) Date: Tue, 10 Mar 1998 22:03:51 -0500 From: "Matthew Wall" To: "IETF ACAP Discussion List" cc: "Chris Newman" Subject: Re: Transfer of ACAP data was Re: I-D ACTION:draft-ietf-asid-mime-direct-06.txt (fwd) Message-ID: <524524.3098556231@cambyses.cyrusoft.com> X-Mailer: Mulberry (MacOS) [1.4.0a2, s/n S-171717] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --On Tue, Mar 10, 1998 16:16 -0800 "Chris Newman" wrote: > Some people would suggest we use XML as the representation format. It's > not a bad format, but there's no stable spec to reference. Someone would > have to publish XML in an RFC first. [other stuff snipped] I categorically refuse to endorse any representation format or other alleged standard that requires paid membership in a consortium to access or reference. It's a closed standard no matter how good and no matter how many companies endorse it. Just my 2 c, but that's why this is an IETF group, after all. And as Chris points out, we can't legally reference this as an ACAP practice as long as there's no referenceable RFC or equivalent public document. To provide some catty backfill, one of the original proponents of XML was at our '97 ACAP meeting at the Holiday Inn in Pittsburgh. He actually provided useful participation at the time, as those of you who were there may recall. On this, I have no quibble. However, we were promised full access to, and participation in, the development of the XML specification at the time with the understanding we'd conjointly work on an XML-ACAP interop model. After several months of fruitless private email exchanges with this person and the designated W3C contacts, I was finally told any ACAP-interested party would also have to be a member of the W3C consortium, period, to participate. End of exchanges. If it stinks like dung, I don't want to have to taste it to find out what it really is. This one stinks of closed system thinking. I give it a big thumbs down (or, nose-held, to continue the metaphor) for this reason. - matt --------------AF19E378F4F264900FC5F48E-- From ipp-owner@pwg.org Wed Mar 11 12:08:20 1998 Delivery-Date: Wed, 11 Mar 1998 12:08:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA07017 for ; Wed, 11 Mar 1998 12:08:20 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13057 for ; Wed, 11 Mar 1998 12:10:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28230 for ; Wed, 11 Mar 1998 12:08:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 12:03:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27700 for ipp-outgoing; Wed, 11 Mar 1998 12:03:36 -0500 (EST) Message-Id: <3.0.1.32.19980311085808.009e6c40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 08:58:08 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-stdguide-ops-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI. Now they tell us... Carl-Uno ---- >To: IETF-Announce:; >Cc: stdguide@midnight.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-stdguide-ops-06.txt >Date: Wed, 11 Mar 1998 06:25:46 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Guide for Internet Standards Writers >Working Group of the IETF. > > Title : Guide for Internet Standards Writers > Author(s) : G. Scott > Filename : draft-ietf-stdguide-ops-06.txt > Pages : 19 > Date : 10-Mar-98 > > This document is a guide for Internet standard writers. It defines > those characteristics that make standards coherent, unambiguous, and > easy to interpret. Also, it singles out usage believed to have led > to unclear specifications, resulting in non-interoperable > interpretations in the past. These guidelines are to be used with > RFC 1543, ''Instructions to RFC Authors.'' > > This version of the document is a draft. > >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-stdguide-ops-06.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-stdguide-ops-06.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-stdguide-ops-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From adm Wed Mar 11 12:06:29 1998 Delivery-Date: Wed, 11 Mar 1998 12:08:25 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA06919 for ietf-123-outbound.10@ietf.org; Wed, 11 Mar 1998 12:05:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26480; Wed, 11 Mar 1998 09:37:45 -0500 (EST) Message-Id: <199803111437.JAA26480@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-dhcp-option-00.txt Date: Wed, 11 Mar 1998 09:37:44 -0500 Sender: cclark@cnri.reston.va.us --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 : DHCP Option for Internet Printing Protocol Services Author(s) : R. Turner Filename : draft-ietf-ipp-dhcp-option-00.txt Pages : 3 Date : 10-Mar-98 This document defines a new DHCP option for automatic configuration of Internet Printing Protocol (IPP)[1] services to potential clients. Services. This new option provides an IPP client with enough configuration information to initiate a session with an IPP server without manual configuration of the client, and without existing directory services. 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-dhcp-option-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-dhcp-option-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-dhcp-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Mar 11 13:25:59 1998 Delivery-Date: Wed, 11 Mar 1998 13:26:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09878 for ; Wed, 11 Mar 1998 13:25:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13515 for ; Wed, 11 Mar 1998 13:28:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00612 for ; Wed, 11 Mar 1998 13:25:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 13:13:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28930 for ipp-outgoing; Wed, 11 Mar 1998 13:13:40 -0500 (EST) Message-Id: <3.0.1.32.19980311095040.01182800@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:50:40 PST To: Harry Lewis , From: Tom Hastings Subject: RE: IPP> Notification content In-Reply-To: <5030300018796328000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org If the notification transport is SNMP, then I can see why the registration would be difficult if it included sending attributes that the registration specified. On the other hand, if the registration mechanism is simply attributes in a Job object that remain stored in that Job object for the life of the job, then allowing the requester to include the attribute names to be sent with the notification is straightforward and natural. >From a model point of view, we could cover both by saying that on an SNMP transport binding, the trap recipient has to go and read the attributes desired, but in a notification transport binding to, say, UDP data grams or email, the attributes and their current values at the time of the event would be bound into the notification information. Tom At 09:52 03/09/1998 PST, Harry Lewis wrote: >Yes, thank you Randy. We went on, at the JMP meeting, to discuss this quite at >length. I am preparing the JMP minutes for distribution today or tomorrow. I >will cross post a reference (if that's still allowed). > >Harry Lewis - IBM Printing Systems > > > > >rturner@sharplabs.com on 03/09/98 10:34:27 AM >Please respond to rturner@sharplabs.com @ internet >To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus >cc: Roger K Debry/Boulder/IBM@ibmus >Subject: RE: IPP> Notification content > > > >I seem to remember there was some concensus towards the end of the >discussion that two items needed to be defined: > >1. What events cause a notification to be generated, and >2. What parameters get transmitted along with the event >notification. > >I emphasized at the meeting that the parameters that are transmitted >along with a particular event are "standardized" (fixed) in a >standards-track document. If a client needs to know more about the >particular event, the client can subsequently issue an IPP request or >possibly an SNMP request depending upon the original event. > >Randy > > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Monday, March 09, 1998 9:27 AM > To: ipp@pwg.org > Cc: Roger K Debry > Subject: IPP> Notification content > > In Austin, I think we discussed the IPP notification requirement >that any > attribute may be requested during registration for a given >event. I think the > requirement stems from the notion that notification content >should just "mimic" > the response to a query. But this is probably unrealistic. A >query/response is > synchronous - during which, the "agent's" job is to gather the >requested > information and package the response. With notifications, you >pre-register for > asynchronous events. It would be a much greater burden on the >agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants >which > notifications, but also what information they requested with >each type of event! > > Harry Lewis - IBM Printing Systems > > > > > > > From ipp-owner@pwg.org Wed Mar 11 13:26:10 1998 Delivery-Date: Wed, 11 Mar 1998 13:26:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09888 for ; Wed, 11 Mar 1998 13:26:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13518 for ; Wed, 11 Mar 1998 13:28:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00636 for ; Wed, 11 Mar 1998 13:26:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 13:13:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28920 for ipp-outgoing; Wed, 11 Mar 1998 13:13:36 -0500 (EST) Message-Id: <3.0.1.32.19980311093307.010ba2d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:33:07 PST To: Paul Moore , "'ipp@pwg.org'" From: Tom Hastings Subject: Re: IPP> MS requirements for UPD In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC369@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Then I suggest that we develop a requirements document for UPD based on the meeting that took place last week. Any volunteers? How do the UPD and the GPD file requirements relate to the host-to-device protocol requirement additions to IPP that we are considering? Tom At 18:42 03/06/1998 PST, Paul Moore wrote: >At the Austin UPD session I was asked if I could post the MS requirements >for our Unidrive 5 product. Sadly I cannot find any - this is not unusual >inside MS - we make it up as we go along :-) > > From ipp-owner@pwg.org Wed Mar 11 13:26:20 1998 Delivery-Date: Wed, 11 Mar 1998 13:26:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09896 for ; Wed, 11 Mar 1998 13:26:19 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13521 for ; Wed, 11 Mar 1998 13:28:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00649 for ; Wed, 11 Mar 1998 13:26:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 13:13:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28921 for ipp-outgoing; Wed, 11 Mar 1998 13:13:36 -0500 (EST) Message-Id: <3.0.1.32.19980311093213.010be660@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:32:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> NOT - device-to-host events, not end-user events Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org In discussing the host-to-device requirements, we came up with a requirement that the printer be able to feed back information about whether it was choked up with data or needed more data for the current job. So we could have events like: Slow down data transfer Speed up data transfer There is an even more important event for a device to send to a host: Ready for another job This event is useful for a number of configurations: 1. Such an event could anticipate the completion of the current job, so that the devices could overlap jobs. Printers that completely interpret a job or document before marking would want to indicate that they are ready for the next job much sooner that printers that mark as they interpret. Printers with a long output paper path may want to ask for the next job while the output paper path is being emptied, so that the printer doesn't slow down between jobs. A host that has a job would then be advised that this device could accept it now. If the host did not have a job, the host could still keep an indication that this device is a candidate for a job when a new job is submitted to the host. 2. This event is especially useful for the IPP fan-out case of a server/host that controls multiple devices represented by a single IPP Printer object. 3. This event is also useful for the simpler case where a device is controlled by more than one host and the device wants to indicate that it is ready for another job from any of the hosts (or from a particular one, if the device is trying to be fair). I just read the current Notification Requirements and it is focused on events that end users needs, so the above event are ones that hosts need, not end-users. But these events are NOT events that administrators need. Usually in the IPP WG, we have been making the distinction between end-users vs. system operators/adminstrators, not between end-users versus servers/hosts that are submitting jobs to devices on behalf of end-users. So are the above events in-scope for our IPP notification effort or out of scope? I think the answer depends on whether the IPP WG is going to tackle the host-to-device requirements for IPP. Tom From ipp-owner@pwg.org Wed Mar 11 13:50:59 1998 Delivery-Date: Wed, 11 Mar 1998 13:51:10 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12714 for ; Wed, 11 Mar 1998 13:50:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13719 for ; Wed, 11 Mar 1998 13:53:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA01426 for ; Wed, 11 Mar 1998 13:50:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 13:46:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00873 for ipp-outgoing; Wed, 11 Mar 1998 13:46:21 -0500 (EST) Message-ID: <3506DB1F.4D905747@underscore.com> Date: Wed, 11 Mar 1998 13:42:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3.0.1.32.19980311093213.010be660@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer This doesn't quite sound right. I mean, flow control should be mandated by the underlying transport, right? We certainly don't want to reinvent such a key aspect of end-to-end communications within IPP. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Mar 11 14:25:49 1998 Delivery-Date: Wed, 11 Mar 1998 14:25:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA16578 for ; Wed, 11 Mar 1998 14:25:49 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13898 for ; Wed, 11 Mar 1998 14:28:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02157 for ; Wed, 11 Mar 1998 14:25:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 14:21:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01614 for ipp-outgoing; Wed, 11 Mar 1998 14:21:29 -0500 (EST) Date: Wed, 11 Mar 1998 11:10:20 -0800 (Pacific Standard Time) From: Ron Bergman To: Jay Martin cc: Tom Hastings , ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events In-Reply-To: <3506DB1F.4D905747@underscore.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Tom, I certainly agree with Jay on this subject. I don't know of any transport that does not provide some method of flow control. Certainly TCP provides an excellent flow control mechanism. I don't recall this requirement discussed in any of the meetings in Austin. Where did this come from? Ron Bergman Dataproducts Corp. On Wed, 11 Mar 1998, Jay Martin wrote: > Tom Hastings wrote: > > > > In discussing the host-to-device requirements, we came up with a requirement > > that the printer be able to feed back information about whether it was > > choked up with data or needed more data for the current job. > > > > So we could have events like: > > > > Slow down data transfer > > Speed up data transfer > > This doesn't quite sound right. I mean, flow control should be mandated > by the underlying transport, right? We certainly don't want to reinvent > such a key aspect of end-to-end communications within IPP. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From ipp-owner@pwg.org Wed Mar 11 15:01:46 1998 Delivery-Date: Wed, 11 Mar 1998 15:01:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA17774 for ; Wed, 11 Mar 1998 15:01:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA14054 for ; Wed, 11 Mar 1998 15:04:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02869 for ; Wed, 11 Mar 1998 15:01:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 14:57:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02326 for ipp-outgoing; Wed, 11 Mar 1998 14:57:28 -0500 (EST) From: Roger K Debry To: Subject: IPP> Minutes of 3/11/98 telephone conference Message-ID: <5030100018385778000002L082*@MHS> Date: Wed, 11 Mar 1998 14:56:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA17774 Minutes of 3/11 Telephone Conference Attending: Carl-Uno Manros, Tom Hastings, Pete Zahler, Roger deBry, Scott Isaacson, Jay Martin, Ira MacDonald, Randy Turner 1. Carl-Uno said that Don Wright cannot continue as secretary for IPP telephone conference calls. Carl-Uno will find someone to replace Don. 2. Paul Moore had said he would try to get the requirements document from Microsoft on UDP. He has subsequently said that a formal requirements document does not exist. 3. Randy is working on a proposal for host-to-device. He said he will have a document ready by the end of this week. There was some discussion whether or not host-to-device was an IETF issue. Carl-Uno wants to be sure that it is posted as a personl contribution at this point, since there has been no review by the working group. Randy's document will include: - an abstraction of transport layer - mapping of IPP to TCP/IP - discussion on notifications 4. Don was to provide documentation on TIPSI elements that would apply to a host-to-device protocol. Nothing reported yet. 5. Tom and Scott to work on MIB attributes that would be aappropriate for host-to-device protocols. Nothing done to date. 6. Some discussion was held on Randy's recent submission on DHCP option for IPP. Randy said that it was supposed to have been a personal submission and not an IPP workgroup submission. Randy said that this was required for his host-to-device proposal and he wanted it to be on the IETF standards track. 7. Brief discussion of Pete Zahler's testing work. Pete said that he is working on getting a printer on the network for testing and is working on updates for the test plan document 8. Discussion of Notification work items - Requirements document has been updated and submitted. Scott and Harry have posted presentation material to the ftp site. Tom asked whether or not anyone had considered datagrams for notifications. Ira said that there was some issues with SNMP Notify. 9. Carl-Uno said that he wants to find a "Champion" for each of the notification and host-to-device work items. He will work on this. 10. Scott is having ongoing discussions with IPP mapping to SLP and driving this with the SLP people. 11. Discussed the need to define a new error code and words to go with it on printer busy condition. Randy has posted a discussion to the FTP site and said that he will write up the text for the Model document. 12. Dictionary attributes - Tom and Roger will work on this with the goal of having a proposal for the enxt PWG meeting. 13. Carl Uno asked if anyone wanted to work with Tom on Document attributes. No one offered. 14. An old homework item was discussed - the registration of mime types with IANA. No specific action item was taken. 15. There was some discussion of Tom's proposal for early binding of default attributes. The consensus seemd to be that this was not just a small change to the Model document. The possibility of having some vendor(s) do this as a private extension was discussed. 16. Carl-uno is looking for someone to be the editor of an "Implementor's Guide." 17. There was soem discussion on UDP, but no one felt that they understood what follow-on activities were planned. UDP should be a separate working group from IPP. 18. Reminder that the next IPP face to face meeting is April 8-9 in Portland. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Mar 11 16:09:49 1998 Delivery-Date: Wed, 11 Mar 1998 16:09:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20036 for ; Wed, 11 Mar 1998 16:09:44 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14341 for ; Wed, 11 Mar 1998 16:12:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03732 for ; Wed, 11 Mar 1998 16:09:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:05:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03174 for ipp-outgoing; Wed, 11 Mar 1998 16:05:00 -0500 (EST) Message-ID: <19980311210445.11550.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> Printer state Content-Type: text/plain Date: Wed, 11 Mar 1998 13:04:45 PST Sender: ipp-owner@pwg.org I was looking into the different printer states defined in Model document (page: 99 - 100). The document says "The following standard values are defined '3' 'idle' '4' 'processing' '5' 'stopped' .. " I looked at the definition of 'stopped' state, and it says, "If a Printer receives a job (whose required resources are ready) while in this state, such a job SHALL transit into the pending state immediately...." There may be a situation when the actual output device is powered off. In that case, should IPP server respond with a state 'stopped'? If so, does that mean that IPP server still accepts print-job request instead of sending an error like "server-error-internal-error"? IMHO, if an output device is powered off, all IPP print job requests should fail with the above-mentioned server error. Also, the printer should have another state '6' 'no-device' to represent this condition. Any comments/suggestions? PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Mar 11 16:28:45 1998 Delivery-Date: Wed, 11 Mar 1998 16:28:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20541 for ; Wed, 11 Mar 1998 16:28:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14469 for ; Wed, 11 Mar 1998 16:31:19 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04912 for ; Wed, 11 Mar 1998 16:28:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:20:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03839 for ipp-outgoing; Wed, 11 Mar 1998 16:20:44 -0500 (EST) Message-Id: <3506FF42.833F0AD9@dazel.com> Date: Wed, 11 Mar 1998 15:16:50 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Harry Lewis Cc: ipp@pwg.org Subject: Re: IPP> Notification content References: <5030300018795096000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Harry Lewis wrote: > > In Austin, I think we discussed the IPP notification requirement that any > attribute may be requested during registration for a given event. I think the > requirement stems from the notion that notification content should just "mimic" > the response to a query. But this is probably unrealistic. A query/response is > synchronous - during which, the "agent's" job is to gather the requested > information and package the response. With notifications, you pre-register for > asynchronous events. It would be a much greater burden on the agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants which > notifications, but also what information they requested with each type of event! IMHO, this is one of those areas where the requirements differ depending upon whether we are talking about a host->device protocol, or the more general client->server protocol. In the case of a host->device protocol, I agree 100%... the host should be able to register for specific event types, where the event associated with each event type has some fixed, standardized content. This is along the lines of what was discussed in the JMP meeting in Austin. However, in the more general client->server case, I think that variable content is an important requirement. Specifically, I think that it is important that the notification be capable of holding enough information such that the client does *not* have to go back and query the server to get what it needs. Seeing as how we cannot mandate what information the client should be interested in, this implies that we should allow the client to specify its interest. Furthermore, if we are to allow vendors to extend IPP, then the only way that clients can get at that extended information in a notification is if we allow the client to ask for what it wants. one man's opinion... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Mar 11 16:28:58 1998 Delivery-Date: Wed, 11 Mar 1998 16:28:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20546 for ; Wed, 11 Mar 1998 16:28:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14472 for ; Wed, 11 Mar 1998 16:31:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04958 for ; Wed, 11 Mar 1998 16:28:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:21:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03875 for ipp-outgoing; Wed, 11 Mar 1998 16:21:11 -0500 (EST) Message-ID: <35070017.1D7BDF96@underscore.com> Date: Wed, 11 Mar 1998 16:20:23 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Puru Bish CC: ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org If the IPP server is a *spooling* server (eg, process(es) running on a general host system), then job submissions should not fail if the associated output device is powered off, IHMO. ...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 -- ---------------------------------------------------------------------- Puru Bish wrote: > > I was looking into the different printer states defined in Model > document (page: 99 - 100). The document says > > "The following standard values are defined > '3' 'idle' > '4' 'processing' > '5' 'stopped' .. " > > I looked at the definition of 'stopped' state, and it says, > "If a Printer receives a job (whose required > resources are ready) while in this state, such a job > SHALL transit into the pending state immediately...." > There may be a situation when the actual output device is > powered off. In that case, should IPP server respond with > a state 'stopped'? If so, does that mean that IPP server > still accepts print-job request instead of sending an error like > "server-error-internal-error"? > > IMHO, if an output device is powered off, all IPP print job requests > should fail with the above-mentioned server error. Also, > the printer should have another state > '6' 'no-device' > to represent this condition. > > Any comments/suggestions? > PB > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Mar 11 16:35:02 1998 Delivery-Date: Wed, 11 Mar 1998 16:35:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20698 for ; Wed, 11 Mar 1998 16:35:01 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14522 for ; Wed, 11 Mar 1998 16:37:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA05653 for ; Wed, 11 Mar 1998 16:34:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:30:49 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05083 for ipp-outgoing; Wed, 11 Mar 1998 16:30:42 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: FW: IPP> NOT - device-to-host events, not end-user events Date: Wed, 11 Mar 1998 13:30:35 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org -----Original Message----- From: Turner, Randy Sent: Wednesday, March 11, 1998 1:30 PM To: 'Jay Martin' Subject: RE: IPP> NOT - device-to-host events, not end-user events I agree with Jay completely. It would be very difficult for me to agree any more on this....but I'll try. ;) Randy. -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, March 11, 1998 10:43 AM To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer This doesn't quite sound right. I mean, flow control should be mandated by the underlying transport, right? We certainly don't want to reinvent such a key aspect of end-to-end communications within IPP. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Mar 11 16:47:19 1998 Delivery-Date: Wed, 11 Mar 1998 16:47:20 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21093 for ; Wed, 11 Mar 1998 16:47:19 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA14596 for ; Wed, 11 Mar 1998 16:49:52 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06282 for ; Wed, 11 Mar 1998 16:47:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:43:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05749 for ipp-outgoing; Wed, 11 Mar 1998 16:43:05 -0500 (EST) Message-ID: <35070456.F1D6BC37@xionics.com> Date: Wed, 11 Mar 1998 16:38:30 -0500 From: Adrian Hall Organization: Xionics Document Technologies, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: Jay Martin CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org This would depend. I can certainly see a couple of scenarios: 1. The Printer turned off is a part of a pool of printers - the server should continue spooling and simply use one of the other printers in the pool. 2. The user wants the print-out semi-immediately - in which case some sort of notification that the printer is turned off. Both are valid for the same condition. -- Adrian Hall Sr. Software Developer Xionics Document Technologies, Inc. Jay Martin wrote: > > If the IPP server is a *spooling* server (eg, process(es) running > on a general host system), then job submissions should not fail > if the associated output device is powered off, IHMO. > > ...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 -- > ---------------------------------------------------------------------- > > Puru Bish wrote: > > > > I was looking into the different printer states defined in Model > > document (page: 99 - 100). The document says > > > > "The following standard values are defined > > '3' 'idle' > > '4' 'processing' > > '5' 'stopped' .. " > > > > I looked at the definition of 'stopped' state, and it says, > > "If a Printer receives a job (whose required > > resources are ready) while in this state, such a job > > SHALL transit into the pending state immediately...." > > There may be a situation when the actual output device is > > powered off. In that case, should IPP server respond with > > a state 'stopped'? If so, does that mean that IPP server > > still accepts print-job request instead of sending an error like > > "server-error-internal-error"? > > > > IMHO, if an output device is powered off, all IPP print job requests > > should fail with the above-mentioned server error. Also, > > the printer should have another state > > '6' 'no-device' > > to represent this condition. > > > > Any comments/suggestions? > > PB > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Mar 11 17:02:37 1998 Delivery-Date: Wed, 11 Mar 1998 17:02:37 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA21628 for ; Wed, 11 Mar 1998 17:02:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14699 for ; Wed, 11 Mar 1998 17:05:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06948 for ; Wed, 11 Mar 1998 17:02:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 16:58:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06411 for ipp-outgoing; Wed, 11 Mar 1998 16:58:20 -0500 (EST) Message-ID: <350708E2.6ECE3659@underscore.com> Date: Wed, 11 Mar 1998 16:57:55 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Adrian Hall CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> <35070456.F1D6BC37@xionics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Yes, of course, the user should see some sort of "device problem" when a job is spooled but the device is powered off. The point I was making was that the job submission itself should not fail. ...jay Adrian Hall wrote: > > This would depend. I can certainly see a couple of scenarios: > > 1. The Printer turned off is a part of a pool of > printers - the server should continue spooling > and simply use one of the other printers in > the pool. > > 2. The user wants the print-out semi-immediately - > in which case some sort of notification that > the printer is turned off. > > Both are valid for the same condition. > > -- > Adrian Hall > Sr. Software Developer > Xionics Document Technologies, Inc. > > Jay Martin wrote: > > > > If the IPP server is a *spooling* server (eg, process(es) running > > on a general host system), then job submissions should not fail > > if the associated output device is powered off, IHMO. > > > > ...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 -- > > ---------------------------------------------------------------------- > > > > Puru Bish wrote: > > > > > > I was looking into the different printer states defined in Model > > > document (page: 99 - 100). The document says > > > > > > "The following standard values are defined > > > '3' 'idle' > > > '4' 'processing' > > > '5' 'stopped' .. " > > > > > > I looked at the definition of 'stopped' state, and it says, > > > "If a Printer receives a job (whose required > > > resources are ready) while in this state, such a job > > > SHALL transit into the pending state immediately...." > > > There may be a situation when the actual output device is > > > powered off. In that case, should IPP server respond with > > > a state 'stopped'? If so, does that mean that IPP server > > > still accepts print-job request instead of sending an error like > > > "server-error-internal-error"? > > > > > > IMHO, if an output device is powered off, all IPP print job requests > > > should fail with the above-mentioned server error. Also, > > > the printer should have another state > > > '6' 'no-device' > > > to represent this condition. > > > > > > Any comments/suggestions? > > > PB > > > > > > ______________________________________________________ > > > Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Mar 11 17:27:01 1998 Delivery-Date: Wed, 11 Mar 1998 17:27:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA22525 for ; Wed, 11 Mar 1998 17:27:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14826 for ; Wed, 11 Mar 1998 17:29:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07638 for ; Wed, 11 Mar 1998 17:26:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 17:22:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07104 for ipp-outgoing; Wed, 11 Mar 1998 17:22:25 -0500 (EST) Message-Id: <35070DC4.42DDF332@dazel.com> Date: Wed, 11 Mar 1998 16:18:44 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3.0.1.32.19980311093213.010be660@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer I agree with others comments regarding these events... I think that is an issue for the underlying transport. However... > There is an even more important event for a device to send to a host: > > Ready for another job I think that this could/would be a very useful event. As Tom pointed out, it is another case of something that is more appropriate for the host->device protocol than it is for a client application (I know that I am probably starting to sound like a broken record, but I think that it is important to point out these differences, as there are some who believe that there are none). The one point that I would add about a "ready for job" event is that, unless we make notifications absolutely reliable (very unlikely), an application could not rely on just this event to know that a printer was ready to accept another job. In that case, we would also want to model this piece of information as an attribute (or some sort of state value) for the printer. That way, if the server application missed the "ready for job" event, it would still be able to pick up this information by polling the printer object. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Mar 11 20:27:42 1998 Delivery-Date: Wed, 11 Mar 1998 20:27:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA24651 for ; Wed, 11 Mar 1998 20:27:41 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15696 for ; Wed, 11 Mar 1998 20:30:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA08474 for ; Wed, 11 Mar 1998 20:27:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 20:22:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07946 for ipp-outgoing; Wed, 11 Mar 1998 20:22:35 -0500 (EST) Message-Id: <3.0.1.32.19980311172044.011668d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 17:20:44 PST To: Paul Moore , Ron Bergman , Jay Martin From: Tom Hastings Subject: Re: IPP> NOT - device-to-host events, not end-user events Cc: ipp@pwg.org In-Reply-To: References: <3506DB1F.4D905747@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 11:10 03/11/1998 PST, Ron Bergman wrote: >Tom, > >I certainly agree with Jay on this subject. I don't know of any transport >that does not provide some method of flow control. Certainly TCP provides >an excellent flow control mechanism. > >I don't recall this requirement discussed in any of the meetings in >Austin. Where did this come from? Paul Moore suggested this. It is NOT flow control but rather advisory to a host that is controlling a large number of devices at once. Paul says he has NT systems that control a large number of devices, like 500, so that knowing which devices the host is getting ahead and which devices the host is falling behind in getting PDL data to the device would be useful. My understanding of what Paul was saying was that the host would then increase the priority of the threads that were getting behind and lower the priority of the threads that were getting ahead. Or does TCP/IP have such advisory events (as opposed to stop sending and start sending)? Tom > > > Ron Bergman > Dataproducts Corp. > > >On Wed, 11 Mar 1998, Jay Martin wrote: > >> Tom Hastings wrote: >> > >> > In discussing the host-to-device requirements, we came up with a requirement >> > that the printer be able to feed back information about whether it was >> > choked up with data or needed more data for the current job. >> > >> > So we could have events like: >> > >> > Slow down data transfer >> > Speed up data transfer >> >> This doesn't quite sound right. I mean, flow control should be mandated >> by the underlying transport, right? We certainly don't want to reinvent >> such a key aspect of end-to-end communications within IPP. >> >> ...jay >> >> ---------------------------------------------------------------------- >> -- JK Martin | Email: jkm@underscore.com -- >> -- Underscore, Inc. | Voice: (603) 889-7000 -- >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >> ---------------------------------------------------------------------- >> > > > From ipp-owner@pwg.org Wed Mar 11 21:01:03 1998 Delivery-Date: Wed, 11 Mar 1998 21:01:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24885 for ; Wed, 11 Mar 1998 21:00:53 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15808 for ; Wed, 11 Mar 1998 21:03:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA09106 for ; Wed, 11 Mar 1998 21:00:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 11 Mar 1998 20:56:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08573 for ipp-outgoing; Wed, 11 Mar 1998 20:56:46 -0500 (EST) Message-Id: <3.0.1.32.19980311175501.011816e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 17:55:01 PST To: Jay Martin , Adrian Hall From: Tom Hastings Subject: Re: IPP> Printer state Cc: Puru Bish , ipp@pwg.org In-Reply-To: <350708E2.6ECE3659@underscore.com> References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> <35070456.F1D6BC37@xionics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Yes, the Printer object implemented in a server object does accept the job even though the device is powered down. And the requester MAY get an indication that there is a problem, because the job's OPTIONAL "job-state-reason" attribute that MAY be returned in the Print-Job response containing the value: 'printer-stopped' (or 'printer-stopped-partly' in the case that only some of the fan-out printers are stopped). Unfortunately, the requeseter will NOT get this indication in the response, if the IPP Printer object does not implement the OPTIONAL "job-state-reasons" attribute. The client can then query the Printer's "printer-state" and "printer-state-reasons" attribute and see that the "printer-state" is 'stopped' and the "printer-state-reasons" is 'error-shutdown' ('warning-shutdown' if only some of the fan-out printers are shutdown). The explanation of the 'stopped' state on page 89 of the Model document says (in its entirity of two paragraphs): '5' 'stopped': If a Printer receives a job (whose required resources are ready) while in this state, such a job SHALL transit into the pending state immediately. Such a job SHALL transit into the processing state only after some human fixes the problem that stopped the printer and after jobs ahead of it complete printing. The "printer-state-reasons" attribute SHALL contain at least one reason, e.g. media-jam, which prevents it from either processing the current job or transitioning a pending job to the processing state. Note: if a Printer controls more than one output device, the above definition implies that a Printer is stopped only if all output devices are stopped. Also, it is tempting to define stopped as when a sufficient number of output devices are stopped and leave it to an implementation to define the sufficient number. But such a rule complicates the definition of stopped and processing. For example, with this alternate definition of stopped, a job can move from idle to processing without human intervention, even though the Printer is stopped. Does the Model document need any futher clarification? Tom At 13:57 03/11/1998 PST, Jay Martin wrote: >Yes, of course, the user should see some sort of "device problem" >when a job is spooled but the device is powered off. The point >I was making was that the job submission itself should not fail. > > ...jay > > >Adrian Hall wrote: >> >> This would depend. I can certainly see a couple of scenarios: >> >> 1. The Printer turned off is a part of a pool of >> printers - the server should continue spooling >> and simply use one of the other printers in >> the pool. >> >> 2. The user wants the print-out semi-immediately - >> in which case some sort of notification that >> the printer is turned off. >> >> Both are valid for the same condition. >> >> -- >> Adrian Hall >> Sr. Software Developer >> Xionics Document Technologies, Inc. >> >> Jay Martin wrote: >> > >> > If the IPP server is a *spooling* server (eg, process(es) running >> > on a general host system), then job submissions should not fail >> > if the associated output device is powered off, IHMO. >> > >> > ...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 -- >> > ---------------------------------------------------------------------- >> > >> > Puru Bish wrote: >> > > >> > > I was looking into the different printer states defined in Model >> > > document (page: 99 - 100). The document says >> > > >> > > "The following standard values are defined >> > > '3' 'idle' >> > > '4' 'processing' >> > > '5' 'stopped' .. " >> > > >> > > I looked at the definition of 'stopped' state, and it says, >> > > "If a Printer receives a job (whose required >> > > resources are ready) while in this state, such a job >> > > SHALL transit into the pending state immediately...." >> > > There may be a situation when the actual output device is >> > > powered off. In that case, should IPP server respond with >> > > a state 'stopped'? If so, does that mean that IPP server >> > > still accepts print-job request instead of sending an error like >> > > "server-error-internal-error"? >> > > >> > > IMHO, if an output device is powered off, all IPP print job requests >> > > should fail with the above-mentioned server error. Also, >> > > the printer should have another state >> > > '6' 'no-device' >> > > to represent this condition. >> > > >> > > Any comments/suggestions? >> > > PB >> > > >> > > ______________________________________________________ >> > > Get Your Private, Free Email at http://www.hotmail.com > > From ipp-owner@pwg.org Thu Mar 12 10:28:56 1998 Delivery-Date: Thu, 12 Mar 1998 10:28:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17463 for ; Thu, 12 Mar 1998 10:28:55 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA18177 for ; Thu, 12 Mar 1998 10:31:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA20581 for ; Thu, 12 Mar 1998 10:28:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 10:15:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20033 for ipp-outgoing; Thu, 12 Mar 1998 10:15:07 -0500 (EST) Message-Id: <199803121514.KAA16847@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-not-01.txt Date: Thu, 12 Mar 1998 10:14:13 -0500 Sender: ipp-owner@pwg.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 : Requirements for IPP Notifications Author(s) : R. deBry Filename : draft-ietf-ipp-not-01.txt Pages : 8 Date : 11-Mar-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). 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-not-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-not-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-not-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-not-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Thu Mar 12 11:11:47 1998 Delivery-Date: Thu, 12 Mar 1998 11:11:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA19311 for ; Thu, 12 Mar 1998 11:11:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18517 for ; Thu, 12 Mar 1998 11:14:20 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21211 for ; Thu, 12 Mar 1998 11:11:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 11:07:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20677 for ipp-outgoing; Thu, 12 Mar 1998 11:07:04 -0500 (EST) Message-ID: <3508072E.5928096C@underscore.com> Date: Thu, 12 Mar 1998 11:02:54 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Paul Moore , Ron Bergman , ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3506DB1F.4D905747@underscore.com> <3.0.1.32.19980311172044.011668d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom, No, most (all?) TCP stack implementations do not expose data throttling events to the client. (That is one of the several "transparent" things the stream-like TCP design gives the client.) While it wouldn't be trivial, I suppose a client app could make some thread priority adjustments based on detecting a "blocked" outbound stream. That is, upon trying to send a buffer, the client would reduce the thread priority if the API write function returned the (UNIX) equivalent of EWOULDBLOCK (assuming the socket was setup for non-blocking I/O support). While I understand Paul Moore's situation, I still don't think it's a good idea to introduce this kind of communications status in an application-level protocol such as IPP. Does anyone disagree? ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > At 11:10 03/11/1998 PST, Ron Bergman wrote: > >Tom, > > > >I certainly agree with Jay on this subject. I don't know of any transport > >that does not provide some method of flow control. Certainly TCP provides > >an excellent flow control mechanism. > > > >I don't recall this requirement discussed in any of the meetings in > >Austin. Where did this come from? > > Paul Moore suggested this. It is NOT flow control but rather > advisory to a host that is controlling a large number of devices > at once. Paul says he has NT systems that control a large number of > devices, like 500, so that knowing which devices the host is getting > ahead and which devices the host is falling behind in getting PDL data > to the device would be useful. My understanding of what Paul was saying > was that the host would then increase the priority of the threads that > were getting behind and lower the priority of the threads that were > getting ahead. > > Or does TCP/IP have such advisory events (as opposed to stop sending > and start sending)? > > Tom > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Wed, 11 Mar 1998, Jay Martin wrote: > > > >> Tom Hastings wrote: > >> > > >> > In discussing the host-to-device requirements, we came up with a > requirement > >> > that the printer be able to feed back information about whether it was > >> > choked up with data or needed more data for the current job. > >> > > >> > So we could have events like: > >> > > >> > Slow down data transfer > >> > Speed up data transfer > >> > >> This doesn't quite sound right. I mean, flow control should be mandated > >> by the underlying transport, right? We certainly don't want to reinvent > >> such a key aspect of end-to-end communications within IPP. > >> > >> ...jay > >> > >> ---------------------------------------------------------------------- > >> -- JK Martin | Email: jkm@underscore.com -- > >> -- Underscore, Inc. | Voice: (603) 889-7000 -- > >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > >> ---------------------------------------------------------------------- > >> > > > > > > From ipp-owner@pwg.org Thu Mar 12 12:07:08 1998 Delivery-Date: Thu, 12 Mar 1998 12:07:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA21379 for ; Thu, 12 Mar 1998 12:07:08 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA18922 for ; Thu, 12 Mar 1998 12:09:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21853 for ; Thu, 12 Mar 1998 12:07:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 12:02:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21334 for ipp-outgoing; Thu, 12 Mar 1998 12:02:43 -0500 (EST) Message-ID: <3508151F.1AD453D2@underscore.com> Date: Thu, 12 Mar 1998 12:02:23 -0500 From: Jeff Schnitzer Reply-To: Roger K Debry Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org [Roger accidentally sent this to ipp-owner rather than ipp@pwg.org] Subject: Re: IPP> NOT - device-to-host events, not end-user events Date: Thu, 12 Mar 1998 11:52:23 -0500 From: Roger K Debry To: In IPDS we defined some data stream level constructs to return information about the state of the printer. However, we do not use these for flow control, which should be handled by the transport. However, we find these data stream constructs *VERY* useful in resynchronizing the printer with the server in the case of some error conditions. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 > ipp-owner@pwg.org on 03/12/98 09:09:05 AM > To: hastings@cp10.es.xerox.com @ internet > cc: ipp@pwg.org @ internet, rbergma@dpc.com @ internet, paulmo@microsoft.com @internet > Subject: Re: IPP> NOT - device-to-host events, not end-user events > > > Tom, > > No, most (all?) TCP stack implementations do not expose > data throttling events to the client. (That is one of > the several "transparent" things the stream-like TCP > design gives the client.) > > While it wouldn't be trivial, I suppose a client app could > make some thread priority adjustments based on detecting a > "blocked" outbound stream. That is, upon trying to send a > buffer, the client would reduce the thread priority if the > API write function returned the (UNIX) equivalent of EWOULDBLOCK > (assuming the socket was setup for non-blocking I/O support). > > While I understand Paul Moore's situation, I still don't think > it's a good idea to introduce this kind of communications > status in an application-level protocol such as IPP. > > Does anyone disagree? > > ...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 -- > ---------------------------------------------------------------------- > > > Tom Hastings wrote: > > > > At 11:10 03/11/1998 PST, Ron Bergman wrote: > > >Tom, > > > > > >I certainly agree with Jay on this subject. I don't know of any transport > > >that does not provide some method of flow control. Certainly TCP provides > > >an excellent flow control mechanism. > > > > > >I don't recall this requirement discussed in any of the meetings in > > >Austin. Where did this come from? > > > > Paul Moore suggested this. It is NOT flow control but rather > > advisory to a host that is controlling a large number of devices > > at once. Paul says he has NT systems that control a large number of > > devices, like 500, so that knowing which devices the host is getting > > ahead and which devices the host is falling behind in getting PDL data > > to the device would be useful. My understanding of what Paul was saying > > was that the host would then increase the priority of the threads that > > were getting behind and lower the priority of the threads that were > > getting ahead. > > > > Or does TCP/IP have such advisory events (as opposed to stop sending > > and start sending)? > > > > Tom > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > >On Wed, 11 Mar 1998, Jay Martin wrote: > > > > > >> Tom Hastings wrote: > > >> > > > >> > In discussing the host-to-device requirements, we came up with a > > requirement > > >> > that the printer be able to feed back information about whether it was > > >> > choked up with data or needed more data for the current job. > > >> > > > >> > So we could have events like: > > >> > > > >> > Slow down data transfer > > >> > Speed up data transfer > > >> > > >> This doesn't quite sound right. I mean, flow control should be mandated > > >> by the underlying transport, right? We certainly don't want to reinvent > > >> such a key aspect of end-to-end communications within IPP. > > >> > > >> ...jay > > >> > > >> ---------------------------------------------------------------------- > > >> -- JK Martin | Email: jkm@underscore.com -- > > >> -- Underscore, Inc. | Voice: (603) 889-7000 -- > > >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > >> ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Mar 12 13:39:34 1998 Delivery-Date: Thu, 12 Mar 1998 13:39:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA24759 for ; Thu, 12 Mar 1998 13:39:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19455 for ; Thu, 12 Mar 1998 13:42:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA22648 for ; Thu, 12 Mar 1998 13:39:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 13:34:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22088 for ipp-outgoing; Thu, 12 Mar 1998 13:34:11 -0500 (EST) Message-Id: <3.0.1.32.19980312092715.009b7120@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 09:27:15 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-palme-int-print-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, This I-D gives you explicit advice on how to format documents for international distribution. I actually applied these rules for many years working in ITU and ISO, but now they have also been documented! Carl-Uno >To: IETF-Announce:; >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-palme-int-print-03.txt >Date: Thu, 12 Mar 1998 06:47:16 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Making Postscript and PDF International > Author(s) : J. Palme > Filename : draft-palme-int-print-03.txt > Pages : 3 > Date : 11-Mar-98 > >Certain text formats, for example Postscript (MIME-Type: >application/postscript; file extension .ps) and Portable Document Format >(MIME-Type: application/pdf; file extension .pdf) specify exactly the >page layout of the printed document. The commonly used paper format is >different in North America and the rest of the world. North America uses >the 'Letter' format, while the rest of the world mostly uses the ISO- >standard 'A4' format. This means that documents formatted on one >continent may not be easily printable on another continent. This memo >gives advice on how to produce documents which are equally well >printable with the Letter and the A4 formats. By using the advice in >this document, you can put up a document on the Internet, which >recipients can print without problem both in and outside North America. > >A very short summary of the advice in this document: If you are using >U.S. Letter paper format, ensure that both the left and right margins >are at least 21 mm (0.8 in). If you are using A4 paper format, ensure >that both the top and bottom margins are at least 33 mm (1.3 in). > >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-palme-int-print-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-palme-int-print-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-palme-int-print-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Mar 12 13:46:43 1998 Delivery-Date: Thu, 12 Mar 1998 13:46:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA25099 for ; Thu, 12 Mar 1998 13:46:42 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19491 for ; Thu, 12 Mar 1998 13:49:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23271 for ; Thu, 12 Mar 1998 13:46:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 13:42:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22728 for ipp-outgoing; Thu, 12 Mar 1998 13:42:28 -0500 (EST) Message-ID: <35082C8A.6C6C8CCA@underscore.com> Date: Thu, 12 Mar 1998 13:42:18 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> New I-D for expressing "feature sets" Content-Type: multipart/mixed; boundary="------------50CC26D163E528D22DA6E8BB" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------50CC26D163E528D22DA6E8BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Negotiating capabilities/features is a pretty common thing in client/server protocols, including IPP. I'm forwarding this in case anyone is interested. ...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 -- ---------------------------------------------------------------------- --------------50CC26D163E528D22DA6E8BB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns.ietf.org (ietf.org [132.151.1.19]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id NAA07735 for ; Thu, 12 Mar 1998 13:28:57 -0500 (EST) Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA22990 for ietf-123-outbound.05@ietf.org; Thu, 12 Mar 1998 12:55:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15763; Thu, 12 Mar 1998 09:48:30 -0500 (EST) Message-Id: <199803121448.JAA15763@ns.ietf.org> Mime-Version: 1.0 To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-feature-algebra-00.txt Date: Thu, 12 Mar 1998 09:48:29 -0500 Sender: cclark@cnri.reston.va.us Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : An algebra for describing media feature sets Author(s) : G. Klyne Filename : draft-ietf-conneg-feature-algebra-00.txt Pages : 16 Date : 11-Mar-98 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra which can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document does not set out to specify a syntax for defining feature sets. 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-conneg-feature-algebra-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-algebra-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980311152104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-algebra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-algebra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311152104.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------50CC26D163E528D22DA6E8BB-- From adm Thu Mar 12 14:16:29 1998 Delivery-Date: Thu, 12 Mar 1998 14:25:03 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA26140 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 14:15:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16824; Thu, 12 Mar 1998 10:13:55 -0500 (EST) Message-Id: <199803121513.KAA16824@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippm-ipdv-00.txt Date: Thu, 12 Mar 1998 10:13:54 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Instantaneous Packet Delay Variation Metric for IPPM Author(s) : C. Demichelis Filename : draft-ietf-ippm-ipdv-00.txt Pages : 14 Date : 11-Mar-98 This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on statistics of the difference in One-way Delay of consecutive packets. This particular definition of variation is called ''Instantaneous Packet Delay Variation (ipdv)''. The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. In the second case it allows an evaluation of the relative skew. Measurements performed on both directions (Two-ways measurements) allow a better estimation of clock differences. The precision that can be obtained is evaluated. This memo is intended to have, as much as possible, the structure of the ippm draft on one-way delay metric. 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-ippm-ipdv-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-ipdv-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980312095124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-ipdv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-ipdv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312095124.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 14:36:32 1998 Delivery-Date: Thu, 12 Mar 1998 14:38:25 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA27114 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 14:35:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16847; Thu, 12 Mar 1998 10:14:13 -0500 (EST) Message-Id: <199803121514.KAA16847@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipp-not-01.txt Date: Thu, 12 Mar 1998 10:14:13 -0500 Sender: cclark@cnri.reston.va.us --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 : Requirements for IPP Notifications Author(s) : R. deBry Filename : draft-ietf-ipp-not-01.txt Pages : 8 Date : 11-Mar-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). 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-not-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-not-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-not-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-not-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Thu Mar 12 14:53:02 1998 Delivery-Date: Thu, 12 Mar 1998 14:53:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA27689 for ; Thu, 12 Mar 1998 14:53:02 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19885 for ; Thu, 12 Mar 1998 14:55:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA24084 for ; Thu, 12 Mar 1998 14:52:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 14:48:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23556 for ipp-outgoing; Thu, 12 Mar 1998 14:48:31 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Status code question Date: Thu, 12 Mar 1998 11:48:25 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does it mean that the job data has been successfully delivered to the device, or does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think we may have a problem with this operation. Randy From ipp-owner@pwg.org Thu Mar 12 15:09:26 1998 Delivery-Date: Thu, 12 Mar 1998 15:09:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA28275 for ; Thu, 12 Mar 1998 15:09:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19986 for ; Thu, 12 Mar 1998 15:11:59 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24771 for ; Thu, 12 Mar 1998 15:09:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 15:05:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24211 for ipp-outgoing; Thu, 12 Mar 1998 15:05:25 -0500 (EST) Message-ID: <19980312200457.1307.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: hastings@cp10.es.xerox.com Cc: ipp@pwg.org Subject: IPP> Re: IPP- Printer state Content-Type: text/plain Date: Thu, 12 Mar 1998 12:04:57 PST Sender: ipp-owner@pwg.org Thanks, Tom for clarifying the issue. I still have a question - should an IPP server behave the same way even when it does not spool any job? -PB >From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 >Yes, the Printer object implemented in a server object does accept the >job even though the device is powered down. > >And the requester MAY get an indication that there is a problem, because >the job's OPTIONAL "job-state-reason" attribute that MAY be returned in the >Print-Job response containing the value: 'printer-stopped' >(or 'printer-stopped-partly' in the case that only some of the fan-out >printers are stopped). Unfortunately, the requeseter will NOT get this >indication in the response, if the IPP Printer object does not implement >the OPTIONAL "job-state-reasons" attribute. > >The client can then query the Printer's "printer-state" >and "printer-state-reasons" attribute and see that the "printer-state" >is 'stopped' and the "printer-state-reasons" is 'error-shutdown' >('warning-shutdown' if only some of the fan-out printers are shutdown). > > >The explanation of the 'stopped' state on page 89 of the Model document >says (in its entirity of two paragraphs): > >'5' 'stopped': If a Printer receives a job (whose required resources are >ready) while in this state, such a job SHALL transit into the pending state >immediately. Such a job SHALL transit into the processing state only after >some human fixes the problem that stopped the printer and after jobs ahead >of it complete printing. The "printer-state-reasons" attribute SHALL >contain at least one reason, e.g. media-jam, which prevents it from either >processing the current job or transitioning a pending job to the processing >state. > >Note: if a Printer controls more than one output device, the above >definition implies that a Printer is stopped only if all output devices are >stopped. Also, it is tempting to define stopped as when a sufficient >number of output devices are stopped and leave it to an implementation to >define the sufficient number. But such a rule complicates the definition >of stopped and processing. For example, with this alternate definition of >stopped, a job can move from idle to processing without human intervention, >even though the Printer is stopped. > > > >Does the Model document need any futher clarification? > >Tom ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Thu Mar 12 16:44:32 1998 Delivery-Date: Thu, 12 Mar 1998 16:44:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01390 for ; Thu, 12 Mar 1998 16:44:32 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20555 for ; Thu, 12 Mar 1998 16:47:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25699 for ; Thu, 12 Mar 1998 16:44:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 16:39:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25135 for ipp-outgoing; Thu, 12 Mar 1998 16:39:35 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Status code question Message-ID: <5030100018438424000002L042*@MHS> Date: Thu, 12 Mar 1998 16:38:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA01390 > Does it > mean that the job data has been successfully delivered to the device, or > does it mean the job has completed printing successfully? Neither. My understanding of sections 3.1.7, "Job Creation Operations" and 15.4.8, "Return one of the success status codes", is that the sucess code is returned after the Job has been created and the request accepted, but (possibly) before the appended Document Content has been accepted. If you want to find out if the job completed printing successfully, you have to poll, and hope that the Printer remembers a completed job for a time longer than your polling interval. -Carl ipp-owner@pwg.org on 03/12/98 12:51:03 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Status code question I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does it mean that the job data has been successfully delivered to the device, or does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think we may have a problem with this operation. Randy From ipp-owner@pwg.org Thu Mar 12 16:51:10 1998 Delivery-Date: Thu, 12 Mar 1998 16:51:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA01521 for ; Thu, 12 Mar 1998 16:51:10 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20625 for ; Thu, 12 Mar 1998 16:53:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26321 for ; Thu, 12 Mar 1998 16:51:09 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 16:47:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25764 for ipp-outgoing; Thu, 12 Mar 1998 16:46:57 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> Status code question Message-ID: <5030100018438734000002L042*@MHS> Date: Thu, 12 Mar 1998 16:46:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA01521 I thought Randy's question was specific to Print-Job, in which case I believe a response means the job was successfully created AND received. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ipp-owner@pwg.org on 03/12/98 02:41:23 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: Re: IPP> Status code question > Does it > mean that the job data has been successfully delivered to the device, or > does it mean the job has completed printing successfully? Neither. My understanding of sections 3.1.7, "Job Creation Operations" and 15.4.8, "Return one of the success status codes", is that the sucess code is returned after the Job has been created and the request accepted, but (possibly) before the appended Document Content has been accepted. If you want to find out if the job completed printing successfully, you have to poll, and hope that the Printer remembers a completed job for a time longer than your polling interval. -Carl ipp-owner@pwg.org on 03/12/98 12:51:03 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Status code question I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does it mean that the job data has been successfully delivered to the device, or does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think we may have a problem with this operation. Randy From ipp-owner@pwg.org Thu Mar 12 18:40:53 1998 Delivery-Date: Thu, 12 Mar 1998 18:40:54 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA04177 for ; Thu, 12 Mar 1998 18:40:53 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21186 for ; Thu, 12 Mar 1998 18:43:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27284 for ; Thu, 12 Mar 1998 18:40:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 18:36:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26734 for ipp-outgoing; Thu, 12 Mar 1998 18:36:36 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 15:36:21 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-owner@pwg.org Thu Mar 12 18:53:17 1998 Delivery-Date: Thu, 12 Mar 1998 18:53:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA04350 for ; Thu, 12 Mar 1998 18:53:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21244 for ; Thu, 12 Mar 1998 18:55:44 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27905 for ; Thu, 12 Mar 1998 18:53:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 18:49:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27387 for ipp-outgoing; Thu, 12 Mar 1998 18:49:03 -0500 (EST) Message-Id: <3.0.1.32.19980312154344.00cadd40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 15:43:44 PST To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > Why are we getting all these "bright" ideas after the work is supposed to be finished? I don't know if we can do the split at this stage. I expect that we could try to negotiate that with the RFC editor, but it would mean actually doing another editing run and insert new cross-references etc. It would also impact references in all the other documents. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Mar 12 19:03:53 1998 Delivery-Date: Thu, 12 Mar 1998 19:03:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA04514 for ; Thu, 12 Mar 1998 19:03:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21274 for ; Thu, 12 Mar 1998 19:06:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA28532 for ; Thu, 12 Mar 1998 19:03:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:00:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28010 for ipp-outgoing; Thu, 12 Mar 1998 18:59:55 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 15:58:06 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org This wouldn't be changing any technical specs or semantics...just an editorial move to isolate functionality. This type of change would make it easier to address transport issues without affecting the status or advancement of an encoding specification; and vice-versa. It would also make it clearer for future IPP-related documents to reference particular aspects of IPP, without bringing any additional baggage to have to sort through. Randy -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Thursday, March 12, 1998 3:44 PM To: Turner, Randy; 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > Why are we getting all these "bright" ideas after the work is supposed to be finished? I don't know if we can do the split at this stage. I expect that we could try to negotiate that with the RFC editor, but it would mean actually doing another editing run and insert new cross-references etc. It would also impact references in all the other documents. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Mar 12 19:32:29 1998 Delivery-Date: Thu, 12 Mar 1998 19:32:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA04816 for ; Thu, 12 Mar 1998 19:32:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21362 for ; Thu, 12 Mar 1998 19:35:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA29238 for ; Thu, 12 Mar 1998 19:32:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:28:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28706 for ipp-outgoing; Thu, 12 Mar 1998 19:28:00 -0500 (EST) Message-ID: <35087D7F.95C97B5C@underscore.com> Date: Thu, 12 Mar 1998 19:27:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> IPP document set - naming convention(s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org If the notion of "IPP-over-anything-other-than-HTTP" is ever going to be proven, then splitting the doc into two components is a great idea. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This wouldn't be changing any technical specs or semantics...just an > editorial move to isolate functionality. This type of change would make > it easier to address transport issues without affecting the status or > advancement of an encoding specification; and vice-versa. It would also > make it clearer for future IPP-related documents to reference particular > aspects of IPP, without bringing any additional baggage to have to sort > through. > > Randy > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, March 12, 1998 3:44 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > > > Why are we getting all these "bright" ideas after the work is > supposed to > be finished? I don't know if we can do the split at this stage. > > I expect that we could try to negotiate that with the RFC > editor, but it > would mean actually doing another editing run and insert new > cross-references etc. It would also impact references in all the > other > documents. > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Mar 12 19:47:27 1998 Delivery-Date: Thu, 12 Mar 1998 19:47:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA04971 for ; Thu, 12 Mar 1998 19:47:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21408 for ; Thu, 12 Mar 1998 19:50:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA00685 for ; Thu, 12 Mar 1998 19:47:23 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:38:40 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29351 for ipp-outgoing; Thu, 12 Mar 1998 19:38:28 -0500 (EST) Date: Thu, 12 Mar 1998 16:43:59 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803130043.AA11671@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Status code question Sender: ipp-owner@pwg.org Hi Randy, "success" just means that the job was well-formed and accepted for subsequent printing. It does NOT mean that the job has completed printing successfully. Cheers, - Ira McDonald From ipp-owner@pwg.org Thu Mar 12 19:47:32 1998 Delivery-Date: Thu, 12 Mar 1998 19:47:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA04976 for ; Thu, 12 Mar 1998 19:47:31 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21411 for ; Thu, 12 Mar 1998 19:50:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA00693 for ; Thu, 12 Mar 1998 19:47:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:38:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29328 for ipp-outgoing; Thu, 12 Mar 1998 19:38:17 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 16:38:15 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Yes, this is what I am doing in creating a host-to-device version of IPP, I noticed from a design perspective that its clearer if the encoding and transport are isolated into separate documents. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Thursday, March 12, 1998 4:28 PM To: Turner, Randy Cc: 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) If the notion of "IPP-over-anything-other-than-HTTP" is ever going to be proven, then splitting the doc into two components is a great idea. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This wouldn't be changing any technical specs or semantics...just an > editorial move to isolate functionality. This type of change would make > it easier to address transport issues without affecting the status or > advancement of an encoding specification; and vice-versa. It would also > make it clearer for future IPP-related documents to reference particular > aspects of IPP, without bringing any additional baggage to have to sort > through. > > Randy > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, March 12, 1998 3:44 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > > > Why are we getting all these "bright" ideas after the work is > supposed to > be finished? I don't know if we can do the split at this stage. > > I expect that we could try to negotiate that with the RFC > editor, but it > would mean actually doing another editing run and insert new > cross-references etc. It would also impact references in all the > other > documents. > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Mar 12 19:50:54 1998 Delivery-Date: Thu, 12 Mar 1998 19:50:54 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA04995 for ; Thu, 12 Mar 1998 19:50:53 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21417 for ; Thu, 12 Mar 1998 19:53:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01161 for ; Thu, 12 Mar 1998 19:50:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:43:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00016 for ipp-outgoing; Thu, 12 Mar 1998 19:43:05 -0500 (EST) Date: Thu, 12 Mar 1998 16:48:34 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803130048.AA11674@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> IPP document set - naming convention(s) Sender: ipp-owner@pwg.org Hi Randy, Considering splitting the protocol document (recently renamed Protocol Encoding and Transport Mappings) into two documents should definitely be delayed until after our IETF Aread Directors report the results of IESG last call on IPP/1.0. My two cents, - Ira McDonald PS - I think splitting them makes sense, but only if EACH transport mapping (http, tcp, smtp) becomes a separate document. From ipp-owner@pwg.org Thu Mar 12 19:55:53 1998 Delivery-Date: Thu, 12 Mar 1998 19:55:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA05022 for ; Thu, 12 Mar 1998 19:55:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21427 for ; Thu, 12 Mar 1998 19:58:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01787 for ; Thu, 12 Mar 1998 19:55:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 12 Mar 1998 19:51:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01214 for ipp-outgoing; Thu, 12 Mar 1998 19:51:16 -0500 (EST) Message-Id: <3.0.1.32.19980312164908.011f3980@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 16:49:08 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Minor typo in example 9.1, "PrintJob" should be "Print-Job" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org On page 18, the symbolic value in the example in section 9.1 should be changed from "PrintJob" to "Print-Job" to reflect the spelling of operations in the Model and be consistent with the rest of the examples. However, since this symbolic value is not sent on the wire, this typo doesn't affect what is sent of the wire. Tom From ipp-owner@pwg.org Fri Mar 13 01:28:47 1998 Delivery-Date: Fri, 13 Mar 1998 01:28:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA20439 for ; Fri, 13 Mar 1998 01:28:42 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA22030 for ; Fri, 13 Mar 1998 01:31:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA04564 for ; Fri, 13 Mar 1998 01:28:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 01:23:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA03839 for ipp-outgoing; Fri, 13 Mar 1998 01:23:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Minor comments to latest Notification requirements doc Date: Thu, 12 Mar 1998 22:23:35 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org In Section 3.0, notification requirements are specified. In each subsection, 3.1, 3.2, 3.3, a specific requirement is listed. However in a couple of subsections identify what is NOT a requirement. And another subsection at the same section level as a formal requirement, lists a caveat to the previously numbered requirement. For ease of readability, each subsection 3.x, should list a specific requirement. If there is a caveat or other note to the requirement, then it should appear as another subsection, 3.x.y, of the requirement (i.e., 3.x) to which it is referring. For example, section 3.6 should probably be moved to section 3.1.1. Also, section 3.7 should probably be moved to 3.3.1. It there is a caveat or exception to a particular requirement, then I would like to know about it in the context of what I'm reading at the time. Also, on another item, we've talked about not requiring an event notification sender to verify reception of a particular notification message to a notification recipient. We did this (I guess) to save us the work of having to figure out how to do this. However, I think this idea is fundamentally in conflict with the other requirement that end users can specify reliability and quality-of-service to be attached to a particular notification registration. If the user specified that an event must be delivered to the intended recipient, and emphasizes this point with an associated reliability or QoS parameter, then it is critical that we provide enough information as possible as to the status of the notification delivery. Just my $0.02 Randy From ipp-owner@pwg.org Fri Mar 13 11:29:23 1998 Delivery-Date: Fri, 13 Mar 1998 11:29:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA05734 for ; Fri, 13 Mar 1998 11:29:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA23912 for ; Fri, 13 Mar 1998 11:31:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA16482 for ; Fri, 13 Mar 1998 11:29:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 11:20:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15939 for ipp-outgoing; Fri, 13 Mar 1998 11:20:36 -0500 (EST) Message-Id: <1.5.4.32.19980313162222.0067b624@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: Fri, 13 Mar 1998 08:22:22 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Early morning thougthts on features Sender: ipp-owner@pwg.org Hi, I ran across a little real life example on how you can turn a defect into a feature: I have my shirts washed by a cleaners which is located in my favorite super market. Now and again I get a shirt back with a little label stating: "We have replaced a button FREE of charge as part of our sevice". I thought this was an excellent little feature until I discovered one day that about one third of all finished shirts in the shop seemed to have such a label. It then dawned on me that apparently their washing machines are eating buttons for beakfeast, lunch and dinner. So instead of getting a lot of complaints about missing buttons, they have just hired a couple of folks that replace the buttons and at the same time turned this into a service - your shirt might actually miss a button when you hand it in. We could take the same attitude to some of our "missing" IPP features, say notifications. Notifications? We have got notifications! You can get notifications any time you want! You do not have to wait around for them to come, you just poll your IPP Printer whenever you want to find out something! This means that you get the notifications at your own convenience, they do not come rushing at your machine uncontrolled, potentially interrupting other important things you are doing etc. It is early in the morning.... Carl-Uno From ipp-owner@pwg.org Fri Mar 13 13:00:52 1998 Delivery-Date: Fri, 13 Mar 1998 13:00:52 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA13770 for ; Fri, 13 Mar 1998 13:00:51 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA24579 for ; Fri, 13 Mar 1998 13:03:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17171 for ; Fri, 13 Mar 1998 13:00:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 12:55:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16629 for ipp-outgoing; Fri, 13 Mar 1998 12:55:38 -0500 (EST) Message-Id: <3.0.1.32.19980313095000.00cd55f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 09:50:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-v11-spec-rev-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-v11-spec-rev-03.txt >Date: Fri, 13 Mar 1998 05:10:11 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. > > Title : Hypertext Transfer Protocol -- HTTP/1.1 > Author(s) : J. Mogul, T. Berners-Lee, L. Masinter, P. Leach, > R. Fielding, H. Nielsen, J. Gettys > Filename : draft-ietf-http-v11-spec-rev-03.txt > Pages : 156 > Date : 12-Mar-98 > >The Hypertext Transfer Protocol (HTTP) is an application-level protocol >for distributed, collaborative, hypermedia information systems. It is a >generic, stateless, protocol which can be used for many tasks, such as >name servers and distributed object management systems, through >extension of its request methods. A feature of HTTP is the typing and >negotiation of data representation, allowing systems to be built >independently of the data being transferred. > >HTTP has been in use by the World-Wide Web global information initiative >since 1990. This specification defines the protocol referred to as >''HTTP/1.1'', and is an update to RFC2068 [33]. > >At the time of this revision's submission, there were no known outstanding >technical or editorial issues. The HTTP/1.1 issues list, along with >many representations of this specification including Postscript, Microsoft >Word, with and without change bars, with or without gzip compression >can be found at http://www.w3.org/Protocols/HTTP/Issues/. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-v11-spec-rev-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-v11-spec-rev-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Mar 13 13:14:33 1998 Delivery-Date: Fri, 13 Mar 1998 13:14:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15636 for ; Fri, 13 Mar 1998 13:14:33 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA24629 for ; Fri, 13 Mar 1998 13:17:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17810 for ; Fri, 13 Mar 1998 13:14:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 13:10:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17253 for ipp-outgoing; Fri, 13 Mar 1998 13:10:14 -0500 (EST) Message-Id: <3.0.1.32.19980313100257.00cd39f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 10:02:57 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-conneg-media-features-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >To: IETF-Announce:; >Cc: ietf-medfree@imc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-conneg-media-features-00.txt >Date: Fri, 13 Mar 1998 05:23:28 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Content Negotiation Working Group of the IETF. > > Title : Media Features for Display, Print, and Fax > Author(s) : L. Masinter, K. Holtman, A. Mutz, D. Wing > Filename : draft-ietf-conneg-media-features-00.txt > Pages : 4 > Date : 12-Mar-98 > >This specification defines some common media features for describing >image resolution, size, color, and image representation methods that >are common to web browsing, printing, and facsimile applications. >These features are registered for use within the framework of [REG]. > >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-conneg-media-features-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-conneg-media-features-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Mar 13 14:21:35 1998 Delivery-Date: Fri, 13 Mar 1998 14:21:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA21733 for ; Fri, 13 Mar 1998 14:21:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA24991 for ; Fri, 13 Mar 1998 14:24:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA18529 for ; Fri, 13 Mar 1998 14:21:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 14:17:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17976 for ipp-outgoing; Fri, 13 Mar 1998 14:16:54 -0500 (EST) Message-Id: <3.0.1.32.19980313111043.00beabe0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 11:10:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-conneg-feature-reg-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Here is yet another one... Carl-Uno >To: IETF-Announce:; >Cc: ietf-medfree@imc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-conneg-feature-reg-00.txt >Date: Fri, 13 Mar 1998 05:24:01 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Content Negotiation Working Group of the IETF. > > Title : Content Feature Tag Registration Procedure > Author(s) : E. Hardie, K. Holtman, A. Mutz > Filename : draft-ietf-conneg-feature-reg-00.txt > Pages : 7 > Date : 12-Mar-98 > > Recent Internet applications, such as the World Wide Web, tie > together a great diversity in data formats, client and server > platforms, and communities. This has created a need for content > feature descriptions and negotiation mechanisms in order to identify > and reconcile the form of information to the capabilities and > preferences of the parties involved. > > Extensible content feature identification and negotiation mechanisms > require a common vocabulary in order to positively identify content > features. A registration process and authority for content features > is defined with the intent of sharing this vocabulary between > communicating parties. In addition, a URI tree is defined to enable > sharing of content feature definitions without registration. > > This document defines a registration procedure which uses the > Internet Assigned Numbers Authority (IANA) as a central registry for > the content feature vocabulary. > >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-conneg-feature-reg-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-conneg-feature-reg-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Mar 13 15:08:15 1998 Delivery-Date: Fri, 13 Mar 1998 15:08:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA23748 for ; Fri, 13 Mar 1998 15:08:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25305 for ; Fri, 13 Mar 1998 15:10:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA19159 for ; Fri, 13 Mar 1998 15:08:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 15:04:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18653 for ipp-outgoing; Fri, 13 Mar 1998 15:04:23 -0500 (EST) Message-Id: <199803132002.MAA26526@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 12:05:33 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: Re: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I think we had this discussion in Austin as part of Tom's proposal. We decided to change the name of the protocol document. Its new name is “Internet Printing Protocol/1.0: Encoding and Transport”. We decided not to split the two documents. Although the IPP encoding is, in theory, transport independent. In fact, it depends on HTTP chunking. With an alternate transport, we would have to solve the chunking problem. It would be more efficient if the document data were the only part chunked, but that would require a change to the encoding layer. So, at this point, I don't endorse separating the two documents. Bob Herriot At 03:36 PM 3/12/98 , Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > From ipp-owner@pwg.org Fri Mar 13 15:15:23 1998 Delivery-Date: Fri, 13 Mar 1998 15:15:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24129 for ; Fri, 13 Mar 1998 15:15:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25357 for ; Fri, 13 Mar 1998 15:17:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA19792 for ; Fri, 13 Mar 1998 15:15:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 15:11:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19248 for ipp-outgoing; Fri, 13 Mar 1998 15:11:22 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Robert Herriot'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Fri, 13 Mar 1998 12:11:15 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I'm curious why the existing binary encoding is inherently dependent on chunking?....I thought chunking was a part of the transport of the encoding. I don't think there is anything inherent (or explicitly referenced) by the current encoding that involves chunking. You're right that another transport would have to solve the chunking problem, but it's a TRANSPORT issue, so this would naturally fall into a transport mapping document. If there was a bit or byte that specified HTTP chunking within the binary encoding, then this is a different story. Randy -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Friday, March 13, 1998 12:06 PM To: Turner, Randy; 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) I think we had this discussion in Austin as part of Tom's proposal. We decided to change the name of the protocol document. Its new name is "Internet Printing Protocol/1.0: Encoding and Transport". We decided not to split the two documents. Although the IPP encoding is, in theory, transport independent. In fact, it depends on HTTP chunking. With an alternate transport, we would have to solve the chunking problem. It would be more efficient if the document data were the only part chunked, but that would require a change to the encoding layer. So, at this point, I don't endorse separating the two documents. Bob Herriot At 03:36 PM 3/12/98 , Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > From ipp-owner@pwg.org Fri Mar 13 15:31:38 1998 Delivery-Date: Fri, 13 Mar 1998 15:31:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24895 for ; Fri, 13 Mar 1998 15:31:37 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25476 for ; Fri, 13 Mar 1998 15:34:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA20411 for ; Fri, 13 Mar 1998 15:31:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 15:27:08 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19871 for ipp-outgoing; Fri, 13 Mar 1998 15:27:00 -0500 (EST) Message-ID: <35099629.1055600A@underscore.com> Date: Fri, 13 Mar 1998 15:25:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'Robert Herriot'" , "'ipp@pwg.org'" Subject: Re: IPP> IPP document set - naming convention(s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I agree with Randy completely. The way Bob describes it, IPP is absolutely bound to HTTP...theory or not. Why is it such a big deal to split the document into its two respective parts? I would think that those who truly believe the IPP encoding is "transport independent" would insist on such a separation of the documentation. Further, I don't think the IETF cares all that much about whether there is one document or two. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > I'm curious why the existing binary encoding is inherently dependent on > chunking?....I thought chunking was a part of the transport of the > encoding. I don't think there is anything inherent (or explicitly > referenced) by the current encoding that involves chunking. You're right > that another transport would have to solve the chunking problem, but > it's a TRANSPORT issue, so this would naturally fall into a transport > mapping document. If there was a bit or byte that specified HTTP > chunking within the binary encoding, then this is a different story. > > Randy > > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Friday, March 13, 1998 12:06 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > I think we had this discussion in Austin as part of Tom's > proposal. We > decided to change the name of the protocol document. Its new > name is > "Internet Printing Protocol/1.0: Encoding and Transport". We > decided not to > split the two documents. > > Although the IPP encoding is, in theory, transport independent. > In fact, it > depends on HTTP chunking. With an alternate transport, we would > have to > solve the chunking problem. It would be more efficient if the > document data > were the only part chunked, but that would require a change to > the encoding > layer. > > So, at this point, I don't endorse separating the two documents. > > Bob Herriot > > At 03:36 PM 3/12/98 , Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > From ipp-owner@pwg.org Fri Mar 13 15:37:00 1998 Delivery-Date: Fri, 13 Mar 1998 15:37:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25143 for ; Fri, 13 Mar 1998 15:36:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25526 for ; Fri, 13 Mar 1998 15:39:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA21002 for ; Fri, 13 Mar 1998 15:36:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 15:33:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20464 for ipp-outgoing; Fri, 13 Mar 1998 15:32:54 -0500 (EST) Message-Id: <199803132030.MAA26566@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 12:34:19 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO new information on POST versus PRINT method Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I have now discovered that IPP implementation using Java servlets can be implemented with either POST or PRINT or any collection of methods we might want, and it doesn't really matter because of the excellent design of Java Servlets. So, I no longer have objections about a PRINT method based on lack of support by the webserver. Now it is more of a network issue and I don't have enough information to know which is better in that environment. In case you care about the details of servlets, here they are: When a servlet Foo is first instantiated its 'init' method is called. It is instantiated when the web server starts or when the web server detects that the servlet 'Foo.class' file is new. In the later case, the web server calls the 'destroy' method in the running 'Foo' servlet if one is running. Each time the web server receives a request for '/servlet/Foo', it calls the 'service' method with two parameters: a request and response object. Each 'service' call is a separate thread so the servlet can be processing more than one request. If the servlet overrides the 'service' method, it can process requests for any method, and it can determine the method via the request object with the 'getMethod' method. If the servlet doesn't override the 'service' method, the superclass 'service' method calls 'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the nonstandard methods. If the servlet overrides 'doGet', it can process GET methods. If the servlet overrides 'doPost', it can process POST methods. Bob Herriot From ipp-owner@pwg.org Fri Mar 13 15:50:59 1998 Delivery-Date: Fri, 13 Mar 1998 15:50:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25761 for ; Fri, 13 Mar 1998 15:50:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25647 for ; Fri, 13 Mar 1998 15:53:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA21630 for ; Fri, 13 Mar 1998 15:50:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 15:46:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21092 for ipp-outgoing; Fri, 13 Mar 1998 15:46:49 -0500 (EST) From: don@lexmark.com Message-Id: <199803132046.AA01929@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com Cc: Ipp@pwg.org Date: Fri, 13 Mar 1998 15:45:36 -0500 Subject: Re: IPP> IPP document set - naming convention(s) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I think this issue was decided in Austin with a name change for the Protocol document. Considering the pain separating them now would be and having to deal with editing all the cross references, etc. in the IETF format is just not worth it. When the time comes to map IPP to another transport then Bob or whoever is editor of that protocol document can make the split. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> IPP document set - naming convention(s) Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-owner@pwg.org Fri Mar 13 16:04:04 1998 Delivery-Date: Fri, 13 Mar 1998 16:04:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27003 for ; Fri, 13 Mar 1998 16:04:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA25741 for ; Fri, 13 Mar 1998 16:06:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22246 for ; Fri, 13 Mar 1998 16:04:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 16:00:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21728 for ipp-outgoing; Fri, 13 Mar 1998 16:00:05 -0500 (EST) Message-Id: <199803132057.MAA26619@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 13:01:03 -0800 To: "Turner, Randy" , "'Robert Herriot'" From: Robert Herriot Subject: RE: IPP> IPP document set - naming convention(s) Cc: "'ipp@pwg.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA27003 The current binary encoding assumes that chunking occurs at a lower layer. IPP could work without chunking, but we thought it was important to avoid the LPD problem where the length of a document must be know before sending it. If I were writing a server for receiving IPP over a raw socket, I would prefer not to have chunking at a lower layer because I would have to implement a lower layer to put the chunks back together for the upper layer. I would prefer to read the encoded attributes directly off the socket and chunk only the document data. Therefore I would end up with a slightly difference encoding for raw sockets than for HTTP. Bob Herriot At 12:11 PM 3/13/98 , Turner, Randy wrote: > >I'm curious why the existing binary encoding is inherently dependent on >chunking?....I thought chunking was a part of the transport of the >encoding. I don't think there is anything inherent (or explicitly >referenced) by the current encoding that involves chunking. You're right >that another transport would have to solve the chunking problem, but >it's a TRANSPORT issue, so this would naturally fall into a transport >mapping document. If there was a bit or byte that specified HTTP >chunking within the binary encoding, then this is a different story. > >Randy > > > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Friday, March 13, 1998 12:06 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > I think we had this discussion in Austin as part of Tom's >proposal.  We > decided to change the name of the protocol document. Its new >name is > "Internet Printing Protocol/1.0: Encoding and Transport".  We >decided not to > split the two documents. > > Although the IPP encoding is, in theory, transport independent. >In fact, it > depends on HTTP chunking. With an alternate transport, we would >have to > solve the chunking problem.  It would be more efficient if the >document data > were the only part chunked, but that would require a change to >the encoding > layer. > > So, at this point, I don't endorse separating the two documents. > > Bob Herriot > > At 03:36 PM 3/12/98 , Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not >model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over >HTTP 1.1 > > > >? > > > >Randy > > > From ipp-owner@pwg.org Fri Mar 13 17:09:56 1998 Delivery-Date: Fri, 13 Mar 1998 17:09:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA01034 for ; Fri, 13 Mar 1998 17:09:55 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA26113 for ; Fri, 13 Mar 1998 17:12:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23063 for ; Fri, 13 Mar 1998 17:09:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 17:05:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22508 for ipp-outgoing; Fri, 13 Mar 1998 17:05:11 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Fri, 13 Mar 1998 14:05:12 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org This issue was not brought up in Austin. Only a name change for the current document was an issue. As far as I can tell, including the minutes from Austin, my split proposal is new, and is derived from my efforts at actually doing another mapping document. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Friday, March 13, 1998 12:46 PM To: rturner@sharplabs.com Cc: Ipp@pwg.org Subject: Re: IPP> IPP document set - naming convention(s) I think this issue was decided in Austin with a name change for the Protocol document. Considering the pain separating them now would be and having to deal with editing all the cross references, etc. in the IETF format is just not worth it. When the time comes to map IPP to another transport then Bob or whoever is editor of that protocol document can make the split. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> IPP document set - naming convention(s) Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-owner@pwg.org Fri Mar 13 17:29:06 1998 Delivery-Date: Fri, 13 Mar 1998 17:29:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA01667 for ; Fri, 13 Mar 1998 17:29:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA26232 for ; Fri, 13 Mar 1998 17:31:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA23656 for ; Fri, 13 Mar 1998 17:29:05 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 17:25:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23149 for ipp-outgoing; Fri, 13 Mar 1998 17:25:14 -0500 (EST) Message-Id: <3.0.1.32.19980313142333.0116eb90@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 14:23:33 PST To: Robert Herriot , ipp@pwg.org From: Tom Hastings Subject: Re: IPP>PRO new information on POST versus PRINT method In-Reply-To: <199803132030.MAA26566@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:34 03/13/1998 PST, Robert Herriot wrote: >I have now discovered that IPP implementation using Java servlets can be >implemented with either POST or PRINT or any collection of methods we might >want, and it doesn't really matter because of the excellent design of Java >Servlets. > >So, I no longer have objections about a PRINT method based on lack of >support by the webserver. Now it is more of a network issue and I don't >have enough information to know which is better in that environment. > >In case you care about the details of servlets, here they are: > >When a servlet Foo is first instantiated its 'init' method is called. It is >instantiated when the web server starts or when the web server detects that >the servlet 'Foo.class' file is new. In the later case, the web server >calls the 'destroy' method in the running 'Foo' servlet if one is running. > >Each time the web server receives a request for '/servlet/Foo', it calls >the 'service' method with two parameters: a request and response object. >Each 'service' call is a separate thread so the servlet can be processing >more than one request. If the servlet overrides the 'service' method, it >can process requests for any method, and it can determine the method via >the request object with the 'getMethod' method. If the servlet doesn't >override the 'service' method, the superclass 'service' method calls >'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the >nonstandard methods. If the servlet overrides 'doGet', it can process GET >methods. If the servlet overrides 'doPost', it can process POST methods. So what happens if IPP were to use a new method, not GET or POST, such as PRINT? Wouldn't this be a "nonstandard" method and so would return an error as you say? > >Bob Herriot > > > > > From ipp-owner@pwg.org Fri Mar 13 18:07:42 1998 Delivery-Date: Fri, 13 Mar 1998 18:07:42 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02822 for ; Fri, 13 Mar 1998 18:07:41 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA26341 for ; Fri, 13 Mar 1998 18:10:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24291 for ; Fri, 13 Mar 1998 18:07:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 18:03:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA23774 for ipp-outgoing; Fri, 13 Mar 1998 18:03:46 -0500 (EST) Message-Id: <199803132258.OAA26779@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 15:01:50 -0800 To: Tom Hastings , Robert Herriot , ipp@pwg.org From: Robert Herriot Subject: Re: IPP>PRO new information on POST versus PRINT method In-Reply-To: <3.0.1.32.19980313142333.0116eb90@garfield> References: <199803132030.MAA26566@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA02822 If you implement "service" method in your servlet class, it is called for each request coming in regardless of the HTTP method. The "doGet" and "doPost" methods allow you to implement specific HTTP methods without having to test for the others that you don't support. Thus with the current POST method, I implement "doPost" and not "service" in my "IppServlet" class and let the superclass "HttpServlet" handle the call to the "service" method. If we were to change IPP to use a PRINT method , I would rename my "doPost" method to "service" and add a check that the method was indeed "PRINT". If we added several methods, such as PRINT_JOB, CREATE_JOB, etc, I would rename the "doPost" method to "service" but I would need some additional checks for HTTP method names. Bob Herriot At 02:23 PM 3/13/98 , Tom Hastings wrote: >At 12:34 03/13/1998 PST, Robert Herriot wrote: >>I have now discovered that IPP implementation using Java servlets can be >>implemented with either POST or PRINT or any collection of methods we might >>want, and it doesn't really matter because of the excellent design of Java >>Servlets. >> >>So, I no longer have objections about a PRINT  method based on lack of >>support by the webserver.  Now it is more of a network issue and I don't >>have enough information to know which is better in that environment. >> >>In case you care about the details of servlets, here they are: >> >>When a servlet Foo is first instantiated its 'init' method is called. It is >>instantiated when the web server starts or when the web server detects that >>the servlet 'Foo.class' file is new.  In the later case, the web server >>calls the 'destroy' method in the running 'Foo' servlet if one is running. >> >>Each time the web server receives a request for '/servlet/Foo', it calls >>the 'service' method with two parameters: a request and response object. >>Each 'service' call is a separate thread so the servlet can be processing >>more than one request. If the servlet overrides the 'service' method, it >>can process requests for any method, and it can determine the method via >>the request object with the 'getMethod' method. If the servlet doesn't >>override the 'service' method, the superclass 'service' method calls >>'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the >>nonstandard methods. If the servlet overrides 'doGet', it can process GET >>methods. If the servlet overrides 'doPost', it can process POST methods. > >So what happens if IPP were to use a new method, not GET or POST, such >as PRINT?  Wouldn't this be a "nonstandard" method and so would return >an error as you say? > >> >>Bob Herriot >> >> >> >> >> > From ipp-owner@pwg.org Fri Mar 13 18:15:02 1998 Delivery-Date: Fri, 13 Mar 1998 18:15:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA02955 for ; Fri, 13 Mar 1998 18:15:02 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA26379 for ; Fri, 13 Mar 1998 18:17:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA24926 for ; Fri, 13 Mar 1998 18:14:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 18:10:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24370 for ipp-outgoing; Fri, 13 Mar 1998 18:10:21 -0500 (EST) Message-Id: <3.0.1.32.19980313150834.01170e40@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 15:08:34 PST To: Robert Herriot , "Turner, Randy" , "'Robert Herriot'" From: Tom Hastings Subject: RE: IPP> IPP document set - naming convention(s) Cc: "'ipp@pwg.org'" In-Reply-To: <199803132057.MAA26619@woden.eng.sun.com> 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="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA02955 At 13:01 03/13/1998 PST, Robert Herriot wrote: >The current binary encoding assumes that chunking occurs at a lower layer. >IPP >could work without chunking, but we thought it was important to avoid the LPD >problem where the length of a document must be know before sending it. > >If I were writing a server for receiving IPP over a raw socket, I would prefer >not to have chunking at a lower layer because I would have to implement a >lower >layer to put the chunks back together for the upper layer. I would prefer to >read the encoded attributes directly off the socket and chunk only the >document >data. > >Therefore I would end up with a slightly difference encoding for raw sockets >than for HTTP. In reviewing the various host-to-device protocols at the meeting, TIPSI and CPAP both have a separate channel for the data. So the control stuff goes over and comes back over a bi-directional control TCP/IP channel and the data goes over the separate data channel. The control channel would NOT need to be chunked, I would think. The data channel could just be a simple TCP/IP socket, so it wouldn't need chunking either. For example, in CPAP, the device returns the port for the data channel, and the host opens it and send raw data without headers of any kind and then closes the channel at the end of the document (which corresponds to the end of the data for a Print-Job or Send-Document IPP operation). Comments? Tom > >Bob Herriot > >At 12:11 PM 3/13/98 , Turner, Randy wrote: >> >>I'm curious why the existing binary encoding is inherently dependent on >>chunking?....I thought chunking was a part of the transport of the >>encoding. I don't think there is anything inherent (or explicitly >>referenced) by the current encoding that involves chunking. You're right >>that another transport would have to solve the chunking problem, but >>it's a TRANSPORT issue, so this would naturally fall into a transport >>mapping document. If there was a bit or byte that specified HTTP >>chunking within the binary encoding, then this is a different story. >> >>Randy >> >> >> -----Original Message----- >> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] >> Sent: Friday, March 13, 1998 12:06 PM >> To: Turner, Randy; 'ipp@pwg.org' >> Subject: Re: IPP> IPP document set - naming convention(s) >> >> I think we had this discussion in Austin as part of Tom's >>proposal.  We >> decided to change the name of the protocol document. Its new >>name is >> "Internet Printing Protocol/1.0: Encoding and Transport".  We >>decided not to >> split the two documents. >> >> Although the IPP encoding is, in theory, transport independent. >>In fact, it >> depends on HTTP chunking. With an alternate transport, we would >>have to >> solve the chunking problem.  It would be more efficient if the >>document data >> were the only part chunked, but that would require a change to >>the encoding >> layer. >> >> So, at this point, I don't endorse separating the two documents. >> >> Bob Herriot >> >> At 03:36 PM 3/12/98 , Turner, Randy wrote: >> > >> >Would anyone have any problem(s) splitting the protocol (not >>model) >> >document into two documents? >> > >> >Document 1 would be an encoding document >> >Document 2 would describe how to transport the encoding over >>HTTP 1.1 >> > >> >? >> > >> >Randy >> > >> > > > From ipp-owner@pwg.org Fri Mar 13 20:10:58 1998 Delivery-Date: Fri, 13 Mar 1998 20:10:58 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA05089 for ; Fri, 13 Mar 1998 20:10:57 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26692 for ; Fri, 13 Mar 1998 20:13:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25595 for ; Fri, 13 Mar 1998 20:10:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 20:05:50 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25065 for ipp-outgoing; Fri, 13 Mar 1998 20:05:41 -0500 (EST) Message-Id: <199803140103.RAA27029@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 17:06:58 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: RE: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA05089 It's not new. It was part of Tom's proposal at the Austin meeting. We discussed and rejected it as too late. At 02:05 PM 3/13/98 , Turner, Randy wrote: > >This issue was not brought up in Austin. Only a name change for the >current document was an issue. As far as I can tell, including the >minutes from Austin, my split proposal is new, and is derived from my >efforts at actually doing another mapping document. > >Randy > > -----Original Message----- > From: don@lexmark.com [SMTP:don@lexmark.com] > Sent: Friday, March 13, 1998 12:46 PM > To: rturner@sharplabs.com > Cc: Ipp@pwg.org > Subject: Re: IPP> IPP document set - naming convention(s) > > > I think this issue was decided in Austin with a name change for >the > Protocol document. > Considering the pain separating them now would be and having to >deal with > editing all > the cross references, etc. in the IETF format is just not worth >it.  When > the time comes to > map IPP to another transport then Bob or whoever is editor of >that protocol > document > can make the split. > > ********************************************** > * Don Wright                 don@lexmark.com * > * Product Manager, Strategic Alliances       * > * Lexmark International                      * > * 740 New Circle Rd                          * > * Lexington, Ky 40550                        * > * 606-232-4808 (phone) 606-232-6740 (fax)    * > ********************************************** > > > > > > > To:   ipp%pwg.org@interlock.lexmark.com > cc:    (bcc: Don Wright) > bcc:  Don Wright > Subject:  IPP> IPP document set - naming convention(s) > > > > > > Would anyone have any problem(s) splitting the protocol (not >model) > document into two documents? > Document 1 would be an encoding document > Document 2 would describe how to transport the encoding over >HTTP 1.1 > ? > Randy > From ipp-owner@pwg.org Fri Mar 13 20:36:17 1998 Delivery-Date: Fri, 13 Mar 1998 20:36:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA05402 for ; Fri, 13 Mar 1998 20:36:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26735 for ; Fri, 13 Mar 1998 20:38:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26207 for ; Fri, 13 Mar 1998 20:36:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 13 Mar 1998 20:32:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25684 for ipp-outgoing; Fri, 13 Mar 1998 20:32:23 -0500 (EST) Message-Id: <3.0.1.32.19980313172719.00c12d30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 17:27:19 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> IPP document set - naming convention(s) In-Reply-To: <199803140103.RAA27029@woden.eng.sun.com> 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="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA05402 All, I suggest that we shelve this discussion until we get the feedback from the IESG. If they require other changes to the protocol document, then we can consider the split. If they are happy with the document as is, I do not see enough reason to change what we have. Carl-Uno At 05:06 PM 3/13/98 PST, you wrote: >It's not new. It was part of Tom's proposal at the Austin meeting. We >discussed >and rejected it as too late. > > > >At 02:05 PM 3/13/98 , Turner, Randy wrote: >> >>This issue was not brought up in Austin. Only a name change for the >>current document was an issue. As far as I can tell, including the >>minutes from Austin, my split proposal is new, and is derived from my >>efforts at actually doing another mapping document. >> >>Randy >> >> -----Original Message----- >> From: don@lexmark.com [SMTP:don@lexmark.com] >> Sent: Friday, March 13, 1998 12:46 PM >> To: rturner@sharplabs.com >> Cc: Ipp@pwg.org >> Subject: Re: IPP> IPP document set - naming convention(s) >> >> >> I think this issue was decided in Austin with a name change for >>the >> Protocol document. >> Considering the pain separating them now would be and having to >>deal with >> editing all >> the cross references, etc. in the IETF format is just not worth >>it.  When >> the time comes to >> map IPP to another transport then Bob or whoever is editor of >>that protocol >> document >> can make the split. >> >> ********************************************** >> * Don Wright                 don@lexmark.com * >> * Product Manager, Strategic Alliances       * >> * Lexmark International                      * >> * 740 New Circle Rd                          * >> * Lexington, Ky 40550                        * >> * 606-232-4808 (phone) 606-232-6740 (fax)    * >> ********************************************** >> >> >> >> >> >> >> To:   ipp%pwg.org@interlock.lexmark.com >> cc:    (bcc: Don Wright) >> bcc:  Don Wright >> Subject:  IPP> IPP document set - naming convention(s) >> >> >> >> >> >> Would anyone have any problem(s) splitting the protocol (not >>model) >> document into two documents? >> Document 1 would be an encoding document >> Document 2 would describe how to transport the encoding over >>HTTP 1.1 >> ? >> Randy >> > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Sun Mar 15 19:35:02 1998 Delivery-Date: Sun, 15 Mar 1998 19:35:07 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA22861 for ; Sun, 15 Mar 1998 19:34:51 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01184 for ; Sun, 15 Mar 1998 19:37:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18267 for ; Sun, 15 Mar 1998 19:34:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 15 Mar 1998 19:31:42 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17861 for jmp-outgoing; Sun, 15 Mar 1998 19:29:36 -0500 (EST) Date: Sun, 15 Mar 1998 16:35:07 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803160035.AA12733@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: JMP> SNMPv3 unsuited for IPP/JMP Notifications Sender: jmp-owner@pwg.org Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-owner@pwg.org Sun Mar 15 19:40:30 1998 Delivery-Date: Sun, 15 Mar 1998 19:40:30 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA22894 for ; Sun, 15 Mar 1998 19:40:30 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01198 for ; Sun, 15 Mar 1998 19:43:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18629 for ; Sun, 15 Mar 1998 19:40:29 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 15 Mar 1998 19:29:47 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17853 for ipp-outgoing; Sun, 15 Mar 1998 19:29:31 -0500 (EST) Date: Sun, 15 Mar 1998 16:35:07 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803160035.AA12733@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Sender: ipp-owner@pwg.org Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-owner@pwg.org Sun Mar 15 20:38:14 1998 Delivery-Date: Sun, 15 Mar 1998 20:38:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA23343 for ; Sun, 15 Mar 1998 20:38:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01285 for ; Sun, 15 Mar 1998 20:40:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19263 for ; Sun, 15 Mar 1998 20:38:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 15 Mar 1998 20:33:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18737 for ipp-outgoing; Sun, 15 Mar 1998 20:33:43 -0500 (EST) From: "Rajesh Chawla" To: "IPP Mailing List" Subject: IPP> Beta Release of IPP Test Suite Date: Sun, 15 Mar 1998 20:35:38 -0500 Message-ID: <01bd507b$d2b63d40$8dc245c6@rajesh.ari.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org Hello, TR Computing Solutions is announcing the availability of the IPP Test Suite, Beta Version. The Test Suite allows you to: 1) Specify the operations to be sent to the printer in an ASCII file. 2) Allows valid and invalid data to be sent to the printer. 3) Allows the sending of user-defined attributes to the printer. 4) Provides for the capture of all data sent to and received from the printer. For more information please contact Rajesh Chawla at rajesh@trcs.com. Regards, Rajesh ====================================================== Rajesh Chawla TR Computing Solutions (703) 787-9689 (Fax) 13622 Flintwood Place Herndon VA 20171 From ipp-owner@pwg.org Mon Mar 16 12:05:47 1998 Delivery-Date: Mon, 16 Mar 1998 12:05:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA28904 for ; Mon, 16 Mar 1998 12:05:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04230 for ; Mon, 16 Mar 1998 12:08:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA00942 for ; Mon, 16 Mar 1998 12:05:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 11:55:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00378 for ipp-outgoing; Mon, 16 Mar 1998 11:55:49 -0500 (EST) Message-Id: <3.0.1.32.19980316084839.00b5b980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 08:48:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-ext-mandatory-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Note that this document explicitly mentions printing. Carl-Uno >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-ext-mandatory-00.txt >Date: Mon, 16 Mar 1998 05:20:33 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group >of the IETF. > > Title : Mandatory Extensions in HTTP > Author(s) : P. Leach, H. Nielsen, S. Lawrence > Filename : draft-ietf-http-ext-mandatory-00.txt > Pages : 12 > Date : 13-Mar-98 > > HTTP is used increasingly in applications that need more facilities > than the standard version of the protocol provides, ranging from > distributed authoring, collaboration, and printing, to various remote > procedure call mechanisms. This document proposes the use of a > mandatory extension mechanism designed to address the tension between > private agreement and public specification and to accommodate > extension of applications such as HTTP clients, servers, and proxies. > The proposal associates each extension with a URI[2], and use a few > new RFC 822[1] style header fields to carry the extension identifier > and related information between the parties involved in an extended > transaction. > > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-ext-mandatory-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-ext-mandatory-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-ext-mandatory-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 16 12:18:29 1998 Delivery-Date: Mon, 16 Mar 1998 12:18:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA29541 for ; Mon, 16 Mar 1998 12:18:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04346 for ; Mon, 16 Mar 1998 12:21:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA01542 for ; Mon, 16 Mar 1998 12:18:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 12:13:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01014 for ipp-outgoing; Mon, 16 Mar 1998 12:13:04 -0500 (EST) Message-Id: <3.0.1.32.19980316090710.00910dd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 09:07:10 PST To: Ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-authentication-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-authentication-01.txt >Date: Mon, 16 Mar 1998 05:21:14 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. > > Title : HTTP Authentication: Basic and Digest > Access Authentication > Author(s) : J. Franks, E. Sink, P. Leach, J. Hostetler, > P. Hallam-Baker, L. Stewart, S. Lawrence, A. Luotonen > Filename : draft-ietf-http-authentication-01.txt > Pages : 26 > Date : 13-Mar-98 > >''HTTP/1.0'' includes the specification for a Basic Access Authentication >scheme. This scheme is not considered to be a secure method of user >authentication (unless used in conjunction with some external secure >system such as SSL [5]), as the user name and password are passed over >the network as cleartext. > >This document also provides the specification for HTTP's authentication >framework, the original Basic authentication scheme and a scheme based >on cryptographic hashes, referred to as ''Digest Access Authentication''. >It is therefore also intended to serve as a replacement for RFC 2069 >[6]. Some optional elements specified by RFC 2069 have been removed >from this specification due to problems found since its publication; >other new elements have been added -for compatibility, those new >elements have been made optional, but are strongly recommended. > >Like Basic, Digest access authentication verifies that both parties to a >communication know a shared secret (a password); unlike Basic, this >verification can be done without sending the password in the clear, >which is Basic's biggest weakness. As with most other authentication >protocols, the greatest sources of risks are usually found not in the >core protocol itself but in policies and procedures surrounding its use. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-authentication-01.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-authentication-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 16 12:37:51 1998 Delivery-Date: Mon, 16 Mar 1998 12:38:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA00847 for ; Mon, 16 Mar 1998 12:37:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04480 for ; Mon, 16 Mar 1998 12:40:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA02189 for ; Mon, 16 Mar 1998 12:37:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 12:32:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01668 for ipp-outgoing; Mon, 16 Mar 1998 12:32:41 -0500 (EST) Message-Id: <3.0.1.32.19980316092044.00cca4e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 09:20:44 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-tls-https-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno >To: IETF-Announce:; >Cc: ietf-tls@consensus.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-tls-https-01.txt >Date: Mon, 16 Mar 1998 05:22:46 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : HTTP Over TLS > Author(s) : E. Rescorla > Filename : draft-ietf-tls-https-01.txt > Pages : 6 > Date : 13-Mar-98 > > This memo describes how to use TLS to secure HTTP connections over > the Internet. Current practice is to layer HTTP over SSL (the prede- > cessor to TLS), distinguishing secured traffic from insecure traffic > by the use of a different server port. This document documents that > practice using TLS. A companion document describes a method for using > HTTP/TLS over the same port as normal HTTP. > >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-tls-https-01.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-https-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-tls-https-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 16 14:01:52 1998 Delivery-Date: Mon, 16 Mar 1998 14:01:52 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA06349 for ; Mon, 16 Mar 1998 14:01:51 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04986 for ; Mon, 16 Mar 1998 14:04:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA03303 for ; Mon, 16 Mar 1998 14:01:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 13:55:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02756 for ipp-outgoing; Mon, 16 Mar 1998 13:55:50 -0500 (EST) Message-Id: <3.0.1.32.19980316105000.00b47100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 10:50:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference Agenda for 980318 Cc: masinter@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference Agenda for 980318 I would like to spend this week's phone conference to go over some of the new drafts from other working groups, which may impact the implementation of IPP. We should decide if we need to comment on some of these drafts in the IETF LA meeting. The relevant drafts are: - Hypertext Transfer Protocol -- HTTP/1.1 ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-03.txt This is an update of RFC 2068 and reflects some implementation experience and bug fixes to HTT 1.1. - Mandatory Extensions in HTTP ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-ext-mandatory-00.txt This seems to define a few proposed extensions to RFC 2068. - HTTP Authentication: Basic and Digest Access Authentication ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-01.txt This is an update of RFC 2069 and states that Basic Authentication can only be used in combination with an underlying secure transfer protocol. - HTTP Over TLS ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-https-01.txt This is the TLS profile for HTTP 1.1. Can we apply this for IPP as is? - Media Features for Display, Print, and Fax ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.txt This is from the newly formed CONNEG group and partly overlaps with IPP. Seems to have been made mostly by people from the IFAX group. Is more aligned with the Printer MIB than with IPP. - Content Feature Tag Registration Procedure ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-00.txt This is a companion draft to the previous one from the CONNEG group. --- If you are interested in discussing details in these documents, please read them before the phone conference. The phone-in information is: Date and Time: March 18, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 212-547-0243 (For Xerox participants 8*535-5000) Pass code: cmanros Please note that the phone number is different from last time. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 16 14:28:07 1998 Delivery-Date: Mon, 16 Mar 1998 14:28:07 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA07699 for ; Mon, 16 Mar 1998 14:28:07 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05163 for ; Mon, 16 Mar 1998 14:30:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA03963 for ; Mon, 16 Mar 1998 14:28:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 14:22:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03405 for ipp-outgoing; Mon, 16 Mar 1998 14:22:37 -0500 (EST) Message-Id: <3.0.1.32.19980316111116.00b45a00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 11:11:16 PST To: Harald.Alvestrand@maxware.no, moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> IESG feedback on IPP drafts Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harald and Keith, As you might image, the IPP WG members are getting anxious to learn about the IESG decision about our documents, and I would need to know if I have to make the IESG feedback a main agenda point for the IPP meeting in LA, or if we can use the time to discuss further work (Notifications and IPP MIB seems to be things that still needs to be done before the current scope of IPP work is finished). When is the next meeting or phone conference of the IESG, assuming that our subject is on the agenda? On a different subject, will you guys have any time for an IPP demo in LA? Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 16 15:05:07 1998 Delivery-Date: Mon, 16 Mar 1998 15:05:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA09386 for ; Mon, 16 Mar 1998 15:05:06 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05425 for ; Mon, 16 Mar 1998 15:07:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05366 for ; Mon, 16 Mar 1998 15:04:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 14:59:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04843 for ipp-outgoing; Mon, 16 Mar 1998 14:59:49 -0500 (EST) Date: Mon, 16 Mar 1998 14:59:01 -0500 (EST) From: Gail Zacharias To: ipp@pwg.org Subject: IPP> IPP implementation demo Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Harlequin is going to be showing a preliminary IPP server for our ScriptWorks product at Seybold this week. If you're interested in seeing a demo, stop by Meeting Room #2 at the Javits Convention Center, and ask for Neil Epstein. From jmp-owner@pwg.org Mon Mar 16 17:03:19 1998 Delivery-Date: Mon, 16 Mar 1998 17:03:45 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17614 for ; Mon, 16 Mar 1998 17:03:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05982 for ; Mon, 16 Mar 1998 17:05:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06314 for ; Mon, 16 Mar 1998 17:02:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 16:59:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05682 for jmp-outgoing; Mon, 16 Mar 1998 16:57:09 -0500 (EST) Message-ID: <350D9DB9.1B183565@underscore.com> Date: Mon, 16 Mar 1998 16:46:33 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ira Mcdonald x10962 CC: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: JMP> Re: IPP> SNMPv3 unsuited for IPP/JMP Notifications References: <9803160035.AA12733@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Ira, Thanks so much for your review and comments regarding the applicability (or not) of the new SNMPv3 async notification facilities. I particularly liked your summary paragraph: > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. This comes as no surprise to those of us developing SENSE over the last two years or so. SNMP was primarily designed for management network elements, and has never demonstrated the power required in larger, non-management applications, such as generic client-side features of network printing. That is precisely why we went off and did SENSE, to create a more scalable, more generic system for async notifications. Simply hacking onto existing (or future) SNMP facilities never seemed to make the grade. And now your analysis seems to verify that original assumption. Perhaps someday the PWG will come to understand the need for SENSE...or something just like it, anyway. ...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 -- ---------------------------------------------------------------------- Ira Mcdonald x10962 wrote: > > Copies To: ipp@pwg.org > jmp_pwg.org > > Hi folks, Sunday (15 March 1998) > > Extracted below (with line numbers) is summary information from the five > SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). > > As Randy Turner has argued, it IS possible to use a small subset (Target > and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are > a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) > SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' > declaration at line 2773 of RFC 2273). > > But, the functionality provided is INFERIOR in important ways to that > provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted > on Wednesday (4 March 1998) or to my informal understanding of the IBM > method presented by Harry Lewis during last week's PWG monthly meeting > in Austin, TX. > > 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope > (traps of 'interest') specified as object identifier subtrees. > The SNMPv3 Target/Notification MIBs support scope only by short (32 > character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due > to their length) are NOT amenable to standardization. > > 2) The JAM MIB supports automatic trap deregistration specified as > 'DateAndTime'. > The SNMPv3 Target/Notification MIBs do NOT support automatic trap > deregistration at all! > > 3) The JAM MIB supports simple integer indices for all 'read-create' > object groups (written by a remote client). > The SNMPv3 Target/Notification MIBs support indices ONLY as (32 > character) UTF-8 'SnmpAdminString' values, seriously restricting the > number of SNMP objects which can be transferred in a single packet. > Since SNMP runs over UDP (in the Internet suite) and there is no > 'chunking' for SNMP requests, this limitation is significant! > > 4) The JAM MIB supports a 'read-only' lookup table (maintained by the > SNMP agent on the device) which provides direct lookup from SNMP > transport domain and transport address to a client (target) trap > registration entry (to avoid duplicate registrations). > But, the SNMPv3 Target/Notification MIBs support only brute force > (ie, read the entire Target table) for this important functionality! > > 5) The JAM MIB scales well to a very large number of (end-user) trap > client (target) registrations. > But, the SNMPv3 Target/Notification MIBs do not scale well. They > are intended ONLY for use by network management stations! > > 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses > could be used for (questionably) 'reliable' event notification. > But, 'Inform' is intended by the SNMPv3 developers to be used ONLY > for reporting up a hierarchy of network management stations! > Also, 'Inform' is not defined in SNMPv1, so the huge installed base > of SNMP agents which (almost exclusively) speak SNMPv1 cannot use > 'Inform'. > > 7) Lastly, as SNMP agent toolkits become available from software tool > vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the > printer industry vendors will inevitably conflict with the very > different intent of the SNMPv3 developers. Recall why the Job Mon > MIB is a PWG standard and NOT an IETF standard! > > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. > > Cheers, > - Ira McDonald (High North, outside consultant at Xerox) > > ------------------------------------------------------------------------ > **** SNMPv3 Documents **** > > rfc2271.txt: Architecture for Describing SNMP Management Frameworks > - 38-44: > This document describes an architecture for describing SNMP > Management Frameworks. The architecture is designed to be modular to > allow the evolution of the SNMP protocol standards over time. The > major portions of the architecture are an SNMP engine containing a > Message Processing Subsystem, a Security Subsystem and an Access > Control Subsystem, and possibly multiple SNMP applications which > provide specific functional processing of management data. > - 1913: > SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN > - 2420: > snmpFrameworkMIBCompliance MODULE-COMPLIANCE > > rfc2272.txt: Message Processing and Dispatching for SNMP > - 41-46: > This document describes the Message Processing and Dispatching for > SNMP messages within the SNMP architecture [RFC2271]. It defines the > procedures for dispatching potentially multiple versions of SNMP > messages to the proper SNMP Message Processing Models, and for > dispatching PDUs to SNMP applications. This document also describes > one Message Processing Model - the SNMPv3 Message Processing Model. > - 810: > SNMP-MPD-MIB DEFINITIONS ::= BEGIN > - 936: > snmpMPDCompliance MODULE-COMPLIANCE > - 976: > SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > > rfc2273.txt: SNMPv3 Applications > - 37-44: > This memo describes five types of SNMP applications which make use of > an SNMP engine as described in [RFC2271]. The types of application > described are Command Generators, Command Responders, Notification > Originators, Notification Receivers, and Proxy Forwarders. > > This memo also defines MIB modules for specifying targets of > management operations, for notification filtering, and for proxy > forwarding. > - 1561: > SNMP-TARGET-MIB DEFINITIONS ::= BEGIN > - 2209: > snmpTargetCommandResponderCompliance MODULE-COMPLIANCE > - 2305: > SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN > - 2773: > snmpNotifyBasicCompliance MODULE-COMPLIANCE > - 2881: > snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE > - 2894: > snmpNotifyFullCompliance MODULE-COMPLIANCE > - 2960: > SNMP-PROXY-MIB DEFINITIONS ::= BEGIN > - 3242: > snmpProxyCompliance MODULE-COMPLIANCE > > rfc2274.txt: User-based Security Model (USM) for SNMPv3 > - 37-41: > This document describes the User-based Security Model (USM) for SNMP > version 3 for use in the SNMP architecture [RFC2271]. It defines the > Elements of Procedure for providing SNMP message level security. > This document also includes a MIB for remotely monitoring/managing > the configuration parameters for this Security Model. > - 861: > USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > - 1701: > SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN > - 2439: > usmMIBCompliance MODULE-COMPLIANCE > > rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 > - 38-42: > This document describes the View-based Access Control Model for use > in the SNMP architecture [RFC2271]. It defines the Elements of > Procedure for controlling access to management information. This > document also includes a MIB for remotely managing the configuration > parameters for the View-based Access Control Model. > - 541: > SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN > - 1356: > vacmMIBCompliance MODULE-COMPLIANCE > ------------------------------------------------------------------------ From ipp-owner@pwg.org Mon Mar 16 17:05:52 1998 Delivery-Date: Mon, 16 Mar 1998 17:05:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA18095 for ; Mon, 16 Mar 1998 17:05:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05999 for ; Mon, 16 Mar 1998 17:08:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA06597 for ; Mon, 16 Mar 1998 17:05:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 16:57:34 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05690 for ipp-outgoing; Mon, 16 Mar 1998 16:57:16 -0500 (EST) Message-ID: <350D9DB9.1B183565@underscore.com> Date: Mon, 16 Mar 1998 16:46:33 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ira Mcdonald x10962 CC: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: Re: IPP> SNMPv3 unsuited for IPP/JMP Notifications References: <9803160035.AA12733@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Ira, Thanks so much for your review and comments regarding the applicability (or not) of the new SNMPv3 async notification facilities. I particularly liked your summary paragraph: > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. This comes as no surprise to those of us developing SENSE over the last two years or so. SNMP was primarily designed for management network elements, and has never demonstrated the power required in larger, non-management applications, such as generic client-side features of network printing. That is precisely why we went off and did SENSE, to create a more scalable, more generic system for async notifications. Simply hacking onto existing (or future) SNMP facilities never seemed to make the grade. And now your analysis seems to verify that original assumption. Perhaps someday the PWG will come to understand the need for SENSE...or something just like it, anyway. ...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 -- ---------------------------------------------------------------------- Ira Mcdonald x10962 wrote: > > Copies To: ipp@pwg.org > jmp_pwg.org > > Hi folks, Sunday (15 March 1998) > > Extracted below (with line numbers) is summary information from the five > SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). > > As Randy Turner has argued, it IS possible to use a small subset (Target > and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are > a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) > SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' > declaration at line 2773 of RFC 2273). > > But, the functionality provided is INFERIOR in important ways to that > provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted > on Wednesday (4 March 1998) or to my informal understanding of the IBM > method presented by Harry Lewis during last week's PWG monthly meeting > in Austin, TX. > > 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope > (traps of 'interest') specified as object identifier subtrees. > The SNMPv3 Target/Notification MIBs support scope only by short (32 > character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due > to their length) are NOT amenable to standardization. > > 2) The JAM MIB supports automatic trap deregistration specified as > 'DateAndTime'. > The SNMPv3 Target/Notification MIBs do NOT support automatic trap > deregistration at all! > > 3) The JAM MIB supports simple integer indices for all 'read-create' > object groups (written by a remote client). > The SNMPv3 Target/Notification MIBs support indices ONLY as (32 > character) UTF-8 'SnmpAdminString' values, seriously restricting the > number of SNMP objects which can be transferred in a single packet. > Since SNMP runs over UDP (in the Internet suite) and there is no > 'chunking' for SNMP requests, this limitation is significant! > > 4) The JAM MIB supports a 'read-only' lookup table (maintained by the > SNMP agent on the device) which provides direct lookup from SNMP > transport domain and transport address to a client (target) trap > registration entry (to avoid duplicate registrations). > But, the SNMPv3 Target/Notification MIBs support only brute force > (ie, read the entire Target table) for this important functionality! > > 5) The JAM MIB scales well to a very large number of (end-user) trap > client (target) registrations. > But, the SNMPv3 Target/Notification MIBs do not scale well. They > are intended ONLY for use by network management stations! > > 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses > could be used for (questionably) 'reliable' event notification. > But, 'Inform' is intended by the SNMPv3 developers to be used ONLY > for reporting up a hierarchy of network management stations! > Also, 'Inform' is not defined in SNMPv1, so the huge installed base > of SNMP agents which (almost exclusively) speak SNMPv1 cannot use > 'Inform'. > > 7) Lastly, as SNMP agent toolkits become available from software tool > vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the > printer industry vendors will inevitably conflict with the very > different intent of the SNMPv3 developers. Recall why the Job Mon > MIB is a PWG standard and NOT an IETF standard! > > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. > > Cheers, > - Ira McDonald (High North, outside consultant at Xerox) > > ------------------------------------------------------------------------ > **** SNMPv3 Documents **** > > rfc2271.txt: Architecture for Describing SNMP Management Frameworks > - 38-44: > This document describes an architecture for describing SNMP > Management Frameworks. The architecture is designed to be modular to > allow the evolution of the SNMP protocol standards over time. The > major portions of the architecture are an SNMP engine containing a > Message Processing Subsystem, a Security Subsystem and an Access > Control Subsystem, and possibly multiple SNMP applications which > provide specific functional processing of management data. > - 1913: > SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN > - 2420: > snmpFrameworkMIBCompliance MODULE-COMPLIANCE > > rfc2272.txt: Message Processing and Dispatching for SNMP > - 41-46: > This document describes the Message Processing and Dispatching for > SNMP messages within the SNMP architecture [RFC2271]. It defines the > procedures for dispatching potentially multiple versions of SNMP > messages to the proper SNMP Message Processing Models, and for > dispatching PDUs to SNMP applications. This document also describes > one Message Processing Model - the SNMPv3 Message Processing Model. > - 810: > SNMP-MPD-MIB DEFINITIONS ::= BEGIN > - 936: > snmpMPDCompliance MODULE-COMPLIANCE > - 976: > SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > > rfc2273.txt: SNMPv3 Applications > - 37-44: > This memo describes five types of SNMP applications which make use of > an SNMP engine as described in [RFC2271]. The types of application > described are Command Generators, Command Responders, Notification > Originators, Notification Receivers, and Proxy Forwarders. > > This memo also defines MIB modules for specifying targets of > management operations, for notification filtering, and for proxy > forwarding. > - 1561: > SNMP-TARGET-MIB DEFINITIONS ::= BEGIN > - 2209: > snmpTargetCommandResponderCompliance MODULE-COMPLIANCE > - 2305: > SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN > - 2773: > snmpNotifyBasicCompliance MODULE-COMPLIANCE > - 2881: > snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE > - 2894: > snmpNotifyFullCompliance MODULE-COMPLIANCE > - 2960: > SNMP-PROXY-MIB DEFINITIONS ::= BEGIN > - 3242: > snmpProxyCompliance MODULE-COMPLIANCE > > rfc2274.txt: User-based Security Model (USM) for SNMPv3 > - 37-41: > This document describes the User-based Security Model (USM) for SNMP > version 3 for use in the SNMP architecture [RFC2271]. It defines the > Elements of Procedure for providing SNMP message level security. > This document also includes a MIB for remotely monitoring/managing > the configuration parameters for this Security Model. > - 861: > USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > - 1701: > SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN > - 2439: > usmMIBCompliance MODULE-COMPLIANCE > > rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 > - 38-42: > This document describes the View-based Access Control Model for use > in the SNMP architecture [RFC2271]. It defines the Elements of > Procedure for controlling access to management information. This > document also includes a MIB for remotely managing the configuration > parameters for the View-based Access Control Model. > - 541: > SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN > - 1356: > vacmMIBCompliance MODULE-COMPLIANCE > ------------------------------------------------------------------------ From ipp-owner@pwg.org Mon Mar 16 18:07:50 1998 Delivery-Date: Mon, 16 Mar 1998 18:09:11 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA24579 for ; Mon, 16 Mar 1998 18:07:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06185 for ; Mon, 16 Mar 1998 18:10:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA07705 for ; Mon, 16 Mar 1998 18:07:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 18:00:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07162 for ipp-outgoing; Mon, 16 Mar 1998 18:00:01 -0500 (EST) Message-Id: <199803162257.RAA20974@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Harald.Alvestrand@maxware.no, moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IESG feedback on IPP drafts In-reply-to: Your message of "Mon, 16 Mar 1998 11:11:16 PST." <3.0.1.32.19980316111116.00b45a00@garfield> Date: Mon, 16 Mar 1998 17:57:58 -0500 Sender: ipp-owner@pwg.org Carl-Uno, I must apologize...the IPP review is taking longer than I had thought. The documents themselves are long, and there were an unusually large number of comments. And for the last few days I have been dealing with a family medical emergency. I hope to have the review completed by the end of this week, and will then know whether IPP needs to discuss it at the LA meeting. The next IESG meeting will be sometime after the LA IETF. Keith From ipp-owner@pwg.org Mon Mar 16 19:35:14 1998 Delivery-Date: Mon, 16 Mar 1998 19:36:34 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA29814 for ; Mon, 16 Mar 1998 19:35:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06454 for ; Mon, 16 Mar 1998 19:37:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA08536 for ; Mon, 16 Mar 1998 19:34:50 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 19:27:33 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07992 for ipp-outgoing; Mon, 16 Mar 1998 19:27:23 -0500 (EST) Message-Id: <3.0.1.32.19980316162536.00a409d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 16:25:36 PST To: "Puru Bish" From: Tom Hastings Subject: Re: IPP> Re: IPP- Printer state Cc: ipp@pwg.org In-Reply-To: <19980312200457.1307.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 12:04 03/12/1998 PST, Puru Bish wrote: > >Thanks, Tom for clarifying the issue. > >I still have a question - should an IPP server behave the same >way even when it does not spool any job? You mean what should an IPP Printer object implemented in a server that does not spool jobs, but forwards jobs onto a single device directly (perhaps using IPP or some other device protocol), but the device to which it forwards jobs is shutdown? I would think that the following response might be the best: The server would reject the Create-Job and return the error code: 'server-error-service-unavailable'. Then the client could query the Printer's "printer-state" and see 'stopped' and the Printer's "printer-state-reasons" and see 'error-shutdown'. Do others agree? Tom > >-PB > >>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 > >>Yes, the Printer object implemented in a server object does accept the >>job even though the device is powered down. >> >>And the requester MAY get an indication that there is a problem, >because >>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in >the >>Print-Job response containing the value: 'printer-stopped' >>(or 'printer-stopped-partly' in the case that only some of the fan-out >>printers are stopped). Unfortunately, the requeseter will NOT get this >>indication in the response, if the IPP Printer object does not >implement >>the OPTIONAL "job-state-reasons" attribute. >> >>The client can then query the Printer's "printer-state" >>and "printer-state-reasons" attribute and see that the "printer-state" >>is 'stopped' and the "printer-state-reasons" is 'error-shutdown' >>('warning-shutdown' if only some of the fan-out printers are shutdown). >> >> >>The explanation of the 'stopped' state on page 89 of the Model document >>says (in its entirity of two paragraphs): >> >>'5' 'stopped': If a Printer receives a job (whose required resources >are >>ready) while in this state, such a job SHALL transit into the pending >state >>immediately. Such a job SHALL transit into the processing state only >after >>some human fixes the problem that stopped the printer and after jobs >ahead >>of it complete printing. The "printer-state-reasons" attribute SHALL >>contain at least one reason, e.g. media-jam, which prevents it from >either >>processing the current job or transitioning a pending job to the >processing >>state. >> >>Note: if a Printer controls more than one output device, the above >>definition implies that a Printer is stopped only if all output devices >are >>stopped. Also, it is tempting to define stopped as when a sufficient >>number of output devices are stopped and leave it to an implementation >to >>define the sufficient number. But such a rule complicates the >definition >>of stopped and processing. For example, with this alternate definition >of >>stopped, a job can move from idle to processing without human >intervention, >>even though the Printer is stopped. >> >> >> >>Does the Model document need any futher clarification? >> >>Tom > > > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > > From ipp-owner@pwg.org Mon Mar 16 20:56:45 1998 Delivery-Date: Mon, 16 Mar 1998 20:56:45 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA02830 for ; Mon, 16 Mar 1998 20:56:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA06590 for ; Mon, 16 Mar 1998 20:59:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA10697 for ; Mon, 16 Mar 1998 20:56:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 16 Mar 1998 20:50:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA10159 for ipp-outgoing; Mon, 16 Mar 1998 20:50:43 -0500 (EST) Message-ID: <350DD604.8093BAD4@underscore.com> Date: Mon, 16 Mar 1998 20:46:44 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Re: IPP- Printer state References: <3.0.1.32.19980316162536.00a409d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Yes, I suppose your summary is correct, Tom. However, I get the feeling Puru is asking about an embedded server implementation, one in which the IPP server is embedded within the printer. If this is true, then the error return should be the infamous "too busy" error code, the one that Randy is working on (I believe). ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > At 12:04 03/12/1998 PST, Puru Bish wrote: > > > >Thanks, Tom for clarifying the issue. > > > >I still have a question - should an IPP server behave the same > >way even when it does not spool any job? > > You mean what should an IPP Printer object implemented in a server > that does not spool jobs, but forwards jobs onto a single device directly > (perhaps using IPP or some other device protocol), but the device > to which it forwards jobs is shutdown? > > I would think that the following response might be the best: > > The server would reject the Create-Job and return the error code: > 'server-error-service-unavailable'. > Then the client could query the Printer's "printer-state" and see 'stopped' > and the Printer's "printer-state-reasons" and see 'error-shutdown'. > > Do others agree? > > Tom > > > > >-PB > > > >>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 > > > >>Yes, the Printer object implemented in a server object does accept the > >>job even though the device is powered down. > >> > >>And the requester MAY get an indication that there is a problem, > >because > >>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in > >the > >>Print-Job response containing the value: 'printer-stopped' > >>(or 'printer-stopped-partly' in the case that only some of the fan-out > >>printers are stopped). Unfortunately, the requeseter will NOT get this > >>indication in the response, if the IPP Printer object does not > >implement > >>the OPTIONAL "job-state-reasons" attribute. > >> > >>The client can then query the Printer's "printer-state" > >>and "printer-state-reasons" attribute and see that the "printer-state" > >>is 'stopped' and the "printer-state-reasons" is 'error-shutdown' > >>('warning-shutdown' if only some of the fan-out printers are shutdown). > >> > >> > >>The explanation of the 'stopped' state on page 89 of the Model document > >>says (in its entirity of two paragraphs): > >> > >>'5' 'stopped': If a Printer receives a job (whose required resources > >are > >>ready) while in this state, such a job SHALL transit into the pending > >state > >>immediately. Such a job SHALL transit into the processing state only > >after > >>some human fixes the problem that stopped the printer and after jobs > >ahead > >>of it complete printing. The "printer-state-reasons" attribute SHALL > >>contain at least one reason, e.g. media-jam, which prevents it from > >either > >>processing the current job or transitioning a pending job to the > >processing > >>state. > >> > >>Note: if a Printer controls more than one output device, the above > >>definition implies that a Printer is stopped only if all output devices > >are > >>stopped. Also, it is tempting to define stopped as when a sufficient > >>number of output devices are stopped and leave it to an implementation > >to > >>define the sufficient number. But such a rule complicates the > >definition > >>of stopped and processing. For example, with this alternate definition > >of > >>stopped, a job can move from idle to processing without human > >intervention, > >>even though the Printer is stopped. > >> > >> > >> > >>Does the Model document need any futher clarification? > >> > >>Tom > > > > > > > > > >______________________________________________________ > >Get Your Private, Free Email at http://www.hotmail.com > > > > From ipp-owner@pwg.org Tue Mar 17 12:38:40 1998 Delivery-Date: Tue, 17 Mar 1998 12:38:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA10197 for ; Tue, 17 Mar 1998 12:38:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA09453 for ; Tue, 17 Mar 1998 12:41:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26404 for ; Tue, 17 Mar 1998 12:38:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 12:32:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25869 for ipp-outgoing; Tue, 17 Mar 1998 12:32:45 -0500 (EST) Message-ID: <350EB3B6.D12B459C@underscore.com> Date: Tue, 17 Mar 1998 12:32:38 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> [Fwd: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt] Content-Type: multipart/mixed; boundary="------------CD32AB3A5ED4F392253A206D" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------CD32AB3A5ED4F392253A206D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI... --------------CD32AB3A5ED4F392253A206D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA16919 for ; Tue, 17 Mar 1998 10:56:44 -0500 (EST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id KAA22764; Tue, 17 Mar 1998 10:53:18 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA13430 for ; Tue, 17 Mar 1998 10:53:02 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id KAA10005 for ; Tue, 17 Mar 1998 10:53:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03783; Tue, 17 Mar 1998 10:52:55 -0500 (EST) Message-Id: <199803171552.KAA03783@ns.ietf.org> Mime-Version: 1.0 To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt Date: Tue, 17 Mar 1998 10:52:53 -0500 Sender: cclark@cnri.reston.va.us Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification MIB Author(s) : B. Stewart Filename : draft-ietf-disman-notif-log-mib-02.txt Pages : 15 Date : 13-Mar-98 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing SNMP notifications. 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-disman-notif-log-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980316082325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316082325.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------CD32AB3A5ED4F392253A206D-- From jmp-owner@pwg.org Tue Mar 17 13:28:16 1998 Delivery-Date: Tue, 17 Mar 1998 13:28:17 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12462 for ; Tue, 17 Mar 1998 13:28:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09676 for ; Tue, 17 Mar 1998 13:30:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27055 for ; Tue, 17 Mar 1998 13:28:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 13:25:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26551 for jmp-outgoing; Tue, 17 Mar 1998 13:23:09 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: JMP> RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications Date: Tue, 17 Mar 1998 10:23:01 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org I am not sure what the dissenting opinion is, whether SNMPv3 is not the correct solution? Or, is the proposed notification MIB not the right solution? If SNMP is the wrong solution, then any SNMP-accessed MIB would be the wrong solution, including the JAM MIB. I will try and address the concerns outlined below, with matching numbers. 1) Scopes of interest are still supported by OID subtree specifications; it's the intended notification recipients that are identified and matched by the UTF-8 tag. 2) Registration lifetimes would be a good idea. It's quite possible for an IPP MIB to augment the notification table with objects that represent registration lifetimes. No need to throw the baby out with the bath water on this one. Since it is an explicit augmentation, the indices would be the same. 3) Indices that appear as SnmpAdminString types are labeled as NOT-ACCESSIBLE, so they should not appear in the response packet of a GET, or GET-BULK. 4) I'm not sure if a brute force search would be required or not (yet). It appears from reading the RFC that this might be the case and I understand how this conclusion could be made. However, I'm not sure that duplicate registrations could be identified solely on the basis of "transport" and "transport-address" matching. This particular scenario would require more study. 5) This rationale does not exist for SNMPv3. This held true only for V2 (and derivatives). All the text about "dual-role entities" from V2 has been removed from the V3 doc set. The V3 specs now generically identify "notification senders" and "notification recipients". The idea of specific functionality being reserved for a "mid-level" manager entity no longer exists. Implementors are free to instrument whatever feature they need, depending upon the type of management (or managed) entity is being constructed. 6) Again, this idea is a V2 idea, the restrictions on "how" a feature is used has been removed from the V3 specifications. See #5 above. Also, I have it on good authority from Jeff Case at SNMP Research, that the effort required to take the V1 trap code base and move it to V3 trap/inform is no great task. A lot of code reuse is possible. Also, V3 informs are as reliable as any other notification mechanism. 7) Again, I have it on first hand communication from Bob Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their "intent" was never to disallow the type of functionality I have proposed. Rather, it seems like a prudent reuse of all vendors' existing agent code base. This reuse of technology (both in design and existing code) is what I am trying to take advantage of. Given the speed at which SNMPv3 is being adopted, I feel like a lot of vendors are going to want to implement V3 agents anyway. Also, after looking at Ira's proposal for the JAM MIB, there are some ideas present in the JAM MIB that were not included in the standard notification/target MIBs specified in RFC 2273. I think we should include these ideas in whatever we come up with. I don't think we should completely reinvent the wheel here, rather, I think we should come up with a suitable set of additional (non-overlapping) notification features and AUGMENT the standard set. This is because, for a lot of reasons, I think vendors will eventually have to support them anyway to be "V3 compliant" at some point in the future. By the way, I have no SNMP religious affiliation, just a desire to reuse technology. If we find out that our requirements exceed the boundaries of what SNMPv3 and related technology can deliver, then I would be just as happy to pursue another path. But I think we need to study this stuff a little more before taking any radical direction change. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 15, 1998 4:35 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-owner@pwg.org Tue Mar 17 13:30:23 1998 Delivery-Date: Tue, 17 Mar 1998 13:30:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12534 for ; Tue, 17 Mar 1998 13:30:23 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09690 for ; Tue, 17 Mar 1998 13:32:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27271 for ; Tue, 17 Mar 1998 13:30:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 13:23:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26543 for ipp-outgoing; Tue, 17 Mar 1998 13:23:02 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications Date: Tue, 17 Mar 1998 10:23:01 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I am not sure what the dissenting opinion is, whether SNMPv3 is not the correct solution? Or, is the proposed notification MIB not the right solution? If SNMP is the wrong solution, then any SNMP-accessed MIB would be the wrong solution, including the JAM MIB. I will try and address the concerns outlined below, with matching numbers. 1) Scopes of interest are still supported by OID subtree specifications; it's the intended notification recipients that are identified and matched by the UTF-8 tag. 2) Registration lifetimes would be a good idea. It's quite possible for an IPP MIB to augment the notification table with objects that represent registration lifetimes. No need to throw the baby out with the bath water on this one. Since it is an explicit augmentation, the indices would be the same. 3) Indices that appear as SnmpAdminString types are labeled as NOT-ACCESSIBLE, so they should not appear in the response packet of a GET, or GET-BULK. 4) I'm not sure if a brute force search would be required or not (yet). It appears from reading the RFC that this might be the case and I understand how this conclusion could be made. However, I'm not sure that duplicate registrations could be identified solely on the basis of "transport" and "transport-address" matching. This particular scenario would require more study. 5) This rationale does not exist for SNMPv3. This held true only for V2 (and derivatives). All the text about "dual-role entities" from V2 has been removed from the V3 doc set. The V3 specs now generically identify "notification senders" and "notification recipients". The idea of specific functionality being reserved for a "mid-level" manager entity no longer exists. Implementors are free to instrument whatever feature they need, depending upon the type of management (or managed) entity is being constructed. 6) Again, this idea is a V2 idea, the restrictions on "how" a feature is used has been removed from the V3 specifications. See #5 above. Also, I have it on good authority from Jeff Case at SNMP Research, that the effort required to take the V1 trap code base and move it to V3 trap/inform is no great task. A lot of code reuse is possible. Also, V3 informs are as reliable as any other notification mechanism. 7) Again, I have it on first hand communication from Bob Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their "intent" was never to disallow the type of functionality I have proposed. Rather, it seems like a prudent reuse of all vendors' existing agent code base. This reuse of technology (both in design and existing code) is what I am trying to take advantage of. Given the speed at which SNMPv3 is being adopted, I feel like a lot of vendors are going to want to implement V3 agents anyway. Also, after looking at Ira's proposal for the JAM MIB, there are some ideas present in the JAM MIB that were not included in the standard notification/target MIBs specified in RFC 2273. I think we should include these ideas in whatever we come up with. I don't think we should completely reinvent the wheel here, rather, I think we should come up with a suitable set of additional (non-overlapping) notification features and AUGMENT the standard set. This is because, for a lot of reasons, I think vendors will eventually have to support them anyway to be "V3 compliant" at some point in the future. By the way, I have no SNMP religious affiliation, just a desire to reuse technology. If we find out that our requirements exceed the boundaries of what SNMPv3 and related technology can deliver, then I would be just as happy to pursue another path. But I think we need to study this stuff a little more before taking any radical direction change. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 15, 1998 4:35 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-owner@pwg.org Tue Mar 17 16:22:04 1998 Delivery-Date: Tue, 17 Mar 1998 16:22:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20738 for ; Tue, 17 Mar 1998 16:22:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10703 for ; Tue, 17 Mar 1998 16:24:36 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28533 for ; Tue, 17 Mar 1998 16:21:56 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 16:17:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28000 for ipp-outgoing; Tue, 17 Mar 1998 16:17:31 -0500 (EST) Message-Id: <3.0.1.32.19980317131137.00ca3660@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 13:11:37 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-iesg-iana-considerations-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Carl-Uno -- >To: IETF-Announce:; >Cc: iesg@ns.ietf.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-iesg-iana-considerations-03.txt >Date: Mon, 16 Mar 1998 05:43:25 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IETF Steering Group Working Group of the IETF. > > Title : Guidelines for Writing an IANA Considerations Section in RFCs > Author(s) : H. Alvestrand, T. Narten > Filename : draft-iesg-iana-considerations-03.txt > Pages : 10 > Date : 13-Mar-98 > > Many protocols make use of identifiers consisting of constants and > other well-known values. Even after a protocol has been defined and > deployment has begun, new values may need to be assigned (e.g., for a > new option type in DHCP, or a new authentication algorithm). To > insure that such quantities have unique values, their assignment must > be administered by a central authority. In the Internet, that role is > provided by the Internet Assigned Numbers Authority (IANA). > > In order for the IANA to manage a given numbering space prudently, it > needs guidelines describing the conditions under which new values can > be assigned. If the IANA is expected to play a role in the management > of a numbering space, the IANA must be given clear and concise > instructions describing that role. This document discusses issues > that should be considered in formulating an identifier assignment > policy and provides guidelines to document authors on the specific > text that must be included in documents that place demands on the > IANA. > >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-iesg-iana-considerations-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-iesg-iana-considerations-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 17 16:34:45 1998 Delivery-Date: Tue, 17 Mar 1998 16:34:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA21342 for ; Tue, 17 Mar 1998 16:34:44 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10774 for ; Tue, 17 Mar 1998 16:37:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA29136 for ; Tue, 17 Mar 1998 16:33:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 16:29:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28612 for ipp-outgoing; Tue, 17 Mar 1998 16:28:54 -0500 (EST) Message-Id: <3.0.1.32.19980317132250.00ca9b30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 13:22:50 PST To: ipp@pwg.org From: Daniel Manchala (by way of Carl-Uno Manros ) Subject: IPP> Draft available from Rohit Khare. Upgrading to TLS within HTTP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, this should also show up as an I-D shortly. Carl-Uno -- >Subject: Repost: Upgrading to TLS within HTTP >Date: Mon, 16 Mar 1998 15:50:05 PST >From: Rohit Khare > > >Upgrading to TLS Within HTTP > > _Rohit Khare_, UC Irvine, March 16, 1998 > > _________________________________________________________________ > > 0. Motivation > > At the [1]Washington DC IETF meeting last year, the Applications Area > Directors indicated they would like to see a mechanism for applying > Transport Layer Security [TLS] within an [2]HTTP connection, at the > same port, instead of only being able to recommend a distinct port > (443) and scheme (https). The TLS working group has moved forward with > an extensive draft on properly implementing https > ([3]draft-ietf-tls-https-00), but there is alternate precedent in SMTP > and other applications of TLS ([4]draft-hoffman-smtp-ssl, > [5]draft-newman-tls-imappop-03, [6]murray-auth-ftp-ssl-00). > > There has already been extensive debate on the [7]http-wg , > [8]ietf-tls and [9]ietf-apps-tls mailing lists about the advisability > of permitting optional 'upgrades' to secure connections within the > same channel, primarily focusing on the thread of man-in-the-middle > attacks. Our intent here is not to engage in this debate, but merely > to document a proposed mechanism for doing either with HTTP. Several > applications being built upon HTTP might use this mechanism, such as > the [10]Internet Printing Protocol; we look to them for implementation > guidance. > > 1. Introduction > > TLS, a/k/a SSL (Secure Sockets Layer) establishes a private end-to-end > connection, optionally including strong mutual authentication, using a > variety of cryptosystems. Initially, a handshake phase uses three > subprotocols to set up a record layer, authenticate endpoints, set > parameters, as well as report errors. Then, there is an ongoing > layered record protocol that handles encryption, compression, and > reassembly for the remainder of the connection. The latter is intended > to be completely transparent. For example, there is no dependency > between TLS's record markers and or certificates and HTTP/1.1's > chunked encoding or authentication. > > The need to 'secure' running connections is not merely 'running SSL > over port 80', an early challenge for firewall developers answered by > Ari Luotonen's [11]ssl-tunneling-02 draft in 1995. The HTTP/1.1 spec > reserves CONNECT for future use, deferring to the more recent > [12]draft-luotonen-web-proxy-tunneling-00 proposal. This technique > perpetuates the concept that security is indicated by a magic port > number -- CONNECT establishes a generic TCP tunnel, so port number is > the only way to specify the layering of TLS with HTTP (https) or with > NTTP (snews). > > Instead, the preferred mechanism to initiate and insert TLS in an > HTTP/1.1 session should be the Upgrade: header, as defined in section > 14.42 of rev-03. Ideally, TLS-capable clients should add "Upgrade: > TLS/1.0" to their initial request, and TLS-capable servers may reply > with "101 Switching Protocol", complete the handshake, and continue > with the "normal" response to the original request. However, the > specification quoth: > > "The Upgrade header field only applies to switching > application-layer protocols upon the existing transport-layer > connection." > > Aside from this minor semantic difference -- invoking TLS indeed > changes the existing transport-layer connection -- this is an ideal > application of Upgrade. This technique overlays the TLS-request on an > HTTP method; requires client-initiation, and allows servers to choose > whether or not to make the switch. Like the other examples of > TLS-enabled application protocols, the original session is preserved > across the TLS handshake; secured communications resumes with a > servers' reply. > > The potential for a man-in-the-middle attack (wherein the "TLS/1.0" > upgrade token is stripped out) is precisely the same as for mixed > http/https use: > > 1. Removing the token is similar to rewriting web pages to change > https:// links to http:// links. > 2. The risk is only present if the server is willing to vend that > information over an insecure channel in the first place > 3. If the client knows for a fact that a server is TLS-compliant, it > can insist on it by only connecting as https:// or by only sending > an upgrade request on a no-op method like OPTIONS. > > Furthermore, for clients which do not actively try to invoke TLS, > servers can use Upgrade: to advertise TLS compliance, too. Since > TLS-compliance should be considered a feature of the server and not > the resource at hand, it should be sufficient to send it once, and let > clients cache that fact. > > 2. Potential Solution > > Define "TLS/x.y" as a reference to the TLS specification > ([13]draft-ietf-tls-protocol-03), with x and y bound to its major and > minor version numbers. Section 6.2.1 of the current draft explains why > the TLS version would currently be defined as 1.0, not the actual > parameters on the wire (which is "3.1" for backwards compatibility > with SSL3). > > An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of > the field-values of the Upgrade: header. The origin-server MAY respond > with "101 Switching Protocols"; if so it MUST include the header > "Upgrade: TLS/x.y" to indicate what it is switching to. > > Servers which can upgrade to TLS MAY include the header "TLS/x.y" in > an Upgrade response header to inform the client; servers SHOULD > include such indication in response to any OPTIONS request. > > Similarly, servers MAY require clients to switch to TLS first by > responding with a new error code "418: Upgrade Required", which MUST > specify the protocol to be supported. @@ This is a change to 'core' > HTTP; if, processwise, it's too difficult to slip in a general-purpose > error code, we may have to fall-back to "418: TLS Required". > > Upgrade is a hop-by-hop header (Section 13.5.1), so each intervening > proxy which supports TLS MUST also request the same version of TLS/x.y > on its subsequent request. Furthermore, any caching proxy which > supports TLS MUST NOT reply from its cache when TLS/x.y has been > requested (although clients are still recommended to explicitly > include "Cache-control: no-cache"). > > Note: proxy servers may be able to request or initiate a TLS-secured > connection, e.g. the outgoing or incoming firewall of a trusted > subnetwork. > > 3. Next Steps > > I could proceed by formalizing Section 2 as an Internet-Draft, but > under the jurisdiction of which IETF working group? Furthermore, I do > not have access nor personal interest in a TLS-capable client/server > pair to experiment with. > > N.B. I believe this work is completely separate from HTTP-extension > work proceeding in the web evolution / http-extension working group. > This uses Upgrade for its stated purpose -- to switch to an entirely > different protocol -- not to define or modify HTTP methods and > semantics. > > Please watch [14]http://www.ics.uci.edu/~rohit/http-tls for updates of > this document and any Internet-Drafts relating to this proposal. > > 4. Acknowledgments > > Thanks to Paul Hoffman for his work on the STARTTLS command extension > for ESMTP. Thanks to Roy Fielding for assistance with the rationale > behind Upgrade: and OPTIONS. > > 5. References > >References > > 1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html > 2. http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt > 3. http://ds.internic.net/internet-drafts/draft-ietf-tls-https-00.txt > 4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl > 5. http://ds.internic.net/internet-drafts/draft-newman-tls-imappop-03.txt > 6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt > 7. http://www.ics.uci.edu/pub/ietf/http/ > 8. http://www.consensus.com/ietf-tls/ > 9. http://www.imc.org/ietf-apps-tls/ > 10. http://www.pwg.org/ipp/index.html > 11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt > 12. http://ds.internic.net/internet-drafts/draft-luotonen-web-proxy-tunneling-00 .txt > 13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt > 14. http://www.ics.uci.edu/~rohit/http-tls > > From ipp-owner@pwg.org Tue Mar 17 17:33:54 1998 Delivery-Date: Tue, 17 Mar 1998 17:33:55 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23949 for ; Tue, 17 Mar 1998 17:33:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11143 for ; Tue, 17 Mar 1998 17:36:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00264 for ; Tue, 17 Mar 1998 17:33:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 17:28:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29620 for ipp-outgoing; Tue, 17 Mar 1998 17:28:14 -0500 (EST) Message-Id: <3.0.1.32.19980317142120.0122eea0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 14:21:20 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-svrloc-printer-scheme-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Scott Isaacson is co-author on this one. Carl-Uno -- >To: IETF-Announce:; >Cc: srvloc@srvloc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-svrloc-printer-scheme-02.txt >Date: Tue, 17 Mar 1998 07:13:47 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Service Location Protocol Working Group of the IETF. > > Title : Definition of printer: URLs for use with > Service Location > Author(s) : S. Isaacson, P. St. Pierre > Filename : draft-ietf-svrloc-printer-scheme-02.txt > Pages : 11 > Date : 16-Mar-98 > > This document defines the printer service type and the attributes > associated with it. This template is designed to be used in > conjuction with the Service Location Protocol [1], but may be > used with any directory service supporting attribute/value pair > registration. > > The printer service type is designed as an abstract service type. It > is expected that printers advertised with the printer type may be > accessible by one or more protocols. IPP and lpr are a two examples > of printing protocols that may be used to perform the actual printing > function. > >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-svrloc-printer-scheme-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-svrloc-printer-scheme-02.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-svrloc-printer-scheme-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 17 19:23:54 1998 Delivery-Date: Tue, 17 Mar 1998 19:24:02 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA27921 for ; Tue, 17 Mar 1998 19:23:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11482 for ; Tue, 17 Mar 1998 19:26:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01566 for ; Tue, 17 Mar 1998 19:23:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 19:19:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00968 for ipp-outgoing; Tue, 17 Mar 1998 19:19:01 -0500 (EST) Message-Id: <3.0.1.32.19980317161311.0125d100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:13:11 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-disman-event-mib-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, Event MIB anyone? Carl-Uno --- >Cc: disman@nexen.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-disman-event-mib-03.txt >Date: Tue, 17 Mar 1998 07:15:19 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Distributed Management Working Group of the IETF. > > Title : Event MIB > Author(s) : B. Stewart > Filename : draft-ietf-disman-event-mib-03.txt > Pages : 23 > Date : 16-Mar-98 > >This memo defines an experimental portion of the Management Information >Base (MIB) for use with network management protocols in the Internet >community. In particular, it describes managed objects used for >managing monitoring of MIB objects and taking action through events. > >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-disman-event-mib-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-disman-event-mib-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 17 19:27:39 1998 Delivery-Date: Tue, 17 Mar 1998 19:27:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA28104 for ; Tue, 17 Mar 1998 19:27:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11506 for ; Tue, 17 Mar 1998 19:30:11 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02090 for ; Tue, 17 Mar 1998 19:27:36 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 19:22:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01399 for ipp-outgoing; Tue, 17 Mar 1998 19:22:28 -0500 (EST) Message-Id: <3.0.1.32.19980317161636.00cef100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:16:36 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-applmib-mib-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org FYI, They keep coming in.. Carl-Uno -- >To: IETF-Announce:; >Cc: applmib@emi-summit.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-applmib-mib-07.txt >Date: Tue, 17 Mar 1998 07:56:24 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Application MIB Working Group of the IETF. > > Title : Application Management MIB > Author(s) : J. Saperia, C. Krupczak, R. Presuhn, C. Kalbfleisch > Filename : draft-ietf-applmib-mib-07.txt > Pages : 62 > Date : 16-Mar-98 > > This memo defines an experimental portion of the Management > Information Base (MIB) for use with network management protocols in > the Internet Community. In particular, it defines objects used for > the management of applications. This MIB complements the System > Application MIB, providing for the management of applications' common > attributes which could not typically be observed without the > cooperation of the software being managed. > >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-applmib-mib-07.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-applmib-mib-07.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-applmib-mib-07.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 17 20:00:45 1998 Delivery-Date: Tue, 17 Mar 1998 20:00:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA29145 for ; Tue, 17 Mar 1998 20:00:44 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11599 for ; Tue, 17 Mar 1998 20:03:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA02773 for ; Tue, 17 Mar 1998 20:00:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 19:56:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA02224 for ipp-outgoing; Tue, 17 Mar 1998 19:56:49 -0500 (EST) Message-Id: <3.0.1.32.19980317165100.009b0970@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:51:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - "IPP Job Openings" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, In last week's phone conference we discussed the need for additional volonteers to take on new tasks within the WG. In particular, we are looking to fill the following vacancies: 1) Somebody to take over the secretary job for the PWG IPP phone conferences, as Don Wright has said that he has too many other commitments to keep up this task. Means that you need to regularly attend the phone conferences. 2) A champion and preferably editor (sounds better than the earlier WHIP title) for the IPP Notification task. 3) A champion and preferably editor for a new IPP MIB task. 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Please respond to the DL or to me personally, new faces are obviously welcome. If we cannot find people prepared to take on these tasks, we are in trouble! (Curious to see if this goes through the spam filters) Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 17 21:04:36 1998 Delivery-Date: Tue, 17 Mar 1998 21:04:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA01146 for ; Tue, 17 Mar 1998 21:04:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA11743 for ; Tue, 17 Mar 1998 21:07:06 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA03879 for ; Tue, 17 Mar 1998 21:04:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 17 Mar 1998 21:00:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03355 for ipp-outgoing; Tue, 17 Mar 1998 21:00:01 -0500 (EST) Message-Id: <3.0.1.32.19980317175827.010a5a30@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 17:58:27 PST To: Robert Herriot , Carl Kugler From: Tom Hastings Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Cc: In-Reply-To: <199803070031.QAA18149@woden.eng.sun.com> References: <5030100018210342000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id VAA01146 I disagree that we should get rid of one of the implementor choices for the 'type4 keyword | name' syntaxes of several attributes that administrators are likely to define additional values, such as "media", "job-hold-until", and "job-sheets", so maybe we need to clarify the Model document. I agree that the difference between a name and a keyword, is that the name is not localized by the client, while a keyword should be. If the client doesn't find the keyword in its table of keywords to localized names, then the client just displays the keyword as is (and hopes that the user understands English, which is widely understood). I also agree that initially, administrators will defines new values as names, not keywords, since there currently isn't a way for clients to discover new localized names for keywords that the client was not built with. On the other hand, we need to specify a way in the future for a client to discover localized names for keywords in the server that that client doesn't have a localized name for. When such a discovery mechanism is provided, then an IPP object could even support an ambituous multi-lingual administrator to be able to define new keyword values and several localized names in different languages that the client could query. So having attributes specified as 'type4 keyword | name' allows for this future possibility. But it would help to clarify that until an IPP object supports querying the name of a keyword in a specified human language, the implementors SHOULD support allowing administrators to add new attribute values by defining additional names, not keywords, to the IPP object. Tom At 16:34 03/06/1998 PST, Robert Herriot wrote: >I agree with you that there is some confusion here, particularly where the >document says "An administrator MAY define additional values using the >'name' or 'keyword' attribute syntax, depending on implementation." [ line >2248, section 4.2.3]. > >Our intent was to allow an administrator to add new values locally. I have >always assumed that a GUI would convert the standard keywords into some >localized word or phrase, but that a GUI would display values created by an >administrator as is (to keep things simple). Attributes that allow new >administator values need to distinguish between those values that should be >converted and those that should not. > >But the statement in the model document leaves me confused because it says >that an administrator can call a new value a keyword or a name, and that >some implementation may not support both ways. This makes me think that one >of these choices needs to be removed from the standard. The solution should >be one of the two below. > > o We eliminate the concept of type 4 keywords, and let "name" be the way > administrators make extensions. We should encourage GUIs to localize > keywords and display names as is. All attributes whose values are type 4 > keywords currently have "name" as an alternate type. So we change >their > > type to "type 3 keyword | name" > > o We eliminate "name" from the attributes that are "type 4 keyword | > name" and let a language be associated with keywords. We encourage GUIs >to > leave keywords as is if they aren't in the localization table. > >I like the first option best. It still leaves two data types for some >attributes, but it is better than allowing a language with keywords when >most have no language associated with them. > > >Bob Herriot > >At 01:46 PM 3/5/98 , Carl Kugler wrote: >>Tom- >> >>> Why are there attributes that have both 'type4 keyword' and 'name' >>> (and hence 'nameWithLanguage) data types? >> >>I think that this is a new, different question, and a good one.  Aren't these >>the only attributes for which a multi-valued attribute instance may have a >>mixture of its defined attribute syntaxes? >> >>If true, collapsing the redundant '(type4 keyword | name)' to 'name', would >>allow one attribute syntax tag to apply to a whole attribute, even a >>multi-valued one. It would also make life easier for implementers trying to >use >>strong typing. >> >>  -Carl >> >> >> >>hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM >>Please respond to hastings@cp10.es.xerox.com @ internet >>To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus >>cc: >>Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo >> >> >>At 14:06 02/02/1998 PST, Carl Kugler wrote: >>>Attributes with type 4 keywords also allow the 'name' attribute syntax for >>>administrator defined names.  Keywords SHALL be in U.S. English, but >>attributes >>>that are indicated to have the 'name' attribute syntax also automatically >>have >>>the 'nameWithLanguage' attribute syntax. >>> >>>So in general, attributes with type 4 keywords can use the Language Override >>>Mechanism? >> >>Correct, but because the 13 attributes that have 'type 4 keyword' data type, >>also have the 'name' data type: >> >>  +-------------------+----------------------+----------------------+ >>  | job-hold-until    | job-hold-until-      |job-hold-until-       | >>  | (type4 keyword |  |  default             | supported            | >>  |    name)          |  (type4 keyword |    |(1setOf               | >>  |                   |    name)             | type4 keyword | name)| >>  +-------------------+----------------------+----------------------+ >>  | job-sheets        | job-sheets-default   |job-sheets-supported  | >>  | (type4 keyword |  | (type4 keyword |     |(1setOf               | >>  |    name)          |    name)             | type4 keyword | name)| >>  +-------------------+----------------------+----------------------+ >> >>  +-------------------+----------------------+----------------------+ >>  | media             | media-default        | media-supported      | >>  | (type4 keyword |  | (type4 keyword |     |(1setOf               | >>  |    name)          |    name)             | type4 keyword | name)| >>  |                   |                      |                      | >>  |                   |                      | media-ready          | >>  |                   |                      |(1setOf               | >>  |                   |                      | type4 keyword | name)| >>  +-------------------+----------------------+----------------------+ >> >>not just because they have the 'type 4 keyword' data type.  But we >>thought that if an administrator is making up names (which is what >>type 4 keywords are), that an implementation may want to be simple >>and treat them as names in the language that the administrator is >>using or may want to be more complex and allow the administrator to >>define keywords that clients can localize into various languages. >> >>Sounds like something for the FAQ: >> >>Why are there attributes that have both 'type4 keyword' and 'name' >>(and hence 'nameWithLanguage) data types? >> >>Tom >> >>> >>>  -Carl >>> >>> >> > > > From adm Wed Mar 18 07:56:28 1998 Delivery-Date: Wed, 18 Mar 1998 08:02:30 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id HAA23623 for ietf-123-outbound.10@ietf.org; Wed, 18 Mar 1998 07:55:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA23209; Wed, 18 Mar 1998 07:35:09 -0500 (EST) Message-Id: <199803181235.HAA23209@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ippm@ADVANCED.ORG From: The IESG Subject: Document Action: Framework for IP Performance Metrics to Informational Date: Wed, 18 Mar 1998 07:35:09 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Framework for IP Performance Metrics' as an Informational RFC. This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allyn Romanow and Scott Bradner. From ipp-owner@pwg.org Wed Mar 18 09:22:07 1998 Delivery-Date: Wed, 18 Mar 1998 09:22:07 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26235 for ; Wed, 18 Mar 1998 09:22:06 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA13221 for ; Wed, 18 Mar 1998 09:24:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA16030 for ; Wed, 18 Mar 1998 09:22:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 09:13:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA15475 for ipp-outgoing; Wed, 18 Mar 1998 09:12:59 -0500 (EST) Message-Id: <350FD595.ABBDCE2@dazel.com> Date: Wed, 18 Mar 1998 08:09:25 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Subject: IPP> [Fwd: I-D ACTION:draft-day-envy-00.txt] Content-Type: multipart/mixed; boundary="------------0E3CD8909EEE3C45E31A750C" Sender: ipp-owner@pwg.org This is a multi-part message in MIME format. --------------0E3CD8909EEE3C45E31A750C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As long as others are forwarding IETF announcements ;-)... Here is yet another view on using HTTP for another protocol (presence information, in this case). And, yes, this one is a negative view of HTTP as a general protocol carrier, for some of the same reasons that we have heard from others. One thing is obvious about this whole subject... people seem to be strongly on one side of the fence or the other. enjoy... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX --------------0E3CD8909EEE3C45E31A750C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from support.dazel.com by dazel.com (4.1/SMI-4.1) id AA16550; Tue, 17 Mar 98 12:42:15 CST Received: from ns.ietf.org by support.dazel.com (8.8.7/dazel) id MAA04200 for ; Tue, 17 Mar 1998 12:42:10 -0600 (CST) Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA11289 for ietf-123-outbound.02@ietf.org; Tue, 17 Mar 1998 13:05:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02444 for ; Tue, 17 Mar 1998 10:15:41 -0500 (EST) Message-Id: <199803171515.KAA02444@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ns.ietf.org From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-day-envy-00.txt Date: Tue, 17 Mar 1998 10:15:41 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ''HTTP Envy'' and Presence Information Protocols Author(s) : M. Day Filename : draft-day-envy-00.txt Pages : 3 Date : 16-Mar-98 There are a variety of proposals [Calsyn, Mohr] for building a presence information protocol as a variant or version of HTTP. This document summarizes why I believe that is not a good idea. 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-day-envy-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-day-envy-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-day-envy-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980316143229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-day-envy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-day-envy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316143229.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------0E3CD8909EEE3C45E31A750C-- From ipp-owner@pwg.org Wed Mar 18 13:20:29 1998 Delivery-Date: Wed, 18 Mar 1998 13:20:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07631 for ; Wed, 18 Mar 1998 13:20:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14369 for ; Wed, 18 Mar 1998 13:22:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17274 for ; Wed, 18 Mar 1998 13:20:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 13:13:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16367 for ipp-outgoing; Wed, 18 Mar 1998 13:13:15 -0500 (EST) Message-ID: <35100DC9.321E5501@underscore.com> Date: Wed, 18 Mar 1998 13:09:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org, upd@pwg.org Subject: IPP> ADM - Concerns regarding the scopes of the IPP and UPD projects References: <3.0.1.32.19980317165100.009b0970@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Carl-Uno, In your message titled "ADM - 'IPP Job Openings'" (attached below) you listed this item: 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Seems we keep crossing on this particular path, namely, whether the IPP project (of which the IETF IPP WG is part of that project) is supposed to take on the requirements for a true host-to-device protocol. I have stated many, many times in the past that the IPP project should NOT attempt to address the "host-to-device" protocol issue. Instead, the UPD project was formed (by me, back in May '97) for *expressly* this kind of work. IPP is for printing over the Internet. UPD addresses the more critical needs of the intranet, with requirements that far surpass those of the IPP. Let's let UPD take its own course, without placing unnecessary constraints on it from the outstart. Comments from others? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Carl-Uno Manros wrote: > > All, > > In last week's phone conference we discussed the need for additional > volonteers to take on new tasks within the WG. > > In particular, we are looking to fill the following vacancies: > > 1) Somebody to take over the secretary job for the PWG IPP phone > conferences, as Don Wright has said that he has too many other commitments > to keep up this task. Means that you need to regularly attend the phone > conferences. > > 2) A champion and preferably editor (sounds better than the earlier WHIP > title) for the IPP Notification task. > > 3) A champion and preferably editor for a new IPP MIB task. > > 4) A champion for the host-to-device task (this is currently outside the > scope of the IETF WG). > > Please respond to the DL or to me personally, new faces are obviously welcome. > > If we cannot find people prepared to take on these tasks, we are in trouble! > > (Curious to see if this goes through the spam filters) > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Mar 18 13:32:47 1998 Delivery-Date: Wed, 18 Mar 1998 13:32:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA07872 for ; Wed, 18 Mar 1998 13:32:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14456 for ; Wed, 18 Mar 1998 13:35:17 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18256 for ; Wed, 18 Mar 1998 13:32:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 13:27:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17563 for ipp-outgoing; Wed, 18 Mar 1998 13:27:07 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'upd@pwg.org'" Subject: RE: IPP> ADM - Concerns regarding the scopes of the IPP and UPD p rojects Date: Wed, 18 Mar 1998 10:27:03 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org I thought the UPD study group was formed to talk about print drivers (extending the concept of the GPD concept to the next evel, etc..), and not a host-to-device protocol. I don't recall wire protocols ever brought up in the last couple of meetings. If there is both an application model (GPD, etc) and a wire protocol developed, I would hope there would be two study groups involved, since the expertise on either topic is largely orthogonal. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, March 18, 1998 10:09 AM To: Carl-Uno Manros Cc: ipp@pwg.org; upd@pwg.org Subject: IPP> ADM - Concerns regarding the scopes of the IPP and UPD projects Carl-Uno, In your message titled "ADM - 'IPP Job Openings'" (attached below) you listed this item: 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Seems we keep crossing on this particular path, namely, whether the IPP project (of which the IETF IPP WG is part of that project) is supposed to take on the requirements for a true host-to-device protocol. I have stated many, many times in the past that the IPP project should NOT attempt to address the "host-to-device" protocol issue. Instead, the UPD project was formed (by me, back in May '97) for *expressly* this kind of work. IPP is for printing over the Internet. UPD addresses the more critical needs of the intranet, with requirements that far surpass those of the IPP. Let's let UPD take its own course, without placing unnecessary constraints on it from the outstart. Comments from others? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Carl-Uno Manros wrote: > > All, > > In last week's phone conference we discussed the need for additional > volonteers to take on new tasks within the WG. > > In particular, we are looking to fill the following vacancies: > > 1) Somebody to take over the secretary job for the PWG IPP phone > conferences, as Don Wright has said that he has too many other commitments > to keep up this task. Means that you need to regularly attend the phone > conferences. > > 2) A champion and preferably editor (sounds better than the earlier WHIP > title) for the IPP Notification task. > > 3) A champion and preferably editor for a new IPP MIB task. > > 4) A champion for the host-to-device task (this is currently outside the > scope of the IETF WG). > > Please respond to the DL or to me personally, new faces are obviously welcome. > > If we cannot find people prepared to take on these tasks, we are in trouble! > > (Curious to see if this goes through the spam filters) > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Mar 18 13:51:39 1998 Delivery-Date: Wed, 18 Mar 1998 13:51:40 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA08137 for ; Wed, 18 Mar 1998 13:51:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14575 for ; Wed, 18 Mar 1998 13:54:09 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18934 for ; Wed, 18 Mar 1998 13:51:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 13:46:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18399 for ipp-outgoing; Wed, 18 Mar 1998 13:46:14 -0500 (EST) From: don@lexmark.com Message-Id: <199803181846.AA27930@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com, jkm@underscore.com Cc: Ipp@pwg.org, Upd@pwg.org Date: Wed, 18 Mar 1998 13:45:26 -0500 Subject: IPP> Concerns regarding the scopes of the IPP and UPD projects Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Randy's right on this matter. In fact at the UPD meeting and in the UPD minutes we explicitly excluded protocols from the discussion. The UPD effort is focused generally on generating print PDL not on the means by which it is delivered to the printer. As everyone expects, I don't see the need to create a host-to-printer protocol. I will be posting a draft on using TIP/SI to deliver IPP content from the server (acting as an IPP printer) to the marking device in the next day or so. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Mar 18 17:11:24 1998 Delivery-Date: Wed, 18 Mar 1998 17:11:24 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA19666 for ; Wed, 18 Mar 1998 17:11:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15532 for ; Wed, 18 Mar 1998 17:13:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA20415 for ; Wed, 18 Mar 1998 17:11:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 17:06:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA19870 for ipp-outgoing; Wed, 18 Mar 1998 17:06:19 -0500 (EST) Message-Id: <3.0.1.32.19980318140018.00ccde70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 18 Mar 1998 14:00:18 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 980318 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference 980318 ============================================ Notes taken by Lee Farrell Attendees: Ron Bergman Dataproducts Lee Farrell Canon Information Systems Tom Hastings Xerox Daniel Manchala Xerox Carl-Uno Manros Xerox Larry Masinter Xerox Ira Mcdonald High North Randy Turner Sharp Don Wright Lexmark Steve Zilles Adobe Carl-Uno Manros led the meeting. For today's agenda topic, he said that he would like to review some of the new Internet-Drafts from other IETF Working Groups that might impact the implementation of IPP. We should decide if we need to comment on some of these drafts in the IETF LA meeting. He also hoped to have discussion about the IPP test suite, but Peter Zehler did not join the teleconference. Harlequin has announced that they be showing a preliminary IPP server for their ScriptWorks product at Seybold this week. If somebody is visiting Seybold in NY this week, please give feedback in next week's phone conference. We still have no feedback from IESG. As far as Carl-Uno can tell, Keith Moore (IETF Area Director) is still reading the documents and thinking about comments. Because the IESG is not meeting again until after the LA IETF meeting, we might not have any official statement on the status of the documents at the LA meeting, but we might get some preliminary feedback in time for LA. The group then discussed comments on any of the Internet-Drafts that have recently surfaced? HTTP - draft-ietf-http-v11-spec-rev-03.txt: Page 144-146 list the updates to the HTTP/1.1 document RFC 2068. It didn't seem that anyone had read the document - or at least no one had comments on it. Steve Zilles said that the HTTP Working Group is not planning to have any more meetings, but they are not yet complete with their interoperability testing. draft-ietf-http-ext-mandatory-00.txt: Another document that Carl-Uno discovered is called "Mandatory Extensions to HTTP" lists some additions to HTTP/1.1. Should this be called HTTP/1.2? Carl-Uno will investigate this apparent oxymoron. It appears that the document discusses methods for extending HTTP (similar to PEP-Protocol Extension Protocol.) Carl-Uno believes that the document is not relevant to IPP. Larry Masinter explained that there will be a separate Working Group formed to address HTTP extensions. The document will be updated as part of the new Working Group activity. draft-ietf-http-authentication-01.txt: This is an update of RFC 2069, and only a few minor elements have changed. Daniel does not believe that the changes are significant enough to affect IPP activity. A few changes have been made to the Digest authentication scheme. Daniel will examine this further to see what changes to an implementation are necessary. TLS - draft-ietf-tls-https-01.txt: This is the TLS profile for HTTP 1.1. Can we apply this for IPP as is? It is much more detailed than the two-page reference to TLS currently in the IPP documents. Daniel described the method proposed for upgrading from an "insecure" to a secure HTTP connection. He says there are still doubts about the degree of security it really offers-especially with regard to "man in the middle" attacks. According to Daniel, the document is only 70% complete, and further testing is still required. The group will need to watch this document as it progresses, and evaluate its (potential) impact on IPP. Daniel also called attention to a document named "Upgrading to TLS within HTTP", which is not yet out as an I-D, suggests a solution how TLS can be combined with applications, such as HTTP, to share the same port number. This is in response to requirements from Keith Moore in the previous IETF meeting. It is complementary to the HTTP over TLS document. CONNEG - draft-ietf-conneg-media-features-00.txt: This document is from the newly formed CONNEG (Content Negotiation) Working Group and partly overlaps with IPP. Carl-Uno wants to make sure that this document does not conflict with the IPP printing model and features. According to Carl-Uno, it is more aligned with the Printer MIB than with IPP. Larry Masinter says that this is more due to historical reasons rather than anything else. Larry suggests that the IPP group review the document and submit any proposed changes-especially for the printer section. Why is there only a single token for media type? Is this sufficient? This issue will be raised at the next IPP meeting. draft-ietf-conneg-feature-reg-00.txt: Carl-Uno wants the group to consider if we should adopt the registration methods proposed in this document. Are they appropriate for IPP? Larry Masinter mentioned that there is a CONNEG document describing an algebra for specifying combinations of features. This algebra might be useful for consideration in a future version of IPP. The algerbra seems to allow for combinations, which makes the question about single token for media type redundant. MIB - A couple of new MIB drafts for Events and Applications were mentioned. It was suggested to look further at those drafts in the work on IPP Notifications. HTTP Envy - One Internet-Draft titled "HTTP Envy" has been submitted that suggests that people should not be using HTTP for protocols. However, there are no alternatives suggested in the document. Carl-Uno says that the document might be an interesting read, but he does not think it contains anything new that should cause us to change our decision to use HTTP for IPP. Server Location - draft-ietf-svrloc-printer-scheme-02.txt: SLP is being promoted by the IESG as the "correct" method for locating services. According to Ira, they feel that LDAP is too heavyweight. Scott Isaacson, Randy Turner and Ira McDonald reviewed the SLP draft with the editor (P. St. Pierre), and the document has been updated to incorporate many of the comments that are relevant to the IPP Working Group requirements. Meeting adjourned at 12:00 noon. The next teleconference will be held on March 25 at 10:00am PST. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Mar 18 17:55:07 1998 Delivery-Date: Wed, 18 Mar 1998 17:55:08 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA20903 for ; Wed, 18 Mar 1998 17:55:07 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15689 for ; Wed, 18 Mar 1998 17:57:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA21089 for ; Wed, 18 Mar 1998 17:55:07 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 17:51:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20580 for ipp-outgoing; Wed, 18 Mar 1998 17:51:06 -0500 (EST) From: don@lexmark.com Message-Id: <199803182250.AA12953@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 18 Mar 1998 17:49:42 -0500 Subject: IPP> IPP over TIPSI Mapping Proposal Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA20903 I have posted a PWG-DRAFT to the ftp server in PDF and PostScript format. The URLs are: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-pwg-ipp-tipsi-mapping-01.pdf ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-pwg-ipp-tipsi-mapping-01.ps This is NOT an IETF draft and therefore I have chosen NOT to limit my content and writing style to that which can be conveyed in 72 column lines with monospaced Courier font. The .PS file is formated for an Apple LaserWriter and should therefore print on almost any PostScript printer. If you can't read .PDF or print .PS then I am sorry, but I don't have time to make everything "TEXT-ONLY PRETTY." Here's the introduction which explains what the document is and what I'm attempting to communication: ------------------------- The Internet Printing Protocol (IPP) is an application level protocol that can provide distributed printing using Internet tools and technologies. IPP version 1.0 (IPP/1.0) focuses only on end user functionality. Anyone reading this document for the first time is strongly encouraged to read the IPP document set. The IPP V1.0 model describes a print environment with only an IPP Client and an IPP Printer. It is important, however, to understand that in many real system implementations (which lie underneath the abstracted model), there are other components of a print service which are not explicitly defined in the IPP/1.0 model. The following figure illustrates where IPP/1.0 fits with respect to these other components. Note that in the figure, the communications means between the IPP Printer?s Print Service and the actual output device is undefined. In some implementations, it is expected that the IPP Server, the Print Service, and the output device will be contained in one physical entity in which case the communications means among them is unimportant. In what is expected to be a common implementation, the IPP Server and the IPP Print Service are implemented on a general purpose computing platform and the output device is a separate device which marks on the media. In this case, there are many advantages to a standard communications means or protocol to be defined. IEEE Standard 1284.1-1997 defines a robust, general purpose protocol for communications between a "system" and a "printer." This document will describe the application of IEEE Std. 1284.1-1997 to the IPP environment. --------------------- Comments welcome! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Mar 18 18:40:47 1998 Delivery-Date: Wed, 18 Mar 1998 18:40:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA21763 for ; Wed, 18 Mar 1998 18:40:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15882 for ; Wed, 18 Mar 1998 18:43:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21838 for ; Wed, 18 Mar 1998 18:40:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 18:36:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA21298 for ipp-outgoing; Wed, 18 Mar 1998 18:36:14 -0500 (EST) Message-Id: <199803182334.PAA01641@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 18 Mar 1998 15:38:05 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Tom and I discussed this issue and I agreed to write it up. Summary In the model document, all attributes whose values include "type 4 keyword"s are actually "type 4 keyword | name". Name and type 4 provide two nearly identical mechanisms that will burden IPP implementations and confuse administrators. I propose that we drop type 4 keywords and state that the "name" provides the sole mechanism for an administrator to add new values. If we want to support multiple languages for administrator created names, we can allow name values to stand for a collection of names, each in a different language. But this is not a protocol issue -- it is a server implementation and administrator issue. It becomes a hint to implementors and does not change the protocol. Details The current model document has four levels of keywords from type1 to type 4. We intended that type 4 keywords would be created locally by administrators, and that type 1 through type 3 would be registered with IANA making them publicly known. We intended that a client would map a keyword to some human-readable localized string. For type1 through type 3, the mapping can be canned because the keywords are all known at implementation time. Mapping of type 4 keywords require some ADDITIONAL mapping mechanism that an administrator can configure and clients can download. This idea was proposed in ISO DPA and then removed from DPA. It has never been completed or implemented. I don't think any of us really wants to implement this mechanism. We intended that a client would display a name as is. So a client doesn't have to do anything special when an administor adds a new name. Currently we think of a name as existing in a single language on the server. From the clients standpoint name and text values have a single language associated with them. But from an administrative and server standpoint, we could allow a name value to stand for a collection of name values each in a different language. When a client requests and attributes with a name value, the client would receive the name in the language requested or, if not available, the one in the server's configured language. The same rule could apply to text. For IPP version 1.0, we don't have to deal with the server end of this. All we have to say is that attributes whose values are of "type 4 keyword | name" become "type 3 keyword | name" and we abolish "type 3 keywords". We show indicate that the "name" exists for administrator to add values that are not supported by the implementation. Bob Herriot From ipp-owner@pwg.org Wed Mar 18 21:24:05 1998 Delivery-Date: Wed, 18 Mar 1998 21:24:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA24149 for ; Wed, 18 Mar 1998 21:24:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA16237 for ; Wed, 18 Mar 1998 21:26:37 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA23214 for ; Wed, 18 Mar 1998 21:24:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 18 Mar 1998 21:19:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA22676 for ipp-outgoing; Wed, 18 Mar 1998 21:19:35 -0500 (EST) Message-ID: <19980319021924.28425.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> Clarification: printer-uri, job-uri Content-Type: text/plain Date: Wed, 18 Mar 1998 18:19:24 PST Sender: ipp-owner@pwg.org Hi all, In the IPP Model document, there is no specification for the value-tags of "printer-uri" and "job-uri" in a IPP request. Should these 2 attriubtes have "name" or "uri" value tag? The response may contain a "job-uri" in the Job Object Attributes group (15.3.4.3), and this "job-uri" is defined to have "uri" value-tag (4.3), but can the "job-uri" in a request be the same as that in a response or should they be the same? The second point that needs clarification is that in the "Note:" section of 3.2.1.1 in the IPP Model document, it was mentioned that "The simplest Print-Job Request consists of just the Document Content, the "attributes- charset" and "attributes-natural-language" operation attributes, and nothing else." However, in the description of Print-Job Request of section 15.3.4.3, the "printer-uri" attribute is specified as a MUST (indicated by (M)). Which rule takes precedence here? -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Thu Mar 19 11:38:43 1998 Delivery-Date: Thu, 19 Mar 1998 11:38:43 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA20120 for ; Thu, 19 Mar 1998 11:38:42 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18449 for ; Thu, 19 Mar 1998 11:41:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06232 for ; Thu, 19 Mar 1998 11:38:42 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Mar 1998 11:26:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05682 for ipp-outgoing; Thu, 19 Mar 1998 11:26:08 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP>MOD Suggest dropping type 4 keyword to simplify impl Message-ID: <5030100018711512000002L022*@MHS> Date: Thu, 19 Mar 1998 11:25:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA20120 I don't understand this sentence: > All > we have to say is that attributes whose values are of "type 4 keyword | > name" become "type 3 keyword | name" and we abolish "type 3 keywords". -Carl ipp-owner@pwg.org on 03/18/98 04:38:55 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen Tom and I discussed this issue and I agreed to write it up. Summary In the model document, all attributes whose values include "type 4 keyword"s are actually "type 4 keyword | name". Name and type 4 provide two nearly identical mechanisms that will burden IPP implementations and confuse administrators. I propose that we drop type 4 keywords and state that the "name" provides the sole mechanism for an administrator to add new values. If we want to support multiple languages for administrator created names, we can allow name values to stand for a collection of names, each in a different language. But this is not a protocol issue -- it is a server implementation and administrator issue. It becomes a hint to implementors and does not change the protocol. Details The current model document has four levels of keywords from type1 to type 4. We intended that type 4 keywords would be created locally by administrators, and that type 1 through type 3 would be registered with IANA making them publicly known. We intended that a client would map a keyword to some human-readable localized string. For type1 through type 3, the mapping can be canned because the keywords are all known at implementation time. Mapping of type 4 keywords require some ADDITIONAL mapping mechanism that an administrator can configure and clients can download. This idea was proposed in ISO DPA and then removed from DPA. It has never been completed or implemented. I don't think any of us really wants to implement this mechanism. We intended that a client would display a name as is. So a client doesn't have to do anything special when an administor adds a new name. Currently we think of a name as existing in a single language on the server. From the clients standpoint name and text values have a single language associated with them. But from an administrative and server standpoint, we could allow a name value to stand for a collection of name values each in a different language. When a client requests and attributes with a name value, the client would receive the name in the language requested or, if not available, the one in the server's configured language. The same rule could apply to text. For IPP version 1.0, we don't have to deal with the server end of this. All we have to say is that attributes whose values are of "type 4 keyword | name" become "type 3 keyword | name" and we abolish "type 3 keywords". We show indicate that the "name" exists for administrator to add values that are not supported by the implementation. Bob Herriot From ipp-owner@pwg.org Thu Mar 19 15:30:00 1998 Delivery-Date: Thu, 19 Mar 1998 15:30:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA09822 for ; Thu, 19 Mar 1998 15:30:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19752 for ; Thu, 19 Mar 1998 15:32:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA10450 for ; Thu, 19 Mar 1998 15:29:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 19 Mar 1998 15:25:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09928 for ipp-outgoing; Thu, 19 Mar 1998 15:25:17 -0500 (EST) Message-Id: <199803192022.MAA02483@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Mar 1998 12:26:33 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD Suggest dropping type 4 keyword to simplify impl In-Reply-To: <5030100018711512000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA09822 I made a typo. Change the last 3 to a 4. This sentence was repeating what I had said in the second paragraph correctly. The corrected sentence is. All we have to say is that attributes whose values are of  "type 4 keyword | name" become  "type 3 keyword | name" and we abolish "type 4 keywords". At 08:25 AM 3/19/98 , Carl Kugler wrote: >I don't understand this sentence: > >> All >> we have to say is that attributes whose values are of  "type 4 keyword | >> name" become  "type 3 keyword | name" and we abolish "type 3 keywords". > >  -Carl > > > > >ipp-owner@pwg.org on 03/18/98 04:38:55 PM >Please respond to ipp-owner@pwg.org @ internet >To: ipp@pwg.org @ internet >cc: >Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen > > >Tom and I discussed this issue and I agreed to write it up. > >Summary > >In the model document, all attributes whose values include "type 4 keyword"s >are actually "type 4 keyword | name".  Name and type 4 provide two nearly >identical mechanisms that will burden IPP implementations and confuse >administrators. > >I propose that we drop type 4 keywords and state that the "name"  provides >the sole mechanism for an administrator to add new values.  If we want to >support multiple languages for administrator created names, we can allow >name values to stand for a collection of names, each in a different >language. But this is not a protocol issue -- it is a server implementation >and administrator issue.  It becomes a hint to implementors and does not >change the protocol. > >Details > >The current model document has four levels of keywords from type1 to type 4. > We intended that type 4 keywords would be created locally by >administrators, and that type 1 through type 3 would be registered with IANA >making them publicly known. > >We intended that a client would map a keyword to some human-readable >localized string.  For type1 through type 3, the mapping can be canned >because the keywords are all known at implementation time.  Mapping of type >4 keywords require some ADDITIONAL mapping mechanism that an administrator >can configure and clients can download. This idea was proposed in ISO DPA >and then removed from DPA. It has never been completed or implemented. I >don't think any of us really wants to implement this mechanism. > >We intended that a client would display a name as is.  So a client doesn't >have to do anything special when an administor adds a new name. Currently we >think of a name as existing in a single language on the server.  From the >clients standpoint name and text values have a single language associated >with them.  But from an administrative and server standpoint, we could allow >a name value to stand for a collection of name values each in a different >language.  When a client requests and attributes with a name value, the >client would receive the name in the language requested or, if not >available, the one in the server's configured language. The same rule could >apply to text. > >For IPP version 1.0, we don't have to deal with the server end of this. All >we have to say is that attributes whose values are of  "type 4 keyword | >name" become  "type 3 keyword | name" and we abolish "type 3 keywords".  We >show indicate that the "name" exists for administrator to add values that >are not supported by the implementation. > >Bob Herriot > From ipp-owner@pwg.org Fri Mar 20 21:08:51 1998 Delivery-Date: Fri, 20 Mar 1998 21:08:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA07830 for ; Fri, 20 Mar 1998 21:08:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA25527 for ; Fri, 20 Mar 1998 21:11:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA25198 for ; Fri, 20 Mar 1998 21:08:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Mar 1998 21:00:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24661 for ipp-outgoing; Fri, 20 Mar 1998 21:00:42 -0500 (EST) Message-Id: <199803210158.RAA03881@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Mar 1998 18:02:24 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From ipp-owner@pwg.org Sat Mar 21 18:28:16 1998 Delivery-Date: Sat, 21 Mar 1998 18:28:17 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA00771 for ; Sat, 21 Mar 1998 18:28:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA27283 for ; Sat, 21 Mar 1998 18:30:47 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA06646 for ; Sat, 21 Mar 1998 18:28:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 21 Mar 1998 18:19:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06101 for ipp-outgoing; Sat, 21 Mar 1998 18:19:21 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP>MOD: Problem in IPP encoding with "attributes-charset" Date: Sat, 21 Mar 1998 15:19:16 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I believe we have found some other hidden dependencies that are similar to this, but we just reorder the logic of our attribute processing in order to "do the right thing". While doing in this in the protocol specification may help some implementations, it hasn't hindered our efforts too much. But then again our server is only a proof-of-concept implementation with limited capability. But even with our prototype, taking the attributes in a particular order hasn't been too difficult. If the WG agrees to make this change to the documents, I would have no problem with it. Randy -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Friday, March 20, 1998 6:02 PM To: ipp@pwg.org Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From ipp-owner@pwg.org Sun Mar 22 11:51:53 1998 Delivery-Date: Sun, 22 Mar 1998 11:51:53 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA09684 for ; Sun, 22 Mar 1998 11:51:52 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA00654 for ; Sun, 22 Mar 1998 11:54:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17889 for ; Sun, 22 Mar 1998 11:51:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 11:42:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17335 for ipp-outgoing; Sun, 22 Mar 1998 11:42:10 -0500 (EST) Date: Sun, 22 Mar 1998 08:47:45 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803221647.AA15780@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, robert.herriot@Eng.Sun.COM Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charset" Sender: ipp-owner@pwg.org Hi Bob, Yes, you're right that the charset and natural language attributes must appear first. That rule is near universal in modern protocols. Cheers, - Ira McDonald High North Inc ---------------------------------------------------------------------- >From ipp-owner@pwg.org Fri Mar 20 21:15:39 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA15628; Fri, 20 Mar 98 21:15:38 EST Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA10061; Fri, 20 Mar 98 21:09:42 EST Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52148(4)>; Fri, 20 Mar 1998 18:09:39 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA25039 for ; Fri, 20 Mar 1998 21:06:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Mar 1998 21:00:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24661 for ipp-outgoing; Fri, 20 Mar 1998 21:00:42 -0500 (EST) Message-Id: <199803210158.RAA03881@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Mar 1998 18:02:24 PST To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Status: R I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From jmp-owner@pwg.org Sun Mar 22 12:36:09 1998 Delivery-Date: Sun, 22 Mar 1998 12:36:10 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA10157 for ; Sun, 22 Mar 1998 12:36:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA00718 for ; Sun, 22 Mar 1998 12:38:41 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18519 for ; Sun, 22 Mar 1998 12:36:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 12:33:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17984 for jmp-outgoing; Sun, 22 Mar 1998 12:31:05 -0500 (EST) Date: Sun, 22 Mar 1998 09:36:47 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803221736.AA15842@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: JMP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Sender: jmp-owner@pwg.org Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From ipp-owner@pwg.org Sun Mar 22 12:37:51 1998 Delivery-Date: Sun, 22 Mar 1998 12:37:51 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA10170 for ; Sun, 22 Mar 1998 12:37:51 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA00721 for ; Sun, 22 Mar 1998 12:40:22 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18720 for ; Sun, 22 Mar 1998 12:37:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 12:31:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17976 for ipp-outgoing; Sun, 22 Mar 1998 12:30:58 -0500 (EST) Date: Sun, 22 Mar 1998 09:36:47 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803221736.AA15842@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Sender: ipp-owner@pwg.org Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From jmp-owner@pwg.org Sun Mar 22 18:01:22 1998 Delivery-Date: Sun, 22 Mar 1998 18:01:22 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13355 for ; Sun, 22 Mar 1998 18:01:21 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01246 for ; Sun, 22 Mar 1998 18:03:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA19474 for ; Sun, 22 Mar 1998 18:01:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 17:58:37 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18998 for jmp-outgoing; Sun, 22 Mar 1998 17:56:26 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: JMP> RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Date: Sun, 22 Mar 1998 14:56:06 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org There two questions that have yet to be answered. You've repeatedly stated that SNMPv3 is not intended for "very many notification clients". I would like to hear a technical analysis of why you think this is the case. Also, I think its VERY unrealistic that an embedded device will have to manage "several hundred" client notification requests. If every client can specify a totally different object set to be sent along with each notification, then I don't think this is realistic for embedded devices. If you have a defined trap/notification, with a specific list of objects that are returned, then a notification originator only has to keep track of transport domains and addresses, not every combination of object sets that "possibly hundreds of notification clients" might want to know about. I don't think SNMPv3 is heavyweight. It's designed be implemented in everything from $300 managed 100Mbit hubs, all the way to enterprise ATM switches. And I think whatever solution we come up with will have to have the capability to support a distributed event notification system, similar to the way SENSE and other distributed notification mechanisms remove the burden from individual embedded printers from having to keep up with the entire world of notifications. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 9:37 AM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From ipp-owner@pwg.org Sun Mar 22 18:03:58 1998 Delivery-Date: Sun, 22 Mar 1998 18:03:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA13391 for ; Sun, 22 Mar 1998 18:03:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01249 for ; Sun, 22 Mar 1998 18:06:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA19738 for ; Sun, 22 Mar 1998 18:03:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 17:56:39 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18990 for ipp-outgoing; Sun, 22 Mar 1998 17:56:20 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Date: Sun, 22 Mar 1998 14:56:06 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org There two questions that have yet to be answered. You've repeatedly stated that SNMPv3 is not intended for "very many notification clients". I would like to hear a technical analysis of why you think this is the case. Also, I think its VERY unrealistic that an embedded device will have to manage "several hundred" client notification requests. If every client can specify a totally different object set to be sent along with each notification, then I don't think this is realistic for embedded devices. If you have a defined trap/notification, with a specific list of objects that are returned, then a notification originator only has to keep track of transport domains and addresses, not every combination of object sets that "possibly hundreds of notification clients" might want to know about. I don't think SNMPv3 is heavyweight. It's designed be implemented in everything from $300 managed 100Mbit hubs, all the way to enterprise ATM switches. And I think whatever solution we come up with will have to have the capability to support a distributed event notification system, similar to the way SENSE and other distributed notification mechanisms remove the burden from individual embedded printers from having to keep up with the entire world of notifications. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 9:37 AM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From jmp-owner@pwg.org Sun Mar 22 19:36:29 1998 Delivery-Date: Sun, 22 Mar 1998 19:36:51 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14130 for ; Sun, 22 Mar 1998 19:36:28 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01364 for ; Sun, 22 Mar 1998 19:38:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20371 for ; Sun, 22 Mar 1998 19:36:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 19:33:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19865 for jmp-outgoing; Sun, 22 Mar 1998 19:31:32 -0500 (EST) Date: Sun, 22 Mar 1998 16:37:08 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803230037.AA15969@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: JMP> Re: SNMPv3 unsuited for IPP/JMP Notifications Sender: jmp-owner@pwg.org Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From ipp-owner@pwg.org Sun Mar 22 19:38:33 1998 Delivery-Date: Sun, 22 Mar 1998 19:38:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA14142 for ; Sun, 22 Mar 1998 19:38:33 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01367 for ; Sun, 22 Mar 1998 19:41:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20601 for ; Sun, 22 Mar 1998 19:38:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 19:31:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19857 for ipp-outgoing; Sun, 22 Mar 1998 19:31:25 -0500 (EST) Date: Sun, 22 Mar 1998 16:37:08 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803230037.AA15969@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Sender: ipp-owner@pwg.org Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From jmp-owner@pwg.org Sun Mar 22 20:11:38 1998 Delivery-Date: Sun, 22 Mar 1998 20:11:38 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14312 for ; Sun, 22 Mar 1998 20:11:37 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01411 for ; Sun, 22 Mar 1998 20:14:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA21183 for ; Sun, 22 Mar 1998 20:11:32 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 20:09:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20705 for jmp-outgoing; Sun, 22 Mar 1998 20:06:55 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org, jmp@pwg.org Subject: JMP> RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Date: Sun, 22 Mar 1998 17:04:26 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org Your scalability rationale essentially boils down to string indices, since not all SNMPv3 implementations have to implement security via shared secrets. I don't think this single rationale is enough to dismiss on a scalability question. All along we've been talking about how to scale things down enough to make things "simple, lightweight", including talk about a much lighter weight protocol for host-to-device communication, where a notification protocol might be used. For you to bring up the fact that Xerox and other vendors have up to 1 million dollar printers is an argument for many notifications, but doesn't make much sense in the context of our heretofore previous discussions. You even talk about "1 million dollar printers" and "VERY lightweight" in the same paragraph ;) ;) I will reiterate my belief that I don't think its realistic for a simple embedded device to maintain notification info for hundreds of clients. I don't think its in the notification requirements document...maybe we should talk about the number of notifications that an embedded device should minimally support? And include the outcome of that discussion in the requirements doc. Also, I used my managed device examples (small hub to enterprise switch) to illustrate low-cost to high-cost devices with very wide variances in burden cost for manufacturing (memory, power, cpu, etc.). Maybe what we are actually debating is semantics in how we define "lightweight" and "heavyweight" Does lightweight mean simple to build (overall)? Simple to code? Lightweight in terms of CPU cycles? Other? It sometimes sounds like we are defining terms differently. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 4:37 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From ipp-owner@pwg.org Sun Mar 22 20:13:25 1998 Delivery-Date: Sun, 22 Mar 1998 20:13:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA14331 for ; Sun, 22 Mar 1998 20:13:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01417 for ; Sun, 22 Mar 1998 20:15:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA21439 for ; Sun, 22 Mar 1998 20:13:18 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sun, 22 Mar 1998 20:07:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20697 for ipp-outgoing; Sun, 22 Mar 1998 20:06:48 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Date: Sun, 22 Mar 1998 17:04:26 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Your scalability rationale essentially boils down to string indices, since not all SNMPv3 implementations have to implement security via shared secrets. I don't think this single rationale is enough to dismiss on a scalability question. All along we've been talking about how to scale things down enough to make things "simple, lightweight", including talk about a much lighter weight protocol for host-to-device communication, where a notification protocol might be used. For you to bring up the fact that Xerox and other vendors have up to 1 million dollar printers is an argument for many notifications, but doesn't make much sense in the context of our heretofore previous discussions. You even talk about "1 million dollar printers" and "VERY lightweight" in the same paragraph ;) ;) I will reiterate my belief that I don't think its realistic for a simple embedded device to maintain notification info for hundreds of clients. I don't think its in the notification requirements document...maybe we should talk about the number of notifications that an embedded device should minimally support? And include the outcome of that discussion in the requirements doc. Also, I used my managed device examples (small hub to enterprise switch) to illustrate low-cost to high-cost devices with very wide variances in burden cost for manufacturing (memory, power, cpu, etc.). Maybe what we are actually debating is semantics in how we define "lightweight" and "heavyweight" Does lightweight mean simple to build (overall)? Simple to code? Lightweight in terms of CPU cycles? Other? It sometimes sounds like we are defining terms differently. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 4:37 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From jmp-owner@pwg.org Mon Mar 23 10:35:23 1998 Delivery-Date: Mon, 23 Mar 1998 10:35:23 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA07069 for ; Mon, 23 Mar 1998 10:35:22 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02870 for ; Mon, 23 Mar 1998 10:37:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA03684 for ; Mon, 23 Mar 1998 10:35:10 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 10:30:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02697 for jmp-outgoing; Mon, 23 Mar 1998 10:27:03 -0500 (EST) Message-ID: <35167F33.3D332CAF@underscore.com> Date: Mon, 23 Mar 1998 10:26:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients. I agree 110%. That fundamental belief is one of the most critical assumptions for which SENSE was designed. Namely, require the managed entity (ie, a printer) to provide minimal scalability for key services (ie, just a few simultaneous client accesses), then route that information into a generalized client/server system with a very high degree of scalability. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Mar 23 10:40:25 1998 Delivery-Date: Mon, 23 Mar 1998 10:40:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA07190 for ; Mon, 23 Mar 1998 10:40:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02902 for ; Mon, 23 Mar 1998 10:42:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04138 for ; Mon, 23 Mar 1998 10:40:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 10:27:56 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02721 for ipp-outgoing; Mon, 23 Mar 1998 10:27:17 -0500 (EST) Message-ID: <35167F33.3D332CAF@underscore.com> Date: Mon, 23 Mar 1998 10:26:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients. I agree 110%. That fundamental belief is one of the most critical assumptions for which SENSE was designed. Namely, require the managed entity (ie, a printer) to provide minimal scalability for key services (ie, just a few simultaneous client accesses), then route that information into a generalized client/server system with a very high degree of scalability. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Mar 23 10:40:41 1998 Delivery-Date: Mon, 23 Mar 1998 10:40:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA07195 for ; Mon, 23 Mar 1998 10:40:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02904 for ; Mon, 23 Mar 1998 10:42:58 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA04137 for ; Mon, 23 Mar 1998 10:40:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 10:23:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02527 for ipp-outgoing; Mon, 23 Mar 1998 10:23:12 -0500 (EST) Message-ID: <35167E4B.2EEBA340@underscore.com> Date: Mon, 23 Mar 1998 10:22:51 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Ira Mcdonald x10962 , Sense mailing list Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: <9803230037.AA15969@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org This is a *great* thread. Hopefully everyone is reading the exchanges between Randy and Ira so as to quickly come up to speed on the applicability (or not) of SNMPv3 to the network printer universe. One comment Ira wrote to Randy is particularly notable: > >I don't think SNMPv3 is heavyweight. It's designed be implemented in > >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM > >switches. And I think whatever solution we come up with will have to > >have the capability to support a distributed event notification system, > >similar to the way SENSE and other distributed notification mechanisms > >remove the burden from individual embedded printers from having to keep > >up with the entire world of notifications. > > IEM> But, your examples are all of infrastructure (intermediate-systems), > not printers, scanners, and other end-systems. Managing a hub or router > has essentially nothing in common with managing end-systems, except that > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be > widely deployed for at least the next three years - look at the deployment > track record of SNMPv2! In essence, all things are *not* necessarily equal under SNMP in terms of scale and functionality. I have been trying to get people in the PWG to understand this essential fact for years now. SNMP was designed for "network elements" (what Ira calls "infrastructure elements", another good name). That was the sole problem domain for which SNMP was designed. Can SNMP be used for other applications? Of course. Must we necessarily constrain our product designs around the limitations of SNMP? (That is, if SNMP can't do it, then either can/should we.) That's silly. Just because you can, doesn't mean you should... > No vendor can tell their customers that they can't manage their printers > until they deploy (largely non-existant) new enterprise open management > systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that > have support for SNMPv3 (some of those that I just mentioned don't have > support for SNMPv2, yet). Xerox research has found that many customers > HATE to be told that "this product just requires a few little server > applications." Elegant distributed event notification schemes like > SENSE are very unpopular with Xerox product planners and marketers > (and customers). Perhaps your customers haven't been bitten by unstable > NetWare NLMs or NT server applications? Amen, brother. We at Underscore constantly wrestle with the plain fact that customers ABHORE the need to install/maintain/operate additional components required to make your product work. That cold, hard fact became painfully obvious with our work on designing a product-oriented implementation of SENSE. For example, we needed a very, very lightweight directory service. No problem. How about LDAP? What about SLP? Hey, even NDS may be possible. And yet the continual problem we faced was: Which lightweight directory is ubiquitously available across all major server platforms today? The answer, of course, is: None. So we had to (quickly) design/implement the very, very lightweight directory service directly inside SENSE. It was no big deal, and we do not have any external dependencies that customers abhore. > [Jay, I personally think SENSE is good stuff - but technical excellence > isn't the only or even major factor in the deployment of technology.] Again, amen. I would never consider the current SENSE design as "technically excellent". That was NEVER the goal. The goals? Simple. Very lightweight. Eminently portable. Easy to use. Easy to understand. Easy to extend. Low resource requirements. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From jmp-owner@pwg.org Mon Mar 23 13:51:48 1998 Delivery-Date: Mon, 23 Mar 1998 13:51:49 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA21676 for ; Mon, 23 Mar 1998 13:51:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03753 for ; Mon, 23 Mar 1998 13:54:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA05532 for ; Mon, 23 Mar 1998 13:51:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 13:46:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04823 for jmp-outgoing; Mon, 23 Mar 1998 13:44:36 -0500 (EST) Message-Id: <3.0.1.32.19980323103827.009c1280@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 10:38:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: JMP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org All, We have had a rather intensive debate between Randy, who first proposed that we might want to use SNMPv3 traps or informs for IPP notifications, and Ira, who thinks that the whole idea is wrong. With the exception of Jay's comments earlier today, it has been very quiet from the rest of the group on this subject. Are there any other views on the subject? Do you support one or the other combattants' views? If all we will be hearing is arguments between mainly two people with diametrically opposite views, we are not going to archieve anything. We are supposed to discuss this next week in the IETF in LA and it would be nice to have a little better understanding of where the group stands in this debate by then. Should we abandon SNMPv3 as a candidate for IPP notifications and concentrate our efforts on a new or different solution? Please give more feedback to the DL. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Mon Mar 23 13:58:04 1998 Delivery-Date: Mon, 23 Mar 1998 13:58:05 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA21931 for ; Mon, 23 Mar 1998 13:58:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03790 for ; Mon, 23 Mar 1998 14:00:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06415 for ; Mon, 23 Mar 1998 13:57:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 13:53:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05172 for jmp-outgoing; Mon, 23 Mar 1998 13:48:24 -0500 (EST) From: Harry Lewis To: Cc: , , Subject: JMP> Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257914000002L042*@MHS> Date: Mon, 23 Mar 1998 13:54:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: jmp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA21931 I response to Ira' comment... > IEM> But, your examples are all of infrastructure (intermediate-systems), > not printers, scanners, and other end-systems. Managing a hub or router > has essentially nothing in common with managing end-systems, except that > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be > widely deployed for at least the next three years - look at the deployment We (PWG) crossed the "using SNMP to manage printers" question long ago. Some people have never been comfortable with it but no one can deny we did. To some degree, one can argue that every network element is part of it's infrastructure. That's pretty much how I believe we got where we are. I'm not saying it's right or wrong. I've just been trying to make good use of it rather than judge it or wish for something different. Also, I don't believe we can predict SNMPv3 rollout based on V2 lag. SNMPv2 had a goory history - so bad that many chose not to implement. I view SNMPv3 as the answer to the v2 problem, not a repeat of it. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Mar 23 13:59:14 1998 Delivery-Date: Mon, 23 Mar 1998 13:59:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA21988 for ; Mon, 23 Mar 1998 13:59:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03801 for ; Mon, 23 Mar 1998 14:01:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA06552 for ; Mon, 23 Mar 1998 13:59:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 13:45:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04831 for ipp-outgoing; Mon, 23 Mar 1998 13:44:43 -0500 (EST) Message-Id: <3.0.1.32.19980323103827.009c1280@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 10:38:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, We have had a rather intensive debate between Randy, who first proposed that we might want to use SNMPv3 traps or informs for IPP notifications, and Ira, who thinks that the whole idea is wrong. With the exception of Jay's comments earlier today, it has been very quiet from the rest of the group on this subject. Are there any other views on the subject? Do you support one or the other combattants' views? If all we will be hearing is arguments between mainly two people with diametrically opposite views, we are not going to archieve anything. We are supposed to discuss this next week in the IETF in LA and it would be nice to have a little better understanding of where the group stands in this debate by then. Should we abandon SNMPv3 as a candidate for IPP notifications and concentrate our efforts on a new or different solution? Please give more feedback to the DL. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 23 14:00:13 1998 Delivery-Date: Mon, 23 Mar 1998 14:00:13 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA22032 for ; Mon, 23 Mar 1998 14:00:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03805 for ; Mon, 23 Mar 1998 14:02:43 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA06683 for ; Mon, 23 Mar 1998 14:00:06 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 13:48:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05084 for ipp-outgoing; Mon, 23 Mar 1998 13:47:40 -0500 (EST) From: Harry Lewis To: Cc: , , Subject: Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257914000002L042*@MHS> Date: Mon, 23 Mar 1998 13:54:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA22032 I response to Ira' comment... > IEM> But, your examples are all of infrastructure (intermediate-systems), > not printers, scanners, and other end-systems. Managing a hub or router > has essentially nothing in common with managing end-systems, except that > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be > widely deployed for at least the next three years - look at the deployment We (PWG) crossed the "using SNMP to manage printers" question long ago. Some people have never been comfortable with it but no one can deny we did. To some degree, one can argue that every network element is part of it's infrastructure. That's pretty much how I believe we got where we are. I'm not saying it's right or wrong. I've just been trying to make good use of it rather than judge it or wish for something different. Also, I don't believe we can predict SNMPv3 rollout based on V2 lag. SNMPv2 had a goory history - so bad that many chose not to implement. I view SNMPv3 as the answer to the v2 problem, not a repeat of it. Harry Lewis - IBM Printing Systems From jmp-owner@pwg.org Mon Mar 23 14:15:48 1998 Delivery-Date: Mon, 23 Mar 1998 14:15:48 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA22740 for ; Mon, 23 Mar 1998 14:15:37 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03858 for ; Mon, 23 Mar 1998 14:18:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07430 for ; Mon, 23 Mar 1998 14:15:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 14:12:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06791 for jmp-outgoing; Mon, 23 Mar 1998 14:09:42 -0500 (EST) From: Harry Lewis To: Cc: , , , Subject: JMP> Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257048000002L082*@MHS> Date: Mon, 23 Mar 1998 14:15:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: jmp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA22740 I also agree... (its not realistic for a simple embedded device to maintain notification info for hundreds of clients). But, this does not mean that the embedded Device should never be able to handle notification to multiple clients. There may be more than one "notification server", or some smaller scale networks using peer-to-peer printing without a notification server. Yes, the embedded device will ultimately limit the number of notification hosts it can service, but (as I presented in Austin) I feel 16 - 32 is not unreasonable for many "network printers". Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 03/23/98 08:33:19 AM Please respond to owner-sense@pwg.org To: rturner@sharplabs.com cc: sense@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notification Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients From ipp-owner@pwg.org Mon Mar 23 14:18:05 1998 Delivery-Date: Mon, 23 Mar 1998 14:18:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA22812 for ; Mon, 23 Mar 1998 14:18:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA03870 for ; Mon, 23 Mar 1998 14:20:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07723 for ; Mon, 23 Mar 1998 14:17:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 14:10:14 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06806 for ipp-outgoing; Mon, 23 Mar 1998 14:09:56 -0500 (EST) From: Harry Lewis To: Cc: , , , Subject: Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257048000002L082*@MHS> Date: Mon, 23 Mar 1998 14:15:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA22812 I also agree... (its not realistic for a simple embedded device to maintain notification info for hundreds of clients). But, this does not mean that the embedded Device should never be able to handle notification to multiple clients. There may be more than one "notification server", or some smaller scale networks using peer-to-peer printing without a notification server. Yes, the embedded device will ultimately limit the number of notification hosts it can service, but (as I presented in Austin) I feel 16 - 32 is not unreasonable for many "network printers". Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 03/23/98 08:33:19 AM Please respond to owner-sense@pwg.org To: rturner@sharplabs.com cc: sense@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notification Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients From jmp-owner@pwg.org Mon Mar 23 14:48:41 1998 Delivery-Date: Mon, 23 Mar 1998 14:49:06 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA23839 for ; Mon, 23 Mar 1998 14:48:40 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04015 for ; Mon, 23 Mar 1998 14:51:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA08413 for ; Mon, 23 Mar 1998 14:48:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 14:45:28 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07827 for jmp-outgoing; Mon, 23 Mar 1998 14:43:14 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 11:42:56 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: jmp-owner@pwg.org Some time since I aired my views on this. I think we should make IPP notifications a mechanism whereby a client can request that a notification be sent to it via any mechanism. That is to say - the notification itself is sent any way you like and is not part of IPP. IPP merely provides the means for the client to request that this be done. We might want to define some standard optional mechanisms (email being the obvious one). All notifications are optional. The IPP Model also needs to define what events are notification candidates and what they mean. The IPP request indicates which events it wants notification on, what mechanism to use, any parameters associated with that mechanism (email address) and maybe message content. The mechanisms available should be something that is queryable (get printer attributes). There is a separate thing that deals with device level alerts and events - along with robust data transmission, etc. etc. My thoughts on that topic have already been aired! > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 10:38 AM > To: ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > All, > > We have had a rather intensive debate between Randy, who first > proposed that we might want to use SNMPv3 traps or informs for > IPP notifications, and Ira, who thinks that the whole idea is > wrong. > > With the exception of Jay's comments earlier today, it has been > very quiet from the rest of the group on this subject. Are there > any other views on the subject? Do you support one or the other > combattants' views? > > If all we will be hearing is arguments between mainly two people > with diametrically opposite views, we are not going to archieve > anything. > > We are supposed to discuss this next week in the IETF in LA and > it would be nice to have a little better understanding of where > the group stands in this debate by then. Should we abandon SNMPv3 > as a candidate for IPP notifications and concentrate our efforts > on a new or different solution? > > Please give more feedback to the DL. > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 23 14:51:12 1998 Delivery-Date: Mon, 23 Mar 1998 14:51:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA24009 for ; Mon, 23 Mar 1998 14:51:11 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04035 for ; Mon, 23 Mar 1998 14:53:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA08713 for ; Mon, 23 Mar 1998 14:51:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 14:43:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07843 for ipp-outgoing; Mon, 23 Mar 1998 14:43:27 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 11:42:56 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: ipp-owner@pwg.org Some time since I aired my views on this. I think we should make IPP notifications a mechanism whereby a client can request that a notification be sent to it via any mechanism. That is to say - the notification itself is sent any way you like and is not part of IPP. IPP merely provides the means for the client to request that this be done. We might want to define some standard optional mechanisms (email being the obvious one). All notifications are optional. The IPP Model also needs to define what events are notification candidates and what they mean. The IPP request indicates which events it wants notification on, what mechanism to use, any parameters associated with that mechanism (email address) and maybe message content. The mechanisms available should be something that is queryable (get printer attributes). There is a separate thing that deals with device level alerts and events - along with robust data transmission, etc. etc. My thoughts on that topic have already been aired! > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 10:38 AM > To: ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > All, > > We have had a rather intensive debate between Randy, who first > proposed that we might want to use SNMPv3 traps or informs for > IPP notifications, and Ira, who thinks that the whole idea is > wrong. > > With the exception of Jay's comments earlier today, it has been > very quiet from the rest of the group on this subject. Are there > any other views on the subject? Do you support one or the other > combattants' views? > > If all we will be hearing is arguments between mainly two people > with diametrically opposite views, we are not going to archieve > anything. > > We are supposed to discuss this next week in the IETF in LA and > it would be nice to have a little better understanding of where > the group stands in this debate by then. Should we abandon SNMPv3 > as a candidate for IPP notifications and concentrate our efforts > on a new or different solution? > > Please give more feedback to the DL. > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Mon Mar 23 16:22:17 1998 Delivery-Date: Mon, 23 Mar 1998 16:22:17 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA28293 for ; Mon, 23 Mar 1998 16:22:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04526 for ; Mon, 23 Mar 1998 16:24:48 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA09513 for ; Mon, 23 Mar 1998 16:22:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 16:18:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08914 for jmp-outgoing; Mon, 23 Mar 1998 16:16:09 -0500 (EST) Message-Id: <3.0.1.32.19980323131002.00ceac30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 13:10:02 PST To: Paul Moore , ipp@pwg.org From: Carl-Uno Manros Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Paul, As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email. There has been some interesting discussion lately in the IFAX group about their intended use of MDNs for notifications over email. Those seem to indicate that implementation and actual use of MDNs in email is likely to be a very slow process... Carl-Uno At 11:42 AM 3/23/98 PST, Paul Moore wrote: >Some time since I aired my views on this. > >I think we should make IPP notifications a mechanism whereby a client can >request that a notification be sent to it via any mechanism. > >That is to say - the notification itself is sent any way you like and is not >part of IPP. IPP merely provides the means for the client to request that >this be done. > >We might want to define some standard optional mechanisms (email being the >obvious one). All notifications are optional. > >The IPP Model also needs to define what events are notification candidates >and what they mean. > >The IPP request indicates which events it wants notification on, what >mechanism to use, any parameters associated with that mechanism (email >address) and maybe message content. > >The mechanisms available should be something that is queryable (get printer >attributes). > >There is a separate thing that deals with device level alerts and events - >along with robust data transmission, etc. etc. My thoughts on that topic >have already been aired! > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, March 23, 1998 10:38 AM >> To: ipp@pwg.org >> Cc: jmp@pwg.org; sense@pwg.org >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? >> >> All, >> >> We have had a rather intensive debate between Randy, who first >> proposed that we might want to use SNMPv3 traps or informs for >> IPP notifications, and Ira, who thinks that the whole idea is >> wrong. >> >> With the exception of Jay's comments earlier today, it has been >> very quiet from the rest of the group on this subject. Are there >> any other views on the subject? Do you support one or the other >> combattants' views? >> >> If all we will be hearing is arguments between mainly two people >> with diametrically opposite views, we are not going to archieve >> anything. >> >> We are supposed to discuss this next week in the IETF in LA and >> it would be nice to have a little better understanding of where >> the group stands in this debate by then. Should we abandon SNMPv3 >> as a candidate for IPP notifications and concentrate our efforts >> on a new or different solution? >> >> Please give more feedback to the DL. >> >> 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 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 23 16:25:05 1998 Delivery-Date: Mon, 23 Mar 1998 16:25:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA28455 for ; Mon, 23 Mar 1998 16:25:01 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04541 for ; Mon, 23 Mar 1998 16:27:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA09804 for ; Mon, 23 Mar 1998 16:24:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 16:16:36 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08922 for ipp-outgoing; Mon, 23 Mar 1998 16:16:15 -0500 (EST) Message-Id: <3.0.1.32.19980323131002.00ceac30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 13:10:02 PST To: Paul Moore , ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Paul, As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email. There has been some interesting discussion lately in the IFAX group about their intended use of MDNs for notifications over email. Those seem to indicate that implementation and actual use of MDNs in email is likely to be a very slow process... Carl-Uno At 11:42 AM 3/23/98 PST, Paul Moore wrote: >Some time since I aired my views on this. > >I think we should make IPP notifications a mechanism whereby a client can >request that a notification be sent to it via any mechanism. > >That is to say - the notification itself is sent any way you like and is not >part of IPP. IPP merely provides the means for the client to request that >this be done. > >We might want to define some standard optional mechanisms (email being the >obvious one). All notifications are optional. > >The IPP Model also needs to define what events are notification candidates >and what they mean. > >The IPP request indicates which events it wants notification on, what >mechanism to use, any parameters associated with that mechanism (email >address) and maybe message content. > >The mechanisms available should be something that is queryable (get printer >attributes). > >There is a separate thing that deals with device level alerts and events - >along with robust data transmission, etc. etc. My thoughts on that topic >have already been aired! > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, March 23, 1998 10:38 AM >> To: ipp@pwg.org >> Cc: jmp@pwg.org; sense@pwg.org >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? >> >> All, >> >> We have had a rather intensive debate between Randy, who first >> proposed that we might want to use SNMPv3 traps or informs for >> IPP notifications, and Ira, who thinks that the whole idea is >> wrong. >> >> With the exception of Jay's comments earlier today, it has been >> very quiet from the rest of the group on this subject. Are there >> any other views on the subject? Do you support one or the other >> combattants' views? >> >> If all we will be hearing is arguments between mainly two people >> with diametrically opposite views, we are not going to archieve >> anything. >> >> We are supposed to discuss this next week in the IETF in LA and >> it would be nice to have a little better understanding of where >> the group stands in this debate by then. Should we abandon SNMPv3 >> as a candidate for IPP notifications and concentrate our efforts >> on a new or different solution? >> >> Please give more feedback to the DL. >> >> 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 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Mon Mar 23 16:35:23 1998 Delivery-Date: Mon, 23 Mar 1998 16:35:23 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29236 for ; Mon, 23 Mar 1998 16:35:22 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04577 for ; Mon, 23 Mar 1998 16:37:53 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA10513 for ; Mon, 23 Mar 1998 16:35:16 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 16:31:59 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09892 for jmp-outgoing; Mon, 23 Mar 1998 16:29:32 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B4@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , Paul Moore , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 13:29:20 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: jmp-owner@pwg.org If this is the case "As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email." Then why is there a discussion? I can use anything I like for notifications. I cannot see why SNMP appears in this discussion. If a system wants to use SNMP to get events from a device then this is already possible - it has nothing to do with IPP. What IPP needs is end user focussed stuff (pagers, email, etc.). Faster than email would be the network native messenger service (SMB Net Send for example). > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 1:10 PM > To: Paul Moore; ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > Paul, > > As far as I am aware, we seem to have agreements on most of the points in > your message. The area in which there is still debate is for a delivery > mechanism, that can send out notifications more quickly than with email. > > There has been some interesting discussion lately in the IFAX group about > their intended use of MDNs for notifications over email. Those seem to > indicate that implementation and actual use of MDNs in email is likely to > be a very slow process... > > Carl-Uno > > > At 11:42 AM 3/23/98 PST, Paul Moore wrote: > >Some time since I aired my views on this. > > > >I think we should make IPP notifications a mechanism whereby a client can > >request that a notification be sent to it via any mechanism. > > > >That is to say - the notification itself is sent any way you like and is > not > >part of IPP. IPP merely provides the means for the client to request that > >this be done. > > > >We might want to define some standard optional mechanisms (email being > the > >obvious one). All notifications are optional. > > > >The IPP Model also needs to define what events are notification > candidates > >and what they mean. > > > >The IPP request indicates which events it wants notification on, what > >mechanism to use, any parameters associated with that mechanism (email > >address) and maybe message content. > > > >The mechanisms available should be something that is queryable (get > printer > >attributes). > > > >There is a separate thing that deals with device level alerts and events > - > >along with robust data transmission, etc. etc. My thoughts on that topic > >have already been aired! > > > >> -----Original Message----- > >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> Sent: Monday, March 23, 1998 10:38 AM > >> To: ipp@pwg.org > >> Cc: jmp@pwg.org; sense@pwg.org > >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > >> > >> All, > >> > >> We have had a rather intensive debate between Randy, who first > >> proposed that we might want to use SNMPv3 traps or informs for > >> IPP notifications, and Ira, who thinks that the whole idea is > >> wrong. > >> > >> With the exception of Jay's comments earlier today, it has been > >> very quiet from the rest of the group on this subject. Are there > >> any other views on the subject? Do you support one or the other > >> combattants' views? > >> > >> If all we will be hearing is arguments between mainly two people > >> with diametrically opposite views, we are not going to archieve > >> anything. > >> > >> We are supposed to discuss this next week in the IETF in LA and > >> it would be nice to have a little better understanding of where > >> the group stands in this debate by then. Should we abandon SNMPv3 > >> as a candidate for IPP notifications and concentrate our efforts > >> on a new or different solution? > >> > >> Please give more feedback to the DL. > >> > >> 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 > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Mar 23 16:37:34 1998 Delivery-Date: Mon, 23 Mar 1998 16:37:35 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA29424 for ; Mon, 23 Mar 1998 16:37:34 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04580 for ; Mon, 23 Mar 1998 16:40:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA10820 for ; Mon, 23 Mar 1998 16:37:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 16:30:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09907 for ipp-outgoing; Mon, 23 Mar 1998 16:29:45 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B4@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , Paul Moore , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 13:29:20 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org If this is the case "As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email." Then why is there a discussion? I can use anything I like for notifications. I cannot see why SNMP appears in this discussion. If a system wants to use SNMP to get events from a device then this is already possible - it has nothing to do with IPP. What IPP needs is end user focussed stuff (pagers, email, etc.). Faster than email would be the network native messenger service (SMB Net Send for example). > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 1:10 PM > To: Paul Moore; ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > Paul, > > As far as I am aware, we seem to have agreements on most of the points in > your message. The area in which there is still debate is for a delivery > mechanism, that can send out notifications more quickly than with email. > > There has been some interesting discussion lately in the IFAX group about > their intended use of MDNs for notifications over email. Those seem to > indicate that implementation and actual use of MDNs in email is likely to > be a very slow process... > > Carl-Uno > > > At 11:42 AM 3/23/98 PST, Paul Moore wrote: > >Some time since I aired my views on this. > > > >I think we should make IPP notifications a mechanism whereby a client can > >request that a notification be sent to it via any mechanism. > > > >That is to say - the notification itself is sent any way you like and is > not > >part of IPP. IPP merely provides the means for the client to request that > >this be done. > > > >We might want to define some standard optional mechanisms (email being > the > >obvious one). All notifications are optional. > > > >The IPP Model also needs to define what events are notification > candidates > >and what they mean. > > > >The IPP request indicates which events it wants notification on, what > >mechanism to use, any parameters associated with that mechanism (email > >address) and maybe message content. > > > >The mechanisms available should be something that is queryable (get > printer > >attributes). > > > >There is a separate thing that deals with device level alerts and events > - > >along with robust data transmission, etc. etc. My thoughts on that topic > >have already been aired! > > > >> -----Original Message----- > >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> Sent: Monday, March 23, 1998 10:38 AM > >> To: ipp@pwg.org > >> Cc: jmp@pwg.org; sense@pwg.org > >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > >> > >> All, > >> > >> We have had a rather intensive debate between Randy, who first > >> proposed that we might want to use SNMPv3 traps or informs for > >> IPP notifications, and Ira, who thinks that the whole idea is > >> wrong. > >> > >> With the exception of Jay's comments earlier today, it has been > >> very quiet from the rest of the group on this subject. Are there > >> any other views on the subject? Do you support one or the other > >> combattants' views? > >> > >> If all we will be hearing is arguments between mainly two people > >> with diametrically opposite views, we are not going to archieve > >> anything. > >> > >> We are supposed to discuss this next week in the IETF in LA and > >> it would be nice to have a little better understanding of where > >> the group stands in this debate by then. Should we abandon SNMPv3 > >> as a candidate for IPP notifications and concentrate our efforts > >> on a new or different solution? > >> > >> Please give more feedback to the DL. > >> > >> 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 > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Mon Mar 23 21:31:14 1998 Delivery-Date: Mon, 23 Mar 1998 21:31:15 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA05900 for ; Mon, 23 Mar 1998 21:31:03 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05629 for ; Mon, 23 Mar 1998 21:33:33 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA12129 for ; Mon, 23 Mar 1998 21:30:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 21:27:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA11667 for jmp-outgoing; Mon, 23 Mar 1998 21:25:08 -0500 (EST) Date: Mon, 23 Mar 1998 18:30:49 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803240230.AA16432@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, jmp@pwg.org Subject: JMP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Sender: jmp-owner@pwg.org Hi Randy, Harry, Paul, Jay, et al, I concede all points. I got dragooned into stating my technical objections to the scalability of the SNMPv3 trap registration mechanisms. The discussion has wandered off completely into the merits of the SNMPv3 protocol itself, which is irrelevant. I never wanted to start this thread. I hereby withdraw from it. I'll watch with interest what you folks decide on. Cheers, - Ira McDonald (High North) PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. From ipp-owner@pwg.org Mon Mar 23 21:33:30 1998 Delivery-Date: Mon, 23 Mar 1998 21:33:31 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA05921 for ; Mon, 23 Mar 1998 21:33:30 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA05632 for ; Mon, 23 Mar 1998 21:36:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA12387 for ; Mon, 23 Mar 1998 21:33:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 21:25:21 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA11659 for ipp-outgoing; Mon, 23 Mar 1998 21:25:02 -0500 (EST) Date: Mon, 23 Mar 1998 18:30:49 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803240230.AA16432@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Sender: ipp-owner@pwg.org Hi Randy, Harry, Paul, Jay, et al, I concede all points. I got dragooned into stating my technical objections to the scalability of the SNMPv3 trap registration mechanisms. The discussion has wandered off completely into the merits of the SNMPv3 protocol itself, which is irrelevant. I never wanted to start this thread. I hereby withdraw from it. I'll watch with interest what you folks decide on. Cheers, - Ira McDonald (High North) PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. From jmp-owner@pwg.org Mon Mar 23 23:39:26 1998 Delivery-Date: Mon, 23 Mar 1998 23:39:41 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA12573 for ; Mon, 23 Mar 1998 23:39:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA05827 for ; Mon, 23 Mar 1998 23:41:57 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA13121 for ; Mon, 23 Mar 1998 23:39:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 23:36:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA12609 for jmp-outgoing; Mon, 23 Mar 1998 23:34:32 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , ipp@pwg.org, jmp@pwg.org Subject: JMP> RE: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 20:34:02 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: jmp-owner@pwg.org ..snip.. PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. Need someone to carry your luggage? Randy From ipp-owner@pwg.org Mon Mar 23 23:42:31 1998 Delivery-Date: Mon, 23 Mar 1998 23:42:32 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA12625 for ; Mon, 23 Mar 1998 23:42:31 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA05830 for ; Mon, 23 Mar 1998 23:45:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA13372 for ; Mon, 23 Mar 1998 23:42:28 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 23 Mar 1998 23:34:46 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA12601 for ipp-outgoing; Mon, 23 Mar 1998 23:34:27 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 20:34:02 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org ..snip.. PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. Need someone to carry your luggage? Randy From jmp-owner@pwg.org Tue Mar 24 10:21:59 1998 Delivery-Date: Tue, 24 Mar 1998 10:21:59 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29679 for ; Tue, 24 Mar 1998 10:21:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07074 for ; Tue, 24 Mar 1998 10:24:28 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA24840 for ; Tue, 24 Mar 1998 10:21:52 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 10:18:58 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24310 for jmp-outgoing; Tue, 24 Mar 1998 10:16:18 -0500 (EST) Message-Id: <3517CD57.28B24665@dazel.com> Date: Tue, 24 Mar 1998 09:12:23 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Jay Martin Cc: ipp@pwg.org, jmp@pwg.org, sense@pwg.org Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: <35167F33.3D332CAF@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Jay Martin wrote: > > Turner, Randy wrote: > > > I will reiterate my belief that I don't think its realistic for a simple > > embedded device to maintain notification info for hundreds of clients. > > I agree 110%. That fundamental belief is one of the most critical > assumptions for which SENSE was designed. Namely, require the > managed entity (ie, a printer) to provide minimal scalability for > key services (ie, just a few simultaneous client accesses), then > route that information into a generalized client/server system > with a very high degree of scalability. Well, here we go again... Is it just me, or are we running into the embedded printer requirements versus the print server requirements. If we are talking about IPP, the host to device protocol, then I agree that the device need only support a limited number of notification clients. If we are talking about IPP, the print client to server protocol, then I believe that print server ought to be able to scale to 100's, even 1000's, of clients. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Mar 24 10:26:15 1998 Delivery-Date: Tue, 24 Mar 1998 10:26:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29819 for ; Tue, 24 Mar 1998 10:26:15 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07123 for ; Tue, 24 Mar 1998 10:28:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA25179 for ; Tue, 24 Mar 1998 10:26:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 10:16:52 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24325 for ipp-outgoing; Tue, 24 Mar 1998 10:16:32 -0500 (EST) Message-Id: <3517CD57.28B24665@dazel.com> Date: Tue, 24 Mar 1998 09:12:23 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Jay Martin Cc: ipp@pwg.org, jmp@pwg.org, sense@pwg.org Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: <35167F33.3D332CAF@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Jay Martin wrote: > > Turner, Randy wrote: > > > I will reiterate my belief that I don't think its realistic for a simple > > embedded device to maintain notification info for hundreds of clients. > > I agree 110%. That fundamental belief is one of the most critical > assumptions for which SENSE was designed. Namely, require the > managed entity (ie, a printer) to provide minimal scalability for > key services (ie, just a few simultaneous client accesses), then > route that information into a generalized client/server system > with a very high degree of scalability. Well, here we go again... Is it just me, or are we running into the embedded printer requirements versus the print server requirements. If we are talking about IPP, the host to device protocol, then I agree that the device need only support a limited number of notification clients. If we are talking about IPP, the print client to server protocol, then I believe that print server ought to be able to scale to 100's, even 1000's, of clients. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From jmp-owner@pwg.org Tue Mar 24 11:32:44 1998 Delivery-Date: Tue, 24 Mar 1998 11:32:44 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA02474 for ; Tue, 24 Mar 1998 11:32:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07538 for ; Tue, 24 Mar 1998 11:35:15 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25836 for ; Tue, 24 Mar 1998 11:32:43 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 11:30:24 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25329 for jmp-outgoing; Tue, 24 Mar 1998 11:28:05 -0500 (EST) From: Harry Lewis To: Cc: , Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Message-ID: <5030300019296298000002L082*@MHS> Date: Tue, 24 Mar 1998 11:34:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: jmp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA02474 Well, yes, it gets pretty confusing... >Well, here we go again... > >Is it just me, or are we running into the embedded printer requirements >versus the print server requirements. If we are talking about IPP, the >host to device protocol, then I agree that the device need only support >a limited number of notification clients. If we are talking about IPP, >the print client to server protocol, then I believe that print server >ought to be able to scale to 100's, even 1000's, of clients. > >...walker Because we're talking less about IPP and more about a notification service where, as a potential ubiquitous print submission protocol, IPP needs a mechanism for registering clients for notifications, regardless of the scalability of the notification server I think we need to look at notification services both from the limitations of an embedded device (where most notifications will originate), AND from the point of view of a robust server implementation (like SENSE). The device is not likely to accept the notion of give me e-mail on this message, pager from noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ONLY, the following content with that notice. But, I'm hearing that we wish to consider all this flexibility (and more) in our design. If we break notification into "stages"... the "device originated notification" and the "server based notification"... I think it is likely that typical client-server-device breakpoints will result in several registered hosts at the device. It is also possible to create a limited peer-to-peer printing system with no notification server where print clients register directly with the device. It is also possible to create a notification server that simply polls the device, eliminating the need for a device notification protocol or registration scheme. Since, as Jim points out, we really are talking about (at least) two stages of notification, we should be careful to indicate which part of the problem our recommendation is addressing. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Mar 24 11:34:30 1998 Delivery-Date: Tue, 24 Mar 1998 11:34:30 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA02682 for ; Tue, 24 Mar 1998 11:34:29 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07554 for ; Tue, 24 Mar 1998 11:37:01 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26065 for ; Tue, 24 Mar 1998 11:34:30 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 11:28:15 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25321 for ipp-outgoing; Tue, 24 Mar 1998 11:27:58 -0500 (EST) From: Harry Lewis To: Cc: , Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Message-ID: <5030300019296298000002L082*@MHS> Date: Tue, 24 Mar 1998 11:34:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA02682 Well, yes, it gets pretty confusing... >Well, here we go again... > >Is it just me, or are we running into the embedded printer requirements >versus the print server requirements. If we are talking about IPP, the >host to device protocol, then I agree that the device need only support >a limited number of notification clients. If we are talking about IPP, >the print client to server protocol, then I believe that print server >ought to be able to scale to 100's, even 1000's, of clients. > >...walker Because we're talking less about IPP and more about a notification service where, as a potential ubiquitous print submission protocol, IPP needs a mechanism for registering clients for notifications, regardless of the scalability of the notification server I think we need to look at notification services both from the limitations of an embedded device (where most notifications will originate), AND from the point of view of a robust server implementation (like SENSE). The device is not likely to accept the notion of give me e-mail on this message, pager from noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ONLY, the following content with that notice. But, I'm hearing that we wish to consider all this flexibility (and more) in our design. If we break notification into "stages"... the "device originated notification" and the "server based notification"... I think it is likely that typical client-server-device breakpoints will result in several registered hosts at the device. It is also possible to create a limited peer-to-peer printing system with no notification server where print clients register directly with the device. It is also possible to create a notification server that simply polls the device, eliminating the need for a device notification protocol or registration scheme. Since, as Jim points out, we really are talking about (at least) two stages of notification, we should be careful to indicate which part of the problem our recommendation is addressing. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Mar 24 12:23:02 1998 Delivery-Date: Tue, 24 Mar 1998 12:23:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA05052 for ; Tue, 24 Mar 1998 12:23:02 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07727 for ; Tue, 24 Mar 1998 12:25:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26731 for ; Tue, 24 Mar 1998 12:22:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 12:19:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26174 for ipp-outgoing; Tue, 24 Mar 1998 12:18:53 -0500 (EST) Message-Id: <3.0.1.32.19980324091036.01204330@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 09:10:36 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 980325 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org PWG IPP Phone Conference Agenda for 980325 Latests news from Keith Moore is that we will NOT get any feedback from him or the IESG worth discussing in LA. This leaves IPP Notifications as the main agenda item for the IPP LA meeting. I would like to concentrate our discussions this week on the different aspects of notifications and try to straighten out where we think that we have agreements and where we need to do more work, so that we can identify the things worth spending time on in LA. We have the discussions from the Austin meeting as a basis. It seems to me that we could start working on the IPP part of the solution right away, and keep up the discussion about how to actually deliver the notifications. Tom's recent proposal on a dictionary attribute is one option for how we could express things like requesting notifications to more than one destination. If we have sufficient time we should also move on to the subject of host-to-device. Out of the home work assignments from Austin, Don has produced a strawaman for how TIPSI could be used. Randy is also working on a proposal on how to modify IPP to serve as a host-to-device protocol, but we are still waiting for that to show up. The phone-in information is: Date and Time: March 25, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 212-547-0304 (For Xerox participants 8*535-5000) Pass code: cmanros Please note that the phone number is different from last time. Carl-Uno -- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 24 16:40:57 1998 Delivery-Date: Tue, 24 Mar 1998 16:40:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA10478 for ; Tue, 24 Mar 1998 16:40:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09176 for ; Tue, 24 Mar 1998 16:43:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28399 for ; Tue, 24 Mar 1998 16:40:46 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 16:35:43 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27877 for ipp-outgoing; Tue, 24 Mar 1998 16:35:32 -0500 (EST) Message-Id: <3.0.1.32.19980324131914.01211100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 13:19:14 PST To: agenda@ns.ietf.org, moore+iesg@cs.utk.edu, Harald.Alvestrand@maxware.no From: Carl-Uno Manros Subject: IPP> Agenda for IPP WG in LA Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org IPP WG Agenda - Wednesday March 1, 1998 1300 - 1500 =================================================== 1) Review and discuss proposed requirements for IPP Notifications and entertain proposals for possible existing standarization efforts on which IPP Notifications could be built. o Requirements for IPP Notifications 2) Discuss how to make sure that the generic directory attributes from the IPP Model & Semantics documents gets mapped to SLP and LDAP. o Internet Printing Protocol/1.0: Model and Semantics o Definition of printer: URLs for use with Service Location 3) Discuss any other future work on IPP. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 24 17:02:24 1998 Delivery-Date: Tue, 24 Mar 1998 17:02:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA10879 for ; Tue, 24 Mar 1998 17:02:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09276 for ; Tue, 24 Mar 1998 17:04:54 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA29500 for ; Tue, 24 Mar 1998 17:02:17 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 16:55:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28500 for ipp-outgoing; Tue, 24 Mar 1998 16:54:53 -0500 (EST) Message-Id: <3.0.1.32.19980324134847.00ce9450@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 13:48:47 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Sessions of interest to IPP in LA Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_890804927==_" Sender: ipp-owner@pwg.org --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" Hi all, On request, I have put together a "condenced" version of the overall IETF41 Agenda only keeping the sessions that I believe to be of interest to IPPers. This is obviously just my own personal stab at identifying things based on our earlier or ongoing discussion subjects from the IPP DL. You should consult the full official IETF41 Agenda for other subjects, as well as for any last minute updates. Attached in HTML format. Regards, Carl-Uno --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IPP-special.html" DRAFT Agenda of the Forty-first IETF
Agenda of the Forty-first IETF
March 30 - April 3, 1998
   
MONDAY, March 30, 1998
 
0900-0930 Opening Plenary - San Francisco/Sacramento Room

0930-1130 Morning Sessions
 
 NONE

1300-1500 Afternoon Sessions I
 
San Diego              APP    httpext     HTTP Extensibility BOF
  
1530-1730 Afternoon Sessions II
 
Santa Barbara A      SEC    tls            Transport Layer Security WG
 
1930-2200 Evening Sessions
 
Santa Anita C         OPS   disman    Distributed Management WG
 
TUESDAY, March 31, 1998
 
0900-1000 Morning Sessions I
 
Emeral Bay             OPS   snmpv3   SNMP Version 3 WG
 
1015-1115 Morning Sessions II
 
Santa Barbara A     INT    svrloc       Service Location Protocol WG
Emerald Bay           OPS   snmpv3    SNMP Version 3 WG

1300-1400 Afternoon Sessions I
 
Santa Anita AB       INT    ip1394       IP Over IEEE 1394 WG

1415-1515 Afternoon Sessions II
 
Santa Anita AB       INT    ip1394      IP Over IEEE 1394 WG
 
1545-1645 Afternoon Sessions III
 
Santa Barabara A    APP   acap        Application Configuration Access Protocol WG
 
1700-1800 Afternoon Sessions IV
 
Santa Anita C          APP    mhtml     MIME Encapsulation of Aggregate HTML Doc. WG
 
WEDNESDAY, April 1, 1998
 
0900-1130 Morning Sessions
 
Emerald Bay           APP   fax            Internet Fax WG
Avalon                    APP   ldapext     LDAP Extensions WG
 
1300-1500 Afternoon Sessions I
 
Santa Anita C         APP   ipp            Internet Printing Protocol WG
 
1530-1730 Afternoon Sessions II
 
NONE
 
1930-2200 Evening Sessions
 
San Diego              APP   dasl           DAV Searching and Locating BOF
 
THURSDAY, April 2, 1998
 
0900-1130 Morning Sessions
 
Emeral Bay            APP    fax          Internet Fax WG

1300-1500 Afternoon Sessions I
 
Santa Anita AB      APP     webdav    WWW Distributed Authoring and Versioning WG

1530-1730 Afternoon Sessions II
 
Santa Anita AB       APP    conneg     Content Negotiation WG
 
FRIDAY, April 3, 1998
 
1000-1130 IAB Open Plenary - San Francisco/Sacramento Room

          o    General Comments - Fred Baker
          o    Nominations Committee Report - Michael St. Johns
          o    IAB Open Plenary Session
          o    IESG Open Plenary Session
===========================================================================
Key to Abbreviations

APP   Applications                          Harald Alvestrand/Maxware and
                                                       Keith Moore/UTK
GEN   General Interest                    Fred Baker/Cisco Systems
INT    Internet                                 Jeffrey Burgan @Home Network and
                                                       Thomas Narten/IBM Corporation
OPS    Operations & Management   John Curran/BBN Corporation and
                                                       Michael O'Dell/UUNET Technologies
RTG     Routing                                Joel Halpern/Newbridge Networks
SEC     Security                                Jeff Schiller/MIT
TSV     Transport                             Scott Bradner/Harvard University and
                                                        Allyn Romanow/MCI Corporation
USV     User Services                      Joyce K. Reynolds/ISI
 
  --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com --=====================_890804927==_-- From ipp-owner@pwg.org Tue Mar 24 17:03:14 1998 Delivery-Date: Tue, 24 Mar 1998 17:03:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA10900 for ; Tue, 24 Mar 1998 17:03:13 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09279 for ; Tue, 24 Mar 1998 17:05:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA29662 for ; Tue, 24 Mar 1998 17:03:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 16:55:55 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28581 for ipp-outgoing; Tue, 24 Mar 1998 16:55:39 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> new proposal Date: Tue, 24 Mar 1998 13:55:27 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Hi everyone, I will be placing a proposal for a new transport mapping on the FTP server sometime this evening. The conference call tomorrow is at 10 AM. It is a relatively short proposal (downsized from 15 pages to 10 pages recently). If you have time tomorrow morning, you might want to pull it down and glance at it before the phone conference. I will send another mail message to the DL when it is posted, hopefully by 7:00 PM PST. Sorry for the delay, I was bogged down again with "products" this week. "Man! The bottom line sure gets in the way sometimes..." R. From ipp-owner@pwg.org Tue Mar 24 18:39:25 1998 Delivery-Date: Tue, 24 Mar 1998 18:39:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA12273 for ; Tue, 24 Mar 1998 18:39:25 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09684 for ; Tue, 24 Mar 1998 18:41:55 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00445 for ; Tue, 24 Mar 1998 18:39:21 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 18:32:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29788 for ipp-outgoing; Tue, 24 Mar 1998 18:32:41 -0500 (EST) Message-Id: <3.0.1.32.19980324152613.009bc990@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 15:26:13 PST To: agenda@ns.ietf.org, moore+iesg@cs.utk.edu, Harald.Alvestrand@maxware.no From: Carl-Uno Manros Subject: IPP> Agenda for Internet Printing Protocol (ipp) WG in IETF41 (corrected) Cc: ipp@pwg.org, szilles@adobe.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org OOPS, Got the wrong month on the previous version. Here is the corrected one: IPP WG Agenda - Wednesday April 1, 1998 1300 - 1500 =================================================== 1) Review and discuss proposed requirements for IPP Notifications and entertain proposals for possible existing standarization efforts on which IPP Notifications could be built. o Requirements for IPP Notifications 2) Discuss how to make sure that the generic directory attributes from the IPP Model & Semantics documents gets mapped to SLP and LDAP. o Internet Printing Protocol/1.0: Model and Semantics o Definition of printer: URLs for use with Service Location 3) Discuss any other future work on IPP. Carl-Uno Manros Co-chair IPP WG -- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 24 18:45:00 1998 Delivery-Date: Tue, 24 Mar 1998 18:45:00 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA12333 for ; Tue, 24 Mar 1998 18:44:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09696 for ; Tue, 24 Mar 1998 18:47:30 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00948 for ; Tue, 24 Mar 1998 18:44:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 18:38:05 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00233 for ipp-outgoing; Tue, 24 Mar 1998 18:37:45 -0500 (EST) Message-Id: <3.0.1.32.19980324153634.01213b10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 15:36:34 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org For the IPP telecon, Wed, 3/25: Roger, Bob, and I have been working on various dictionary proposals. Last Friday, we had a teleconference on version 0.8. After Roger hung up, Bob and I came up with yet another simpler proposal which is version 0.9. I edited the document, but neither Bob nor Roger have had the time to send me comments, since they are both away at meetings this week. However, Carl-Uno thought it would be good to at least discuss this work in progress. Send any comments before hand and/or I'll present the ideas on the telecon. I've posted: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setOf-1setOf.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setof-1setof.pdf Briefly, the scheme isn't really a dictionary at all (previous versions were). Other earlier versions were adding a new addressing mechanism for attributes in dictionaries. This proposal adds no new addressing mechanisms, but justs add a new out-of-band value to encode the new Model attribute syntax of 1setOf 1setOf (doubly nested values). Instead, we use the idea of attributes with parallel values, like we already have for "printer-uri-supported" and "uri-security-supported". I fleshed out a real world example for "job-notify", "job-notify-default", and "job-notify-supported" to show how it works, along with a simpler "printer-resolution", "printer-resolution-default" and "printer-resolution-supported" example. I've left the rejected example that uses the 'dictionary' attribute syntax in the document. I've also listed the alternatives that we considered and the reasons for rejecting them. There are two issues remaining: ISSUE 1: If a 1setOf 1setOf value is a single value, does the sender need to include the double nesting or not? It would be nice if our encoding would allow a single value, i.e.,: "job-notify-method-supported" 'mailto', { 'sense', 'tcp/ip-socket' } for representing: job-notify-method-supported (1setOf 1setOf type2 keyword) where the "{" indicates the begin and the "}" indicates the end. Thus the new begin and end construct is not needed for every use of 1setOf 1SetOf, only when there are actually more than one value for the second 1setOf. Here is what I have for the encoding: 5 Encoding In order to allow the 1setOf 1setOf to be represented as merely 1setOf when there is only one value in a set of parallel attributes, we need a begin and end indication of a set of values that are to be grouped together into a 1setOf 1setOf. The simplest and most compatible way to add simple begin and end markers that can be ignored by existing parsers is to use an attribute to mean begin of a 1setOf 1setOf and another attribute to flag the end of a 1setOf 1SetOf value. Since the begin and end flags don't need any values, it is simplest to add a single out-of-band value, say, 'value-marker' and then introduce two new attributes that use it: "begin-set-of-set" and "end-set-of-set". ISSUE 2: Ok to use the same "out-of-band" with different attributes to get the begin and end? Tom From ipp-owner@pwg.org Wed Mar 25 12:49:57 1998 Delivery-Date: Wed, 25 Mar 1998 12:49:58 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA06056 for ; Wed, 25 Mar 1998 12:49:57 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11999 for ; Wed, 25 Mar 1998 12:52:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA14734 for ; Wed, 25 Mar 1998 12:49:53 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Mar 1998 12:41:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14171 for ipp-outgoing; Wed, 25 Mar 1998 12:40:57 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> new proposal Date: Wed, 25 Mar 1998 09:40:44 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD57D2.16DEA2C0" Sender: ipp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD57D2.16DEA2C0 Content-Type: text/plain Sorry for the delay, but our internet connection was up and down last night and I "gave up the ghost". The document is ready this morning as of 9:00 AM in the new_PRO directory on the IPP FTP directory. The document is "Ipptcp.doc". It is a word95 document. I am also included a copy as an attachment to speed things up for those people that can handle attachments. Randy ------ =_NextPart_000_01BD57D2.16DEA2C0 Content-Type: application/msword; name="ipptcp.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipptcp.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMgAAAAAAAAAA EAAALwAAAAEAAAD+////AAAAADMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAAKEkAAPpZAAAAAAAAAAAAAAAAAAAAAAAAKEYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAKQAAAAAWAAApAAAAKRYAAAAAAAApFgA AAAAAACkWAAAAAAAAKRYAAAAAAAApFgAABQAAAC4WAAAAAAAALhYAAAAAAAAuFgAAAAAAAC4WAAA AAAAALhYAAAAAAAAuFgAAAoAAADCWAAAKAAAALhYAAAAAAAA7FgAAEMAAADqWAAAAAAAAOpYAAAA AAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAIA AADsWAAAAAAAAOxYAAAAAAAA7FgAAAAAAADsWAAAAAAAAOxYAAAAAAAA7FgAAAAAAAAvWQAAWAAA AIdZAABzAAAA7FgAAAAAAAAAAAAAAAAAAAAAAAAAAAAApFgAAAAAAADqWAAAAAAAAAAAJQAmAAEA BgDqWAAAAAAAAOpYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOpYAAAAAAAA6lgAAAAAAADsWAAAAAAA AOpYAAAAAAAApFgAAAAAAACkWAAAAAAAAOpYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOpYAAAAAAAA 6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAAAAACkWAAAAAAAAOpYAAAAAAAApFgAAAAAAADq WAAAAAAAAOpYAAAAAAAAAAAAAAAAAABgku8AFVi9AbhYAAAAAAAAuFgAAAAAAACkWAAAAAAAAKRY AAAAAAAApFgAAAAAAACkWAAAAAAAAOpYAAAAAAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbmR5IFR1cm5lcg1FeHBpcmVzOiBTZXB0ZW1i ZXIgMTk5OCAgICAgICAgICAgICAgICAgICAgICAgICAgIFNoYXJwIExhYnMgb2YgQW1lcmljYQ0N DSAgICAgICAgICAgICAgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgb3ZlciBUQ1AvSVANDQ1T dGF0dXMgb2YgdGhpcyBNZW1vDQ1UaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0LiAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDWRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywNYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ13b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQ1JbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkg dGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAnJ3dvcmsgaW4gcHJv Z3Jlc3MnJw0NVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3RhdHVzIG9mIGFueSBJbnRlcm5ldC1EcmFm dCwgcGxlYXNlIGNoZWNrIHRoZQ1gYDFpZC1hYnN0cmFjdHMudHh0JycgbGlzdGluZyBjb250YWlu ZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNRGlyZWN0b3JpZXMgb24gZnRwLmlzLmNv LnphIChBZnJpY2EpLCBuaWMubm9yZHUubmV0IChFdXJvcGUpLA1tdW5uYXJpLm96LmF1IChQYWNp ZmljIFJpbSksIGRzLmludGVybmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDWZ0cC5pc2kuZWR1 IChVUyBXZXN0IENvYXN0KS4NDQ0xIEFic3RyYWN0DQ1UaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJv dG9jb2wgKElQUCkgaXMgZnVuZGFtZW50YWxseSBkZWZpbmVkIGJ5IHRoZSBJUFAgTW9kZWwgJiBT ZW1hbnRpY3MvMS4wIERvY3VtZW50IFsxXS4gVGhlIElQUCBtb2RlbCB3YXMgZGVzaWduZWQgdG8g YmUgdHJhbnNwb3J0LWluZGVwZW5kZW50LiBUaGVyZSBjdXJyZW50bHkgZXhpc3RzIGEgZG9jdW1l bnQgdGhhdCBkZXNjcmliZXMgdXNpbmcgSHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIChIVFRQ KSAxLjEgYXMgYSB0cmFuc3BvcnQgbGF5ZXIgZm9yIElQUCBbSVBQUFJPVF0uIEJlY2F1c2UgdGhl IElQUCBtb2RlbCBkb2N1bWVudCBpcyBub3QgdHJhbnNwb3J0LXNwZWNpZmljLCBpdCB3YXMgZW52 aXNpb25lZCB0aGF0IHBvc3NpYmx5IG11bHRpcGxlIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9ucyB3 b3VsZCBiZSBhdXRob3JlZCBmb3IgSVBQLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBzdWNoIGFu IGFsdGVybmF0ZSB0cmFuc3BvcnQgZm9yIElQUCBtZXNzYWdlcywgYW5kIGF0dGVtcHRzIHRvIGNs YXJpZnkgdGhlIHRyYW5zcG9ydC1pbmRlcGVuZGVuY2UgaW1wbGllZCBieSB0aGUgSVBQIG1vZGVs IGFuZCBzZW1hbnRpY3MgZG9jdW1lbnQuDQ0yIE92ZXJ2aWV3DQ1UaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG5ldyB0cmFuc3BvcnQgbWFwcGluZyBmb3IgdGhlIElQUCBwcm90b2NvbC4gIFRoZSBl eGlzdGluZyBzZXQgb2YgZG9jdW1lbnRzIGRlc2NyaWJpbmcgSVBQIGRlZmluZSBhIG1vZGVsIGFu ZCBhYnN0cmFjdCBwcm90b2NvbCBmb3IgcHJpbnRpbmcsIGFuZCBhbiBleHBsaWNpdCBlbmNvZGlu ZyBhbmQgdHJhbnNwb3J0IG92ZXIgSFRUUCAxLjEuIFRoaXMgZG9jdW1lbnQgaXMgYSB0cmFuc3Bv cnQgZG9jdW1lbnQgdGhhdCBleHBsaWNpdCBkZWZpbmVzIGhvdyB0aGUgZXhpc3RpbmcgSVBQIGVu Y29kaW5nIGlzIHRyYW5zcG9ydGVkIGRpcmVjdGx5IG92ZXIgVENQLg0NVGhpcyBkb2N1bWVudCBt YWtlcyBleHBsaWNpdCByZWZlcmVuY2VzIHRvIGJvdGggdGhlIElQUCBtb2RlbCBkb2N1bWVudCBb SVBQTU9EXSBhbmQgdGhlIGV4aXN0aW5nIElQUCBQcm90b2NvbC9FbmNvZGluZyBkb2N1bWVudCBb SVBQUFJPVF0uIFRoaXMgcHJvcG9zYWwgaW1wbGllcyBubyBzZW1hbnRpYyBjaGFuZ2VzIHRvIHRo ZSBJUFAgbW9kZWwgZG9jdW1lbnQuIEZ1cnRoZXIsIGl0IHJldXNlcyB0aGUgZW5jb2Rpbmcgc3Bl Y2lmaWVkIGluIFtJUFBQUk9UXSBpbiBpdHMgZW50aXJldHkuIE9ubHkgdGhlIG1lY2hhbmlzbSBm b3IgdHJhbnNwb3J0aW5nIHRoZSBleGlzdGluZyBlbmNvZGluZyBpcyBtb2RpZmllZCBieSB0aGlz IHByb3Bvc2FsLg0NMyBJUFAgb3ZlciBUQ1AvSVAgliBSYXRpb25hbGUgU3RhdGVtZW50DQ1UaGVy ZSBpcyBhIHBlcmNlaXZlZCBub3Rpb24gdGhhdCB0aGUgY3VycmVudCBJUFAtb3Zlci1IVFRQIHNw ZWNpZmljYXRpb24gaW1wb3NlcyBhICJoZWF2eXdlaWdodCIgcmVxdWlyZW1lbnQgb24gbG93LWNv c3QsIGVtYmVkZGVkIGRldmljZXMsIGluIHRlcm1zIG9mIHJlc291cmNlcyBhbmQgaW1wbGVtZW50 YXRpb24gZWZmb3J0LiBJbml0aWFsIGltcGxlbWVudGF0aW9ucyBvZiBJUFAtb3Zlci1IVFRQIHdp bGwgYmUgdGFyZ2V0ZWQgdG93YXJkcyBzZXJ2ZXItYmFzZWQgc3lzdGVtcywgd2l0aCBsb2NhbCBz dG9yYWdlIGNhcGFjaXR5IGZvciBzcG9vbGluZyBhbmQgb3RoZXIgam9iIG1hbmFnZW1lbnQgZmVh dHVyZXMuIFRoZSB1c2Ugb2YgSFRUUCBhcyBhIHRyYW5zcG9ydCB3aWxsIGFsbG93IHF1aWNrIGRl cGxveW1lbnQgb2YgaW50ZXJuZXQgY2FwYWJpbGl0eSBmb3IgcHJpbnRpbmcgdGhyb3VnaCBzdGFu ZGFyZCBIVFRQIHNlcnZlciBleHRlbnNpb24gbWVjaGFuaXNtcyAoQ0dJLCBOU0FQSSwgSVNBUEks IEphdmEgc2VydmxldHMsIGV0Yy4pLiBCZWNhdXNlIHRoZSBjb3JlIElQUCBwcm90b2NvbCBtb2Rl bCBjb250YWlucyBubyBIVFRQLXNwZWNpZmljIHJlcXVpcmVtZW50cyBvciBzZW1hbnRpY3MsIHRo aXMgZG9jdW1lbnQgc3VnZ2VzdHMgYW4gYWx0ZXJuYXRlIHRyYW5zcG9ydCBmb3IgdGhlIElQUCBh YnN0cmFjdCBwcm90b2NvbCB1dGlsaXppbmcgc2ltcGxlciB0cmFuc3BvcnQgc2VtYW50aWNzLCBh cyB3ZWxsIGFzIHByb3ZpZGluZyBzbGlnaHQgY2hhbmdlcyB0byBJUFAgY2xpZW50L3NlcnZlciBp bnRlcmFjdGlvbi4gVGhlIGNoYW5nZXMgYXJlIG1pbm9yIGFuZCBhbGxvdyB0aWdodGVyIGludGVn cmF0aW9uIG9mIGNsaWVudCBhbmQgcHJpbnRlciBmb3Igbm90aWZpY2F0aW9ucyBhbmQgc3RhdHVz IGluZm9ybWF0aW9uLg0NVGhlIGZvbGxvd2luZyBkaWFncmFtIHNob3dzIG9uZSBJUFAgdG9wb2xv Z3kgZm9yIHdoaWNoIHRoZSBwcm9wb3NlZCBUQ1AvSVAgdHJhbnNwb3J0IHdvdWxkIGJlIHV0aWxp emVkDQ1JUFAvSFRUUCBjbGllbnRzICAgICAgICAgICAgIElQUCBTZXJ2ZXIgICAgICAgICAgICBJ UFAgUHJpbnRlcnMNDSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS18 DSAgfCAgIEMxICB8ICAgSFRUUCAgICAgIHwgICAgICAgICArICAgICAgICB8ICAgVENQICAgfC0t LS0tLXwNICB8ICAgICAgIHw9PT09PT09PT09PT09fCAgICAgICAgICsgICAgICAgIHw9PT09PT09 PT18ICBQMSAgfA0gIC0tLS0tLS0tLSAgICAgICAgICAgICB8ICAgIEggICAgKyAgICAgICAgfCAg ICAgICAgIHwtLS0tLS18DSAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICArICAgVCAg ICB8DSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwgICAgVCAgICArICAgICAgICB8DSAgfCAgIEMy ICB8ICAgSFRUUCAgICAgIHwgICAgICAgICArICAgQyAgICB8ICAgVENQICAgfC0tLS0tLXwNICB8 ICAgICAgIHw9PT09PT09PT09PT09fCAgICBUICAgICsgICAgICAgIHw9PT09PT09PT18ICBQMiAg fA0gIC0tLS0tLS0tLSAgICAgICAgICAgICB8ICAgICAgICAgKyAgIFAgICAgfCAgICAgICAgIHwt LS0tLS18DSAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgUCAgICArICAgICAgICB8DSAgLS0t LS0tLS0tICAgICAgICAgICAgIHwgICAgICAgICArICAgICAgICB8ICAgVENQICAgfC0tLS0tLXwN ICB8ICAgQzMgIHwgICBIVFRQICAgICAgfCAgICAgICAgICsgICAgICAgIHw9PT09PT09PT18ICBQ MyAgfA0gIHwgICAgICAgfD09PT09PT09PT09PT18ICAgICAgICAgKyAgICAgICAgfCAgICAgICAg IHwtLS0tLS18DSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS18DQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDENDQ1FeGlzdGluZyBJUFAvMS4w LW92ZXItSFRUUCBjbGllbnRzIHdvdWxkIHN1Ym1pdCBqb2JzIHRvIElQUCBzZXJ2ZXJzLiBUaGUg c2VydmVycyB3b3VsZCByZWxheSB0aGUgSVBQIHJlcXVlc3RzIHRvIHBoeXNpY2FsIHByaW50ZXJz IHVzaW5nIHRoZSBwcm9wb3NlZCBUQ1AvSVAgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IGdhdGV3 YXkgaXMganVzdCB0aGF0LCBhIHRyYW5zcG9ydCBnYXRld2F5LCBub3QgYW4gYXBwbGljYXRpb24t bGV2ZWwgZ2F0ZXdheS4gVGhlcmVmb3JlLCB0aGVyZSB3b3VsZCBiZSBubyBsb3NzIGluIGFwcGxp Y2F0aW9uIGluZm9ybWF0aW9uIGZyb20gY2xpZW50IHRvIGV2ZW50dWFsIHBoeXNpY2FsIHByaW50 ZXIuIA0NT2YgY291cnNlLCB0aGlzIHVzZSBvZiB0aGUgcHJvcG9zZWQgc2ltcGxlIHRyYW5zcG9y dCBpcyBidXQgb25lIHBvc3NpYmxlIHRvcG9sb2d5LiBUaGUgZGlhZ3JhbSBhYm92ZSBjb3VsZCBi ZSBjaGFuZ2VkIHNvIHRoYXQgYm90aCBJUFAgc2VydmVycyBhbmQgSVBQIGNsaWVudHMgQk9USCBj b25uZWN0IHRvIElQUCBwaHlzaWNhbCBwcmludGVycywgaWYgYm90aCBzZXJ2ZXJzIGFuZCBjbGll bnRzIHdpc2ggdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGZlYXR1cmVzIG9mIHRoZSBwcm9wb3Nl ZCB0cmFuc3BvcnQuIEFsc28sIHNjZW5hcmlvcyB3aGVyZWluIG11bHRpcGxlIGxldmVscyBvZiBz ZXJ2ZXJzIGNvbW11bmljYXRpbmcgd2l0aCBzZXJ2ZXJzIHdoaWNoIGV2ZW50dWFsbHkgY29tbXVu aWNhdGUgd2l0aCBhIHBoeXNpY2FsIHByaW50ZXIgY291bGQgYmUgc3VwcG9ydGVkIGFzIHdlbGwu DQ1JUFAgc2VjdXJpdHkgaXMgYWxzbyBhZGRyZXNzZWQgYnkgdGhpcyBtZW1vLCBhbmQgYSBzaW1w bGVyIG1lY2hhbmlzbSBmb3Igc3VwcG9ydCBvZiBpbi1iYW5kIHNlY3VyaXR5IG5lZ290aWF0aW9u IGlzIGluY2x1ZGVkIGluIHRoZSBwcm9wb3NlZCB0cmFuc3BvcnQuDQ00IElQUCBQcm90b2NvbCBQ cm9jZXNzaW5nDQ1UaGlzIGRyYWZ0IHByb3Bvc2VzIGEgbW9kZWwgZm9yIElQUCBwcm90b2NvbCBv cGVyYXRpb24gdGhhdCBmb2xsb3dzIG90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyB0aGF0IHN1 cHBvcnQgbXVsdGlwbGUgdHJhbnNwb3J0cywgaW5jbHVkaW5nIFNOTVAgVmVyc2lvbiAzIFtSRkMy MjczXS4gVGhlIG9wZXJhdGlvbiBtb2RlbCBkZXNjcmliZWQgaGVyZWluIHNwZWNpZmllcyB0d28g aW5kZXBlbmRlbnRseSBvcGVyYXRpbmcgImxheWVycyI6IFRoZSBJUFAgcHJvY2Vzc2luZyBsYXll ciBhbmQgb25lIG9yIG1vcmUgdHJhbnNwb3J0IGxheWVycy4NDVRoZSBJUFAgcHJvY2Vzc2luZyBs YXllciBpcyB0aGUgY29yZSBwcm90b2NvbCBlbmdpbmUgdGhhdCB1bmRlcnN0YW5kcyB0aGUgc2Vt YW50aWNzIG9mIHByb3RvY29sIG9wZXJhdGlvbnMsIHN1Y2ggYXMgcmVxdWVzdHMgYW5kIHJlc3Bv bnNlcy4gVGhlIGNvcmUgSVBQIHByb3RvY29sIGVuZ2luZSBvcGVyYXRlcyBpbmRlcGVuZGVudGx5 IG9mIHRyYW5zcG9ydC4gVGhlIGluZGVwZW5kZW5jZSBpcyBhY2hpZXZlZCB0aHJvdWdoIGFkaGVy ZW5jZSB0byBzcGVjaWZpYyBpbnRlcmZhY2VzLiBUaGUgbmV4dCBzZWN0aW9uIGRlc2NyaWJlcyB0 aGUgYWJzdHJhY3QgaW50ZXJmYWNlKHMpIGVtcGxveWVkIHRvIGFjaGlldmUgdGhlIG11bHRpcGxl LXRyYW5zcG9ydCBtb2RlbC4gVGhlIGRpc2N1c3Npb24gb2YgYWJzdHJhY3QgdHJhbnNwb3J0IGlu dGVyZmFjZXMgYW5kIHN1YnNlcXVlbnQgc3RhdHVzIGNvZGVzIGlzIG1lcmVseSB0byBlbXBoYXNp emUgYW5kIGNsYXJpZnkgaG93IGEgcGFydGljdWxhciBJUFAgaW1wbGVtZW50YXRpb24gbWlnaHQg YmUgYXJjaGl0ZWN0ZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnRzLiBJdCBhbHNvIGls bHVzdHJhdGVzIGhvdyBJUFAgInRyYW5zcG9ydC1nYXRld2F5cyIgY2FuIGJlIGNvbnN0cnVjdGVk LiBUaGUgaW5jbHVzaW9uIG9mIHRoaXMgYWJzdHJhY3QgbW9kZWwgZG9lcyBub3QgaW1wbHkgdGhh dCBhIHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBwcm90b2NvbCBtYXBwaW5nIFNI T1VMRCBvciBNVVNUIGJlIGNvbnN0cnVjdGVkIHVzaW5nIHRoZXNlIGFic3RyYWN0IHNlbWFudGlj cy4NDTQuMSBJUFAgVHJhbnNwb3J0IEludGVyZmFjZQ0NVGhlIGZvbGxvd2luZyBhYnN0cmFjdCBp bnRlcmZhY2UgaXMgdXNlZCBieSBhbiBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgdG8gdHJhbnNtaXQg YSBQRFUsIGFjcm9zcyBhIHBhcnRpY3VsYXIgdHJhbnNwb3J0LCB0byBhbm90aGVyIElQUCBwcm90 b2NvbCBwcm9jZXNzaW5nIGVuZ2luZS4gVGhlIG1vZGVsIGFuZCBmb3JtYXQgaXMgdGFrZW4gZnJv bSBbUkZDMjI3M10gYXMgYW4gZXhhbXBsZSBhYnN0cmFjdCBpbnRlcmZhY2UsIHdpdGggc2ltaWxh ciBmZWF0dXJlczoNDXBkdUhhbmRsZSA9IHNlbmRQZHUoDSAgICAgICAgIElOICAgdHJhbnNwb3J0 RG9tYWluICAgICAgICAgICAtLSB0cmFuc3BvcnQgZG9tYWluIHRvIGJlIHVzZWQNICAgICAgICAg SU4gICB0cmFuc3BvcnRBZGRyZXNzICAgICAgICAgIC0tIGRlc3RpbmF0aW9uIG5ldHdvcmsgYWRk cmVzcw0gICAgICAgICBJTiAgIG1lc3NhZ2VQcm9jZXNzaW5nTW9kZWwgICAgLS0gSVBQIFZlcnNp b24gTnVtYmVyDSAgICAgICAgIElOICAgc2VjdXJpdHlNb2RlbCAgICAgICAgICAgICAtLSBTZWN1 cml0eSBNb2RlbCB0byB1c2UNICAgICAgICAgSU4gICBzZWN1cml0eU5hbWUgICAgICAgICAgICAg IC0tIG9uIGJlaGFsZiBvZiB0aGlzIHByaW5jaXBhbA0gICAgICAgICBJTiAgIHNlY3VyaXR5TGV2 ZWwgICAgICAgICAgICAgLS0gTGV2ZWwgb2YgU2VjdXJpdHkgcmVxdWVzdGVkDSAgICAgICAgIElO ICAgcGR1VmVyc2lvbiAgICAgICAgICAgICAgICAtLSBFbmNvZGluZyBtb2RlbCB1c2VkDSAgICAg ICAgIElOICAgUERVICAgICAgICAgICAgICAgICAgICAgICAtLSBJUFAgUHJvdG9jb2wgRGF0YSBV bml0DSAgICAgICAgIElOICAgZXhwZWN0UmVzcG9uc2UgICAgICAgICAgICAtLSBUUlVFIG9yIEZB TFNFDSAgICAgICAgICAgICAgKQ0NV2hlcmUsDQ0idHJhbnNwb3J0RG9tYWluIiBpcyB0aGUgcGFy dGljdWxhciB0cmFuc3BvcnQgb3ZlciB3aGljaCB0aGUgSVBQIFBEVSBpcyBiZWluZyBkZWxpdmVy ZWQuDQ0idHJhbnNwb3J0QWRkcmVzcyIgaXMgdGhlIHBhcnRpY3VsYXIgYWRkcmVzcyB3aXRoaW4g dGhlIHRyYW5zcG9ydERvbWFpbiB0aGF0IHNob3VsZCByZWNlaXZlIHRoZSBQRFUuDQ0ibWVzc2Fn ZVByb2Nlc3NpbmdNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgSVBQIHZlcnNpb24gbnVtYmVyIGZv ciB3aGljaCB0aGUgcHJvY2Vzc2luZyBhbmQgc2VtYW50aWNzIG9mIHRoZSBQRFUgYXJlIHRvIGJl IGFwcGxpZWQuIFNpbmNlIHRoZSBJUFAgY29yZSBwcm9jZXNzaW5nIGVuZ2luZSBhbmQgdGhlIHRy YW5zcG9ydCBsYXllciBtYXkgYmUgaW5kZXBlbmRlbnRseSBpbXBsZW1lbnRlZCwgdGhlcmUgbWln aHQgYmUgdmVyc2lvbiBjb25mbGljdHMgd2hlcmVpbiBhIHBhcnRpY3VsYXIgdHJhbnNwb3J0IGxh eWVyIGNhbm5vdCBzdXBwb3J0IGEgcGFydGljdWxhciB2ZXJzaW9uIG9mIHRoZSBJUFAgbW9kZWwu DQ0ic2VjdXJpdHlNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgc2VjdXJpdHkgbWVjaGFuaXNtIGJl aW5nIGVtcGxveWVkIGZvciBwcm90ZWN0aW5nIHRoZSBQRFUuDQ0ic2VjdXJpdHlMZXZlbCIgaXMg dGhlIHBhcnRpY3VsYXIgbGV2ZWwgb3IgZGVncmVlIG9mIHNlY3VyaXR5IHdpdGhpbiB0aGUgInNl Y3VyaXR5TW9kZWwiIHVzZWQgdG8gY29udmV5IHRoaXMgUERVLg0NInNlY3VyaXR5TmFtZSIgaXMg YSBwYXJ0aWN1bGFyIGVuZC11c2VyIGlkZW50aWZpZXIgKGlmIGtub3duKSB0aGF0IHNob3VsZCBi ZSB1c2VkIGR1cmluZyB0aGUgZ2VuZXJhdGlvbiBvZiBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlv biBmb3IgYSBwYXJ0aWN1bGFyIHNlY3VyaXR5IG1lY2hhbmlzbS4NDSJwZHVWZXJzaW9uIiBpcyB0 aGUgcGFydGljdWxhciBlbmNvZGluZyBydWxlcyB1c2VkIHRvIGVuY29kZSB0aGUgUERVLiBUaGlz IHBhcmFtZXRlciBpcyBwYXNzZWQgdG8gdGhlIHRyYW5zcG9ydCBsYXllciBiZWNhdXNlIHRoZSBw YXJ0aWN1bGFyIHRyYW5zcG9ydCBsYXllciBtaWdodCBub3QgYmUgYWJsZSB0byByZWxpYWJsZSBl bmNhcHN1bGF0ZSBjZXJ0YWluIGVuY29kaW5ncyBhbmQgZ3VhcmFudGVlIHRoZWlyIGRlbGl2ZXJ5 Lg0NInNlbmRQZHVIYW5kbGUiIGlzIGFuIG9wYXF1ZSAidHJhbnNhY3Rpb24taWQiIGdlbmVyYXRl ZCBieSB0aGUgc3BlY2lmaWMgdHJhbnNwb3J0IGxheWVyIGZvciB0aGlzIFBEVS4NDQ1UaGUgY29y ZSBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgd291bGQgZm9ybXVsYXRlIElQUCBtZXNzYWdlcyB2aWEg c29tZSBlbmNvZGluZywgYW5kIHRoZW4gc3Vic2VxdWVudGx5IHBhc3MgdGhlc2UgZW5jb2RlZCBQ RFVzIHRvIHRoZSBhcHByb3ByaWF0ZSB0cmFuc3BvcnQgbGF5ZXIgaWRlbnRpZmllZCBieSB0cmFu c3BvcnREb21haW4gYW5kIGVuZHBvaW50IGlkZW50aWZpZWQgYnkgdHJhbnNwb3J0QWRkcmVzcy4g SW4gYWN0dWFsIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZXNlIHR3byBwYXJhbWV0ZXJzIHdv dWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgInNjaGVtZSIgYW5kICJob3N0IiBwYXJ0cyBvZiBhIFVS SS4NDQ0gcGR1TGVuZ3RoID0gcmVjZWl2ZVBkdSggICAgICAgICAgICAgIC0tIHByb2Nlc3MgUmVz cG9uc2UgUERVDSAgICAgICAgIElOICAgdHJhbnNwb3J0RG9tYWluDSAgICAgICAgIElOICAgdHJh bnNwb3J0QWRkcmVzcw0gICAgICAgICBJTiAgIG1lc3NhZ2VQcm9jZXNzaW5nTW9kZWwgICAgLS0g SVBQIHZlcnNpb24gbnVtYmVyDSAgICAgICAgIElOICAgc2VjdXJpdHlNb2RlbCAgICAgICAgICAg ICAtLSBTZWN1cml0eSBNb2RlbCBpbiB1c2UNICAgICAgICAgSU4gICBzZWN1cml0eUxldmVsICAg ICAgICAgICAgIC0tIExldmVsIG9mIHNlY3VyaXR5DSAgICAgICAgIElOICAgc2VjdXJpdHlOYW1l ICAgICAgICAgICAgICAtLSBvbiBiZWhhbGYgb2YgdGhpcyBwcmluY2lwYWwNICAgICAgICAgSU4g ICBwZHVWZXJzaW9uICAgICAgICAgICAgICAgIC0tIGVuY29kaW5nIG1ldGhvZCB1c2VkDSAgICAg ICAgIElOICAgUERVICAgICAgICAgICAgICAgICAgICAgICAtLSBJUFAgUHJvdG9jb2wgRGF0YSBV bml0DSAgICAgICAgIElOICAgc2VuZFBkdUhhbmRsZSAgICAgICAgICAgICAtLSBoYW5kbGUgZnJv bSBzZW5kUERVDSAgICAgICAgICAgICAgKQ0NV2hlcmUsDQ0icGR1TGVuZ3RoIiBpcyB0aGUgbGVu Z3RoLCBpbiBvY3RldHMsIG9mIHRoZSByZWNlaXZlZCBQRFUuIElmIHRoZSANDSJ0cmFuc3BvcnRE b21haW4iIGlzIHRoZSBwYXJ0aWN1bGFyIHRyYW5zcG9ydCBvdmVyIHdoaWNoIHRoZSBJUFAgUERV IGlzIHJlY2VpdmVkLg0NInRyYW5zcG9ydEFkZHJlc3MiIGlzIHRoZSBwYXJ0aWN1bGFyIGFkZHJl c3Mgd2l0aGluIHRoZSB0cmFuc3BvcnREb21haW4gdGhhdCBvcmlnaW5hdGVkIHRoZSByZWNlaXZl ZCBQRFUuDQ0ibWVzc2FnZVByb2Nlc3NpbmdNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgSVBQIHZl cnNpb24gbnVtYmVyIGZvciB3aGljaCB0aGUgcHJvY2Vzc2luZyBhbmQgc2VtYW50aWNzIG9mIHRo ZSBQRFUgYXJlIHRvIGJlIGFwcGxpZWQuDQ0ic2VjdXJpdHlNb2RlbCIgaXMgdGhlIHBhcnRpY3Vs YXIgc2VjdXJpdHkgbWVjaGFuaXNtIGJlaW5nIGVtcGxveWVkIGZvciBwcm90ZWN0aW5nIHRoZSBy ZWNlaXZlZCBQRFUuDQ0ic2VjdXJpdHlMZXZlbCIgaXMgdGhlIHBhcnRpY3VsYXIgbGV2ZWwgb3Ig ZGVncmVlIG9mIHNlY3VyaXR5IHdpdGhpbiB0aGUgInNlY3VyaXR5TW9kZWwiIHVzZWQgdG8gY29u dmV5IHRoaXMgUERVLg0NInNlY3VyaXR5TmFtZSIgaXMgYSBwYXJ0aWN1bGFyIGVuZC11c2VyIGlk ZW50aWZpZXIgKGlmIGtub3duKSB0aGF0IHdhcyB0cmFuc2xhdGVkIGZyb20gdGhlIHBhcnRpY3Vs YXIgc2VjdXJpdHkgbWVjaGFuaXNtLg0NInBkdVZlcnNpb24iIGlzIHRoZSBwYXJ0aWN1bGFyIGVu Y29kaW5nIHJ1bGVzIHVzZWQgdG8gZW5jb2RlIHRoZSByZWNlaXZlZCBQRFUuDQ0ic2VuZFBkdUhh bmRsZSIgaXMgYW4gb3BhcXVlICJ0cmFuc2FjdGlvbi1pZCIgZ2VuZXJhdGVkIGJ5IHRoZSBvcmln aW5hdG9yIG9mIHRoaXMgUERVLg0NVGhpcyBwcm9wb3NhbCBzcGVjaWZpZXMgdGhlIHVzZSBvZiB0 aGUgZW5jb2RpbmcgYXMgc3BlY2lmaWVkIGluIFtJUFAtUFJPVF0uIE9uZSBwYXJ0aWN1bGFyIHVz ZSBvZiB0aGlzIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9uIHdvdWxkIGJlIHRvIGltcGxlbWVudCBh IGdhdGV3YXkgZnVuY3Rpb24gYXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEuIA0NSW4gdGhlIGlk ZWFsIGdhdGV3YXkgc2NlbmFyaW8sIGEgY29yZSBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgd291bGQg c2ltcGx5IHJlbGF5IHJlcXVlc3RzIGZyb20gb25lIHRyYW5zcG9ydCAoSFRUUCkgdG8gYW5vdGhl ciB0cmFuc3BvcnQgKFRDUC9JUCksIG9ubHkgdmFyeWluZyB0aGUgdHJhbnNwb3J0RG9tYWluIGFu ZCB0cmFuc3BvcnRBZGRyZXNzIHBhcmFtZXRlcnMgYXMgbmVjZXNzYXJ5LiANDVRoZSBwcmltYXJ5 IG1vdGl2YXRpb24gYnkgY3JlYXRpbmcgdGhlc2UgYWJzdHJhY3QgaW50ZXJmYWNlcyBpcyB0byBh bGxvdyBtYXhpbXVtIHJldXNlIG9mIHRyYW5zcG9ydCwgZW5jb2RpbmcgbG9naWMsIGFuZCBjb3Jl IHByb3RvY29sIHByb2Nlc3NpbmcuIFVzaW5nIHRoaXMgZ2F0ZXdheSBzY2VuYXJpbywgbm8gbG9z cyBvZiBJUFAgc2VtYW50aWMgaW5mb3JtYXRpb24gaXMgaW5jdXJyZWQgZnJvbSBlbmQtdXNlciB0 byBJUFAgcHJpbnRlciBlbmRwb2ludC4gSW4gdGhlb3J5LCBpdCBtaWdodCBldmVuIGJlIHBvc3Np YmxlIHRvIGNvbnN0cnVjdCBnYXRld2F5cyB1c2luZyB0aGlzIG1vZGVsIHRoYXQgYXJlIGltbXVu ZSB0byBkaWZmZXJpbmcgSVBQIHZlcnNpb24gbnVtYmVycyBmcm9tIGNsaWVudCBlbmRwb2ludCB0 byBwcmludGVyIGVuZHBvaW50LiBUaGlzIGlzIGJlY2F1c2UgaW4gdGhpcyBleGFtcGxlLCBubyBt b2RpZmljYXRpb24gb2YgdGhlIElQUCBQRFUgaXRzZWxmIGlzIHBlcmZvcm1lZCB3aGVuIHJlbGF5 aW5nIGZyb20gdHJhbnNwb3J0IHRvIHRyYW5zcG9ydC4gVGhpcyBhc3N1bXB0aW9uIHdvdWxkIG9m IGNvdXJzZSBoYXZlIHRvIHVuZGVyZ28gdmFsaWRhdGlvbi4NDTQuMiBUcmFuc3BvcnQtc3BlY2lm aWMgSGVhZGVyDQ1UaGlzIHByb3Bvc2FsIGFsbG93cyBzb21lIHRyYW5zcG9ydC1zcGVjaWZpYyBj YXBhYmlsaXRpZXMgbm90IGV4cGxpY2l0bHkgYWxsb3dlZCAob3IgZ3VhcmFudGVlZCkgYnkgW0lQ UFBST1RdLiBUaGlzIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9uIHV0aWxpemVzIGEgSVBQLXNwZWNp ZmljIHRyYW5zcG9ydCBoZWFkZXIgdGhhdCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IG1hbmRhdG9y eSBmZWF0dXJlcyBkaXNjdXNzZWQgaW4gW0lQUE1PRF0uIFRoaXMgdHJhbnNwb3J0IGhlYWRlciBj YW4gYWxzbyBwcm92aWRlIGNhcGFiaWxpdGllcyBub3QgZXhwbGljaXRseSBwcm92aWRlZCBieSBb SVBQTU9EXS4gDQ1UaGUgdHJhbnNwb3J0IGhlYWRlciBpbmNsdWRlcyBmb3VyIGZpZWxkcywgQSBw ZHVMZW5ndGggZmllbGQgYW5kIGEgcGR1U3RhdHVzIGZpZWxkLiBUaGUgcGR1TGVuZ3RoIGZpZWxk IGRlbm90ZXMgdGhlIGxlbmd0aCwgaW4gb2N0ZXRzLCBvZiB0aGUgUERVLiBUaGUgcGR1U3RhdHVz IGZpZWxkIGluZGljYXRlcyB0aGUgc3RhdHVzIG9mIHRoZSBwYXJ0aWN1bGFyIFBEVSBiZWluZyBw cm9jZXNzZWQuIEEgbGlzdCBvZiBwb3NzaWJsZSBzdGF0dXMgY29kZXMgaXMgZGlzY3Vzc2VkIGlu IHNlY3Rpb24gNSBvZiB0aGlzIHByb3Bvc2FsLiBUaGUgaGVhZGVyIGl0c2VsZiBpcyBjb21wb3Nl ZCBvZiBBU0NJSSB0ZXh0IHdpdGggdGhlIHN5bnRheCBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2lu ZyBBQk5GOg0NWHB0LUhlYWRlciA9IHBkdVN0YXR1cyBTRVAgcGR1TGVuZ3RoIFNFUCBwZHUNDXBk dVN0YXR1cyA9IDEqRElHSVQNDXBkdUxlbmd0aCA9IDEqRElHSVQNDXBkdSA9IE9DVEVULVNUUklO Rw0NU0VQID0gMHgxM3gxMA0NT0NURVQtU1RSSU5HID0gKkJZVEUNDUJZVEUgPSAweDAwLi4weDI1 NQ0NVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gcmVxdWlyZXMgcmVnaXN0cmF0aW9uIG9mIGEgbmV3 IFVSSSBzY2hlbWUsICJJUFAiLCB0aGF0IGRlc2lnbmF0ZXMgYSBwYXJ0aWN1bGFyIGRlZmF1bHQg cG9ydCBudW1iZXIgZm9yIGNvbm5lY3RpbmcgdG8gSVBQIHNlcnZpY2VzIHVzaW5nIHRoZSB0cmFu c3BvcnQgc3BlY2lmaWVkIGJ5IHRoaXMgZG9jdW1lbnQuIE5vdGUgdGhhdCB0aGUgcmVnaXN0cmF0 aW9uIG9ubHkgc3BlY2lmaWVzIGEgZGVmYXVsdCBwb3J0IG51bWJlci4gQXBwZW5kaXggQSBvZiB0 aGlzIGRvY3VtZW50IGlzIHRoZSBjb21wbGV0ZSB0ZXh0IG9mIHRoZSBVUkwgcmVnaXN0cmF0aW9u LiBUaGUgcHJvcG9zZWQgVVJMIHN5bnRheCBpbmNsdWRlcyBhIGZpZWxkIGZvciBzcGVjaWZ5aW5n IHNvbWUgb3RoZXIgVENQIHBvcnQgbnVtYmVyIG90aGVyIHRoYW4gdGhlIGRlZmF1bHQuDQ01LiBU cmFuc3BvcnQgTGF5ZXIgU3RhdHVzIENvZGVzDQ1UaGUgZm9sbG93aW5nIHRyYW5zcG9ydC1zcGVj aWZpYyBlcnJvciBjb2RlcyBhcmUgZ3JvdXBlZCBpbnRvIHRocmVlIGRpZmZlcmVudCBjYXRlZ29y aWVzIG9mIHNldmVyaXR5OiBOb3JtYWwsIEVycm9yLCBhbmQgV2FybmluZy4gVGhlc2Ugc3RhdHVz IGNvZGVzIHdvdWxkIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWJzdHJhY3QgdHJhbnNwb3J0IGlu dGVyZmFjZSBwcmV2aW91c2x5IGRlc2NyaWJlZC4NDU5vcm1hbA0NU1VDQ0VTUyAtIHRyYW5zcG9y dCBsYXllciByZXF1ZXN0IGNvbXBsZXRlZCBzdWNjZXNzZnVsbHkNDUVycm9ycw0NRVJSLVBST1RP Q09MIC0gbWFsZm9ybWVkIHRyYW5zcG9ydCBsYXllciBwYWNrZXQgd2FzIHJlY2VpdmVkDUVSUi1U SU1FT1VUIC0gdGltZW91dCB3YWl0aW5nIGZvciByZXNwb25zZQ1FUlItRElTQ09OIC0gc2Vzc2lv biBhYm5vcm1hbGx5IGRpc2Nvbm5lY3RlZA1FUlItQkFEVkVSIC0gSVBQIHZlcnNpb24gbm90IHN1 cHBvcnRlZA1FUlItQkFEUERVIC0gSVBQIHByb3RvY29sIGVuY29kaW5nIG5vdCBzdXBwb3J0ZWQN RVJSLVdPVUxEQkxPQ0sgLSBJbml0aWF0aW5nIHRoaXMgb3BlcmF0aW9uIHdvdWxkIGNhdXNlIGFu IGluZGVmaW5pdGUgYmxvY2tpbmcgc3RhdGUgdG8gb2NjdXIuDUVSUi1JTlRFUk5BTCAtIEFuIGlu dGVybmFsIHRyYW5zcG9ydCBlcnJvciBvY2N1cnJlZC4NDVdhcm5pbmdzDQ1XQVJOLU1PUkUtREFU QSAtIE1vcmUgZGF0YSBpcyBhdmFpbGFibGUgZnJvbSB0aGUgdHJhbnNwb3J0IGxheWVyIGZvciB0 aGlzIHBhcnRpY3VsYXIgcmVxdWVzdC4gVGhpcyBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgbW9yZSB0 aGFuIG9uZSBpbmRpdmlkdWFsIHRyYW5zcG9ydCBsYXllciBwYWNrZXQgd2FzIG5lY2Vzc2FyeSB0 byBjb250YWluIGEgcGFydGljdWxhciBJUFAgbWVzc2FnZS4NDTYuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQ1UaGUgcHJvcG9zZWQgdHJhbnNwb3J0IHNwZWNpZmllcyB0aGUgdXNlIG9mIG9uZSBv ciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcgU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cml0 eSBMYXllciAoU0FTTCkgW1JGQzIyMjJdIHByb2ZpbGVzOg0NU1RBUlRUTFMgW1NUQVJUVExTXQ1B Tk9OWU1PVVMgW1JGQzIyNDVdDUNSQU0tTUQ1ICBbUkZDMjE5NV0NDVNBU0wgYWxsb3dzIHRoZSBw dWJsaWNhdGlvbiBvZiBvbmx5IG9uZSBVUkkgZm9yIHNlcnZpY2UgZGlzY292ZXJ5IG1lY2hhbmlz bXMgKGRpcmVjdG9yeSBzZXJ2aWNlcywgREhDUCwgZXRjKS4gVGhlIGV4aXN0aW5nIElQUC1vdmVy LUhUVFAgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyB0aGUgdXNlIG9mIGRpZmZlcmVudCBVUkkgcHVi bGljYXRpb25zIGZvciBzZWN1cmUgYW5kIG5vbi1zZWN1cmUgSVBQIHNlcnZpY2VzLiBTQVNMIG5l Z290aWF0aW9uIGlzIHBlcmZvcm1lZCAiaW4tYmFuZCIsIG92ZXIgYSBzaW5nbGUgY29ubmVjdGlv biwgdGhlcmVieSBlbGltaW5hdGluZyB0aGUgbmVlZCBmb3IgZGlmZmVyZW50IFVSSXMgZm9yIGRp ZmZlcmVudCBzZWN1cml0eSBtZWNoYW5pc21zLiBPZiB0aGUgdGhyZWUgcHJvZmlsZXMgc3BlY2lm aWVkIGFib3ZlLCBhbGwgYnV0IHRoZSBTVEFSVFRMUyBwcm9maWxlIGlzIGF2YWlsYWJsZSBmb3Ig cmVmZXJlbmNpbmcgYXMgYW4gUkZDLiBHaXZlbiB0aGF0IHRoaXMgbWVtbyAoSVBQIG92ZXIgVENQ L0lQKSBpcyBkYXRlZCBNYXJjaCAxOTk4LCB0aGUgZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIFNU QVJUVExTIHByb2ZpbGUgaXMgc2NoZWR1bGVkIGZvciBsYXN0IGNhbGwgYXQgdGhlIGJlZ2lubmlu ZyBvZiBBcHJpbCAxOTk4LiBBbnRpY2lwYXRlZCBSRkMgc3RhdHVzIGZvciB0aGlzIGRyYWZ0IGZh bGxzIHdpdGhpbiBhIHJlYXNvbmFibGUgdGltZSBwZXJpb2QgZm9yIGluY2x1c2lvbiBpbiB0aGlz IHByb3Bvc2FsLg0NVGhpcyBkb2N1bWVudCBzdWdnZXN0cyB0aGUgdXNlIG9mIGJvdGggQU5PTllN T1VTIGFuZCBDUkFNLU1ENSBhcyBNQU5EQVRPUlkgc2VjdXJpdHkgbWVjaGFuaXNtcy4gQm90aCBv ZiB0aGVzZSBtZWNoYW5pc21zIG9ubHkgcHJvdmlkZSBhdXRoZW50aWNhdGlvbiwgbm90IHByaXZh Y3kuIElmIHByaXZhY3kgaXMgcmVxdWlyZWQsIHRoZW4sIGxpa2UgdGhlIElQUCBtb2RlbCBkb2N1 bWVudCBzcGVjaWZpZXMsIFRMUyBzaG91bGQgYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgU1RBUlRU TFMgU0FTTCBwcm9maWxlLg0NVGhlIEFOT05ZTU9VUyBtZWNoYW5pc20gYWxsb3dzIHNpbWlsYXIg YWNjZXNzIHNlbWFudGljcyBhcyAiYW5vbnltb3VzIEZUUCIsIHVzaW5nIGp1c3QgYSBzaW1wbGUg Y2xlYXIgdGV4dCBpZCBzdHJpbmcgc3VjaCBhcyBhbiBlbWFpbCBhZGRyZXNzIG9yIG90aGVyIHNp bXBsZSBBU0NJSSBzdHJpbmcuDQ1DUkFNLU1ENSBpcyBhIHZlcnkgc2ltcGxlIG1lY2hhbmlzbSBm b3IgYXV0aGVudGljYXRpb24gdXNpbmcgaW5mb3JtYXRpb24gdGhhdCBpcyBub3QgcGFzc2VkIGFz IGNsZWFyIHRleHQuIENSQU0tTUQ1IGxpa2Ugb3RoZXIgTUQ1LWJhc2VkIGF1dGhlbnRpY2F0aW9u IHNjaGVtZXMsIHJlcXVpcmVzIHRoZSBrbm93bGVkZ2Ugb2YgYSBzaGFyZWQgc2VjcmV0IGJldHdl ZW4gY2xpZW50IGFuZCBwcmludGVyLiBTaGFyZWQgc2VjcmV0cyBkbyBub3QgbmVlZCB0byBiZSBr ZXB0IGZvciBhbGwgcG9zc2libGUgZW5kLXVzZXJzLiBSYXRoZXIsIGFkbWluaXN0cmF0b3JzIG1h eSB3YW50IHRvIHByb3ZpZGUgc2VjcmV0IGtleXMgdGhhdCBtYXAgdG8gZWl0aGVyIHNtYWxsIGdy b3Vwcywgb3IgZGVwYXJ0bWVudGFsIGFjY2VzcyBrZXlzLiBIb3dldmVyLCB0aGUgdXNlIG9mIGFn Z3JlZ2F0ZWQga2V5cyBkb2VzIGFsbG93IGEgZ3JlYXRlciBwb3NzaWJpbGl0eSBmb3Iga2V5cyB0 byBiZSByZXZlYWxlZCB0byBub24tYXV0aG9yaXplZCBwYXJ0aWVzLiBPbiB0aGUgb3RoZXIgaGFu ZCwgdGhpcyB0eXBlIG9mIHNlY3VyaXR5IG1heSBiZSBhY2NlcHRhYmxlIGZvciBjZXJ0YWluIGVu dmlyb25tZW50cyB0aGF0IGRvIG5vdCB3YW50IG9wZW4gYWNjZXNzIHRvIHNlcnZpY2VzKEFOT05Z TU9VUyksIGJ1dCBkbyBub3Qgd2FudCB0byBkZWFsIHdpdGggVExTLWJhc2VkIHNlY3VyaXR5LiBb UkZDMjEwNF0gY29udGFpbnMgYSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUga2V5ZWQtTUQ1 IG1ldGhvZCBlbXBsb3llZCBieSBDUkFNLU1ENSwgYXMgd2VsbCBhcyBleGFtcGxlIGNvZGUgdGhh dCBpbXBsZW1lbnRzIHRoZSBhbGdvcml0aG0uDQ0NNi4gUmVmZXJlbmNlcw0NW0lQUE1PRF0gRGVC cnkgUi4sIEhhc3RpbmdzIFQuLCBIZXJyaW90IFIuLCBJc2FhY3NvbiBTLiwgUG93ZWxsIFAuLCAi SW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wvMS4wOiBNb2RlbCBhbmQgU2VtYW50aWNzIiwgSW50 ZXJuZXQtRHJhZnQgZHJhZnQtaWV0Zi1pcHAtbW9kZWwtMDksIEphbnVhcnkgMTk5OA0NW0lQUFBS T1RdIEhlcnJpb3QgUi4sIEJ1dGxlciBTLiwgTW9vcmUgUC4sIFR1cm5lciBSLiwgIkludGVybmV0 IFByaW50aW5nIFByb3RvY29sLzEuMDogUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiIsIEludGVybmV0 LURyYWZ0IGRyYWZ0LWlldGYtaXBwLXByb3RvY29sLTA1LCBKYW51YXJ5IDE5OTgNDVtSRkMxNzU5 XSBTbWl0aCBSLiwgV3JpZ2h0IEYuLCBIYXN0aW5ncyBULiwgWmlsbGVzIFMuLCBHeWxsZW5za29n IEouLCAiUHJpbnRlciBNSUIiLCBSRkMgMTc1OSwgTWFyY2ggMTk5NQ0NW1JGQzIyNzNdIExldmkg RC4sIE1leWVyIFAuLCBTdGV3YXJ0IEIuLCAiU05NUHYzIEFwcGxpY2F0aW9ucyIsIFJGQyAyMjcz LCBKYW51YXJ5IDE5OTgNDVtSRkMyMDY4XSBGaWVsZGluZyBSLiwgR2V0dHlzIEouLCBNb2d1bCBK LiwgRnJ5c3R5ayBILiwgQmVybmVycy1MZWUgVC4sICJIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9j b2wgliBIVFRQLzEuMSIsIFJGQyAyMDY4LCBKYW51YXJ5IDE5OTcNDVtSRkMyMTE5XSBCcmFkbmVy IFMuLCAiS2V5d29yZHMgZm9yIFVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExl dmVscyIsIFJGQyAyMjE5LCBNYXJjaCAxOTk3DQ1bUkZDMjIyMl0gTXllcnMgSi4sICJTaW1wbGUg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVyIChTQVNMKSIsIFJGQyAyMjIyLCBPY3Rv YmVyIDE5OTcNDVtSRkMyMjQ1XSBOZXdtYW4gQy4sICJBbm9ueW1vdXMgU0FTTCBNZWNoYW5pc20i LCBSRkMgMjI0NSwgTm92ZW1iZXIgMTk5Nw0NW1JGQy0yMTA0XSBLcmF5Y3p5ayBILiwgQmVsbGFy ZSBNLiwgQ2FuZXR0aSBSLiwgIkhNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVu dGljYXRpb24iLCBSRkMgMjEwNCwgRmVicnVhcnkgMTk5Nw0NW1JGQy0yMTk1XSBLbGVuc2luIEou LCBDYXRvZSBSLiwgS3J1bXZpZWRlIFAuLCAiSU1BUC9QT1AgQVVUSG9yaXplIEV4dGVuc2lvbiBm b3IgU2ltcGxlIENoYWxsZW5nZS9SZXNwb25zZSIsIFJGQyAyMTk1LCBTZXB0ZW1iZXIgMTk5Nw0N W1NUQVJUVExTXSBOZXdtYW4gQy4sICJVc2luZyBUTFMgd2l0aCBJTUFQNCwgUE9QMywgYW5kIEFD QVAiLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC1uZXdtYW4tdGxzLWltYXBwb3AtMDMsIE1hcmNoIDE5 OTgNDQ1BcHBlbmRpeCBBIJYgIklQUCIgU2NoZW1lIFJlZ2lzdHJhdGlvbg0NVGhlIGZvbGxvd2lu ZyBJUFAgc2NoZW1lIHByb3Bvc2FsIGlzIG1lYW50IHRvIHN0YXJ0IGRlYmF0ZSBvbiBJUFAgc2No ZW1lZCBVUkxzLiBUaGUgc2NoZW1lIHN1Z2dlc3RlZCBiZWxvdyB3b3VsZCBiZSBhZHZlcnRpc2Vk IGJ5IHNlcnZlcnMgdG8gcG90ZW50aWFsIGNsaWVudHMuDQ1JUFA6Ly9ob3N0LmRvbWFpbls6cG9y dF0NDQ1DbGllbnRzIGF0dGVtcHRpbmcgYWNjZXNzIHRvIGEgcmVzb3VyY2UgaWRlbnRpZmllZCBi eSB0aGUgIklQUCIgc2NoZW1lIE1VU1QgdXRpbGl6ZSB0aGUgSVBQIHRyYW5zcG9ydCBtYXBwaW5n IHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50Lg0NDRgAoQEApNAvpeA9pggHpwgHqKAFqaAFqgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADAAByHQAA7B8AAPAkAABQJgAAUiYAAKEoAAA5QwAA4UMAAChJ AABCSQAAAP0A/QD9AP0A+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACdQEAA10DAAAKAAMAAEgDAACQAwAAkQMAAJIDAADHAwAAyAMAAMkDAADdAwAA3gMA AB8EAABjBAAApwQAAM0EAADOBAAA0wUAANQFAAAYBgAAXgYAAJwGAADdBgAA+gYAAPsGAAD8BgAA BwcAAAgHAAB0CQAAdQkAAIAJAACBCQAA2goAANsKAABLDAAATAwAAHQMAAB1DAAAFxAAABgQAAB/ EAAAgBAAAMAQAADBEAAA7hAAACwRAABqEQAAqBEAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAAAAAAAAAAAAAAEPAC2oEQAA1REAAAISAABAEgAAfhIAALwSAADpEgAAJxMAAGUTAACjEwAA 0BMAANETAADSEwAA+RMAAPoTAAD7EwAAZhUAAGcVAAAqFwAAKxcAAMMXAADEFwAA3hcAAN8XAAAV GQAAFhkAAEscAABMHAAAaBwAAGkcAABxHQAAch0AAIcdAADOHQAAFR4AAFMeAACUHgAA2x4AACIf AABhHwAAox8AANwfAADsHwAA7R8AAPQfAAD1HwAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAA AAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAAAAAAAAABAAAAAQ8ALfUfAABOIAAATyAAALQgAAC1IAAAEyIAABQiAABwIgAAcSIAAOMiAADk IgAAjyMAAJAjAACHJAAAiCQAAO4kAADvJAAA8CQAAFAmAABRJgAAUiYAAJAmAACuJgAAzSYAAAsn AABMJwAAiScAANAnAAAQKAAAUigAAJEoAAChKAAAoigAAKkoAACqKAAA7SgAAO4oAABAKQAAQSkA AKspAACsKQAALyoAADAqAACVKgAAlioAAAgrAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAPwAAAAAAAD+AAAAAAAA/AAAAAAAAPwA AAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAA AAAAAPwAAAAAAAD8AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAAAAAAAAAEAAAABDwAtCCsAAAkrAACDKwAAhCsAANMrAADUKwAAKywAACwsAADxLAAA8iwAANMt AADULQAAPTAAAD4wAABcMAAAXTAAALIxAACzMQAAPzMAAEAzAABtMwAAbjMAAIIzAACDMwAAlzMA AJgzAACrMwAArDMAALozAAC7MwAA0DMAANEzAADkMwAA5TMAAKU1AACmNQAAxjUAAMc1AACsNgAA rTYAALQ2AAC1NgAA7jYAAO82AAD2NgAA9zYAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AAAAAAAAAAAAAAEPAC33NgAANDcAAF83AACMNwAAszcAAOQ3AABCOAAAdzgAAHg4AACBOAAAgjgA AF45AABfOQAAejkAAHs5AAAIOgAACToAAB06AAAxOgAARToAAEY6AABHPQAASD0AAGo+AABrPgAA Fz8AABg/AAB3QgAAeEIAAHlCAACHQgAAiEIAADhDAAA5QwAA4UMAAOJDAABMRAAATUQAAKREAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA2QAA AAAAANkAAAAAAADZAAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AADXAAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAAAAAAAAAAAAAQAAACQPAA0LETgE E5j+DDT/AQAIAAABgAAAAAA4BAAAAAAAAC0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwUAATgEAAAAAQ8AJqREAAClRAAALkUAAC9FAACVRQAAlkUAAPRFAAD1RQAAPkYAAD9GAAC5RgAA ukYAAEBHAABBRwAAtkcAALdHAAC4RwAA30cAAOBHAACASAAAgUgAAJpIAACbSAAAnEgAACZJAAAn SQAAKEkAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA+gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAP4AAAAAAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Aw8AEdACAAABDwAaDgARAAgAAQBLAA8AAAAAABoAAEDx/wIAGgAGTm9ybWFsAAIAAAADAGEJBAAA AAAAAAAAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAA AAAAAB4A/k8BAPIAHgAKUGxhaW4gVGV4dAACAA8AAwBdAwAAGAD+T/EAAgEYAARJRVRGAAUAEAAQ OAQAAAAAAAAAKEYAAAMAKEkAAAEA/////wADAABCSQAAJQAAAwAAqBEAAPUfAAAIKwAA9zYAAKRE AAAoSQAAJgAnACgAKQAqACsA/0BDABUSkAEAAFRpbWVzIE5ldyBSb21hbgAMEJABAgBTeW1ib2wA CyKQAQAAQXJpYWwAETGQAQAAQ291cmllciBOZXcAIgAEAAAAgBgAANACAABoAQAAAABnyiNmZ8oj ZgnDI0YBAAAAAAAmCgAA2TkAAAEAHQAAAAQAgxB7AAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAAAA AAAAAHMAAABHSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSYW5keSBUdXJuZXIAAAAMUmFuZHkgVHVybmVyDFJhbmR5IFR1cm5lcgAAAAAA AAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA AAAAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAP7////9////MQAAAP7///85AAAA/v////////////////////////// ///////////////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAABCAAAAAACQBAAAAAAAAAAAAAAAAAAA//// /wAAAAAAAAAAAQAAAOEuRQ0WAAUB//////////8BAAAAAAkCAAAAAADAAAAAAAAARgAAAAA0ADQA LQA0AGCS7wAVWL0BMAAAAAAEAAAtADgAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAwADAAMAB9 ACMAMgAuADAAIwAwACMAQwA6AFwAVwBJAE4ARABPABoAAgECAAAAAwAAAP////9WAEIARQBcAE0A UwBGAG8AcgBtAHMALgBFAFgARAAjAE0AaQAAAAAA+lkAAG8AZgABAEMAbwBtAHAATwBiAGoAAAAu ADAAIABPAGIAagBlAGMAdAAgAEwAaQBiAHIAYQByAHkAAAAAAGMAMwA1ADEAEgACAf////////// /////yoARAABAAAAVABoAGkAcwBEAG8AAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAQwBOAAUAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAABAAAAAAAAAP////9oAAAAAAAAAAAA AAAoAAIB/////wQAAAD/////sGBKAAAA/f///wAAAAAAACAAAGAAAAAAAAAAAAAAAAAAAAAAAgAA AAgCAAAAAAAAAQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAP7///8MAAAA DQAAAA4AAAAPAAAA/v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8ACQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERv Y3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuNgD0ObJxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9o EKuRCAArJ7PZMAAAANgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADwAAAABAAAAPwAAAAFAAAA FAEAAAYAAAAgAQAABwAAACwBAAAIAAAAPAEAAAkAAABUAQAAEgAAAGABAAAKAAAAiAEAAAsAAACU AQAADAAAAKABAAANAAAArAEAAA4AAAC4AQAADwAAAMABAAAQAAAAyAEAABMAAADQAQAAAgAAAOQE AAAeAAAASAAAAElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUmFuZHkgVHVybmVyAB4AAAABAAAAAAA1AB4AAAANAAAAUmFuZHkgVHVybmVy AAAPAB4AAAABAAAAAA8AAB4AAAABAAAAAAAAAB4AAAAHAAAATm9ybWFsAAAeAAAADQAAAFJhbmR5 IFR1cm5lcgUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACwAAACABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAEIAAAAAAJAEAAAAAAAAAAAAAAAAAAD/////AAAA AAAAAAABAAAA4S5FDRYABQH//////////wEAAAAACQIAAAAAAMAAAAAAAABGAAAAAOB36QAVWL0B AJ1eABVYvQEwAAAAAAQAAC0AOABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAADAAMAAwAH0AIwAy AC4AMAAjADAAIwBDADoAXABXAEkATgBEAE8AGgACAQIAAAADAAAA/////1YAQgBFAFwATQBTAEYA bwByAG0AcwAuAEUAWABEACMATQBpAAAAAAD6WQAAbwBmAAEAQwBvAG0AcABPAGIAagAAAC4AMAAg AE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAYwAzADUAMQASAAIB//////////////// KgBEAAEAAABUAGgAaQBzAEQAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAABDAE4ABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAEAAAAAAAAA/////2gAAAAAAAAAAAAAACgA AgH/////BAAAAP////+wYEoAAAD9////AAAAAAAAIAAAYAAAAAAAAAAAAAAAAAAAAAACAAAACAIA AAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAc AAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoA AAArAAAALAAAAP7///////////////7///85AAAA/v///zEAAAD9//////////////////////// ///////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAHgAAAAIAAAAxAEoAHgAAAB4AAABNaWNyb3NvZnQgV29yZCBmb3IgV2luZG93cyA5NQBKAEAA AAAAAAAAAAAAAEAAAAAA1vSuYFe9AUAAAAAAkvPkFFi9AUAAAAAAkvPkFFi9AQMAAAABAAAAAwAA ACYKAAADAAAA2TkAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCT lwgAKyz5rjAAAADwAAAABwAAAAEAAABAAAAADwAAAEgAAAAFAAAAcAAAAAYAAAB4AAAACwAAAIAA AAAQAAAAiAAAAAwAAACQAAAAAgAAAOQEAAAeAAAAHgAAAFNoYXJwIExhYm9yYXRvcmllcyBvZiBB bWVyaWNhAEoAAwAAAHsAAAADAAAAHQAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAAAB4AAABIAAAA SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSYW5keSBUdXJuZXIAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------ =_NextPart_000_01BD57D2.16DEA2C0-- From ipp-owner@pwg.org Wed Mar 25 16:27:05 1998 Delivery-Date: Wed, 25 Mar 1998 16:27:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA10658 for ; Wed, 25 Mar 1998 16:26:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA13003 for ; Wed, 25 Mar 1998 16:29:27 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA15461 for ; Wed, 25 Mar 1998 16:26:47 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Mar 1998 16:20:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14930 for ipp-outgoing; Wed, 25 Mar 1998 16:20:36 -0500 (EST) Message-Id: <3519741C.A50232BC@dazel.com> Date: Wed, 25 Mar 1998 15:16:12 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <3.0.1.32.19980324153634.01213b10@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Tom Hastings wrote: > > For the IPP telecon, Wed, 3/25: > > Roger, Bob, and I have been working on various dictionary proposals. > > ... > > Briefly, the scheme isn't really a dictionary at all (previous > versions were). Other earlier versions were adding a new addressing > mechanism for attributes in dictionaries. > > This proposal adds no new addressing mechanisms, > but justs add a new out-of-band value to encode the new Model attribute > syntax of 1setOf 1setOf (doubly nested values). Instead, we use the > idea of attributes with parallel values, like we already have for > "printer-uri-supported" and "uri-security-supported". As discussed in the telecon today, I think that the parallel attribute idea is a bad one... it does not scale well, it is difficult for users to understand and get right, it is error-prone, etc. Our experience from the implementation of parallel attributes in DPA has not been a good one. All in all, I believe that data structures are a good idea, but trying to describe data structures using parallel attributes does not work. > ... > > I've left the rejected example that uses the 'dictionary' attribute syntax > in the document. I've also listed the alternatives that we considered > and the reasons for rejecting them. > > ... I simply do not understand why the original concept of a dictionary value tag (with its associated value length) would not work well. This is the example that is shown in Tom's document. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Mar 25 21:03:58 1998 Delivery-Date: Wed, 25 Mar 1998 21:03:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA14347 for ; Wed, 25 Mar 1998 21:03:42 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA13910 for ; Wed, 25 Mar 1998 21:06:12 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16453 for ; Wed, 25 Mar 1998 21:03:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Mar 1998 20:59:04 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15903 for ipp-outgoing; Wed, 25 Mar 1998 20:58:52 -0500 (EST) Message-Id: <3.0.1.32.19980325175745.031e6d90@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Mar 1998 17:57:45 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Minutes from PWG IPP phone conference, 3/25/98 Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Minutes from PWG IPP Phone Conference 980325 ============================================ Notes taken by Carl-Uno Manros and Tom Hastings. Attendees: Ron Bergman Dataproducts Tom Hastings Xerox Carl-Uno Manros Xerox Ira Mcdonald High North Randy Turner Sharp Don Wright Lexmark Jim Walker DAZEL Peter Zehler Xerox Harry Lewis IBM Jay Martin Underscore Agenda: Carl-Uno Manros led the meeting. For today's agenda topics, he said that he would like to revisit the IPP notification and the host-to-device home work assignments and DL discussions. Status of IPP in the IESG and IPP LA Agenda: Carl-Uno reported that contacts with Keith Moore make it clear that we will not see any feedback from him or the IESG in time for IETF41 next week, and probably not before the PWG IPP meeting in Portland either. The IETF41 IPP agenda is therefore limited to the discussion of IPP notifications and mapping of directory attributes to SLP and LDAP. Carl-Uno then made a quick review of other sessions in IETF41 that might be of interest to IPP WG members coming to LA. Notifications: Then the discussion of IPP notifications started. Carl-Uno suggested that we already have a number of inputs that could be used to work out a solution for the simple kind of user notifications intended in the IETF IPP work item. It was clear from the following discussion that the PWG needs to view notifications in a wider scenario that takes into account host-to-device, administrator etc. requirements, but that this work could be done in parallel to developing a simple notification solution for IPP 1.0. The notification specification is expected to take the form of a standards track IETF RFC, which specifies additional attributes to what is in the Model document. Although the notification specification will be optional to implement, we should aim for it to become a standards track document. Discussions were held around how much flexibility the user needs to have in specifying what should be returned in a notification. Some suggested that standardized packages should be enough, but there were also requirements to have full flexibility to specify the exact attributes (including private attribute extensions) to be returned. Unless the solution gets too complex, it looks like we should expect a few standard packages to be specified and supported, but that implementations could optionally support attribute level specification. There was also discussion about the format of the notification. Everybody seemed to agree that it should be in the form of a MIME type, which is identical or very similar to the application/ipp Mime type and should look more or less identical to the List-Job-Attribute response format. There also seemed to be agreement that the life cycle of a notification request is the same as for the print job. As part of this discussion, Tom Hastings introduced the DL draft on how a directory attribute syntax could be defined. Bob Herriot and Roger deBry had worked with Tom on this, but had not yet seen the current version, when had been written by Tom. There was opposition from Jim Walker and others about the parallel attribute value approach taken in the proposal and Tom undertook to work out a full proposal based on the original idea of introducing a new syntax for comparison. Carl-Uno when summing up the discussion about notifications asked for volunteers to write up a proposal based on the earlier text in the model document, the current requirements document, Tom's revised proposal for the directory attribute, and today's discussion. Tom Hastings and Harry Lewis will try to have a draft ready for discussion in Portland (April 8-9) with Jim Walker's review, if there is time. PWG Host-to-Device protocol discussion: The next agenda item was the alternative approaches to arrive at a suitable solution for a host-to-device protocol (which is not intended as an IETF standard). Don Wright introduced his PWG draft called "IPP to IEEE 1284.1 Mapping". This describes how IEEE 1284.1, a.k.a. TIP/SI, could be used to transfer IPP attributes and document data from a print server to a print device. A few minor extensions would be needed to the IEEE TIP/SI standard itself to support the proposal. In addition, the PWG would develop a PWG standard for a IPP Logical Unit (LU) that works with TIP/SI that accepts IPP attributes directly. Areas for further study would be internationalization and security, plus an explicit mapping of TIP/SI to TCP/IP. Don wanted to have further discussion of the document in the Portland IPP meeting before investing more work in refining the draft. Randy Turner then introduced his proposal on how to map IPP directly on TCP/IP, which he claimed would solve most of the problems that have been stated against using IPP as a host-to-device protocol. The following discussion indicated that people wanted the two channel approach that is used in TIP/SI and CPAP (one for bi-directional control information and one for data) to be added to Randy's proposal. Randy undertook to have a revised version of the proposal ready for discussion in Portland. It will introduce a second pull-only data channel and rewrite some of the proposal for a new URI scheme. Meeting adjourned at 12:30 PM. There will not be any phone conferences for the next two weeks due to the IETF41 and PWG IPP meetings. The next teleconference will be held on April 15 at 10:00am PST. From ipp-owner@pwg.org Thu Mar 26 19:06:57 1998 Delivery-Date: Thu, 26 Mar 1998 19:06:57 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA11548 for ; Thu, 26 Mar 1998 19:06:56 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA17791 for ; Thu, 26 Mar 1998 19:09:26 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA28681 for ; Thu, 26 Mar 1998 19:06:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 26 Mar 1998 18:58:38 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28150 for ipp-outgoing; Thu, 26 Mar 1998 18:58:26 -0500 (EST) Message-Id: <3.0.1.32.19980326153352.009279b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Mar 1998 15:33:52 PST To: ipp@pwg.org From: Dan Wing (by way of Carl-Uno Manros ) Subject: IPP> ADM - BOF announcement: WASRV (Wide Area Service Location) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org This was announced to the IFAX group. It might also be of interest to the IPP group. Carl-Uno --- FYI, There will be a BOF at IETF 41 concerning Wide Area Service Location - There has been recent interest in mechanisms for discovery of services across the global internet. Such interest has manifested itself in numerous papers, standards proposals, and commercial tools. However, what is meant by wide area service location seems to vary in all cases. The organizers of the WASRV BOF will advocate a set of architectural principals for a successful wide area service location system. In brief, discovery should not require a priori knowledge or configuration to perform, should be based on attribute based search criteria and allow rapid, scalable access to service information. Services should be discoverable only when they are actually available and ideally advertise themselves automatically. These principals will be discussed and proposals for solutions to the wide area service location problem will be presented. The goal of the BOF is to determine whether there is sufficient interest in the problem, as we agree to define it, and whether the technical proposals presented will arrive at a feasible technical solution. Please see http://www.bell-labs.com/mailing-lists/wasrv/ for a list of documents including "WASRV Architectural Principles" which describe in detail the issues believe a chartered WASRV WG in the Internet area should address. My apologies if you receive this announcement more than once. The BOF is currently scheduled for 1530-1730 Thursday in the Avalon room (but check your schedules when you arrive for changes :-) Erik Guttman WASRV BOF Cochair ----------------------------------------------------------------------- Erik Guttman http://www.neato.org/~femur/eg.html Sun Microsystems Erik.Guttman@sun.com SMCC Advanced Network Development +49 7263 911 700 From ipp-owner@pwg.org Fri Mar 27 15:10:35 1998 Delivery-Date: Fri, 27 Mar 1998 15:10:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA08717 for ; Fri, 27 Mar 1998 15:10:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20655 for ; Fri, 27 Mar 1998 15:13:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA10248 for ; Fri, 27 Mar 1998 15:10:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 27 Mar 1998 14:57:54 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09690 for ipp-outgoing; Fri, 27 Mar 1998 14:57:41 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charse Message-ID: <5030100019004296000002L062*@MHS> Date: Fri, 27 Mar 1998 14:56:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA08717 I found it rather easy to implement when I did it. "ipp-attribute-fidelity" is another special attribute because it, too, determines how all attributes should be interpreted. I think there's no getting around saving some state during initial attribute processing which is later used to evaluate the operation as a whole. Certainly you could save the raw form of any 'text' or 'name' strings during a first pass over the attributes, then interpret them using the supplied "attributes-charset" and "attributes-natural-language" in a later phase From ipp-owner@pwg.org Mon Mar 30 17:31:17 1998 Delivery-Date: Mon, 30 Mar 1998 17:31:18 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA18056 for ; Mon, 30 Mar 1998 17:31:17 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04867 for ; Mon, 30 Mar 1998 17:33:49 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13853 for ; Mon, 30 Mar 1998 17:31:19 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 30 Mar 1998 17:21:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13300 for ipp-outgoing; Mon, 30 Mar 1998 17:21:15 -0500 (EST) Message-Id: <199803302218.OAA11801@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 30 Mar 1998 14:22:40 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charse In-Reply-To: <5030100019004296000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Yes, I realize that there is a work-around, but none of us should have to deal with this mess in our implementations. Instead, we need to change the spec so that the implementations will be simpler. The lack of ordering with regard to charset and language has no value. "ipp-attribute-fidelity" is not the same problem because its value applies to the following group. That is, the ordering rules work in this case. Bob Herriot At 11:56 AM 3/27/98 , Carl Kugler wrote: >I found it rather easy to implement when I did it. > >"ipp-attribute-fidelity" is another special attribute because it, too, >determines how all attributes should be interpreted. > >I think there's no getting around saving some state during initial attribute >processing which is later used to evaluate the operation as a whole. > >Certainly you could save the raw form of any 'text' or 'name' strings during a >first pass over the attributes, then interpret them using the supplied >"attributes-charset" and "attributes-natural-language" in a later phase > From ipp-owner@pwg.org Mon Mar 30 20:59:13 1998 Delivery-Date: Mon, 30 Mar 1998 20:59:14 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA05298 for ; Mon, 30 Mar 1998 20:59:12 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA16967 for ; Mon, 30 Mar 1998 21:01:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14633 for ; Mon, 30 Mar 1998 20:59:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 30 Mar 1998 20:53:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14074 for ipp-outgoing; Mon, 30 Mar 1998 20:53:15 -0500 (EST) Message-Id: <199803310147.RAA12009@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 30 Mar 1998 17:51:25 -0800 To: walker@dazel.com, Tom Hastings From: Robert Herriot Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Cc: ipp@pwg.org In-Reply-To: <3519741C.A50232BC@dazel.com> References: <3.0.1.32.19980324153634.01213b10@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA05298 Jim, I have similar concerns about the use of attributes with parallel values. I have this nagging feeling that we are going to regret this direction. But thus far it has been the least bad solution that we have found. We have arrived at this unfortunate point because the current binary encoding has painted us into a corner. An XML encoding would allow a very simple solution for dictionaries. We considered having dictionary members appear as normal attributes surrounded by begin-dictionary and end-dictionary "values", but this solution would potentially create name conflicts with names at the top level for parsers that don't know about dictionaries. This solution works if we force a version change or all existing parsers add support for it. We considered having a dictionary structure which would be a new type whose values are nested in an existing value. For small dictionaries, this is the obvious and simple solution, but if we kept the existing limit of 1023 octets per value, some dictionaries would be impossible. Picking a value that is large enough for all likely dictionaries but doesn't burden small implementations was difficult and didn't seem to solve the problem. We looked at ways to keep the 1023 limit and instead chunk the dictionary into multiple values. I had a reasonable but very ugly solution which concatenated the chunks together and use "begin-dictionary" and "end-dictionary" "values" to indicate the structure. By turning the dictionary problem into a naming problem, we seem to have side stepped all of these issues, but as you point out data structures were invented for a reason. Do you have any suggestions for what we should do? Bob Herriot At 01:16 PM 3/25/98 , James Walker wrote: >Tom Hastings wrote: >> >> For the IPP telecon, Wed, 3/25: >> >> Roger, Bob, and I have been working on various dictionary proposals. >> >> ... >> >> Briefly, the scheme isn't really a dictionary at all (previous >> versions were).  Other earlier versions were adding a new addressing >> mechanism for attributes in dictionaries. >> >> This proposal adds no new addressing mechanisms, >> but justs add a new out-of-band value to encode the new Model attribute >> syntax of 1setOf 1setOf (doubly nested values).  Instead, we use the >> idea of attributes with parallel values, like we already have for >> "printer-uri-supported" and "uri-security-supported". > >As discussed in the telecon today, I think that the parallel attribute >idea is a bad one... it does not scale well, it is difficult for users >to understand and get right, it is error-prone, etc.  Our experience >from the implementation of parallel attributes in DPA has not been a >good one.  All in all, I believe that data structures are a good idea, >but trying to describe data structures using parallel attributes does >not work. > >> ... >> >> I've left the rejected example that uses the 'dictionary' attribute syntax >> in the document.  I've also listed the alternatives that we considered >> and the reasons for rejecting them. >> >> ... > >I simply do not understand why the original concept of a dictionary >value tag (with its associated value length) would not work well. >This is the example that is shown in Tom's document. > >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX > From ipp-owner@pwg.org Mon Mar 30 23:15:56 1998 Delivery-Date: Mon, 30 Mar 1998 23:15:56 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA12386 for ; Mon, 30 Mar 1998 23:15:55 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA01182 for ; Mon, 30 Mar 1998 23:18:25 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA15356 for ; Mon, 30 Mar 1998 23:15:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 30 Mar 1998 23:11:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA14814 for ipp-outgoing; Mon, 30 Mar 1998 23:11:13 -0500 (EST) From: duff@field.com Date: Mon, 30 Mar 1998 23:10:41 -0500 (EST) Message-Id: <199803310410.XAA08446@mail.interhop.net> To: Subject: IPP> about filedudes Sender: ipp-owner@pwg.org hey, found this real fast download site www.filedudes.com, check it out! From ipp-owner@pwg.org Tue Mar 31 12:58:48 1998 Delivery-Date: Tue, 31 Mar 1998 12:58:49 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04125 for ; Tue, 31 Mar 1998 12:58:48 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA25616 for ; Tue, 31 Mar 1998 13:01:16 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28028 for ; Tue, 31 Mar 1998 12:58:48 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 31 Mar 1998 12:50:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27487 for ipp-outgoing; Tue, 31 Mar 1998 12:49:53 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Robert Herriot'" , walker@dazel.com, Tom Hastings Cc: ipp@pwg.org Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Date: Tue, 31 Mar 1998 09:49:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I agree - this is one of the areas where we all agreed that XML won with no debate whatsoever. We all know the history of this debate (XML or not XML). We decided to keep the current protocol for IPP1. The informal consensus in maui was that IPP2 (which I think the dictionary discussion is aimed at) must be XML-based. If we dont make that change then we will regret it for ever and ever. > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Monday, March 30, 1998 5:51 PM > To: walker@dazel.com; Tom Hastings > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing > dictionary-like capability > > Jim, > > I have similar concerns about the use of attributes with parallel values. > I have this nagging feeling that we are going to regret this direction. > But thus far it has been the least bad solution that we have found. > > We have arrived at this unfortunate point because the current binary > encoding has painted us into a corner. An XML encoding would > allow a very simple solution for dictionaries. > > We considered having dictionary members appear as normal attributes > surrounded by begin-dictionary and end-dictionary "values", but this > solution > would potentially create name conflicts with names at the top level for > parsers > > that don't know about dictionaries. This solution works if we force a > version > change or all existing parsers add support for it. > > We considered having a dictionary structure which would be a new type > whose values are nested in an existing value. For small dictionaries, this > is the obvious and simple solution, but if we kept the existing limit > of 1023 octets per value, some dictionaries would be impossible. Picking > a value that is large enough for all likely dictionaries but doesn't > burden > small implementations was difficult and didn't seem to solve the problem. > We looked at ways to keep the 1023 limit and instead chunk the dictionary > into multiple values. I had a reasonable but very ugly solution which > concatenated the chunks together and use "begin-dictionary" and > "end-dictionary" "values" to indicate the structure. > > By turning the dictionary problem into a naming problem, we seem to have > side stepped all of these issues, but as you point out data structures > were > invented for a reason. > > Do you have any suggestions for what we should do? > > Bob Herriot > > > > > At 01:16 PM 3/25/98 , James Walker wrote: > >Tom Hastings wrote: > >> > >> For the IPP telecon, Wed, 3/25: > >> > >> Roger, Bob, and I have been working on various dictionary proposals. > >> > >> ... > >> > >> Briefly, the scheme isn't really a dictionary at all (previous > >> versions were).  Other earlier versions were adding a new addressing > >> mechanism for attributes in dictionaries. > >> > >> This proposal adds no new addressing mechanisms, > >> but justs add a new out-of-band value to encode the new Model attribute > >> syntax of 1setOf 1setOf (doubly nested values).  Instead, we use the > >> idea of attributes with parallel values, like we already have for > >> "printer-uri-supported" and "uri-security-supported". > > > >As discussed in the telecon today, I think that the parallel attribute > >idea is a bad one... it does not scale well, it is difficult for users > >to understand and get right, it is error-prone, etc.  Our experience > >from the implementation of parallel attributes in DPA has not been a > >good one.  All in all, I believe that data structures are a good idea, > >but trying to describe data structures using parallel attributes does > >not work. > > > >> ... > >> > >> I've left the rejected example that uses the 'dictionary' attribute > syntax > >> in the document.  I've also listed the alternatives that we considered > >> and the reasons for rejecting them. > >> > >> ... > > > >I simply do not understand why the original concept of a dictionary > >value tag (with its associated value length) would not work well. > >This is the example that is shown in Tom's document. > > > >...walker > > > >-- > >Jim Walker > >System Architect/DAZEL Wizard > >DAZEL Corporation, Austin, TX > > From ipp-owner@pwg.org Tue Mar 31 17:07:09 1998 Delivery-Date: Tue, 31 Mar 1998 17:07:09 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA10725 for ; Tue, 31 Mar 1998 17:07:09 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15803 for ; Tue, 31 Mar 1998 17:09:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA29754 for ; Tue, 31 Mar 1998 17:06:25 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 31 Mar 1998 17:01:17 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29114 for ipp-outgoing; Tue, 31 Mar 1998 17:01:04 -0500 (EST) Message-Id: <3.0.1.32.19980331135443.009917f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 31 Mar 1998 13:54:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - REMINDER - IETF41 IPP meeting April 1 at 1 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hope to see at least a few faces from the IPP group :-) Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Mar 31 18:30:46 1998 Delivery-Date: Tue, 31 Mar 1998 18:30:46 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id SAA03229 for ; Tue, 31 Mar 1998 18:30:45 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12669 for ; Tue, 31 Mar 1998 18:33:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00523 for ; Tue, 31 Mar 1998 18:30:44 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 31 Mar 1998 18:26:41 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29932 for ipp-outgoing; Tue, 31 Mar 1998 18:26:29 -0500 (EST) Message-ID: <19980331232607.16368.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> printer-uri and job-uri Content-Type: text/plain Date: Tue, 31 Mar 1998 15:26:07 PST Sender: ipp-owner@pwg.org Greetings. There are two issues related to printer-uri and job-uri that need some clarifications. Issue1: In the IPP Model document, there is no specification for the value-tags of "printer-uri" and "job-uri" attributes in a IPP request. According to the IPP Model document, section 3.1.3, the "printer-uri" attribute contains the Printer object's URIs which is one of the values in the Printer object's "printer- uri-supported" attribute. This implies that the value-tag of "printer-uri" attribute must be of type "uri". Similarly, the value-tag of "job-uri" attribute should be "uri" as well. Issue 2: In the "Note:" section of 3.2.1.1 in the IPP Model document, it was mentioned that "The simplest Print-Job Request consists of just the Document Content, the "attributes- charset" and "attributes-natural-language" operation attributes, and nothing else." However, in the description of Print-Job Request of section 15.3.4.3, the "printer-uri" attribute is specified as a MUST (indicated by (M)) and also in section 3.1.3 of the same document, it was indicated that either "printer-uri" or "job-uri" MUST appear in every operation request. There seems to be some inconsistency here. Please send your remarks/comments to the mailing list. -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Wed Apr 1 03:41:16 1998 Delivery-Date: Wed, 01 Apr 1998 03:41:26 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id DAA04091 for ; Wed, 1 Apr 1998 03:40:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA09241 for ; Wed, 1 Apr 1998 03:43:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA10043 for ; Wed, 1 Apr 1998 03:40:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 03:34:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA09174 for ipp-outgoing; Wed, 1 Apr 1998 03:34:32 -0500 (EST) Message-Id: <3.0.1.32.19980401003250.011cd8d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 1 Apr 1998 00:32:50 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated 'dictionary' attribute syntax proposal posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've posted an updated proposal for a new 'dictionary' attribute syntax. As agreed at last weeks telecon, I've gone back to the original proposal that introduces a new 'dictionary' attribute syntax. There was implementation experience that parallel attributes is difficult for clients and servers. The consensus was that with the 'dictionary' attribute syntax that some maximum length, like 2047 octets, would be sufficient and there there was no need to have a way to provide for bigger dictionaries. We agreed that we are not trying to solve the dictionary problem for all applications, only for printing. I've also used "job-notify" examples of a dictionary that needs multiple valued attributes in the dictionary. This is only an example, not Harry's and my action item on notification. But it does show how the 'dictionary' mechanism will be useful for specifying notification when submitting a job. The files are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-attr-syntax-v092.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-attr-syntax-v092.pdf The PDF has line numbers. I'd like to put review of this proposal on the agenda for next week. Also lets start the discussion via e-mail. Thanks, Tom From ipp-owner@pwg.org Wed Apr 1 04:02:59 1998 Delivery-Date: Wed, 01 Apr 1998 04:03:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id EAA04215 for ; Wed, 1 Apr 1998 04:02:54 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA16466 for ; Wed, 1 Apr 1998 04:05:23 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA11718 for ; Wed, 1 Apr 1998 04:02:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 03:56:51 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA10873 for ipp-outgoing; Wed, 1 Apr 1998 03:56:37 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: ipp@pwg.org Message-Id: Date: Wed, 1 Apr 1998 09:56:26 +0100 Subject: IPP> IPP: Job template attributes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org I am wondering, are the job template attributes only for information and administration? E.g. if an IPP Server recieves the job template attribute 'copies n' must the IPP Server make the n copies, or does the attribute only tell that the following job will me maked in n copies. Henrik Holst ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (+45) 44366271 Fax: (+45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Wed Apr 1 15:31:01 1998 Delivery-Date: Wed, 01 Apr 1998 15:31:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA17252 for ; Wed, 1 Apr 1998 15:31:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28097 for ; Wed, 1 Apr 1998 15:33:34 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16857 for ; Wed, 1 Apr 1998 15:31:03 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:21:35 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15808 for ipp-outgoing; Wed, 1 Apr 1998 15:21:25 -0500 (EST) Message-ID: <3522A1BA.E367AFCD@underscore.com> Date: Wed, 01 Apr 1998 15:21:14 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore , ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, Sorry, but I forgot to include the message I referenced in that last message. ...jay Paul Moore wrote: > > I agree - this is one of the areas where we all agreed that XML won with no > debate whatsoever. > > We all know the history of this debate (XML or not XML). We decided to keep > the current protocol for IPP1. The informal consensus in maui was that IPP2 > (which I think the dictionary discussion is aimed at) must be XML-based. > > If we dont make that change then we will regret it for ever and ever. > > > -----Original Message----- > > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > > Sent: Monday, March 30, 1998 5:51 PM > > To: walker@dazel.com; Tom Hastings > > Cc: ipp@pwg.org > > Subject: Re: IPP> MOD/PRO - simple proposal for providing > > dictionary-like capability > > > > Jim, > > > > I have similar concerns about the use of attributes with parallel values. > > I have this nagging feeling that we are going to regret this direction. > > But thus far it has been the least bad solution that we have found. > > > > We have arrived at this unfortunate point because the current binary > > encoding has painted us into a corner. An XML encoding would > > allow a very simple solution for dictionaries. > > > > We considered having dictionary members appear as normal attributes > > surrounded by begin-dictionary and end-dictionary "values", but this > > solution > > would potentially create name conflicts with names at the top level for > > parsers > > > > that don't know about dictionaries. This solution works if we force a > > version > > change or all existing parsers add support for it. > > > > We considered having a dictionary structure which would be a new type > > whose values are nested in an existing value. For small dictionaries, this > > is the obvious and simple solution, but if we kept the existing limit > > of 1023 octets per value, some dictionaries would be impossible. Picking > > a value that is large enough for all likely dictionaries but doesn't > > burden > > small implementations was difficult and didn't seem to solve the problem. > > We looked at ways to keep the 1023 limit and instead chunk the dictionary > > into multiple values. I had a reasonable but very ugly solution which > > concatenated the chunks together and use "begin-dictionary" and > > "end-dictionary" "values" to indicate the structure. > > > > By turning the dictionary problem into a naming problem, we seem to have > > side stepped all of these issues, but as you point out data structures > > were > > invented for a reason. > > > > Do you have any suggestions for what we should do? > > > > Bob Herriot > > > > > > > > > > At 01:16 PM 3/25/98 , James Walker wrote: > > >Tom Hastings wrote: > > >> > > >> For the IPP telecon, Wed, 3/25: > > >> > > >> Roger, Bob, and I have been working on various dictionary proposals. > > >> > > >> ... > > >> > > >> Briefly, the scheme isn't really a dictionary at all (previous > > >> versions were). Other earlier versions were adding a new addressing > > >> mechanism for attributes in dictionaries. > > >> > > >> This proposal adds no new addressing mechanisms, > > >> but justs add a new out-of-band value to encode the new Model attribute > > >> syntax of 1setOf 1setOf (doubly nested values). Instead, we use the > > >> idea of attributes with parallel values, like we already have for > > >> "printer-uri-supported" and "uri-security-supported". > > > > > >As discussed in the telecon today, I think that the parallel attribute > > >idea is a bad one... it does not scale well, it is difficult for users > > >to understand and get right, it is error-prone, etc. Our experience > > >from the implementation of parallel attributes in DPA has not been a > > >good one. All in all, I believe that data structures are a good idea, > > >but trying to describe data structures using parallel attributes does > > >not work. > > > > > >> ... > > >> > > >> I've left the rejected example that uses the 'dictionary' attribute > > syntax > > >> in the document. I've also listed the alternatives that we considered > > >> and the reasons for rejecting them. > > >> > > >> ... > > > > > >I simply do not understand why the original concept of a dictionary > > >value tag (with its associated value length) would not work well. > > >This is the example that is shown in Tom's document. > > > > > >...walker > > > > > >-- > > >Jim Walker > > >System Architect/DAZEL Wizard > > >DAZEL Corporation, Austin, TX > > > From ipp-owner@pwg.org Wed Apr 1 15:31:05 1998 Delivery-Date: Wed, 01 Apr 1998 15:31:05 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA17267 for ; Wed, 1 Apr 1998 15:31:04 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA28122 for ; Wed, 1 Apr 1998 15:33:38 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16867 for ; Wed, 1 Apr 1998 15:31:08 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:20:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 (EST) Message-ID: <3522A16D.757A81B1@underscore.com> Date: Wed, 01 Apr 1998 15:19:57 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Paul, Sorry, but I wasn't able to attend the Maui meeting, so perhaps you can clarify something about the perceptions of "IPP v2" for me. The way I read your message (below), IPP v2 will have a totally different encoding than IPP v1 (ie, non-standard BER-like quasi-binary encoding vs. structured text). Is this correct? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Apr 1 19:18:35 1998 Delivery-Date: Wed, 01 Apr 1998 19:18:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22086 for ; Wed, 1 Apr 1998 19:18:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06132 for ; Wed, 1 Apr 1998 19:21:07 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18470 for ; Wed, 1 Apr 1998 19:18:37 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 19:11:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17742 for ipp-outgoing; Wed, 1 Apr 1998 19:10:58 -0500 (EST) Date: Wed, 1 Apr 1998 16:16:45 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9804020016.AA19271@snorkel.eso.mc.xerox.com> To: jkm@underscore.com, paulmo@microsoft.com Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Hi Jay and Paul, Yes, I'm interested to hear more about the 'decision' to do IPPv2 on XML in Maui. It sure didn't widely penetrate the mailing list for the rest of us people. And it sure TOTALLY breaks backward compatibility. Cheers, - Ira McDonald (High North) ----------------------------------------------------------- [Jay's note] >From ipp-owner@pwg.org Wed Apr 1 15:37:41 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA19155; Wed, 1 Apr 98 15:37:40 EST Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA24661; Wed, 1 Apr 98 15:31:25 EST Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52295(4)>; Wed, 1 Apr 1998 12:31:32 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16498 for ; Wed, 1 Apr 1998 15:28:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:20:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 (EST) Message-Id: <3522A16D.757A81B1@underscore.com> Date: Wed, 1 Apr 1998 12:19:57 PST From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) Mime-Version: 1.0 To: Paul Moore Cc: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Status: R Paul, Sorry, but I wasn't able to attend the Maui meeting, so perhaps you can clarify something about the perceptions of "IPP v2" for me. The way I read your message (below), IPP v2 will have a totally different encoding than IPP v1 (ie, non-standard BER-like quasi-binary encoding vs. structured text). Is this correct? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Apr 1 19:24:25 1998 Delivery-Date: Wed, 01 Apr 1998 19:24:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22183 for ; Wed, 1 Apr 1998 19:24:24 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA08000 for ; Wed, 1 Apr 1998 19:26:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19113 for ; Wed, 1 Apr 1998 19:24:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 19:16:23 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18153 for ipp-outgoing; Wed, 1 Apr 1998 19:16:09 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC445@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'imcdonal@eso.mc.xerox.com'" , jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Date: Wed, 1 Apr 1998 16:15:48 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org As I said below - this was an informal consensus. Everybody I spoke to about it said that they thought that we would have to do XML to handle things like dictionaries, etc. Yes it completely breaks compatability - this is why I raised the issue as strongly as I did. I still think that the Maui decision was wrong (but that is water under the bridge now). > -----Original Message----- > From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] > Sent: Wednesday, April 01, 1998 4:17 PM > To: jkm@underscore.com; Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing > dictionary-like capability > > Hi Jay and Paul, > > Yes, I'm interested to hear more about the 'decision' to do > IPPv2 on XML in Maui. It sure didn't widely penetrate the > mailing list for the rest of us people. And it sure TOTALLY > breaks backward compatibility. > > Cheers, > - Ira McDonald (High North) > ----------------------------------------------------------- > [Jay's note] > From ipp-owner@pwg.org Wed Apr 1 15:37:41 1998 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com > (4.1/XeroxClient-1.1) > id AA19155; Wed, 1 Apr 98 15:37:40 EST > Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) > id AA24661; Wed, 1 Apr 98 15:31:25 EST > Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com > with SMTP id <52295(4)>; Wed, 1 Apr 1998 12:31:32 PST > Received: from localhost (daemon@localhost) by lists.underscore.com > (8.7.5/8.7.3) with SMTP id PAA16498 for ; Wed, > 1 Apr 1998 15:28:01 -0500 (EST) > Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:20:22 -0500 > Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id > PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 (EST) > Message-Id: <3522A16D.757A81B1@underscore.com> > Date: Wed, 1 Apr 1998 12:19:57 PST > From: Jay Martin > Organization: Underscore, Inc. > X-Mailer: Mozilla 4.03 [en] (WinNT; I) > Mime-Version: 1.0 > To: Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like > capability > References: > <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: ipp-owner@pwg.org > Status: R > > Paul, > > Sorry, but I wasn't able to attend the Maui meeting, so perhaps > you can clarify something about the perceptions of "IPP v2" > for me. > > The way I read your message (below), IPP v2 will have a totally > different encoding than IPP v1 (ie, non-standard BER-like > quasi-binary encoding vs. structured text). > > Is this correct? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Apr 1 19:30:50 1998 Delivery-Date: Wed, 01 Apr 1998 19:30:50 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22252 for ; Wed, 1 Apr 1998 19:30:50 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10138 for ; Wed, 1 Apr 1998 19:33:21 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19784 for ; Wed, 1 Apr 1998 19:30:49 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 19:22:00 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18759 for ipp-outgoing; Wed, 1 Apr 1998 19:21:45 -0500 (EST) From: Harry Lewis To: Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary- Message-ID: <5030300019596086000002L062*@MHS> Date: Wed, 1 Apr 1998 19:28:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA22252 I don't recall any consensus at Maui which would mandate XML for v2. Not that a lot of interest wasn't expressed! We may find that different folks have different perceptions. Rather than dwell on what might or might not have been informally decided several meetings ago, I suggest we just engage the topic, head-on when the time is appropriate. Does the use of XML for dictionary necessarily force the resolution of an entirely new mapping for IPP? Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 04/01/98 05:13:45 PM Please respond to ipp-owner@pwg.org To: paulmo@microsoft.com, jkm@underscore.com cc: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary- Hi Jay and Paul, Yes, I'm interested to hear more about the 'decision' to do IPPv2 on XML in Maui. It sure didn't widely penetrate the mailing list for the rest of us people. And it sure TOTALLY breaks backward compatibility. Cheers, - Ira McDonald (High North) ----------------------------------------------------------- [Jay's note] >From ipp-owner@pwg.org Wed Apr 1 15:37:41 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA19155; Wed, 1 Apr 98 15:37:40 EST Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA24661; Wed, 1 Apr 98 15:31:25 EST Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52295(4)>; Wed, 1 Apr 1998 12:31:32 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA16498 for ; Wed, 1 Apr 1998 15:28:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:20:22 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 (EST) Message-Id: <3522A16D.757A81B1@underscore.com> Date: Wed, 1 Apr 1998 12:19:57 PST From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) Mime-Version: 1.0 To: Paul Moore Cc: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Status: R Paul, Sorry, but I wasn't able to attend the Maui meeting, so perhaps you can clarify something about the perceptions of "IPP v2" for me. The way I read your message (below), IPP v2 will have a totally different encoding than IPP v1 (ie, non-standard BER-like quasi-binary encoding vs. structured text). Is this correct? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Apr 1 19:49:20 1998 Delivery-Date: Wed, 01 Apr 1998 19:49:21 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22389 for ; Wed, 1 Apr 1998 19:49:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16140 for ; Wed, 1 Apr 1998 19:51:42 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20425 for ; Wed, 1 Apr 1998 19:49:11 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 19:43:31 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19881 for ipp-outgoing; Wed, 1 Apr 1998 19:43:18 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" , "'imcdonal@eso.mc.xerox.com'" , jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Date: Wed, 1 Apr 1998 16:39:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org We did talk about future IPPv2 encodings and transports, but no formal WG concensus was declared since it wouldn't have been appropriate when we don't even have version 1.0 documents at "proposed" yet. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Wednesday, April 01, 1998 4:16 PM To: 'imcdonal@eso.mc.xerox.com'; jkm@underscore.com Cc: ipp@pwg.org Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability As I said below - this was an informal consensus. Everybody I spoke to about it said that they thought that we would have to do XML to handle things like dictionaries, etc. Yes it completely breaks compatability - this is why I raised the issue as strongly as I did. I still think that the Maui decision was wrong (but that is water under the bridge now). > -----Original Message----- > From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] > Sent: Wednesday, April 01, 1998 4:17 PM > To: jkm@underscore.com; Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing > dictionary-like capability > > Hi Jay and Paul, > > Yes, I'm interested to hear more about the 'decision' to do > IPPv2 on XML in Maui. It sure didn't widely penetrate the > mailing list for the rest of us people. And it sure TOTALLY > breaks backward compatibility. > > Cheers, > - Ira McDonald (High North) > ----------------------------------------------------------- > [Jay's note] > From ipp-owner@pwg.org Wed Apr 1 15:37:41 1998 > Return-Path: > Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com > (4.1/XeroxClient-1.1) > id AA19155; Wed, 1 Apr 98 15:37:40 EST > Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) > id AA24661; Wed, 1 Apr 98 15:31:25 EST > Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com > with SMTP id <52295(4)>; Wed, 1 Apr 1998 12:31:32 PST > Received: from localhost (daemon@localhost) by lists.underscore.com > (8.7.5/8.7.3) with SMTP id PAA16498 for ; Wed, > 1 Apr 1998 15:28:01 -0500 (EST) > Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 15:20:22 -0500 > Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id > PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 (EST) > Message-Id: <3522A16D.757A81B1@underscore.com> > Date: Wed, 1 Apr 1998 12:19:57 PST > From: Jay Martin > Organization: Underscore, Inc. > X-Mailer: Mozilla 4.03 [en] (WinNT; I) > Mime-Version: 1.0 > To: Paul Moore > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like > capability > References: > <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: ipp-owner@pwg.org > Status: R > > Paul, > > Sorry, but I wasn't able to attend the Maui meeting, so perhaps > you can clarify something about the perceptions of "IPP v2" > for me. > > The way I read your message (below), IPP v2 will have a totally > different encoding than IPP v1 (ie, non-standard BER-like > quasi-binary encoding vs. structured text). > > Is this correct? > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From list-owner-rmonmib-outgoing@cisco.com Wed Apr 1 19:59:31 1998 Delivery-Date: Wed, 01 Apr 1998 19:59:32 -0500 Return-Path: list-owner-rmonmib-outgoing@cisco.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22459 for ; Wed, 1 Apr 1998 19:59:31 -0500 (EST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19564 for ; Wed, 1 Apr 1998 20:02:04 -0500 (EST) Received: (daemon@localhost) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) id QAA11328 for Rmonmib-outgoing; Wed, 1 Apr 1998 16:54:05 -0800 (PST) Received: from peridot.cisco.com (peridot.cisco.com [171.69.198.64]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id QAA11323 for ; Wed, 1 Apr 1998 16:54:02 -0800 (PST) Received: from cisco.com (sj-dial-3-99.cisco.com [171.68.179.100]) by peridot.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19290; Wed, 1 Apr 1998 16:53:48 -0800 (PST) Message-ID: <3522E19B.B36B8200@cisco.com> Date: Wed, 01 Apr 1998 16:53:47 -0800 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Philippe SCHMITT CC: rmonmib@cisco.com Subject: Re: protocol identifier macros References: <3522519D.522C@acanthe-soft.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmonmib@cisco.com Precedence: bulk Philippe SCHMITT wrote: > > I am trying to define a protocol on the port 1521 for an RMON2 probe. > The protocol is created but not with this port number. > I think 1521 need to be encoded. > So, I am looking for protocol identifier macros. > Are you trying to define a new PI macro? We need more info than UDP or TCP port 1531 to add a PI macro to the PI document. See RFC 2074 or the latest PI spec (draft-ietf-rmonmib-rmonprot-v2-03.txt) for the specific requirements for PI macro submissions. Are you trying to report a bug in a specific RMON-2 agent implementation? If so, you should contact the vendor privately for an explanation. > Thanks in advanced. > > Philippe Schmmitt Andy From ipp-owner@pwg.org Thu Apr 2 02:06:36 1998 Delivery-Date: Thu, 02 Apr 1998 02:06:36 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA04278 for ; Thu, 2 Apr 1998 02:06:35 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA17644 for ; Thu, 2 Apr 1998 02:09:03 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA24447 for ; Thu, 2 Apr 1998 02:06:35 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 01:59:48 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA23858 for ipp-outgoing; Thu, 2 Apr 1998 01:59:34 -0500 (EST) Message-Id: <1.5.4.32.19980402070011.0098f1d0@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: Wed, 01 Apr 1998 23:00:11 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Sender: ipp-owner@pwg.org As far as I remember, we said that we might revisit the subject for a later version of IPP, possibly in combination with a new mapping onto e.g. HTTP NG, at which time missing XML features will hopefully also be stable. Anybody can speculate about what they would prefer to see in a future IPP version, for which we do not even have a plan yet. In addition, this kind of decision is never made in neither a PWG nor an IETF meeting; decisions are made by consensus on the DL, in case somebody has missed that important piece of information. There are certainly other possible solutions for the dictionary attribute than using XML, please read Tom's latest proposal on how it can be done with the current IPP tools for syntax and encoding. Carl-Uno --- At 04:39 PM 4/1/98 -0800, Turner, Randy wrote: > >We did talk about future IPPv2 encodings and transports, but no formal >WG concensus was declared since it wouldn't have been appropriate when >we don't even have version 1.0 documents at "proposed" yet. > >Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Wednesday, April 01, 1998 4:16 PM > To: 'imcdonal@eso.mc.xerox.com'; jkm@underscore.com > Cc: ipp@pwg.org > Subject: RE: IPP> MOD/PRO - simple proposal for providing >dictionary-like capability > > As I said below - this was an informal consensus. Everybody I >spoke to about > it said that they thought that we would have to do XML to handle >things like > dictionaries, etc. > > Yes it completely breaks compatability - this is why I raised >the issue as > strongly as I did. I still think that the Maui decision was >wrong (but that > is water under the bridge now). > > > > > -----Original Message----- > > From: imcdonal@eso.mc.xerox.com >[SMTP:imcdonal@eso.mc.xerox.com] > > Sent: Wednesday, April 01, 1998 4:17 PM > > To: jkm@underscore.com; Paul Moore > > Cc: ipp@pwg.org > > Subject: Re: IPP> MOD/PRO - simple proposal for providing > > dictionary-like capability > > > > Hi Jay and Paul, > > > > Yes, I'm interested to hear more about the 'decision' to do > > IPPv2 on XML in Maui. It sure didn't widely penetrate the > > mailing list for the rest of us people. And it sure TOTALLY > > breaks backward compatibility. > > > > Cheers, > > - Ira McDonald (High North) > > ----------------------------------------------------------- > > [Jay's note] > > From ipp-owner@pwg.org Wed Apr 1 15:37:41 1998 > > Return-Path: > > Received: from zombi (zombi.eso.mc.xerox.com) by >snorkel.eso.mc.xerox.com > > (4.1/XeroxClient-1.1) > > id AA19155; Wed, 1 Apr 98 15:37:40 EST > > Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) > > id AA24661; Wed, 1 Apr 98 15:31:25 EST > > Received: from lists.underscore.com ([199.125.85.30]) by >alpha.xerox.com > > with SMTP id <52295(4)>; Wed, 1 Apr 1998 12:31:32 PST > > Received: from localhost (daemon@localhost) by >lists.underscore.com > > (8.7.5/8.7.3) with SMTP id PAA16498 for >; Wed, > > 1 Apr 1998 15:28:01 -0500 (EST) > > Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Apr 1998 >15:20:22 -0500 > > Received: (from daemon@localhost) by lists.underscore.com >(8.7.5/8.7.3) id > > PAA15724 for ipp-outgoing; Wed, 1 Apr 1998 15:20:09 -0500 >(EST) > > Message-Id: <3522A16D.757A81B1@underscore.com> > > Date: Wed, 1 Apr 1998 12:19:57 PST > > From: Jay Martin > > Organization: Underscore, Inc. > > X-Mailer: Mozilla 4.03 [en] (WinNT; I) > > Mime-Version: 1.0 > > To: Paul Moore > > Cc: ipp@pwg.org > > Subject: Re: IPP> MOD/PRO - simple proposal for providing >dictionary-like > > capability > > References: > > ><5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > Sender: ipp-owner@pwg.org > > Status: R > > > > Paul, > > > > Sorry, but I wasn't able to attend the Maui meeting, so >perhaps > > you can clarify something about the perceptions of "IPP v2" > > for me. > > > > The way I read your message (below), IPP v2 will have a >totally > > different encoding than IPP v1 (ie, non-standard BER-like > > quasi-binary encoding vs. structured text). > > > > Is this correct? > > > > ...jay > > > > >---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com >-- > > -- Underscore, Inc. | Voice: (603) 889-7000 >-- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 >-- > > -- Hudson, NH 03051-4915 | Web: >http://www.underscore.com -- > > >---------------------------------------------------------------------- > > From jmp-owner@pwg.org Thu Apr 2 11:40:40 1998 Delivery-Date: Thu, 02 Apr 1998 11:40:44 -0500 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA10077 for ; Thu, 2 Apr 1998 11:40:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15491 for ; Thu, 2 Apr 1998 11:43:05 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA04616 for ; Thu, 2 Apr 1998 11:40:20 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 11:37:45 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04109 for jmp-outgoing; Thu, 2 Apr 1998 11:35:28 -0500 (EST) Date: Thu, 2 Apr 1998 08:27:05 -0800 (Pacific Standard Time) From: Ron Bergman To: jmp@pwg.org, ipp@pwg.org Subject: JMP> SNMP Notifications and Registration Methods Agenda Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jmp-owner@pwg.org Carl-Uno has agreed to provide a 2-3 hour slot next Thursday to discuss SNMP notifications and registration as applicable to both IPP and the Job Monitoring MIB. There is considerable interest in the IPP group on this subject, since it appears that SNMP traps and/or informs could be one of the possible notification methods for IPP. Randy did a very good job in Austin of providing background on SNMPv3 and I would like to further examine this subject and reach a general consensus as to the direction. The meeting agenda will consist of two primary topics. I. Trap/Inform conditions: The JMP group has defined 11 conditions that could generate a trap/inform condition. I would like to quickly review these with the IPP group to insure that this list is adequate. (If time permits, we will review Tom Hastings proposed definitions for these items.) 1. Start of job 2. Job completion 3. Job aborted 4. Job canceled 5. Job progress, sheets stacked 6. Job progress, copy completed 7. Job received 8. Job hold notification 9. Job release notification 10. Print deadline exceeded 11. Job accounting information expired II. Registration methods: This is presently the most controversial part of the project and I expect will occupy the majority of the meeting. To prepare for the meeting, I suggest that everyone review the SNMPv3 documents (RFCs 2271 to 2275) and the Job Async Monitoring MIB (Joe Filion, and Ira McDonald at ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jam_v010.txt). I can think of four possible alternatives: 1. Use the SNMPv3 registration MIBS. 2. Use the Job Async Monitoring MIB registration. 3. Create a hybrid with the best of both and maybe new ideas. 4. Send SNMP into the world of deprecation, (and never to be heard from again). See you in Portland, Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Thu Apr 2 11:42:22 1998 Delivery-Date: Thu, 02 Apr 1998 11:42:23 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA10096 for ; Thu, 2 Apr 1998 11:42:22 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16092 for ; Thu, 2 Apr 1998 11:44:51 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA04858 for ; Thu, 2 Apr 1998 11:42:14 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 11:35:57 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04117 for ipp-outgoing; Thu, 2 Apr 1998 11:35:34 -0500 (EST) Date: Thu, 2 Apr 1998 08:27:05 -0800 (Pacific Standard Time) From: Ron Bergman To: jmp@pwg.org, ipp@pwg.org Subject: IPP> SNMP Notifications and Registration Methods Agenda Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Carl-Uno has agreed to provide a 2-3 hour slot next Thursday to discuss SNMP notifications and registration as applicable to both IPP and the Job Monitoring MIB. There is considerable interest in the IPP group on this subject, since it appears that SNMP traps and/or informs could be one of the possible notification methods for IPP. Randy did a very good job in Austin of providing background on SNMPv3 and I would like to further examine this subject and reach a general consensus as to the direction. The meeting agenda will consist of two primary topics. I. Trap/Inform conditions: The JMP group has defined 11 conditions that could generate a trap/inform condition. I would like to quickly review these with the IPP group to insure that this list is adequate. (If time permits, we will review Tom Hastings proposed definitions for these items.) 1. Start of job 2. Job completion 3. Job aborted 4. Job canceled 5. Job progress, sheets stacked 6. Job progress, copy completed 7. Job received 8. Job hold notification 9. Job release notification 10. Print deadline exceeded 11. Job accounting information expired II. Registration methods: This is presently the most controversial part of the project and I expect will occupy the majority of the meeting. To prepare for the meeting, I suggest that everyone review the SNMPv3 documents (RFCs 2271 to 2275) and the Job Async Monitoring MIB (Joe Filion, and Ira McDonald at ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jam_v010.txt). I can think of four possible alternatives: 1. Use the SNMPv3 registration MIBS. 2. Use the Job Async Monitoring MIB registration. 3. Create a hybrid with the best of both and maybe new ideas. 4. Send SNMP into the world of deprecation, (and never to be heard from again). See you in Portland, Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Thu Apr 2 17:26:32 1998 Delivery-Date: Thu, 02 Apr 1998 17:26:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA14073 for ; Thu, 2 Apr 1998 17:26:32 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17581 for ; Thu, 2 Apr 1998 17:29:02 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08758 for ; Thu, 2 Apr 1998 17:26:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 17:16:32 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08040 for ipp-outgoing; Thu, 2 Apr 1998 17:16:19 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> IPP: Job template attributes Message-ID: <5030100019191211000002L012*@MHS> Date: Thu, 2 Apr 1998 17:15:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA14073 Henrik- My understanding is that the job template attributes specify requested processing for a job. In your example the server makes n copies. However, the J.T. attributes are OPTIONAL. Also, they can be ignored if ipp-attribute-fidelity is false. -Carl ipp-owner@pwg.org on 04/01/98 01:59:01 AM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: IPP> IPP: Job template attributes I am wondering, are the job template attributes only for information and administration? E.g. if an IPP Server recieves the job template attribute 'copies n' must the IPP Server make the n copies, or does the attribute only tell that the following job will me maked in n copies. Henrik Holst ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (+45) 44366271 Fax: (+45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com From ipp-owner@pwg.org Thu Apr 2 17:35:16 1998 Delivery-Date: Thu, 02 Apr 1998 17:35:16 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA14154 for ; Thu, 2 Apr 1998 17:35:16 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA20657 for ; Thu, 2 Apr 1998 17:37:45 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09459 for ; Thu, 2 Apr 1998 17:35:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 17:31:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08888 for ipp-outgoing; Thu, 2 Apr 1998 17:30:55 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Need clarification: printer-uri and job-uri Message-ID: <5030100019191730000002L002*@MHS> Date: Thu, 2 Apr 1998 17:30:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA14154 While we're on the subject of printer-uri, here's excerpt from the PRO document: 3.9 (Attribute) Name Some attributes are encoded in a special position. These attribute are: * "printer-uri": When the target is a printer and the transport is HTTP or HTTP (for TLS), the target printer-uri defined in each operation in the IPP model document SHALL be an operation attribute called "printer-uri" and it SHALL also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. This * Just to be perfectly clear, is this saying that the printer-uri must always appear in BOTH the HTTP Request-Line AND the Operation attribute group? ipp-owner@pwg.org on 03/31/98 04:29:02 PM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: IPP> printer-uri and job-uri Greetings. There are two issues related to printer-uri and job-uri that need some clarifications. Issue1: In the IPP Model document, there is no specification for the value-tags of "printer-uri" and "job-uri" attributes in a IPP request. According to the IPP Model document, section 3.1.3, the "printer-uri" attribute contains the Printer object's URIs which is one of the values in the Printer object's "printer- uri-supported" attribute. This implies that the value-tag of "printer-uri" attribute must be of type "uri". Similarly, the value-tag of "job-uri" attribute should be "uri" as well. Issue 2: In the "Note:" section of 3.2.1.1 in the IPP Model document, it was mentioned that "The simplest Print-Job Request consists of just the Document Content, the "attributes- charset" and "attributes-natural-language" operation attributes, and nothing else." However, in the description of Print-Job Request of section 15.3.4.3, the "printer-uri" attribute is specified as a MUST (indicated by (M)) and also in section 3.1.3 of the same document, it was indicated that either "printer-uri" or "job-uri" MUST appear in every operation request. There seems to be some inconsistency here. Please send your remarks/comments to the mailing list. -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Thu Apr 2 20:15:00 1998 Delivery-Date: Thu, 02 Apr 1998 20:15:25 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA15290 for ; Thu, 2 Apr 1998 20:14:59 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA21160 for ; Thu, 2 Apr 1998 20:17:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA10485 for ; Thu, 2 Apr 1998 20:14:51 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Apr 1998 20:10:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09921 for ipp-outgoing; Thu, 2 Apr 1998 20:09:58 -0500 (EST) Message-Id: <3.0.1.32.19980402170837.01092610@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 2 Apr 1998 17:08:37 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> contention document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Can we discuss this paper at the upcoming IPP meeting? It is an important issue/clarification for IPP/1.0. Or have we already covered this? Thanks, Tom >From: "Turner, Randy" >To: "'ipp@pwg.org'" >Subject: IPP> contention document >Date: Tue, 10 Feb 1998 22:10:07 PST >Sender: ipp-owner@pwg.org > > >I posted a PDF file on the FTP server containing some ideas on IPP >server contention handling. The URL is: > > ftp://ftp.pwg.org/pub/pwg/ipp/general/contention.pdf > >Randy > > > From ipp-owner@pwg.org Fri Apr 3 00:54:12 1998 Delivery-Date: Fri, 03 Apr 1998 00:54:12 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA21226 for ; Fri, 3 Apr 1998 00:54:11 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA29331 for ; Fri, 3 Apr 1998 00:56:40 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA11328 for ; Fri, 3 Apr 1998 00:54:01 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 00:49:20 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA10798 for ipp-outgoing; Fri, 3 Apr 1998 00:49:08 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Tom Hastings'" , ipp@pwg.org Subject: RE: IPP> contention document Date: Thu, 2 Apr 1998 21:45:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Boy Tom, you keep all your old messages! ;);) I am sending to Scott (and the list) a quick blurb on two status codes that, in addition to what we already have, cover contention situations without becoming too verbose in outlining specific server-related (and implementation-dependent) details. Depending on when people leave for Portland, it should hit the list by Saturday, so maybe we could just talk about these 2 status codes. This would be a lot quicker and avoid taking up too much time on the agenda. Also, I will try and have copies of my updated transport draft on the FTP server (and also copies at the meeting) for the meeting, in case anyone wants to talk about it. Randy -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] Sent: Thursday, April 02, 1998 5:09 PM To: ipp@pwg.org Subject: IPP> contention document Can we discuss this paper at the upcoming IPP meeting? It is an important issue/clarification for IPP/1.0. Or have we already covered this? Thanks, Tom >From: "Turner, Randy" >To: "'ipp@pwg.org'" >Subject: IPP> contention document >Date: Tue, 10 Feb 1998 22:10:07 PST >Sender: ipp-owner@pwg.org > > >I posted a PDF file on the FTP server containing some ideas on IPP >server contention handling. The URL is: > > ftp://ftp.pwg.org/pub/pwg/ipp/general/contention.pdf > >Randy > > > From ipp-owner@pwg.org Fri Apr 3 15:55:59 1998 Delivery-Date: Fri, 03 Apr 1998 15:55:59 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03715 for ; Fri, 3 Apr 1998 15:55:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA06744 for ; Fri, 3 Apr 1998 15:58:29 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24178 for ; Fri, 3 Apr 1998 15:55:55 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 15:49:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23615 for ipp-outgoing; Fri, 3 Apr 1998 15:49:16 -0500 (EST) From: Roger K Debry To: Subject: IPP> Host to device Message-ID: <5030100019224324000002L042*@MHS> Date: Fri, 3 Apr 1998 15:48:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA03715 I have read both Randy's TCP/IP mapping document and Don's TIP/SI mapping document. I have to admit that I haven't spent a lot of time trying to write down a detailed proposal, but I make the following observations: A lot of work went into TIP/SI to develop a host to device protocol which was transport independent. In particular, it runs on both TCP/IP and a IEEE 1284 parallel port. It outlines all of the rules for handling out of band communications, continuation, and acknowledgements. A lot of work has also gone into developing a model for submitting and anaging print jobs in IPP. The model reflects current thinking in this area and has taken into account parallel work on Printer and Job MIB. Although Don would probably not approve, one could take the TIP/SI packet structure (including the TIP/SI packet header), as defined today but with new commands (below), and carry an IPP payload with it. Now we don't have to re-invent flow control, data stream level acks,, etc. The TIP/SI LU becomes the IPP Job ID The TIP/SI payload becomes the IPP message The IPP commands are used in TIP/SI as shown: o Print-Job would not be used in host-to-device o Create-Job replaces the TIP/SI Start job command o Validate-Job would not be used in host-to-device o Get-Printer replaces the TIP/SI RDC and RIC commands o Get-Jobs replaces the TIP/SI JC-QJC command o Send Document and Send URI go to the LU A sample job submission flow would look like: 1. Connect 2. Start Session (as is in TIP/SI) 3. Create-Job (response is IPP job ID) 4. Send Document (destination bit = LU, LU# = IPP Job ID) 5. End-Job (as is in TIP/SI) 6. End-Session (as is in TIP/SI) 7. Disconnect This is very high level and obviously not completely thought through, but it seems to me that we ought to be able to leverage al ot of good, hard work and marry these two ideas together to come up with a version of IPP for host-to-device that meets all of Paul Moore's requirements. Thoughts??? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Fri Apr 3 16:21:44 1998 Delivery-Date: Fri, 03 Apr 1998 16:21:44 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03984 for ; Fri, 3 Apr 1998 16:21:43 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA29921 for ; Fri, 3 Apr 1998 16:24:14 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24828 for ; Fri, 3 Apr 1998 16:21:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 16:17:09 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24271 for ipp-outgoing; Fri, 3 Apr 1998 16:16:56 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Roger K Debry'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Host to device Date: Fri, 3 Apr 1998 13:16:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org One key point to remember is, is that I don't think we need to be taking TIPSI and modifying it. If you don't use it as is, then you are not compliant with TIPSI, and I think a lot of the benefit of using TIPSI is the fact that it exists as an interoperable standard specification. My next draft which I am working on adds client "pull" functionality and cleans up the transport header. I hope to have it out by tomorrow, and I will have copies (hardcopy) at the meeting. Randy -----Original Message----- From: Roger K Debry [SMTP:rdebry@us.ibm.com] Sent: Friday, April 03, 1998 12:49 PM To: ipp@pwg.org Subject: IPP> Host to device I have read both Randy's TCP/IP mapping document and Don's TIP/SI mapping document. I have to admit that I haven't spent a lot of time trying to write down a detailed proposal, but I make the following observations: A lot of work went into TIP/SI to develop a host to device protocol which was transport independent. In particular, it runs on both TCP/IP and a IEEE 1284 parallel port. It outlines all of the rules for handling out of band communications, continuation, and acknowledgements. A lot of work has also gone into developing a model for submitting and anaging print jobs in IPP. The model reflects current thinking in this area and has taken into account parallel work on Printer and Job MIB. Although Don would probably not approve, one could take the TIP/SI packet structure (including the TIP/SI packet header), as defined today but with new commands (below), and carry an IPP payload with it. Now we don't have to re-invent flow control, data stream level acks,, etc. The TIP/SI LU becomes the IPP Job ID The TIP/SI payload becomes the IPP message The IPP commands are used in TIP/SI as shown: o Print-Job would not be used in host-to-device o Create-Job replaces the TIP/SI Start job command o Validate-Job would not be used in host-to-device o Get-Printer replaces the TIP/SI RDC and RIC commands o Get-Jobs replaces the TIP/SI JC-QJC command o Send Document and Send URI go to the LU A sample job submission flow would look like: 1. Connect 2. Start Session (as is in TIP/SI) 3. Create-Job (response is IPP job ID) 4. Send Document (destination bit = LU, LU# = IPP Job ID) 5. End-Job (as is in TIP/SI) 6. End-Session (as is in TIP/SI) 7. Disconnect This is very high level and obviously not completely thought through, but it seems to me that we ought to be able to leverage al ot of good, hard work and marry these two ideas together to come up with a version of IPP for host-to-device that meets all of Paul Moore's requirements. Thoughts??? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Fri Apr 3 16:27:32 1998 Delivery-Date: Fri, 03 Apr 1998 16:27:33 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04046 for ; Fri, 3 Apr 1998 16:27:32 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04936 for ; Fri, 3 Apr 1998 16:30:04 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25427 for ; Fri, 3 Apr 1998 16:27:31 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 16:23:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24882 for ipp-outgoing; Fri, 3 Apr 1998 16:22:47 -0500 (EST) From: don@lexmark.com Message-Id: <199804032122.AA05999@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org Date: Fri, 3 Apr 1998 16:22:22 -0500 Subject: RE: IPP> Host to device Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Randy: My biggest concern is that your proposal is TCP/IP only. Is does not solve the problem for printers connected to servers via: - Parallel - Serial - USB - 1394 - IPX/SPX - AppleTalk - DLC/LLC - etc., etc., etc. If I'm going to use TCP/IP then I might as well go ahead with the HTTP based implementation. You don't provide more status and control or anything else that really buys me anything other than a slightly lighter transport. It's just not work the trouble for the return on investment. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Fri Apr 3 16:35:39 1998 Delivery-Date: Fri, 03 Apr 1998 16:35:39 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04101 for ; Fri, 3 Apr 1998 16:35:39 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA11535 for ; Fri, 3 Apr 1998 16:38:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26092 for ; Fri, 3 Apr 1998 16:35:39 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 16:31:11 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25517 for ipp-outgoing; Fri, 3 Apr 1998 16:30:58 -0500 (EST) Message-Id: <3.0.1.32.19980403132931.011dd7c0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 3 Apr 1998 13:29:31 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Proposal for IPP notification for end-user and host-to-device Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Harry and I have collaborated on writing our action item for a proposal for IPP notification registration that works for host-to-device and end-user. It also includes specific fixed attributes for each possible event. We've included the events from Ron's list, Harry's list, and the original IPP Model document of last September. I have posted the documents in: ftp://ftp.pwg.org/pub/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/ipp/new_NOT/ipp-job-notify-proposal.pdf ftp://ftp.pwg.org/pub/ipp/new_NOT/ipp-job-notify-proposal.txt >From the introduction: This proposal is intended for both the Host to Device IPP print protocol being discussed and as an extension to IPP/1.0. We believe that there is a significant common core that both can use and that each has some unique requirements that the other won't use. There are a number of issues indicated in the document that we should cover at the upcoming meeting, as well as review the proposal. This paper also relates to registration using SNMP, though this paper only deals with registration using IPP, but does include an identified notification delivery method using SNMP traps. Tom From ipp-owner@pwg.org Fri Apr 3 17:06:48 1998 Delivery-Date: Fri, 03 Apr 1998 17:06:48 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04228 for ; Fri, 3 Apr 1998 17:06:47 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA09402 for ; Fri, 3 Apr 1998 17:09:18 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27010 for ; Fri, 3 Apr 1998 17:06:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:00:44 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26256 for ipp-outgoing; Fri, 3 Apr 1998 17:00:30 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D2815059D65@exchange.osicom.com> From: "Gordon, Charles" To: "'don@lexmark.com'" , rturner@sharplabs.com Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org Subject: RE: IPP> Host to device Date: Fri, 3 Apr 1998 16:56:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Given that IPP is the Internet Printing Protocol, do we really need to support anything else besides TCP/IP? Is the IPP working group even mandated to worry about non TCP/IP environments? --- Charles > -----Original Message----- > From: don@lexmark.com [SMTP:don@lexmark.com] > Sent: Friday, April 03, 1998 4:22 PM > To: rturner@sharplabs.com > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > Subject: RE: IPP> Host to device > > > Randy: > > My biggest concern is that your proposal is TCP/IP only. Is does not > solve > the problem for printers connected to servers via: > > - Parallel > - Serial > - USB > - 1394 > - IPX/SPX > - AppleTalk > - DLC/LLC > - etc., etc., etc. > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > based implementation. You don't provide more status and control or > anything else that really buys me anything other than a slightly > lighter > transport. It's just not work the trouble for the return on > investment. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > From ipp-owner@pwg.org Fri Apr 3 17:10:05 1998 Delivery-Date: Fri, 03 Apr 1998 17:10:06 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04329 for ; Fri, 3 Apr 1998 17:10:05 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12025 for ; Fri, 3 Apr 1998 17:12:35 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27459 for ; Fri, 3 Apr 1998 17:10:02 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:04:03 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26587 for ipp-outgoing; Fri, 3 Apr 1998 17:03:40 -0500 (EST) From: don@lexmark.com Message-Id: <199804032203.AA08289@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: CGordon@wal.osicom.com Cc: Rturner@Sharplabs.Com, Rdebry@Us.Ibm.Com, Ipp@pwg.org Date: Fri, 3 Apr 1998 17:03:18 -0500 Subject: RE: IPP> Host to device Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Charles: TCP/IP is the inbound transport from the client to the server. We are talking here about the server to the printer. That connection could be anything. This discussion is certainly appropriate for the Printer Working Group chartered IPP group. While the IETF can pretend that only TCP/IP is used for communication, the reality is that most printers are not connected to computers using TCP/IP. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: Don Wright@Lexmark, rturner%sharplabs.com@interlock.lexmark.com cc: Rdebry%Us.Ibm.Com@interlock.lexmark.com, Ipp%pwg.org@interlock.lexmark.com bcc: Subject: RE: IPP> Host to device Given that IPP is the Internet Printing Protocol, do we really need to support anything else besides TCP/IP? Is the IPP working group even mandated to worry about non TCP/IP environments? --- Charles > -----Original Message----- > From: don@lexmark.com [SMTP:don@lexmark.com] > Sent: Friday, April 03, 1998 4:22 PM > To: rturner@sharplabs.com > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > Subject: RE: IPP> Host to device > > > Randy: > > My biggest concern is that your proposal is TCP/IP only. Is does not > solve > the problem for printers connected to servers via: > > - Parallel > - Serial > - USB > - 1394 > - IPX/SPX > - AppleTalk > - DLC/LLC > - etc., etc., etc. > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > based implementation. You don't provide more status and control or > anything else that really buys me anything other than a slightly > lighter > transport. It's just not work the trouble for the return on > investment. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > From ipp-owner@pwg.org Fri Apr 3 17:20:27 1998 Delivery-Date: Fri, 03 Apr 1998 17:20:27 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04420 for ; Fri, 3 Apr 1998 17:20:26 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21612 for ; Fri, 3 Apr 1998 17:22:56 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA28136 for ; Fri, 3 Apr 1998 17:20:22 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:15:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27557 for ipp-outgoing; Fri, 3 Apr 1998 17:15:04 -0500 (EST) Message-ID: <35255F5E.C78CE947@underscore.com> Date: Fri, 03 Apr 1998 17:14:54 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ipp@pwg.org CC: don@lexmark.com, CGordon@wal.osicom.com, Rdebry@Us.Ibm.Com Subject: Re: IPP> Host to device References: <199804032203.AA08289@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org I was really hoping the IPP WG would be constrained to *only* handling print requests over the "Internet", and that the more functional host-to-device protocol would be addressed via a different project within the PWG (or WG under the IETF, if that's preferred). If I read Roger's approach correctly, it would appear that TIP/SI is being used as nothing more than a thin wrapper around IPP in exactly the same manner as the HTTP approach. This is highly undesirable, 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 -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > Charles: > > TCP/IP is the inbound transport from the client to the server. We are > talking here about the server to the printer. That connection could be > anything. This discussion is certainly appropriate for the Printer Working > Group chartered IPP group. While the IETF can pretend that only TCP/IP is > used for communication, the reality is that most printers are not connected > to computers using TCP/IP. > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > To: Don Wright@Lexmark, rturner%sharplabs.com@interlock.lexmark.com > cc: Rdebry%Us.Ibm.Com@interlock.lexmark.com, > Ipp%pwg.org@interlock.lexmark.com > bcc: > Subject: RE: IPP> Host to device > > Given that IPP is the Internet Printing Protocol, do we really need to > support anything else besides TCP/IP? Is the IPP working group even > mandated to worry about non TCP/IP environments? > --- Charles > > -----Original Message----- > > From: don@lexmark.com [SMTP:don@lexmark.com] > > Sent: Friday, April 03, 1998 4:22 PM > > To: rturner@sharplabs.com > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > Subject: RE: IPP> Host to device > > > > > > Randy: > > > > My biggest concern is that your proposal is TCP/IP only. Is does not > > solve > > the problem for printers connected to servers via: > > > > - Parallel > > - Serial > > - USB > > - 1394 > > - IPX/SPX > > - AppleTalk > > - DLC/LLC > > - etc., etc., etc. > > > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > > based implementation. You don't provide more status and control or > > anything else that really buys me anything other than a slightly > > lighter > > transport. It's just not work the trouble for the return on > > investment. > > > > Don > > > > ********************************************** > > * Don Wright don@lexmark.com * > > * Product Manager, Strategic Alliances * > > * Lexmark International * > > * 740 New Circle Rd * > > * Lexington, Ky 40550 * > > * 606-232-4808 (phone) 606-232-6740 (fax) * > > ********************************************** > > From ipp-owner@pwg.org Fri Apr 3 17:28:29 1998 Delivery-Date: Fri, 03 Apr 1998 17:28:30 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04496 for ; Fri, 3 Apr 1998 17:28:29 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA28538 for ; Fri, 3 Apr 1998 17:31:00 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA29172 for ; Fri, 3 Apr 1998 17:28:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:20:25 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28102 for ipp-outgoing; Fri, 3 Apr 1998 17:19:59 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" , Ipp@pwg.org Cc: don@lexmark.com, CGordon@wal.osicom.com, Rdebry@Us.Ibm.Com Subject: RE: IPP> Host to device Date: Fri, 3 Apr 1998 14:19:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org I'm kinda in Jay's camp, I'm not sure anymore what the desires of the WG are anymore with regards to what we were thinking about....looks like another agenda item for the meeting. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, April 03, 1998 2:15 PM To: Ipp@pwg.org Cc: don@lexmark.com; CGordon@wal.osicom.com; Rdebry@Us.Ibm.Com Subject: Re: IPP> Host to device I was really hoping the IPP WG would be constrained to *only* handling print requests over the "Internet", and that the more functional host-to-device protocol would be addressed via a different project within the PWG (or WG under the IETF, if that's preferred). If I read Roger's approach correctly, it would appear that TIP/SI is being used as nothing more than a thin wrapper around IPP in exactly the same manner as the HTTP approach. This is highly undesirable, 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 -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > Charles: > > TCP/IP is the inbound transport from the client to the server. We are > talking here about the server to the printer. That connection could be > anything. This discussion is certainly appropriate for the Printer Working > Group chartered IPP group. While the IETF can pretend that only TCP/IP is > used for communication, the reality is that most printers are not connected > to computers using TCP/IP. > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > To: Don Wright@Lexmark, rturner%sharplabs.com@interlock.lexmark.com > cc: Rdebry%Us.Ibm.Com@interlock.lexmark.com, > Ipp%pwg.org@interlock.lexmark.com > bcc: > Subject: RE: IPP> Host to device > > Given that IPP is the Internet Printing Protocol, do we really need to > support anything else besides TCP/IP? Is the IPP working group even > mandated to worry about non TCP/IP environments? > --- Charles > > -----Original Message----- > > From: don@lexmark.com [SMTP:don@lexmark.com] > > Sent: Friday, April 03, 1998 4:22 PM > > To: rturner@sharplabs.com > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > Subject: RE: IPP> Host to device > > > > > > Randy: > > > > My biggest concern is that your proposal is TCP/IP only. Is does not > > solve > > the problem for printers connected to servers via: > > > > - Parallel > > - Serial > > - USB > > - 1394 > > - IPX/SPX > > - AppleTalk > > - DLC/LLC > > - etc., etc., etc. > > > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > > based implementation. You don't provide more status and control or > > anything else that really buys me anything other than a slightly > > lighter > > transport. It's just not work the trouble for the return on > > investment. > > > > Don > > > > ********************************************** > > * Don Wright don@lexmark.com * > > * Product Manager, Strategic Alliances * > > * Lexmark International * > > * 740 New Circle Rd * > > * Lexington, Ky 40550 * > > * 606-232-4808 (phone) 606-232-6740 (fax) * > > ********************************************** > > From ipp-owner@pwg.org Fri Apr 3 17:30:00 1998 Delivery-Date: Fri, 03 Apr 1998 17:30:01 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04513 for ; Fri, 3 Apr 1998 17:30:00 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA29998 for ; Fri, 3 Apr 1998 17:32:31 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA29381 for ; Fri, 3 Apr 1998 17:29:59 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:22:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28320 for ipp-outgoing; Fri, 3 Apr 1998 17:21:50 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC46A@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Gordon, Charles'" , "'don@lexmark.com'" , rturner@sharplabs.com Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org Subject: RE: IPP> Host to device Date: Fri, 3 Apr 1998 14:21:34 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: ipp-owner@pwg.org Good point - it would look very odd to have IPP for USB. Also odd would be to have two IPP implmentations on TCP/IP - HTTP and direct TCP/IP. In retrospect the correct thing to have done was to produce a mapping of TIP/SI onto HTTP. Ie. HTTP is just another transport layer. > -----Original Message----- > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > Sent: Friday, April 03, 1998 1:57 PM > To: 'don@lexmark.com'; rturner@sharplabs.com > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > Subject: RE: IPP> Host to device > > Given that IPP is the Internet Printing Protocol, do we really need to > support anything else besides TCP/IP? Is the IPP working group even > mandated to worry about non TCP/IP environments? > > --- Charles > > > -----Original Message----- > > From: don@lexmark.com [SMTP:don@lexmark.com] > > Sent: Friday, April 03, 1998 4:22 PM > > To: rturner@sharplabs.com > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > Subject: RE: IPP> Host to device > > > > > > Randy: > > > > My biggest concern is that your proposal is TCP/IP only. Is does not > > solve > > the problem for printers connected to servers via: > > > > - Parallel > > - Serial > > - USB > > - 1394 > > - IPX/SPX > > - AppleTalk > > - DLC/LLC > > - etc., etc., etc. > > > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > > based implementation. You don't provide more status and control or > > anything else that really buys me anything other than a slightly > > lighter > > transport. It's just not work the trouble for the return on > > investment. > > > > Don > > > > ********************************************** > > * Don Wright don@lexmark.com * > > * Product Manager, Strategic Alliances * > > * Lexmark International * > > * 740 New Circle Rd * > > * Lexington, Ky 40550 * > > * 606-232-4808 (phone) 606-232-6740 (fax) * > > ********************************************** > > From ipp-owner@pwg.org Fri Apr 3 17:39:38 1998 Delivery-Date: Fri, 03 Apr 1998 17:39:38 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04557 for ; Fri, 3 Apr 1998 17:39:37 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA08244 for ; Fri, 3 Apr 1998 17:42:10 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00065 for ; Fri, 3 Apr 1998 17:39:38 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 17:35:16 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29519 for ipp-outgoing; Fri, 3 Apr 1998 17:35:02 -0500 (EST) From: Carl Kugler To: Subject: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarificatio Message-ID: <5030100019228340000002L002*@MHS> Date: Fri, 3 Apr 1998 17:34:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA04557 Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset attribute in any of the three job attributes groups. But section 4.3 of the Model document, "Job Description Attributes", says that attributes-charset is MANDATORY in the "job-description" attribute group. This is causing me cognitive dissonance. From ipp-owner@pwg.org Fri Apr 3 19:29:09 1998 Delivery-Date: Fri, 03 Apr 1998 19:29:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA05252 for ; Fri, 3 Apr 1998 19:29:08 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16644 for ; Fri, 3 Apr 1998 19:31:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01302 for ; Fri, 3 Apr 1998 19:29:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 19:24:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00732 for ipp-outgoing; Fri, 3 Apr 1998 19:23:47 -0500 (EST) Message-Id: <3.0.1.32.19980403161648.0098c210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 3 Apr 1998 16:16:48 PST To: "Gordon, Charles" , ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> Host to device Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org In-Reply-To: <6FCC2B3BA67BD111A47D0060089D2815059D65@exchange.osicom.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Charles, You are right that if we see this only from an IETF perspective, we do not need to care about all the other transfer protocols. However, it is of general interest to members of the PWG to also look for solutions that go beyond the IETF scope. I expect that when we write up a solution for extending the IPP within the IETF to cover IPP notifications, such a proposal will be limited to the TCP/IP case. Carl-Uno At 01:56 PM 4/3/98 PST, Gordon, Charles wrote: >Given that IPP is the Internet Printing Protocol, do we really need to >support anything else besides TCP/IP? Is the IPP working group even >mandated to worry about non TCP/IP environments? > > --- Charles > >> -----Original Message----- >> From: don@lexmark.com [SMTP:don@lexmark.com] >> Sent: Friday, April 03, 1998 4:22 PM >> To: rturner@sharplabs.com >> Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org >> Subject: RE: IPP> Host to device >> >> >> Randy: >> >> My biggest concern is that your proposal is TCP/IP only. Is does not >> solve >> the problem for printers connected to servers via: >> >> - Parallel >> - Serial >> - USB >> - 1394 >> - IPX/SPX >> - AppleTalk >> - DLC/LLC >> - etc., etc., etc. >> >> If I'm going to use TCP/IP then I might as well go ahead with the HTTP >> based implementation. You don't provide more status and control or >> anything else that really buys me anything other than a slightly >> lighter >> transport. It's just not work the trouble for the return on >> investment. >> >> Don >> >> ********************************************** >> * Don Wright don@lexmark.com * >> * Product Manager, Strategic Alliances * >> * Lexmark International * >> * 740 New Circle Rd * >> * Lexington, Ky 40550 * >> * 606-232-4808 (phone) 606-232-6740 (fax) * >> ********************************************** >> > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Apr 3 19:29:09 1998 Delivery-Date: Fri, 03 Apr 1998 19:29:29 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA05252 for ; Fri, 3 Apr 1998 19:29:08 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16644 for ; Fri, 3 Apr 1998 19:31:39 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01302 for ; Fri, 3 Apr 1998 19:29:04 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 19:24:01 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00732 for ipp-outgoing; Fri, 3 Apr 1998 19:23:47 -0500 (EST) Message-Id: <3.0.1.32.19980403161648.0098c210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 3 Apr 1998 16:16:48 PST To: "Gordon, Charles" , ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> Host to device Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org In-Reply-To: <6FCC2B3BA67BD111A47D0060089D2815059D65@exchange.osicom.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Charles, You are right that if we see this only from an IETF perspective, we do not need to care about all the other transfer protocols. However, it is of general interest to members of the PWG to also look for solutions that go beyond the IETF scope. I expect that when we write up a solution for extending the IPP within the IETF to cover IPP notifications, such a proposal will be limited to the TCP/IP case. Carl-Uno At 01:56 PM 4/3/98 PST, Gordon, Charles wrote: >Given that IPP is the Internet Printing Protocol, do we really need to >support anything else besides TCP/IP? Is the IPP working group even >mandated to worry about non TCP/IP environments? > > --- Charles > >> -----Original Message----- >> From: don@lexmark.com [SMTP:don@lexmark.com] >> Sent: Friday, April 03, 1998 4:22 PM >> To: rturner@sharplabs.com >> Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org >> Subject: RE: IPP> Host to device >> >> >> Randy: >> >> My biggest concern is that your proposal is TCP/IP only. Is does not >> solve >> the problem for printers connected to servers via: >> >> - Parallel >> - Serial >> - USB >> - 1394 >> - IPX/SPX >> - AppleTalk >> - DLC/LLC >> - etc., etc., etc. >> >> If I'm going to use TCP/IP then I might as well go ahead with the HTTP >> based implementation. You don't provide more status and control or >> anything else that really buys me anything other than a slightly >> lighter >> transport. It's just not work the trouble for the return on >> investment. >> >> Don >> >> ********************************************** >> * Don Wright don@lexmark.com * >> * Product Manager, Strategic Alliances * >> * Lexmark International * >> * 740 New Circle Rd * >> * Lexington, Ky 40550 * >> * 606-232-4808 (phone) 606-232-6740 (fax) * >> ********************************************** >> > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Apr 3 23:23:37 1998 Delivery-Date: Fri, 03 Apr 1998 23:23:37 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA10903 for ; Fri, 3 Apr 1998 23:23:36 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA17598 for ; Fri, 3 Apr 1998 23:26:08 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03259 for ; Fri, 3 Apr 1998 23:23:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 23:18:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA02684 for ipp-outgoing; Fri, 3 Apr 1998 23:17:58 -0500 (EST) Date: Fri, 3 Apr 1998 20:23:42 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9804040423.AA20312@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: RE: IPP> Host to device Sender: ipp-owner@pwg.org Hi folks, Friday (3 April 1998) I can't resist shooting these ducks in a barrel. The IETF does NOT only publish protocols over TCP/IP. For ten years there have been IETF standard mappings for SNMP (their ONLY 'standards track' net management protocol) over six different transports. The change log of the latest revision of HTTP (draft-ietf-http-v11-spec-rev-03.txt, 13 March 1998) shows updates to REMOVE any impression that TCP/IP should be the only transport. Mapping IPP over multiple non-Internet transports is entirely suitable for an IETF 'standards track' document. The IETF gave up on Internet suite everywhere a LONG time ago. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >Date: Fri, 3 Apr 1998 16:16:48 PST >To: "Gordon, Charles" , ipp@pwg.org >From: Carl-Uno Manros >Subject: RE: IPP> Host to device >Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org > >Charles, > >You are right that if we see this only from an IETF perspective, >we do not need to care about all the other transfer protocols. >However, it is of general interest to members of the PWG to also >look for solutions that go beyond the IETF scope. > >I expect that when we write up a solution for extending the IPP >within the IETF to cover IPP notifications, such a proposal >will be limited to the TCP/IP case. > >Carl-Uno > >At 01:56 PM 4/3/98 PST, Gordon, Charles wrote: >>Given that IPP is the Internet Printing Protocol, do we really need to >>support anything else besides TCP/IP? Is the IPP working group even >>mandated to worry about non TCP/IP environments? >> >> --- Charles >> >>> -----Original Message----- >>> From: don@lexmark.com [SMTP:don@lexmark.com] >>> Sent: Friday, April 03, 1998 4:22 PM >>> To: rturner@sharplabs.com >>> Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org >>> Subject: RE: IPP> Host to device >>> >>> >>> Randy: >>> >>> My biggest concern is that your proposal is TCP/IP only. Is does not >>> solve >>> the problem for printers connected to servers via: >>> >>> - Parallel >>> - Serial >>> - USB >>> - 1394 >>> - IPX/SPX >>> - AppleTalk >>> - DLC/LLC >>> - etc., etc., etc. >>> >>> If I'm going to use TCP/IP then I might as well go ahead with the HTTP >>> based implementation. You don't provide more status and control or >>> anything else that really buys me anything other than a slightly >>> lighter >>> transport. It's just not work the trouble for the return on >>> investment. >>> >>> Don >>> >>> ********************************************** >>> * Don Wright don@lexmark.com * >>> * Product Manager, Strategic Alliances * >>> * Lexmark International * >>> * 740 New Circle Rd * >>> * Lexington, Ky 40550 * >>> * 606-232-4808 (phone) 606-232-6740 (fax) * >>> ********************************************** >>> >> >> >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com >----------------------------------------------------------------------< From ipp-owner@pwg.org Fri Apr 3 23:36:15 1998 Delivery-Date: Fri, 03 Apr 1998 23:36:15 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11312 for ; Fri, 3 Apr 1998 23:36:14 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA29088 for ; Fri, 3 Apr 1998 23:38:46 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03961 for ; Fri, 3 Apr 1998 23:36:12 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Apr 1998 23:31:12 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA03379 for ipp-outgoing; Fri, 3 Apr 1998 23:30:57 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , ipp@pwg.org Subject: RE: IPP> Host to device Date: Fri, 3 Apr 1998 20:27:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Friday, April 03, 1998 8:24 PM To: ipp@pwg.org Subject: RE: IPP> Host to device ..snip.. Mapping IPP over multiple non-Internet transports is entirely suitable for an IETF 'standards track' document. The IETF gave up on Internet suite everywhere a LONG time ago. There is still a presence within the IESG, and at least two on the IAB that have not been "assimilated" into other transports. They are still IP bigots (kinda like myself). To wit, Keith Moore, during the Internet FAX WG meeting this meeting was wearing a T-shirt that had only one phrase on it..."IP: necessary and sufficient". One interesting side note, I noticed he was also running "Linux" on his laptop, not Win95 like most everyone else was running....hmmm.... Randy Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >Date: Fri, 3 Apr 1998 16:16:48 PST >To: "Gordon, Charles" , ipp@pwg.org >From: Carl-Uno Manros >Subject: RE: IPP> Host to device >Cc: Rdebry@Us.Ibm.Com, Ipp@pwg.org > >Charles, > >You are right that if we see this only from an IETF perspective, >we do not need to care about all the other transfer protocols. >However, it is of general interest to members of the PWG to also >look for solutions that go beyond the IETF scope. > >I expect that when we write up a solution for extending the IPP >within the IETF to cover IPP notifications, such a proposal >will be limited to the TCP/IP case. > >Carl-Uno > >At 01:56 PM 4/3/98 PST, Gordon, Charles wrote: >>Given that IPP is the Internet Printing Protocol, do we really need to >>support anything else besides TCP/IP? Is the IPP working group even >>mandated to worry about non TCP/IP environments? >> >> --- Charles >> >>> -----Original Message----- >>> From: don@lexmark.com [SMTP:don@lexmark.com] >>> Sent: Friday, April 03, 1998 4:22 PM >>> To: rturner@sharplabs.com >>> Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org >>> Subject: RE: IPP> Host to device >>> >>> >>> Randy: >>> >>> My biggest concern is that your proposal is TCP/IP only. Is does not >>> solve >>> the problem for printers connected to servers via: >>> >>> - Parallel >>> - Serial >>> - USB >>> - 1394 >>> - IPX/SPX >>> - AppleTalk >>> - DLC/LLC >>> - etc., etc., etc. >>> >>> If I'm going to use TCP/IP then I might as well go ahead with the HTTP >>> based implementation. You don't provide more status and control or >>> anything else that really buys me anything other than a slightly >>> lighter >>> transport. It's just not work the trouble for the return on >>> investment. >>> >>> Don >>> >>> ********************************************** >>> * Don Wright don@lexmark.com * >>> * Product Manager, Strategic Alliances * >>> * Lexmark International * >>> * 740 New Circle Rd * >>> * Lexington, Ky 40550 * >>> * 606-232-4808 (phone) 606-232-6740 (fax) * >>> ********************************************** >>> >> >> >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com >----------------------------------------------------------------------< From ipp-owner@pwg.org Sat Apr 4 02:17:47 1998 Delivery-Date: Sat, 04 Apr 1998 02:17:47 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA17424 for ; Sat, 4 Apr 1998 02:17:46 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA27039 for ; Sat, 4 Apr 1998 02:20:13 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA07830 for ; Sat, 4 Apr 1998 02:17:41 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 4 Apr 1998 02:12:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA07246 for ipp-outgoing; Sat, 4 Apr 1998 02:12:04 -0500 (EST) From: Harry Lewis To: Cc: Roger K Debry , , , Subject: RE: IPP> Host to device Message-ID: <5030300019680543000002L032*@MHS> Date: Sat, 4 Apr 1998 02:18:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id CAA17424 I disagree that it would be odd to see IPP over other transports. Why would that be any less desirable than, say, TIPSI over USB? What is odd, to me, is for a standards group to invent one protocol and not deploy it (TIPSI), then, later, invent another (IPP) and try to limit (rather than enhance) it, trying to substitute the (now) older solution in it's place. Roger's observation is that, what makes TIPSI transport independent, is the packet structure, with continuation flag, ACKs and the ability to interleave commands (like CANCEL), not the command/query definitions themselves (which have been superseded by IPP). Randy is evolving a specific mapping to TCP/IP which addresses these issues as well (chunking, separate channel...). I don't see what is wrong with either approach. Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 04/03/98 03:25:05 PM Please respond to ipp-owner@pwg.org To: rturner@sharplabs.com, don@lexmark.com, CGordon@wal.osicom.com cc: Ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus Subject: RE: IPP> Host to device Good point - it would look very odd to have IPP for USB. Also odd would be to have two IPP implmentations on TCP/IP - HTTP and direct TCP/IP. In retrospect the correct thing to have done was to produce a mapping of TIP/SI onto HTTP. Ie. HTTP is just another transport layer. > -----Original Message----- > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > Sent: Friday, April 03, 1998 1:57 PM > To: 'don@lexmark.com'; rturner@sharplabs.com > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > Subject: RE: IPP> Host to device > > Given that IPP is the Internet Printing Protocol, do we really need to > support anything else besides TCP/IP? Is the IPP working group even > mandated to worry about non TCP/IP environments? > > --- Charles > > > -----Original Message----- > > From: don@lexmark.com [SMTP:don@lexmark.com] > > Sent: Friday, April 03, 1998 4:22 PM > > To: rturner@sharplabs.com > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > Subject: RE: IPP> Host to device > > > > > > Randy: > > > > My biggest concern is that your proposal is TCP/IP only. Is does not > > solve > > the problem for printers connected to servers via: > > > > - Parallel > > - Serial > > - USB > > - 1394 > > - IPX/SPX > > - AppleTalk > > - DLC/LLC > > - etc., etc., etc. > > > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > > based implementation. You don't provide more status and control or > > anything else that really buys me anything other than a slightly > > lighter > > transport. It's just not work the trouble for the return on > > investment. > > > > Don > > > > ********************************************** > > * Don Wright don@lexmark.com * > > * Product Manager, Strategic Alliances * > > * Lexmark International * > > * 740 New Circle Rd * > > * Lexington, Ky 40550 * > > * 606-232-4808 (phone) 606-232-6740 (fax) * > > ********************************************** > > From ipp-owner@pwg.org Sat Apr 4 08:01:02 1998 Delivery-Date: Sat, 04 Apr 1998 08:01:03 -0500 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA19363 for ; Sat, 4 Apr 1998 08:00:58 -0500 (EST) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA20615 for ; Sat, 4 Apr 1998 08:03:24 -0500 (EST) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA18656 for ; Sat, 4 Apr 1998 08:00:54 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Sat, 4 Apr 1998 07:51:19 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA18007 for ipp-outgoing; Sat, 4 Apr 1998 07:51:04 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Host to device Date: Sat, 4 Apr 1998 04:50:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Once I get a draft in more or less complete form, I think you will find the implementation burden to be far less than IPP over HTTP. Once we start actually doing interop with a variety of HTTP servers or clients, I think we will see that in order to properly interoperate in the HTTP world (HTTP 1.1), that we will have to have several iterations of interop to get things even close to handling the variety of HTTP client/server environments that exist. I am mainly concerned with issues like: 1. The fact that Apache is the most widely used and deployed HTTP server in the market, and it doesn't support chunking through the CGI interface. 2. Realizing that there will be problems using things like "chunking" to currently deployed hybrid HTTP 1.0/1.1 servers. 3. Tunneling issues with security, through HTTP proxies. 4. HTTP proxy response caching. There are other issues with proper handling of HTTP headers and status codes that I won't go into in this note. None of the above issues are issues for my transport proposal. In my opinion, the burden of implementation is quite high with HTTP, much higher than what is implied by my proposal. I think the burden is high whether you roll your own HTTP or license the code from an outside vendor. Not that I'm trashing our decision to use it as a transport. I still think it is viable, but it is a very non-trivial design issue for both IPP clients and servers. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Friday, April 03, 1998 1:22 PM To: rturner@sharplabs.com Cc: Rdebry@Us.Ibm.Com; Ipp@Pwg.Org Subject: RE: IPP> Host to device Randy: My biggest concern is that your proposal is TCP/IP only. Is does not solve the problem for printers connected to servers via: - Parallel - Serial - USB - 1394 - IPX/SPX - AppleTalk - DLC/LLC - etc., etc., etc. If I'm going to use TCP/IP then I might as well go ahead with the HTTP based implementation. You don't provide more status and control or anything else that really buys me anything other than a slightly lighter transport. It's just not work the trouble for the return on investment. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jmp-owner@pwg.org Sun Apr 5 12:25:30 1998 Delivery-Date: Sun, 05 Apr 1998 12:25:40 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA07897 for ; Sun, 5 Apr 1998 12:24:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21601 for ; Sun, 5 Apr 1998 12:27:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06658 for ; Sun, 5 Apr 1998 12:24:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 5 Apr 1998 12:21:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06237 for jmp-outgoing; Sun, 5 Apr 1998 12:19:24 -0400 (EDT) Date: Sun, 5 Apr 1998 09:25:04 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9804051625.AA20490@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: JMP> Posted JAM MIB v0.20 - 5 April 1998 Sender: jmp-owner@pwg.org Copies To: jmp@pwg.org hastings@cp10.es.xerox.com Joe_Filion@mc.xerox.com imcdonal@eso.mc.xerox.com Hi folks, Sunday (5 April 1998) In response to Ron Bergman's recent agenda topic on Notifications for the JMP session at the PWG monthly meeting, I just posted the text of a revised (documentation only) JAM MIB written by Joe Filion (Xerox) and Ira McDonald (High North) to the PWG FTP server in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ SYNOPSIS ------------------------------------------------------------------------ This document specifies the Job Async Monitoring (JAM) MIB, an individual contribution to the Job Monitoring Project (JMP) of the Printer Working Group (PWG), a work-in-progress MIB module for the entire printer industry, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The JAM MIB specifies a lightweight SNMP trap registration mechanism for end-user clients, management stations, and management proxies. This SNMP trap registration mechanism is SNMP protocol version independent. This SNMP trap registration mechanism is security scheme independent. The JAM MIB is a companion to the PWG Job Monitoring MIB and the IETF/PWG Printer MIB (published separately). The JAM MIB is UNENCUMBERED by any patents pending or granted or other intellectual property considerations. ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ These files are in 'ftp://ftp.pwg.org/pub/pwg/jmp/contributions': rel_0405.txt - this release note jam_v020.txt - Job Async Monitoring MIB v0.20 - text w/ formfeeds jam_v020.mib - Job Async Monitoring MIB v0.20 - ASN.1 source of MIB From ipp-owner@pwg.org Sun Apr 5 12:29:31 1998 Delivery-Date: Sun, 05 Apr 1998 12:29:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA07945 for ; Sun, 5 Apr 1998 12:29:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA23541 for ; Sun, 5 Apr 1998 12:31:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06989 for ; Sun, 5 Apr 1998 12:29:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 5 Apr 1998 12:19:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06229 for ipp-outgoing; Sun, 5 Apr 1998 12:19:17 -0400 (EDT) Date: Sun, 5 Apr 1998 09:25:04 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9804051625.AA20490@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, hastings@cp10.es.xerox.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Posted JAM MIB v0.20 - 5 April 1998 Sender: ipp-owner@pwg.org Copies To: jmp@pwg.org hastings@cp10.es.xerox.com Joe_Filion@mc.xerox.com imcdonal@eso.mc.xerox.com Hi folks, Sunday (5 April 1998) In response to Ron Bergman's recent agenda topic on Notifications for the JMP session at the PWG monthly meeting, I just posted the text of a revised (documentation only) JAM MIB written by Joe Filion (Xerox) and Ira McDonald (High North) to the PWG FTP server in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ SYNOPSIS ------------------------------------------------------------------------ This document specifies the Job Async Monitoring (JAM) MIB, an individual contribution to the Job Monitoring Project (JMP) of the Printer Working Group (PWG), a work-in-progress MIB module for the entire printer industry, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The JAM MIB specifies a lightweight SNMP trap registration mechanism for end-user clients, management stations, and management proxies. This SNMP trap registration mechanism is SNMP protocol version independent. This SNMP trap registration mechanism is security scheme independent. The JAM MIB is a companion to the PWG Job Monitoring MIB and the IETF/PWG Printer MIB (published separately). The JAM MIB is UNENCUMBERED by any patents pending or granted or other intellectual property considerations. ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ These files are in 'ftp://ftp.pwg.org/pub/pwg/jmp/contributions': rel_0405.txt - this release note jam_v020.txt - Job Async Monitoring MIB v0.20 - text w/ formfeeds jam_v020.mib - Job Async Monitoring MIB v0.20 - ASN.1 source of MIB From ipp-owner@pwg.org Mon Apr 6 13:31:06 1998 Delivery-Date: Mon, 06 Apr 1998 13:31:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01333 for ; Mon, 6 Apr 1998 13:31:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13052 for ; Mon, 6 Apr 1998 13:33:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19884 for ; Mon, 6 Apr 1998 13:30:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 13:18:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18770 for ipp-outgoing; Mon, 6 Apr 1998 13:18:05 -0400 (EDT) Content-return: allowed Date: Mon, 6 Apr 1998 10:17:14 PDT From: "Zehler, Peter " Subject: IPP> TES Print test across the Internet To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org All, A couple of individuals participated in a simple IPP test across the Internet. After resolving a proxy problem on the client side, a simple print job was sent. The test was a success. A trace has been posted in the TES traces directory. Subsequent operations were attempted. The requests/responses were sent and received successfully. However the operations were not yet supported on the printer side and only a dummy response was returned. (these were not posted to the trace directory). Plans to try the operations in the reverse direction could not occur due to problems logging into an ISP. The problems could have been avoided if one of the individuals would have access to the T1 link that has been promised him for about 4 months. (It will be up when the individual returns from the Portland meeting....yeah...sure) Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Mon Apr 6 13:31:26 1998 Delivery-Date: Mon, 06 Apr 1998 13:31:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01351 for ; Mon, 6 Apr 1998 13:31:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13153 for ; Mon, 6 Apr 1998 13:33:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19935 for ; Mon, 6 Apr 1998 13:31:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 13:25:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19095 for ipp-outgoing; Mon, 6 Apr 1998 13:25:08 -0400 (EDT) Message-Id: <3.0.1.32.19980406101757.009cd210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 10:17:57 PDT To: moore+iesg@cs.utk.edu, Harald.Alvestrand@maxware.no From: Carl-Uno Manros Subject: IPP> Short meeting note from the IETF41 IPP WG meeting Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Keith & Harald, Here are my short notes from the IPP WG meeting. Carl-Uno ----- About 30 people attended the IPP WG meeting. The agenda was shortened from the originally published one as no feedback was yet available from the IESG review. The remaining work within the current charter was presented and discussed. This covered IPP notifications and mapping of the IPP generic directory schema to the Service Location Protocol and LDAP. A short discussion was held on possible future work, and the group answered a few questions for clarification from Keith Moore, who is reviewing the drafts for the IESG. Keith estimated that the IESG decision would come during the second half of April. The WG expects to have finished the work on the current charter in time for IETF42. Carl-Uno Manros Co-chair IETF WG on IPP Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 6 13:49:30 1998 Delivery-Date: Mon, 06 Apr 1998 13:49:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01854 for ; Mon, 6 Apr 1998 13:49:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA20154 for ; Mon, 6 Apr 1998 13:51:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20600 for ; Mon, 6 Apr 1998 13:49:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 13:45:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20069 for ipp-outgoing; Mon, 6 Apr 1998 13:45:08 -0400 (EDT) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC47B@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Harry Lewis'" , ipp@pwg.org Cc: Roger K Debry , CGordon@wal.osicom.com, don@lexmark.com, rturner@sharplabs.com Subject: RE: IPP> Host to device Date: Mon, 6 Apr 1998 10:43:03 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org I meant 'odd' in a very specific way. IPP is INTERNET Printng Protocol - USB is not normally considered as an Internet transport. The Internet is, after all, a TCP/IP network. I do not see anybody trying to LIMIT IPP. All I see are people (including me) pointing out its limitiations - this is not the same thing at all. > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Friday, April 03, 1998 11:19 PM > To: ipp@pwg.org > Cc: Roger K Debry; CGordon@wal.osicom.com; don@lexmark.com; > rturner@sharplabs.com > Subject: RE: IPP> Host to device > > I disagree that it would be odd to see IPP over other transports. Why > would > that be any less desirable than, say, TIPSI over USB? What is odd, to me, > is > for a standards group to invent one protocol and not deploy it (TIPSI), > then, > later, invent another (IPP) and try to limit (rather than enhance) it, > trying > to substitute the (now) older solution in it's place. Roger's observation > is > that, what makes TIPSI transport independent, is the packet structure, > with > continuation flag, ACKs and the ability to interleave commands (like > CANCEL), > not the command/query definitions themselves (which have been superseded > by > IPP). Randy is evolving a specific mapping to TCP/IP which addresses these > issues as well (chunking, separate channel...). I don't see what is wrong > with > either approach. > > Harry Lewis - IBM Printing Systems > > > > > ipp-owner@pwg.org on 04/03/98 03:25:05 PM > Please respond to ipp-owner@pwg.org > To: rturner@sharplabs.com, don@lexmark.com, CGordon@wal.osicom.com > cc: Ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus > Subject: RE: IPP> Host to device > > > Good point - it would look very odd to have IPP for USB. > > Also odd would be to have two IPP implmentations on TCP/IP - HTTP and > direct > TCP/IP. > > In retrospect the correct thing to have done was to produce a mapping of > TIP/SI onto HTTP. Ie. HTTP is just another transport layer. > > > -----Original Message----- > > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com] > > Sent: Friday, April 03, 1998 1:57 PM > > To: 'don@lexmark.com'; rturner@sharplabs.com > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > Subject: RE: IPP> Host to device > > > > Given that IPP is the Internet Printing Protocol, do we really need to > > support anything else besides TCP/IP? Is the IPP working group even > > mandated to worry about non TCP/IP environments? > > > > --- Charles > > > > > -----Original Message----- > > > From: don@lexmark.com [SMTP:don@lexmark.com] > > > Sent: Friday, April 03, 1998 4:22 PM > > > To: rturner@sharplabs.com > > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org > > > Subject: RE: IPP> Host to device > > > > > > > > > Randy: > > > > > > My biggest concern is that your proposal is TCP/IP only. Is does not > > > solve > > > the problem for printers connected to servers via: > > > > > > - Parallel > > > - Serial > > > - USB > > > - 1394 > > > - IPX/SPX > > > - AppleTalk > > > - DLC/LLC > > > - etc., etc., etc. > > > > > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP > > > based implementation. You don't provide more status and control or > > > anything else that really buys me anything other than a slightly > > > lighter > > > transport. It's just not work the trouble for the return on > > > investment. > > > > > > Don > > > > > > ********************************************** > > > * Don Wright don@lexmark.com * > > > * Product Manager, Strategic Alliances * > > > * Lexmark International * > > > * 740 New Circle Rd * > > > * Lexington, Ky 40550 * > > > * 606-232-4808 (phone) 606-232-6740 (fax) * > > > ********************************************** > > > > > > From ipp-owner@pwg.org Mon Apr 6 14:08:32 1998 Delivery-Date: Mon, 06 Apr 1998 14:08:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA02354 for ; Mon, 6 Apr 1998 14:08:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA06124 for ; Mon, 6 Apr 1998 14:10:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21235 for ; Mon, 6 Apr 1998 14:08:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 14:04:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20700 for ipp-outgoing; Mon, 6 Apr 1998 14:04:20 -0400 (EDT) Message-Id: <3.0.1.32.19980406105715.00994600@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 10:57:15 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Trouble with references Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, One of the things I discovered during last week's IETF meeting in LA is that we are in trouble with a couple of our references in the IPP drafts. This means that even if we get past the IESG review, we will have trouble when documents arrive at the RFC editor's desk. Here are the problem children: RFC2234 ABNF, although this is an RFC officially on the standards track, Dave Crocker who is the editor, indicated that there are still a couple of minor editorial changes to fix. He will do those ASAP. TLS TLS has been accepted by the IESG, but they have a reference problem with PKIX, which still has to be resolved. The quick fix will be to change PKIX to X.509 as reference. The editors are working on this change. URI The URI draft has not matured to the standards track. There are some serious problems to resolve, which may take considerable time. The advice from Larry Masinter, who is the editor, seems to be to go back to using URL where ever we use URI (which would also mean changing a number of attribute names!). Sigh :-( Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 6 14:42:29 1998 Delivery-Date: Mon, 06 Apr 1998 14:42:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03272 for ; Mon, 6 Apr 1998 14:42:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00296 for ; Mon, 6 Apr 1998 14:44:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21919 for ; Mon, 6 Apr 1998 14:42:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 14:38:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21364 for ipp-outgoing; Mon, 6 Apr 1998 14:38:11 -0400 (EDT) Message-Id: <3.0.1.32.19980406113110.00b6e140@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 11:31:10 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for IPP Meeting in portland, OR - April 8-9, 1998 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org No two days before the meeting and here is the agenda already: Agenda for IPP Meeting in Portland, OR - April 8-9, 1998 ======================================================== Wednesday April 8: - Short report from IEF41 in LA - Continue discussion of IPP notifications, including goodies like: - What goes into the IETF version? - Are we happy using Tom's latest solution for the dictionary attribute? - Review stand of IPP interoperability testing - Review of latest thinking on print driver download Thursday April 9: - Continue discussion of host-to-device protocol, including: - Review and reactions to Don's proposal for TIP/SI - Review and reactions to Randy's proposal for alternate mapping of IPP - Joint review and discussion of SNMPv3 traps and informs Hope to see many of you on Wednesday (bring a raincoat, misable weather expected), Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 6 14:50:46 1998 Delivery-Date: Mon, 06 Apr 1998 14:50:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03410 for ; Mon, 6 Apr 1998 14:50:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00332 for ; Mon, 6 Apr 1998 14:53:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22551 for ; Mon, 6 Apr 1998 14:50:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 14:46:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21991 for ipp-outgoing; Mon, 6 Apr 1998 14:46:35 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> PRO: Protocol Examples Message-ID: <5030100019283275000002L052*@MHS> Date: Mon, 6 Apr 1998 14:46:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA03410 According to MOD, "IPP requires all lower case" for 'charset' and 'naturalLanguage' (refer to sections 4.1.9 and 4.1.10). However, the Protocol Examples in Appendix A of MOD show mixed-case values, e.g.: "en-US" and " US-ASCII", for attributes of type 'charset' and 'naturalLanguage' such as attributes-charset and attributes-natural-language. Is this apparent conflict an error? -Carl Kugler From ipp-owner@pwg.org Mon Apr 6 15:10:16 1998 Delivery-Date: Mon, 06 Apr 1998 15:10:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03811 for ; Mon, 6 Apr 1998 15:10:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00400 for ; Mon, 6 Apr 1998 15:12:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23177 for ; Mon, 6 Apr 1998 15:10:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 15:05:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22650 for ipp-outgoing; Mon, 6 Apr 1998 15:05:18 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> TES Print test across the Internet Message-ID: <5030100019283881000002L012*@MHS> Date: Mon, 6 Apr 1998 15:04:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA03811 Regarding PZ012B00.trc: section 15.3.4.3 of MOD says that attributes-charset and attributes-natural-language are MANDATORY Operation Attributes for a Print-Job Response. I don't see these in your trace. Also, job-uri (which you do have), job-id, job-state are MANDATORY Job Object Attributes for a Print-Job Response when one of the success codes is returned (as in this case). -Carl ipp-owner@pwg.org on 04/06/98 11:22:46 AM Please respond to ipp-owner@pwg.org To: IPP@pwg.org cc: Subject: IPP> TES Print test across the Internet All, A couple of individuals participated in a simple IPP test across the Internet. After resolving a proxy problem on the client side, a simple print job was sent. The test was a success. A trace has been posted in the TES traces directory. Subsequent operations were attempted. The requests/responses were sent and received successfully. However the operations were not yet supported on the printer side and only a dummy response was returned. (these were not posted to the trace directory). Plans to try the operations in the reverse direction could not occur due to problems logging into an ISP. The problems could have been avoided if one of the individuals would have access to the T1 link that has been promised him for about 4 months. (It will be up when the individual returns from the Portland meeting....yeah...sure) Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Mon Apr 6 15:53:40 1998 Delivery-Date: Mon, 06 Apr 1998 15:53:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04666 for ; Mon, 6 Apr 1998 15:53:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00579 for ; Mon, 6 Apr 1998 15:56:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23871 for ; Mon, 6 Apr 1998 15:53:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 15:47:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23323 for ipp-outgoing; Mon, 6 Apr 1998 15:47:37 -0400 (EDT) Message-Id: <199804061944.MAA23582@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Apr 1998 12:47:01 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarificatio In-Reply-To: <5030100019228340000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA04666 If I understand your question correctly, I think that you have having the same confusion that many other people have had about the word "MANDATORY". It means that the "Printer" must support the attribute. It does NOT mean that the attribute must be included in each request/response. In this particular case, attributes-charset is MANDATORY, i.e. the printer must support the attribute, but in the get-jobs reponse it MUST be in the operation attributes group and it is only in each job attribute group if the client requested the attribute via the requested-attributes attribute in the request. Note, even if it is present in a job attributes group it does not affect the charset of those attributes. All attributes in the entire response are in the charset specified by attributes-charset in the operations attribute group, which I still believe must be first in that group (a change we need to make to the model document). Note that in the example attributes-natural-language is in one of the job attribute groups in order to override the natural-language in the operation attributes. As I have been implementing IPP, I have come to believe that this was a bad idea. It again requires a special ordering, i.e. attributes-natural-language must precede all other attributes if processing is to be simple. Bob Herriot At 03:34 PM 4/3/98 , Carl Kugler wrote: >Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >attribute in any of the three job attributes groups.  But section 4.3 of the >Model document, "Job Description Attributes", says that attributes-charset is >MANDATORY in the "job-description" attribute group.  This is causing me >cognitive dissonance. > From ipp-owner@pwg.org Mon Apr 6 16:03:27 1998 Delivery-Date: Mon, 06 Apr 1998 16:04:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04917 for ; Mon, 6 Apr 1998 16:03:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA00627 for ; Mon, 6 Apr 1998 16:05:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24495 for ; Mon, 6 Apr 1998 16:03:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 15:58:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23953 for ipp-outgoing; Mon, 6 Apr 1998 15:58:10 -0400 (EDT) Message-Id: <3.0.1.32.19980406125546.01010b60@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 12:55:46 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - DRAFT IPP WG meeting minutes at the IETF plenary, 4/1/98 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org I've posted these draft minutes at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.doc ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.pdf ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.txt The final minutes will be sent to the IETF later. Perhaps we should review these minutes at the IPP meeting this week before sending them. Tom DRAFT IPP Working Group IETF Meeting Minutes April 1, 1998 Los Angeles, California The meeting of the IPP WG at the IETF plenary was held on April 1, 1998 1:00-3:00 PM. The attendees were: 1. Agenda 1) Requirements for notification 2) Directory features 3) Other future work 4) Area Directors questions about IPP 2. Requirements for notification Carl-Uno presented the requirements for IPP notification: Notification Requester Notification Recipient(s) Notification Content (events, attributes) Notification Formats (human, machine) Notification Timeliness (email, immediate) Scott Isaacson reported that there is an LDAP I-D in WG last call on dynamic attributes: draft-ieft-asid-ldapv3-dynamic-07.txt A requester can supply a "persistent search" on some dynamic attributes of an entry and get results whenever they change. Thus LDAP is providing a mechanism that could be used for notification. This approach scales, in that the LDAP server is centralized, so that each client that wanted to get notifications would register with the LDAP server once. Printers would indicate events to the LDAP server once for each event, no matter how many clients wanted results. Scott also presented a summary of a survey of notification mechanisms that have been developed in other arenas: message queue (pull) publish/subscribe (push) Quality of Service (privacy, latency, authentication, authorization) Variants (durable, once, at least once, at most once) Industry (OMG, Java, SNMPv3, email, SMTP MDN/DSN Abstract Events: Printer (error, warning, report) Job (error, warning, report) Concrete Events: State Change (input tray < 50 sheets) Concentrate on abstract events An attendee suggested that we consider Tool Talk has broadcast has event filtering Jeff Case, SNMPv3 developer, was present and indicated that SNMPv3 needed the System Administrator to setup authorization for each subscriber. Jeff Case and Keith Moore live near each other in Tennessee and will get together to discuss SNMPv3 capabilities and usage for notification. It would be good if a PWG member could attend their discussion as well. 2. Directory Schema Scott Isaacson indicated that he and several other IPP folks worked with the SLP editor to update the printer scheme intended to cover an IPP printer and an LPD printer. The entries for each might look like: service:printer:http://server.sun.com/cgi-bin/push-printer service:printer:lpr:// The SLP STRINGL (L for literal) is identical to IPP keywords, i.e., no translation to user's natural language. One SLP entry is needed for each printer and security combination. So even if an IPP Printer uses a single URI for both secure and regular, the SLP directory will need two entries. In SLP, the concrete protocol is http and lpr, respectively, and the abstract protocol is ipp. 3. Future Work Carl-Uno indicated that possible future work might include: 1) System Administrator functions 2) Extensions, such as dictionaries and per document attributes 3) MIME media types for each of the Printer MIB Interpreter Language families that do not currently have MIME media types. 4) Extensions for Host-to-Device usage 3.1 MIME media type feedback IETF feedback indicated that we should ask vendor's whether they wanted to register their own Interpreter Language family, or wanted the PWG to do it on their behalf. Keith Moore indicated that there is no problem with the PWG registering something that a particular company owns, especially if it is in common usage but that company isn't registering the Interpreter Language family. On the other hand, if an Interpreter Language Family isn't being used any more, there is no point in registering it. ACTION ITEM (Tom Hastings): prepare a straw man list of Printer MIB Interpreter Language family entries, indicating which already have MIME media types, which the PWG wishes to register, unless the vendor responds that they prefer to, and which the PWG has no interest in registering and will leave to the vendor to do as it pleases. 3.2 Host-to-device extensions Keith Moore indicated that the IETF might be willing to have a host-to-device protocol on the IETF standards track. He'd like to hear more about it. 4. Keith Moore's questions and feedback about IPP Keith indicated that he is reading the IPP documents carefully. Because the document is long, it is taking a while. He and the IESG will have some responses in a few weeks. He has some questions that the group was glad to answer: 1) What kind of extensions can be added without effecting interoperation? Answer: new values to existing attributes, new Job Template attributes, new Operation Attributes, and any Job Template attribute extension (if the requester omits or supplies the "ipp-attribute-fidelity" = 'false'). 2) He questioned the Create-Job "ipp-attribute-fidelity" operation attribute being for all Job Template attributes at once. He thought that the *implementation code* would be simpler and more extensible if fidelity were specified per attribute. Answer: We explained that we could compatibility add a Create-Job operation attribute that explicitly listed Job Template attributes that were compulsory (and/or one that listed Job Template attributes that were non-compulsory), since unknown operation attributes SHALL be ignored and returned in the response (with 'successful-ok-ignored-or-substituted-attributes' status code returned as a status). Only if ignoring an operation attribute extension would adversely affect new clients working with older servers, would we have to increment the major version number of the protocol. This was an illustration of how we could compatibly add attributes without impacting interoperability. 3) What job state should an IPP Printer return, if it sends jobs to a device or server that cannot be queried? Answer: return the 'unknown' value for a query of the job's "job-state" attribute. 4) What were the IPP WG feelings about using the Post HTTP operation for all IPP operations? Answer: The meeting attendees discussed the issue of using Post versus a new operation. Keith indicated that using a new operation would simplify administration of firewalls. On the other hand, there were HTTP experts present that said that the purpose of a Post operation was to update a data base. The IPP create operations certainly fit that description. However, the IPP query operations (Get-Job-Attributes, Get-Printer-Attributes, Get-Jobs), aren't updating a data base. There was no conclusion for or against using HTTP Post (or a mixture of Post and Get) or a new operation. As before, there are pros and cons. From ipp-owner@pwg.org Mon Apr 6 16:23:23 1998 Delivery-Date: Mon, 06 Apr 1998 16:23:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA05351 for ; Mon, 6 Apr 1998 16:23:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA00731 for ; Mon, 6 Apr 1998 16:25:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25143 for ; Mon, 6 Apr 1998 16:23:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 16:18:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24605 for ipp-outgoing; Mon, 6 Apr 1998 16:18:41 -0400 (EDT) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC47D@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> ADM - Trouble with references Date: Mon, 6 Apr 1998 13:18:29 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: ipp-owner@pwg.org URI The URI draft has not matured to the standards track. There are some serious problems to resolve, which may take considerable time. The advice from Larry Masinter, who is the editor, seems to be to go back to using URL where ever we use URI (which would also mean changing a number of attribute names!). Which changes the wire representation! This is not just a documentation issue. > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, April 06, 1998 10:57 AM > To: ipp@pwg.org > Subject: IPP> ADM - Trouble with references > > All, > > One of the things I discovered during last week's IETF meeting in LA is > that we are in trouble with a couple of our references in the IPP drafts. > This means that even if we get past the IESG review, we will have trouble > when documents arrive at the RFC editor's desk. > > Here are the problem children: > > RFC2234 ABNF, although this is an RFC officially on the standards > track, > Dave Crocker who is the editor, indicated that there are still > a couple of minor editorial > changes to fix. He will do those ASAP. > > TLS TLS has been accepted by the IESG, but they have a reference > problem > with PKIX, which still has to be resolved. The quick fix > will > be to change PKIX > to X.509 as reference. The editors are working on > this change. > > URI The URI draft has not matured to the standards track. There > are some > serious problems to resolve, which may take considerable > time. The > advice from Larry Masinter, who is the editor, seems to be > to go > back to using URL where ever we use URI (which would also > mean changing a number of > attribute names!). > > Sigh :-( > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 6 17:25:24 1998 Delivery-Date: Mon, 06 Apr 1998 17:25:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06436 for ; Mon, 6 Apr 1998 17:25:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01108 for ; Mon, 6 Apr 1998 17:27:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26028 for ; Mon, 6 Apr 1998 17:10:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 17:06:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25417 for ipp-outgoing; Mon, 6 Apr 1998 17:05:51 -0400 (EDT) From: Carl Kugler To: Subject: IPP> TES Binary traces of Protocol Examples from PRO appendi Message-ID: <5030100019288404000002L042*@MHS> Date: Mon, 6 Apr 1998 17:05:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA06436 I have created application-level binary trace files of all the Protocol Examples from Appendix A of PRO, and uploaded them to ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/ This table shows the mapping from file name to document section and title: File 9. Appendix A: Protocol Examples ----------------------------------------------- 00912A01 9.1 Print-Job Request 00912B01 9.2 Print-Job Response (successful) 00912B02 9.3 Print-Job Response (failure) 00943A01 9.4 Print-URI Request 00955A01 9.5 Create-Job Request 0096AA01 9.6 Get-Jobs Request 0096AB01 9.7 Get-Jobs Response Carl Kugler IBM From ipp-owner@pwg.org Mon Apr 6 17:25:37 1998 Delivery-Date: Mon, 06 Apr 1998 17:25:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06443 for ; Mon, 6 Apr 1998 17:25:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01121 for ; Mon, 6 Apr 1998 17:28:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26562 for ; Mon, 6 Apr 1998 17:14:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 17:10:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25874 for ipp-outgoing; Mon, 6 Apr 1998 17:09:37 -0400 (EDT) Message-ID: <35294481.8E63363F@underscore.com> Date: Mon, 06 Apr 1998 17:09:21 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: Ipp@pwg.org Subject: Re: IPP> TES Binary traces of Protocol Examples from PRO appendi References: <5030100019288404000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org It would be nice if the *complete* URL was listed in your mail message. ;-) Same advice goes to all the other folks who post announcement messages for uploaded files. Thanks in advance. ...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 Kugler wrote: > > I have created application-level binary trace files of all the Protocol > Examples from Appendix A of PRO, and uploaded them to > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/ > > This table shows the mapping from file name to document section and title: > > File 9. Appendix A: Protocol Examples > ----------------------------------------------- > 00912A01 9.1 Print-Job Request > 00912B01 9.2 Print-Job Response (successful) > 00912B02 9.3 Print-Job Response (failure) > 00943A01 9.4 Print-URI Request > 00955A01 9.5 Create-Job Request > 0096AA01 9.6 Get-Jobs Request > 0096AB01 9.7 Get-Jobs Response > > Carl Kugler > IBM From ipp-owner@pwg.org Mon Apr 6 17:28:17 1998 Delivery-Date: Mon, 06 Apr 1998 17:28:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06526 for ; Mon, 6 Apr 1998 17:28:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01153 for ; Mon, 6 Apr 1998 17:30:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27207 for ; Mon, 6 Apr 1998 17:28:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 17:24:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26666 for ipp-outgoing; Mon, 6 Apr 1998 17:23:54 -0400 (EDT) From: Harry Lewis To: Cc: Roger K Debry , , , , Subject: RE: IPP> Host to device Message-ID: <5030300019742395000002L052*@MHS> Date: Mon, 6 Apr 1998 17:31:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA06526 In reverse order... >I do not see anybody trying to LIMIT IPP. All I see are people (including >me) pointing out its limitations - this is not the same thing at all. Agree. Poor phrasing on my part. Your list of limitations has formed an especially good basis for discussing enhancements. >I meant 'odd' in a very specific way. IPP is INTERNET Printing Protocol - USB >is not normally considered as an Internet transport. The Internet is, after >all, a TCP/IP network. Maybe I've allowed myself to become too hopeful regarding our IPP model From ipp-owner@pwg.org Mon Apr 6 17:33:25 1998 Delivery-Date: Mon, 06 Apr 1998 17:33:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06706 for ; Mon, 6 Apr 1998 17:33:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01198 for ; Mon, 6 Apr 1998 17:35:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27812 for ; Mon, 6 Apr 1998 17:33:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 17:29:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27260 for ipp-outgoing; Mon, 6 Apr 1998 17:28:55 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Message-ID: <5030100019289150000002L002*@MHS> Date: Mon, 6 Apr 1998 17:28:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA06706 Thanks, Bob, I think I get it now. Maybe your answer also provides a clue to my next question: If attributes-charset and attributes-natural-language Job Description Attributes are MANDATORY according to MOD/4.3, why aren't they shown as MANDATORY in "Group 3: Job Object Attributes" under Print-Job Response: Print-URI Response: Create-Job Response: Send-Document Response: Send-URI Response: Get-Job-Attributes Response: Get-Jobs Response: in MOD/15.3.4.3 "Validate the presence of a single occurrence of required Operation attributes"? Could it be that the word MANDATORY has different meanings in these two sections? 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. If it is not indicated as MANDATORY, then it is OPTIONAL 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST support and that a client MUST supply It's still not clear to me. -Carl robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM Please respond to robert.herriot@Eng.Sun.COM To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica If I understand your question correctly, I think that you have having the same confusion that many other people have had about the word "MANDATORY". It means that the "Printer" must support the attribute. It does NOT mean that the attribute must be included in each request/response. In this particular case, attributes-charset is MANDATORY, i.e. the printer must support the attribute, but in the get-jobs reponse it MUST be in the operation attributes group and it is only in each job attribute group if the client requested the attribute via the requested-attributes attribute in the request. Note, even if it is present in a job attributes group it does not affect the charset of those attributes. All attributes in the entire response are in the charset specified by attributes-charset in the operations attribute group, which I still believe must be first in that group (a change we need to make to the model document). Note that in the example attributes-natural-language is in one of the job attribute groups in order to override the natural-language in the operation attributes. As I have been implementing IPP, I have come to believe that this was a bad idea. It again requires a special ordering, i.e. attributes-natural-language must precede all other attributes if processing is to be simple. Bob Herriot At 03:34 PM 4/3/98 , Carl Kugler wrote: >Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >attribute in any of the three job attributes groups.* But section 4.3 of the >Model document, "Job Description Attributes", says that attributes-charset is >MANDATORY in the "job-description" attribute group.* This is causing me >cognitive dissonance. > From ipp-owner@pwg.org Mon Apr 6 17:42:18 1998 Delivery-Date: Mon, 06 Apr 1998 17:42:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06838 for ; Mon, 6 Apr 1998 17:42:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01235 for ; Mon, 6 Apr 1998 17:44:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA28463 for ; Mon, 6 Apr 1998 17:42:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 17:38:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27897 for ipp-outgoing; Mon, 6 Apr 1998 17:37:54 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: IPP> TES Binary traces of Protocol Examples from PRO app Message-ID: <5030100019289412000002L022*@MHS> Date: Mon, 6 Apr 1998 17:36:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA06838 You mean like this? ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912a01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912a01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b02.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b02.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00943a01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00943a01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00955a01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00955a01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096aa01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096aa01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096ab01.trc ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096ab01.txt What's the advantage you see? jkm@underscore.com on 04/06/98 03:10:32 PM Please respond to jkm@underscore.com To: Carl Kugler/Boulder/IBM@ibmus cc: Ipp@pwg.org Subject: Re: IPP> TES Binary traces of Protocol Examples from PRO app It would be nice if the *complete* URL was listed in your mail message. ;-) Same advice goes to all the other folks who post announcement messages for uploaded files. Thanks in advance. ...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 Kugler wrote: > > I have created application-level binary trace files of all the Protocol > Examples from Appendix A of PRO, and uploaded them to > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/ > > This table shows the mapping from file name to document section and title: > > File 9. Appendix A: Protocol Examples > ----------------------------------------------- > 00912A01 9.1 Print-Job Request > 00912B01 9.2 Print-Job Response (successful) > 00912B02 9.3 Print-Job Response (failure) > 00943A01 9.4 Print-URI Request > 00955A01 9.5 Create-Job Request > 0096AA01 9.6 Get-Jobs Request > 0096AB01 9.7 Get-Jobs Response > > Carl Kugler > IBM From ipp-owner@pwg.org Mon Apr 6 18:06:48 1998 Delivery-Date: Mon, 06 Apr 1998 18:06:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07062 for ; Mon, 6 Apr 1998 18:06:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01303 for ; Mon, 6 Apr 1998 18:09:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA29138 for ; Mon, 6 Apr 1998 18:06:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 18:02:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28574 for ipp-outgoing; Mon, 6 Apr 1998 18:02:21 -0400 (EDT) From: Harry Lewis To: Subject: RE: IPP> Host to device Message-ID: <5030300019743932000002L022*@MHS> Date: Mon, 6 Apr 1998 18:09:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA07062 Guess I ran out of quarters or something. My last post on this topic should have read... >Maybe I've allowed myself to become too hopeful regarding our IPP model >I view this as an abstract set of print operations and attributes which >can be mapped to nearly any transport protocol, the first being HTTP - thus >making this the Internet Printing Protocol. I expected future mappings, >to TCP/IP for example, and had hoped that printing would begin to look and >feel quite similar throughout the distributed environment. Peer-to-Peer may >be a different story, as you point out. Harry Lewis - IBM Printing Systems -- Forwarded by Harry Lewis-- ipp-owner@pwg.org on 04/06/98 03:26:43 PM Please respond to ipp-owner@pwg.org To: paulmo@microsoft.com cc: ipp@pwg.org, rturner@sharplabs.com, don@lexmark.com, CGordon@wal.osicom.com, Roger K Debry/Boulder/IBM@ibmus Subject: RE: IPP> Host to device In reverse order... >I do not see anybody trying to LIMIT IPP. All I see are people (including >me) pointing out its limitations - this is not the same thing at all. Agree. Poor phrasing on my part. Your list of limitations has formed an especially good basis for discussing enhancements. >I meant 'odd' in a very specific way. IPP is INTERNET Printing Protocol - USB >is not normally considered as an Internet transport. The Internet is, after >all, a TCP/IP network. Maybe I've allowed myself to become too hopeful regarding our IPP model From ipp-owner@pwg.org Mon Apr 6 18:37:58 1998 Delivery-Date: Mon, 06 Apr 1998 18:37:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07585 for ; Mon, 6 Apr 1998 18:37:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01591 for ; Mon, 6 Apr 1998 18:40:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA29784 for ; Mon, 6 Apr 1998 18:37:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 18:33:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29231 for ipp-outgoing; Mon, 6 Apr 1998 18:33:16 -0400 (EDT) Message-Id: <3.0.1.32.19980406153124.00fefa80@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 15:31:24 PDT To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Cc: In-Reply-To: <5030100019289150000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org At 14:28 04/06/1998 PDT, Carl Kugler wrote: >Thanks, Bob, I think I get it now. > >Maybe your answer also provides a clue to my next question: > >If attributes-charset and attributes-natural-language Job Description >Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >MANDATORY in "Group 3: Job Object Attributes" under > > Print-Job Response: > Print-URI Response: > Create-Job Response: > Send-Document Response: > Send-URI Response: > Get-Job-Attributes Response: > Get-Jobs Response: > >in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >Operation attributes"? Because "attributes-charset" and "attributes-natural-language" MUST be returned in Group 1 (not Group 3) as shown. See sections 3.1.4.2 Response Operation Attributes and Sections 3.2 Printer Operations under each Xxx Response Group 1. As Bob explained, MANDATORY in the document mostly means that a Server MUST support the attribute. It is a separate question as to whether the client MUST supply a MANDATORY attribute and whether an IPP object MUST return a MANDATORY attribute. In some cases, the client MUST supply a MANDATORY attribute and in other cases the client NEED NOT supply the MANDATORY attribute in a request. Similarly, in some cases, an IPP object MUST supply a MANDATORY attribute and in other cases the IPP object NEED NOT supply the MANDATORY attribute in a response. We tried to avoid using the word MANDATORY and OPTIONAL to mean whether a sender had to supply in a request or a response. We tried to only use the words MANDATORY and OPTIONAL to mean whether an IPP object had to implement or not. So there are four combinations for attributes in requests, of which only three are possible: MANDATORY OPTIONAL for an IPP object to support MUST supply we have we don't have MAY omit we have we have Keep those questions coming. We can always improve the spec and fix bugs that you find. > >Could it be that the word MANDATORY has different meanings in these two >sections? See above. > > 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. >If it is not indicated as MANDATORY, then it is OPTIONAL > > 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST >support and that a client MUST supply I think I see the confusion. The entire section in 15.3.4.3 is: The following tables list all the attributes for all the operations by attribute group in each request and each response. The left to right order of the groups is the order that the client supplies the groups as specified in Section 3.3. The order of the attributes within a group is arbitrary, though the tables below lists the attributes in the following order with the following notation: (M) MANDATORY attributes that an IPP object MUST support and that a client MUST supply (M*) MANDATORY attributes that an IPP object MUST support, but that a client may omit in a request or an IPP object may omit in a response (O) OPTIONAL attributes that an IPP object NEED NOT support (O*) OPTIONAL attributes that an IPP object NEED NOT support and a client may omit in a request or an IPP object may omit in a response The first line is NOT the definition of MANDATORY, but is explaining the notation (M) which means MANDATORY and that a client MUST supply. The notation (M*) in the second line is also MANDATORY, but a client MAY omit. The presence or absence of the "*" indicates whether the MANDATORY attribte (for support) MAY be omitted or not in a request or response. Would the following rewording help: In parenthesis the following notation is used: M indicates a MANDATORY attirbute that an IPP object MUST support O indicated an OPTIONAL attirbute that an IPP object NEED NOT support * indicates that a client MAY omit the attribute in a request and that an IPP object MAY omit the attribute in a response. The absence of an * means that a client MUST supply the attribute in a request and and an IPP object MUST supply the attribute in a response. Perhaps there is a better notation than *? Perhaps surrounding the attribute name itself inside [] would be a more familiar notation to indicate what can be omitted in a request or a response? > >It's still not clear to me. > > -Carl > > > >robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM >Please respond to robert.herriot@Eng.Sun.COM >To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus >cc: >Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica > > >If I understand your question correctly, I think that you have having the same >confusion >that many other people have had about the word "MANDATORY". It means that >the "Printer" must support the attribute. It does NOT mean that the attribute >must >be included in each request/response. > >In this particular case, attributes-charset is MANDATORY, i.e. the printer >must > >support the attribute, but in the get-jobs reponse it MUST be in the operation >attributes >group and it is only in each job attribute group if the client requested the >attribute via the >requested-attributes attribute in the request. Note, even if it is present >in a >job attributes >group it does not affect the charset of those attributes. All attributes in >the entire >response are in the charset specified by attributes-charset in the operations >attribute >group, which I still believe must be first in that group (a change we need to >make >to the model document). > >Note that in the example attributes-natural-language is in one of the job >attribute >groups in order to override the natural-language in the operation attributes. >As I >have been implementing IPP, I have come to believe that this was a bad idea. >It again >requires a special ordering, i.e. attributes-natural-language must precede all >other >attributes if processing is to be simple. > >Bob Herriot > > >At 03:34 PM 4/3/98 , Carl Kugler wrote: >>Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >>attribute in any of the three job attributes groups.* But section 4.3 of the >>Model document, "Job Description Attributes", says that attributes-charset is >>MANDATORY in the "job-description" attribute group.* This is causing me >>cognitive dissonance. >> > > > > > > From ipp-owner@pwg.org Mon Apr 6 19:12:20 1998 Delivery-Date: Mon, 06 Apr 1998 19:12:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07826 for ; Mon, 6 Apr 1998 19:12:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01686 for ; Mon, 6 Apr 1998 19:14:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA00776 for ; Mon, 6 Apr 1998 19:12:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 19:05:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29893 for ipp-outgoing; Mon, 6 Apr 1998 19:05:33 -0400 (EDT) Message-Id: <3.0.1.32.19980406160330.00c65aa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 16:03:30 PDT To: Paul Moore , "'Carl-Uno Manros'" , ipp@pwg.org From: Tom Hastings Subject: RE: IPP> MOD/ADM - Trouble with references In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC47D@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Yes, Paul is right. Changing the name of an attribute affects the bytes on the wire, since the keyword name of the attribute is sent on the wire. So if we change from "printer-uri" to "printer-url", we are changing the on the wire protocol too (as well as the model). All the attributes affected would be: Operation attributes: printer-uri document-uri Job attributes: job-uri job-printer-uri Printer attributes: printer-uri-supported uri-security-supported reference-uri-schemes-supported Error status codes (editorial only): client-error-request-uri-too-long client-error-uri-scheme-not-supported There are a number of attributes whose data syntax is 'uri', but don't have uri in their names, so we could either change these name RFC 1630 has the following note on the first page: IESG Note: Note that the work contained in this memo does not describe an Internet standard. An Internet standard for general Resource Identifiers is under development within the IETF. At 13:18 04/06/1998 PDT, Paul Moore wrote: > URI The URI draft has not matured to the standards >track. There are some > serious problems to resolve, which may take >considerable > time. The > advice from Larry Masinter, who is the editor, seems >to be to go > back to using URL where ever we use URI (which would >also > mean changing a number of > attribute names!). > >Which changes the wire representation! This is not just a documentation >issue. > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, April 06, 1998 10:57 AM >> To: ipp@pwg.org >> Subject: IPP> ADM - Trouble with references >> >> All, >> >> One of the things I discovered during last week's IETF meeting in LA is >> that we are in trouble with a couple of our references in the IPP drafts. >> This means that even if we get past the IESG review, we will have trouble >> when documents arrive at the RFC editor's desk. >> >> Here are the problem children: >> >> RFC2234 ABNF, although this is an RFC officially on the standards >> track, >> Dave Crocker who is the editor, indicated that there are still >> a couple of minor editorial >> changes to fix. He will do those ASAP. >> >> TLS TLS has been accepted by the IESG, but they have a reference >> problem >> with PKIX, which still has to be resolved. The quick fix >> will >> be to change PKIX >> to X.509 as reference. The editors are working on >> this change. >> >> URI The URI draft has not matured to the standards track. There >> are some >> serious problems to resolve, which may take considerable >> time. The >> advice from Larry Masinter, who is the editor, seems to be >> to go >> back to using URL where ever we use URI (which would also >> mean changing a number of >> attribute names!). >> >> Sigh :-( >> >> Carl-Uno >> >> >> Carl-Uno Manros >> Principal Engineer - Advanced Printing Standards - Xerox Corporation >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Mon Apr 6 19:15:17 1998 Delivery-Date: Mon, 06 Apr 1998 19:15:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07863 for ; Mon, 6 Apr 1998 19:15:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01707 for ; Mon, 6 Apr 1998 19:17:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01071 for ; Mon, 6 Apr 1998 19:15:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 19:08:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00238 for ipp-outgoing; Mon, 6 Apr 1998 19:08:16 -0400 (EDT) Message-ID: <35296051.C2791F82@underscore.com> Date: Mon, 06 Apr 1998 19:08:01 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: Ipp@pwg.org Subject: Re: IPP> TES Binary traces of Protocol Examples from PRO app References: <5030100019289412000002L022*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Thanks, that's a lot more functional for those of us who have URL-enabled email agents (such as Netscape and several others). By putting the entire URL (with *no* spaces or line breaks) in an email message, a user of such an email agent can directly bring up the referenced file with a single click, all without having to change applications, etc. This makes the document much, much more accessible to the user, and thereby should foster improved and more rapid access of the document(s) by the intended audience. And this is what the document write really desires, correct? ;-) ...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 Kugler wrote: > > You mean like this? > > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912a01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912a01.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b01.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b02.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00912b02.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00943a01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00943a01.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00955a01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/00955a01.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096aa01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096aa01.txt > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096ab01.trc > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/0096ab01.txt > > What's the advantage you see? > > jkm@underscore.com on 04/06/98 03:10:32 PM > Please respond to jkm@underscore.com > To: Carl Kugler/Boulder/IBM@ibmus > cc: Ipp@pwg.org > Subject: Re: IPP> TES Binary traces of Protocol Examples from PRO app > > It would be nice if the *complete* URL was listed in your mail > message. ;-) > > Same advice goes to all the other folks who post announcement > messages for uploaded files. Thanks in advance. > > ...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 Kugler wrote: > > > > I have created application-level binary trace files of all the Protocol > > Examples from Appendix A of PRO, and uploaded them to > > ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Traces/ > > > > This table shows the mapping from file name to document section and title: > > > > File 9. Appendix A: Protocol Examples > > ----------------------------------------------- > > 00912A01 9.1 Print-Job Request > > 00912B01 9.2 Print-Job Response (successful) > > 00912B02 9.3 Print-Job Response (failure) > > 00943A01 9.4 Print-URI Request > > 00955A01 9.5 Create-Job Request > > 0096AA01 9.6 Get-Jobs Request > > 0096AB01 9.7 Get-Jobs Response > > > > Carl Kugler > > IBM From ipp-owner@pwg.org Mon Apr 6 19:27:24 1998 Delivery-Date: Mon, 06 Apr 1998 19:27:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08070 for ; Mon, 6 Apr 1998 19:27:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01824 for ; Mon, 6 Apr 1998 19:29:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02308 for ; Mon, 6 Apr 1998 19:27:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 19:18:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01178 for ipp-outgoing; Mon, 6 Apr 1998 19:18:22 -0400 (EDT) From: Harry Lewis To: , Subject: Re: IPP> TES Print test across the Internet Message-ID: <5030300019746230000002L002*@MHS> Date: Mon, 6 Apr 1998 19:25:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA08070 I'd like to introduce the topic of a "WEB WEEK" for discussion at the TES meeting in Portland. We're starting to see *some* interop test activity, but it's sporadic. One of the nice things about a "Bakeoff" is it forces us to prepare and focus on the testing. For IPP, it's nice that we don't have to lug equipment and deal with the problems that can occur in these remote situations. If we could agree on a specific set of activity at a specific time, however, it would give us a goal to achieve with respect to proving interoperability. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Apr 6 19:28:00 1998 Delivery-Date: Mon, 06 Apr 1998 19:28:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08091 for ; Mon, 6 Apr 1998 19:27:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01828 for ; Mon, 6 Apr 1998 19:30:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02383 for ; Mon, 6 Apr 1998 19:27:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 19:18:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01179 for ipp-outgoing; Mon, 6 Apr 1998 19:18:22 -0400 (EDT) Message-Id: <199804062315.QAA24666@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Apr 1998 16:17:46 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Cc: In-Reply-To: <5030100019289150000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA08091 Attributes-charset and attributes-natural-language must be in the operation attributes group for each request and each response. This implies that the Printer must support these job description attributes in order to show what values were sent with submit-job operations. Thus they are MANDATORY. The job attributes group contains values of job attributes. For the Print-Job, Print-URI, Create-Job, Send-Document, Send-URI operations, there is no need for the job attributes group to contain the attributes-charset and attributes-natural-language of the job because they normally have the same value the ones in the operation attributes group, and those are the important values for the response anyway. It was a judgement call as to which attributes to return automatically. We picked likely useful ones. For Get-Job-Attributes and Get-Jobs, attributes-charset and attributes-natural-language would be present in the job attributes group only if the client had named them explicitly or implicitly in the "requested-attributes" attribute in the request. Their values might differ from those in the operation attributes group, especially if the job belonged to someone else. Bob Herriot At 02:28 PM 4/6/98 , Carl Kugler wrote: >Thanks, Bob, I think I get it now. > >Maybe your answer also provides a clue to my next question: > >If attributes-charset and attributes-natural-language Job Description >Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >MANDATORY in "Group 3: Job Object Attributes"  under > > Print-Job Response: > Print-URI Response: > Create-Job Response: > Send-Document Response: > Send-URI Response: > Get-Job-Attributes Response: > Get-Jobs Response: > >in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >Operation attributes"? > >Could it be that the word MANDATORY has different meanings in these two >sections? > > 4.3:  MANDATORY ... attribute[s] MUST be supported by Printer objects. >If it is not indicated as MANDATORY, then it is OPTIONAL > > 15.3.4.3:  MANDATORY attributes [are those] that an IPP object MUST >support and that a client MUST supply > >It's still not clear to me. > > -Carl > > > >robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM >Please respond to robert.herriot@Eng.Sun.COM >To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus >cc: >Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica > > >If I understand your question correctly, I think that you have having the same >confusion >that many other people have had about the word "MANDATORY".  It means that >the "Printer" must support the attribute. It does NOT mean that the attribute >must >be included in each request/response. > >In this particular case, attributes-charset is MANDATORY, i.e. the printer >must > >support the attribute, but in the get-jobs reponse it MUST be in the operation >attributes >group and it is only in each job attribute group if the client requested the >attribute via the >requested-attributes attribute in the request. Note, even if it is present >in a >job attributes >group it does not affect the charset of those attributes.  All attributes in >the entire >response are in the charset specified by attributes-charset in the operations >attribute >group, which I still believe must be first in that group (a change we need to >make >to the model document). > >Note that in the example attributes-natural-language is in one of the job >attribute >groups in order to override the natural-language in the operation attributes. >As I >have been implementing IPP, I have come to believe that this was a bad idea. >It again >requires a special ordering, i.e. attributes-natural-language must precede all >other >attributes if processing is to be simple. > >Bob Herriot > > >At 03:34 PM 4/3/98 , Carl Kugler wrote: >>Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >>attribute in any of the three job attributes groups.* But section 4.3 of the >>Model document, "Job Description Attributes", says that attributes-charset is >>MANDATORY in the "job-description" attribute group.* This is causing me >>cognitive dissonance. >> > From ipp-owner@pwg.org Mon Apr 6 19:33:00 1998 Delivery-Date: Mon, 06 Apr 1998 19:33:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08157 for ; Mon, 6 Apr 1998 19:33:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01850 for ; Mon, 6 Apr 1998 19:35:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02981 for ; Mon, 6 Apr 1998 19:32:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 19:27:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA02240 for ipp-outgoing; Mon, 6 Apr 1998 19:26:37 -0400 (EDT) From: Carl Kugler To: Cc: , Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Message-ID: <5030100019292588000002L082*@MHS> Date: Mon, 6 Apr 1998 19:24:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA08157 Tom Hastings wrote: >At 14:28 04/06/1998 PDT, Carl Kugler wrote: >>Thanks, Bob, I think I get it now. >> >>Maybe your answer also provides a clue to my next question: >> >>If attributes-charset and attributes-natural-language Job Description >>Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >>MANDATORY in "Group 3: Job Object Attributes" under >> >> Print-Job Response: >> Print-URI Response: >> Create-Job Response: >> Send-Document Response: >> Send-URI Response: >> Get-Job-Attributes Response: >> Get-Jobs Response: >> >>in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >>Operation attributes"? > >Because "attributes-charset" and "attributes-natural-language" MUST >be returned in Group 1 (not Group 3) as shown. > >See sections 3.1.4.2 Response Operation Attributes and >Sections 3.2 Printer Operations under each Xxx Response Group 1. > >As Bob explained, MANDATORY in the document mostly means that a >Server MUST support the attribute. It is a separate question as to whether >the client MUST supply a MANDATORY attribute and whether an IPP object >MUST return a MANDATORY attribute. In some cases, the client MUST >supply a MANDATORY attribute and in other cases the client NEED NOT >supply the MANDATORY attribute in a request. Similarly, in some cases, >an IPP object MUST supply a MANDATORY attribute and in other cases the IPP >object NEED NOT supply the MANDATORY attribute in a response. > >We tried to avoid using the word MANDATORY and OPTIONAL to mean whether >a sender had to supply in a request or a response. We tried to only >use the words MANDATORY and OPTIONAL to mean whether an IPP object >had to implement or not. > >So there are four combinations for attributes in requests, of which only >three are possible: > > MANDATORY OPTIONAL for an IPP object to support > >MUST supply we have we don't have > >MAY omit we have we have > So, attributes-charset and attributes-natural-language are MANDATORY Job Description Attributes (4.3.23 and 4.3.24) only in the sense that a Printer must support them. I.e., it must be able return them if a client requests them specifically? > >Keep those questions coming. We can always improve the spec and fix >bugs that you find. > >> >>Could it be that the word MANDATORY has different meanings in these two >>sections? > >See above. > >> >> 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. >>If it is not indicated as MANDATORY, then it is OPTIONAL >> >> 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST >>support and that a client MUST supply > >I think I see the confusion. The entire section in 15.3.4.3 is: > >The following tables list all the attributes for all the operations by >attribute group in each request and each response. The left to right order >of the groups is the order that the client supplies the groups as specified >in Section 3.3. The order of the attributes within a group is arbitrary, >though the tables below lists the attributes in the following order with >the following notation: > >(M) MANDATORY attributes that an IPP object MUST support and that a client >MUST supply > >(M*) MANDATORY attributes that an IPP object MUST support, but that a >client may omit in a request or an IPP object may omit in a response > >(O) OPTIONAL attributes that an IPP object NEED NOT support > >(O*) OPTIONAL attributes that an IPP object NEED NOT support and a client >may omit in a request or an IPP object may omit in a response > >The first line is NOT the definition of MANDATORY, but is explaining >the notation (M) which means MANDATORY and that a client MUST supply. But the context here is a Response, which surely is supplied by a Printer, never a client? Why aren't the attributes-charset and attributes-natural-language (M*) for "Group 3: Job Object Attributes"? > >The notation (M*) in the second line is also MANDATORY, but a client MAY >omit. The presence or absence of the "*" indicates whether the MANDATORY >attribte (for support) MAY be omitted or not in a request or response. > >Would the following rewording help: > >In parenthesis the following notation is used: > >M indicates a MANDATORY attirbute that an IPP object MUST support >O indicated an OPTIONAL attirbute that an IPP object NEED NOT support >* indicates that a client MAY omit the attribute in a request and that > an IPP object MAY omit the attribute in a response. The absence of > an * means that a client MUST supply the attribute in a request and > and an IPP object MUST supply the attribute in a response. > >Perhaps there is a better notation than *? Perhaps surrounding the >attribute name itself inside [] would be a more familiar notation to >indicate what can be omitted in a request or a response? > >> >>It's still not clear to me. >> >> -Carl >> >> >> >>robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM >>Please respond to robert.herriot@Eng.Sun.COM >>To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus >>cc: >>Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica >> >> >>If I understand your question correctly, I think that you have having the >same >>confusion >>that many other people have had about the word "MANDATORY". It means that >>the "Printer" must support the attribute. It does NOT mean that the attribute >>must >>be included in each request/response. >> >>In this particular case, attributes-charset is MANDATORY, i.e. the printer >>must >> >>support the attribute, but in the get-jobs reponse it MUST be in the >operation >>attributes >>group and it is only in each job attribute group if the client requested the >>attribute via the >>requested-attributes attribute in the request. Note, even if it is present >>in a >>job attributes >>group it does not affect the charset of those attributes. All attributes in >>the entire >>response are in the charset specified by attributes-charset in the operations >>attribute >>group, which I still believe must be first in that group (a change we need to >>make >>to the model document). >> >>Note that in the example attributes-natural-language is in one of the job >>attribute >>groups in order to override the natural-language in the operation attributes. >>As I >>have been implementing IPP, I have come to believe that this was a bad idea. >>It again >>requires a special ordering, i.e. attributes-natural-language must precede >all >>other >>attributes if processing is to be simple. >> >>Bob Herriot >> >> >>At 03:34 PM 4/3/98 , Carl Kugler wrote: >>>Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >>>attribute in any of the three job attributes groups.* But section 4.3 of the >>>Model document, "Job Description Attributes", says that >attributes-charset is >>>MANDATORY in the "job-description" attribute group.* This is causing me >>>cognitive dissonance. >>> >> >> From jmp-owner@pwg.org Mon Apr 6 20:27:03 1998 Delivery-Date: Mon, 06 Apr 1998 20:27:04 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA08804 for ; Mon, 6 Apr 1998 20:27:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01983 for ; Mon, 6 Apr 1998 20:29:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04065 for ; Mon, 6 Apr 1998 20:26:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 20:23:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03400 for jmp-outgoing; Mon, 6 Apr 1998 20:19:13 -0400 (EDT) Message-Id: <3.0.1.32.19980406171728.00c67580@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 17:17:28 PDT To: pmp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: JMP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: jmp-owner@pwg.org Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB=20 for the media names that can be used, such as 'iso-a4-white', and=20 'na-letter-white'.=20 Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names:=20 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from=20 Appendix B can be used in addition to media names from Appendix C in the=20 Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence=20 between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::=3D { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type=20 AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the=20 job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets=20 AND=20 OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. =20 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From pmp-owner@pwg.org Mon Apr 6 20:28:20 1998 Delivery-Date: Mon, 06 Apr 1998 20:28:21 -0400 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA08812 for ; Mon, 6 Apr 1998 20:28:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01988 for ; Mon, 6 Apr 1998 20:30:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04188 for ; Mon, 6 Apr 1998 20:27:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 20:24:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03408 for pmp-outgoing; Mon, 6 Apr 1998 20:19:19 -0400 (EDT) Message-Id: <3.0.1.32.19980406171728.00c67580@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 17:17:28 PDT To: pmp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: PMP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pmp-owner@pwg.org Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB=20 for the media names that can be used, such as 'iso-a4-white', and=20 'na-letter-white'.=20 Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names:=20 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from=20 Appendix B can be used in addition to media names from Appendix C in the=20 Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence=20 between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::=3D { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type=20 AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the=20 job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets=20 AND=20 OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. =20 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From ipp-owner@pwg.org Mon Apr 6 20:29:56 1998 Delivery-Date: Mon, 06 Apr 1998 20:29:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA08833 for ; Mon, 6 Apr 1998 20:29:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA01998 for ; Mon, 6 Apr 1998 20:32:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04364 for ; Mon, 6 Apr 1998 20:29:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 20:20:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA03416 for ipp-outgoing; Mon, 6 Apr 1998 20:19:30 -0400 (EDT) Message-Id: <3.0.1.32.19980406171728.00c67580@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 17:17:28 PDT To: pmp@pwg.org, jmp@pwg.org From: Tom Hastings Subject: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB=20 for the media names that can be used, such as 'iso-a4-white', and=20 'na-letter-white'.=20 Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names:=20 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from=20 Appendix B can be used in addition to media names from Appendix C in the=20 Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence=20 between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::=3D { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type=20 AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the=20 job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets=20 AND=20 OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. =20 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From ipp-owner@pwg.org Mon Apr 6 20:51:30 1998 Delivery-Date: Mon, 06 Apr 1998 20:51:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09027 for ; Mon, 6 Apr 1998 20:51:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA02050 for ; Mon, 6 Apr 1998 20:53:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05034 for ; Mon, 6 Apr 1998 20:51:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Apr 1998 20:46:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04476 for ipp-outgoing; Mon, 6 Apr 1998 20:46:25 -0400 (EDT) Message-Id: <3.0.1.32.19980406174443.00bbae40@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 17:44:43 PDT To: Carl Kugler From: Tom Hastings Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Cc: , In-Reply-To: <5030100019292588000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Responses buried in this thread. Tom At 16:24 04/06/1998 PDT, Carl Kugler wrote: >Tom Hastings wrote: >>At 14:28 04/06/1998 PDT, Carl Kugler wrote: >>>Thanks, Bob, I think I get it now. >>> >>>Maybe your answer also provides a clue to my next question: >>> >>>If attributes-charset and attributes-natural-language Job Description >>>Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >>>MANDATORY in "Group 3: Job Object Attributes" under >>> >>> Print-Job Response: >>> Print-URI Response: >>> Create-Job Response: >>> Send-Document Response: >>> Send-URI Response: >>> Get-Job-Attributes Response: >>> Get-Jobs Response: >>> >>>in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >>>Operation attributes"? >> >>Because "attributes-charset" and "attributes-natural-language" MUST >>be returned in Group 1 (not Group 3) as shown. >> >>See sections 3.1.4.2 Response Operation Attributes and >>Sections 3.2 Printer Operations under each Xxx Response Group 1. >> >>As Bob explained, MANDATORY in the document mostly means that a >>Server MUST support the attribute. It is a separate question as to whether >>the client MUST supply a MANDATORY attribute and whether an IPP object >>MUST return a MANDATORY attribute. In some cases, the client MUST >>supply a MANDATORY attribute and in other cases the client NEED NOT >>supply the MANDATORY attribute in a request. Similarly, in some cases, >>an IPP object MUST supply a MANDATORY attribute and in other cases the IPP >>object NEED NOT supply the MANDATORY attribute in a response. >> >>We tried to avoid using the word MANDATORY and OPTIONAL to mean whether >>a sender had to supply in a request or a response. We tried to only >>use the words MANDATORY and OPTIONAL to mean whether an IPP object >>had to implement or not. >> >>So there are four combinations for attributes in requests, of which only >>three are possible: >> >> MANDATORY OPTIONAL for an IPP object to support >> >>MUST supply we have we don't have >> >>MAY omit we have we have >> > >So, attributes-charset and attributes-natural-language are MANDATORY Job >Description Attributes (4.3.23 and 4.3.24) only in the sense that a Printer >must support them. I.e., it must be able return them if a client requests >them specifically? More than that. An IPP object must accept attributes-charset and attributes-natural-language as operation attributes and take action as specified by the semantics of those operation attributes. > >> >>Keep those questions coming. We can always improve the spec and fix >>bugs that you find. >> >>> >>>Could it be that the word MANDATORY has different meanings in these two >>>sections? >> >>See above. >> >>> >>> 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. >>>If it is not indicated as MANDATORY, then it is OPTIONAL >>> >>> 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST >>>support and that a client MUST supply >> >>I think I see the confusion. The entire section in 15.3.4.3 is: >> >>The following tables list all the attributes for all the operations by >>attribute group in each request and each response. The left to right order >>of the groups is the order that the client supplies the groups as specified >>in Section 3.3. The order of the attributes within a group is arbitrary, >>though the tables below lists the attributes in the following order with >>the following notation: >> >>(M) MANDATORY attributes that an IPP object MUST support and that a >client >>MUST supply >> >>(M*) MANDATORY attributes that an IPP object MUST support, but that a >>client may omit in a request or an IPP object may omit in a response >> >>(O) OPTIONAL attributes that an IPP object NEED NOT support >> >>(O*) OPTIONAL attributes that an IPP object NEED NOT support and a >client >>may omit in a request or an IPP object may omit in a response >> >>The first line is NOT the definition of MANDATORY, but is explaining >>the notation (M) which means MANDATORY and that a client MUST supply. > >But the context here is a Response, which surely is supplied by a >Printer, never a client? I think it would help to write the above separately for requests and responses which are separate parts of section 15.3.4.3. > >Why aren't the attributes-charset and attributes-natural-language (M*) for >"Group 3: Job Object Attributes"? Because they are Group 1 operation attributes in all requests and all responses. They just happen to also be copied to the Job object on create requests. So a client could request "attributes-charset" and "attributes-natural-language" job attributes in a Get-Jobs or Get-Job-Attributes operation and get back the values (in Group 3) that had been copied to the job object in the create request. But the "attributes-charset" and "attributes-natural-language" that always come back in Group 1 in the response to such a request don't have anything to do with the values that come back in Group 3 in such a response. The Group 1 reponse MUST be the same as the requester supplied in the Get-Jobs Group 1 request, which is independent of what was supplied (often by some other client) on the create request that created the Job object in the first place. > >> >>The notation (M*) in the second line is also MANDATORY, but a client MAY >>omit. The presence or absence of the "*" indicates whether the MANDATORY >>attribte (for support) MAY be omitted or not in a request or response. >> >>Would the following rewording help: >> >>In parenthesis the following notation is used: >> >>M indicates a MANDATORY attirbute that an IPP object MUST support >>O indicated an OPTIONAL attirbute that an IPP object NEED NOT support >>* indicates that a client MAY omit the attribute in a request and that >> an IPP object MAY omit the attribute in a response. The absence of >> an * means that a client MUST supply the attribute in a request and >> and an IPP object MUST supply the attribute in a response. >> >>Perhaps there is a better notation than *? Perhaps surrounding the >>attribute name itself inside [] would be a more familiar notation to >>indicate what can be omitted in a request or a response? >> >>> >>>It's still not clear to me. >>> >>> -Carl >>> >>> >>> >>>robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM >>>Please respond to robert.herriot@Eng.Sun.COM >>>To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus >>>cc: >>>Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica >>> >>> >>>If I understand your question correctly, I think that you have having the >>same >>>confusion >>>that many other people have had about the word "MANDATORY". It means that >>>the "Printer" must support the attribute. It does NOT mean that the attribute >>>must >>>be included in each request/response. >>> >>>In this particular case, attributes-charset is MANDATORY, i.e. the printer >>>must >>> >>>support the attribute, but in the get-jobs reponse it MUST be in the >>operation >>>attributes >>>group and it is only in each job attribute group if the client requested the >>>attribute via the >>>requested-attributes attribute in the request. Note, even if it is present >>>in a >>>job attributes >>>group it does not affect the charset of those attributes. All attributes in >>>the entire >>>response are in the charset specified by attributes-charset in the operations >>>attribute >>>group, which I still believe must be first in that group (a change we need to >>>make >>>to the model document). >>> >>>Note that in the example attributes-natural-language is in one of the job >>>attribute >>>groups in order to override the natural-language in the operation attributes. >>>As I >>>have been implementing IPP, I have come to believe that this was a bad idea. >>>It again >>>requires a special ordering, i.e. attributes-natural-language must precede >>all >>>other >>>attributes if processing is to be simple. >>> >>>Bob Herriot >>> >>> >>>At 03:34 PM 4/3/98 , Carl Kugler wrote: >>>>Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >>>>attribute in any of the three job attributes groups.* But section 4.3 of the >>>>Model document, "Job Description Attributes", says that >>attributes-charset is >>>>MANDATORY in the "job-description" attribute group.* This is causing me >>>>cognitive dissonance. >>>> >>> >>> > > From ipp-owner@pwg.org Tue Apr 7 01:06:44 1998 Delivery-Date: Tue, 07 Apr 1998 01:06:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA17180 for ; Tue, 7 Apr 1998 01:06:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA02428 for ; Tue, 7 Apr 1998 01:09:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA06173 for ; Tue, 7 Apr 1998 01:06:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 01:01:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA05462 for ipp-outgoing; Tue, 7 Apr 1998 01:01:25 -0400 (EDT) Message-Id: <3.0.1.32.19980406215945.00fbf590@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Apr 1998 21:59:45 PDT To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> PRO: Protocol Examples In-Reply-To: <5030100019283275000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org I would say yes. The Protocol document should be fixed so that all keyword values are all lower case. I checked with the charset registry and the preferred MIME name is "US-ASCII". Fortunrately, it also say up front: The character set names may be up to 40 characters taken from the printable characters of US-ASCII. However, no distinction is made between use of upper and lower case letters. so IPP is ok in forcing the client to make these keywords be all lower case for simplicity in the server. Presumably, the server should reject a client that passes in keywords with uppercase in them, using the error code: 'client-error-bad-request' Or are we expecting servers to convert keywords to lower case before processing them? This could be an interoperability problem if we don't all agree. Tom At 11:46 04/06/1998 PDT, Carl Kugler wrote: >According to MOD, "IPP requires all lower case" for 'charset' and >'naturalLanguage' (refer to sections 4.1.9 and 4.1.10). However, the Protocol >Examples in Appendix A of MOD show mixed-case values, e.g.: "en-US" and " >US-ASCII", for attributes of type 'charset' and 'naturalLanguage' such as >attributes-charset and attributes-natural-language. Is this apparent conflict >an error? > > -Carl Kugler > > From jmp-owner@pwg.org Tue Apr 7 01:21:28 1998 Delivery-Date: Tue, 07 Apr 1998 01:21:29 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA20000 for ; Tue, 7 Apr 1998 01:21:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA02451 for ; Tue, 7 Apr 1998 01:23:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA07460 for ; Tue, 7 Apr 1998 01:21:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 01:16:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA06424 for jmp-outgoing; Tue, 7 Apr 1998 01:11:55 -0400 (EDT) From: "Larry Masinter" To: "Tom Hastings" , , Cc: Subject: JMP> RE: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Date: Mon, 6 Apr 1998 22:11:36 PDT Message-ID: <001201bd61e3$a36026e0$e3d3000d@bronze-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-to: <3.0.1.32.19980406171728.00c67580@garfield> Sender: jmp-owner@pwg.org For what it is worth, the document draft-ietf-connect-media-features-00.txt attempts to use the 'printer mib' for the proper enumeration of paper sizes. If you think it's better to set paper size in terms of actual sizes rather than an enumeration, we should track it in media features. Larry -- http://www.parc.xerox.com/masinter -----Original Message----- From: ipp-owner@pwg.org [mailto:ipp-owner@pwg.org]On Behalf Of Tom Hastings Sent: Monday, April 06, 1998 5:17 PM To: pmp@pwg.org; jmp@pwg.org Cc: ipp@pwg.org Subject: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB for the media names that can be used, such as 'iso-a4-white', and 'na-letter-white'. Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names: 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from Appendix B can be used in addition to media names from Appendix C in the Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::= { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From pmp-owner@pwg.org Tue Apr 7 01:22:45 1998 Delivery-Date: Tue, 07 Apr 1998 01:22:45 -0400 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA20209 for ; Tue, 7 Apr 1998 01:22:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA02454 for ; Tue, 7 Apr 1998 01:25:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA07678 for ; Tue, 7 Apr 1998 01:22:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 01:18:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA06457 for pmp-outgoing; Tue, 7 Apr 1998 01:12:18 -0400 (EDT) From: "Larry Masinter" To: "Tom Hastings" , , Cc: Subject: PMP> RE: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Date: Mon, 6 Apr 1998 22:11:36 PDT Message-ID: <001201bd61e3$a36026e0$e3d3000d@bronze-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-to: <3.0.1.32.19980406171728.00c67580@garfield> Sender: pmp-owner@pwg.org For what it is worth, the document draft-ietf-connect-media-features-00.txt attempts to use the 'printer mib' for the proper enumeration of paper sizes. If you think it's better to set paper size in terms of actual sizes rather than an enumeration, we should track it in media features. Larry -- http://www.parc.xerox.com/masinter -----Original Message----- From: ipp-owner@pwg.org [mailto:ipp-owner@pwg.org]On Behalf Of Tom Hastings Sent: Monday, April 06, 1998 5:17 PM To: pmp@pwg.org; jmp@pwg.org Cc: ipp@pwg.org Subject: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB for the media names that can be used, such as 'iso-a4-white', and 'na-letter-white'. Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names: 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from Appendix B can be used in addition to media names from Appendix C in the Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::= { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From ipp-owner@pwg.org Tue Apr 7 01:24:03 1998 Delivery-Date: Tue, 07 Apr 1998 01:24:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA20421 for ; Tue, 7 Apr 1998 01:24:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA02457 for ; Tue, 7 Apr 1998 01:26:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA07867 for ; Tue, 7 Apr 1998 01:23:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 01:12:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA06440 for ipp-outgoing; Tue, 7 Apr 1998 01:12:04 -0400 (EDT) From: "Larry Masinter" To: "Tom Hastings" , , Cc: Subject: RE: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Date: Mon, 6 Apr 1998 22:11:36 PDT Message-ID: <001201bd61e3$a36026e0$e3d3000d@bronze-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-to: <3.0.1.32.19980406171728.00c67580@garfield> Sender: ipp-owner@pwg.org For what it is worth, the document draft-ietf-connect-media-features-00.txt attempts to use the 'printer mib' for the proper enumeration of paper sizes. If you think it's better to set paper size in terms of actual sizes rather than an enumeration, we should track it in media features. Larry -- http://www.parc.xerox.com/masinter -----Original Message----- From: ipp-owner@pwg.org [mailto:ipp-owner@pwg.org]On Behalf Of Tom Hastings Sent: Monday, April 06, 1998 5:17 PM To: pmp@pwg.org; jmp@pwg.org Cc: ipp@pwg.org Subject: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB for the media names that can be used, such as 'iso-a4-white', and 'na-letter-white'. Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names: 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from Appendix B can be used in addition to media names from Appendix C in the Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::= { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From ipp-owner@pwg.org Tue Apr 7 02:38:40 1998 Delivery-Date: Tue, 07 Apr 1998 02:38:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA23007 for ; Tue, 7 Apr 1998 02:38:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA02547 for ; Tue, 7 Apr 1998 02:41:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA11064 for ; Tue, 7 Apr 1998 02:38:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 02:33:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10372 for ipp-outgoing; Tue, 7 Apr 1998 02:33:19 -0400 (EDT) From: don@lexmark.com Message-Id: <199804070633.AA26093@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.com Cc: Ipp@pwg.org Date: Tue, 7 Apr 1998 02:21:28 -0400 Subject: RE: IPP> MOD/ADM - Trouble with references Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=T6PVYtaONtzMZVRNqShCzgwKvi17iJT7YsiLthwgnTFqLdSZdOP8pBRq" Sender: ipp-owner@pwg.org --0__=T6PVYtaONtzMZVRNqShCzgwKvi17iJT7YsiLthwgnTFqLdSZdOP8pBRq Content-type: text/plain; charset=us-ascii Oh for the beauty of TIPSI which doesn't encode long, ASCII, language specific, character set specific, (case sensitive? - oh, that's another thread) names on the wire. Just a few bits here and there editorially defined. The TIPSI bigot... ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: paulmo%microsoft.com@interlock.lexmark.com, cmanros%cp10.es.xerox.com@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: RE: IPP> MOD/ADM - Trouble with references --0__=T6PVYtaONtzMZVRNqShCzgwKvi17iJT7YsiLthwgnTFqLdSZdOP8pBRq-- From ipp-owner@pwg.org Tue Apr 7 03:23:07 1998 Delivery-Date: Tue, 07 Apr 1998 03:23:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id DAA23506 for ; Tue, 7 Apr 1998 03:23:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA02607 for ; Tue, 7 Apr 1998 03:25:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA14000 for ; Tue, 7 Apr 1998 03:23:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 03:17:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA13158 for ipp-outgoing; Tue, 7 Apr 1998 03:17:07 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Date: Tue, 7 Apr 1998 00:16:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Perhaps Bob's clarification text should actually be put into the std document, that is, since it apparently was not clear to Carl. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Monday, April 06, 1998 2:28 PM To: robert.herriot@Eng.Sun.COM Cc: ipp@pwg.org Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Thanks, Bob, I think I get it now. Maybe your answer also provides a clue to my next question: If attributes-charset and attributes-natural-language Job Description Attributes are MANDATORY according to MOD/4.3, why aren't they shown as MANDATORY in "Group 3: Job Object Attributes" under Print-Job Response: Print-URI Response: Create-Job Response: Send-Document Response: Send-URI Response: Get-Job-Attributes Response: Get-Jobs Response: in MOD/15.3.4.3 "Validate the presence of a single occurrence of required Operation attributes"? Could it be that the word MANDATORY has different meanings in these two sections? 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. If it is not indicated as MANDATORY, then it is OPTIONAL 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST support and that a client MUST supply It's still not clear to me. -Carl robert.herriot@Eng.Sun.COM on 04/06/98 01:48:31 PM Please respond to robert.herriot@Eng.Sun.COM To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica If I understand your question correctly, I think that you have having the same confusion that many other people have had about the word "MANDATORY". It means that the "Printer" must support the attribute. It does NOT mean that the attribute must be included in each request/response. In this particular case, attributes-charset is MANDATORY, i.e. the printer must support the attribute, but in the get-jobs reponse it MUST be in the operation attributes group and it is only in each job attribute group if the client requested the attribute via the requested-attributes attribute in the request. Note, even if it is present in a job attributes group it does not affect the charset of those attributes. All attributes in the entire response are in the charset specified by attributes-charset in the operations attribute group, which I still believe must be first in that group (a change we need to make to the model document). Note that in the example attributes-natural-language is in one of the job attribute groups in order to override the natural-language in the operation attributes. As I have been implementing IPP, I have come to believe that this was a bad idea. It again requires a special ordering, i.e. attributes-natural-language must precede all other attributes if processing is to be simple. Bob Herriot At 03:34 PM 4/3/98 , Carl Kugler wrote: >Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset >attribute in any of the three job attributes groups.* But section 4.3 of the >Model document, "Job Description Attributes", says that attributes-charset is >MANDATORY in the "job-description" attribute group.* This is causing me >cognitive dissonance. > From ipp-owner@pwg.org Tue Apr 7 15:36:41 1998 Delivery-Date: Tue, 07 Apr 1998 15:36:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09603 for ; Tue, 7 Apr 1998 15:36:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04918 for ; Tue, 7 Apr 1998 15:39:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA20288 for ; Tue, 7 Apr 1998 15:36:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 15:28:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19722 for ipp-outgoing; Tue, 7 Apr 1998 15:27:56 -0400 (EDT) From: Carl Kugler To: Cc: , Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Message-ID: <5030100019318974000002L042*@MHS> Date: Tue, 7 Apr 1998 15:25:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA09603 Tom Hastings wrote: >At 16:24 04/06/1998 PDT, Carl Kugler wrote: >>Tom Hastings wrote: >>>At 14:28 04/06/1998 PDT, Carl Kugler wrote: >>>>Thanks, Bob, I think I get it now. >>>> >>>>Maybe your answer also provides a clue to my next question: >>>> >>>>If attributes-charset and attributes-natural-language Job Description >>>>Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >>>>MANDATORY in "Group 3: Job Object Attributes" under >>>> >>>> Print-Job Response: >>>> Print-URI Response: >>>> Create-Job Response: >>>> Send-Document Response: >>>> Send-URI Response: >>>> Get-Job-Attributes Response: >>>> Get-Jobs Response: >>>> >>>>in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >>>>Operation attributes"? >>> >>>Because "attributes-charset" and "attributes-natural-language" MUST >>>be returned in Group 1 (not Group 3) as shown. >>> >>>See sections 3.1.4.2 Response Operation Attributes and >>>Sections 3.2 Printer Operations under each Xxx Response Group 1. >>> >>>As Bob explained, MANDATORY in the document mostly means that a >>>Server MUST support the attribute. It is a separate question as to whether >>>the client MUST supply a MANDATORY attribute and whether an IPP object >>>MUST return a MANDATORY attribute. In some cases, the client MUST >>>supply a MANDATORY attribute and in other cases the client NEED NOT >>>supply the MANDATORY attribute in a request. Similarly, in some cases, >>>an IPP object MUST supply a MANDATORY attribute and in other cases the IPP >>>object NEED NOT supply the MANDATORY attribute in a response. >>> >>>We tried to avoid using the word MANDATORY and OPTIONAL to mean whether >>>a sender had to supply in a request or a response. We tried to only >>>use the words MANDATORY and OPTIONAL to mean whether an IPP object >>>had to implement or not. >>> >>>So there are four combinations for attributes in requests, of which only >>>three are possible: >>> >>> MANDATORY OPTIONAL for an IPP object to support >>> >>>MUST supply we have we don't have >>> >>>MAY omit we have we have >>> >> >>So, attributes-charset and attributes-natural-language are MANDATORY Job >>Description Attributes (4.3.23 and 4.3.24) only in the sense that a Printer >>must support them. I.e., it must be able return them if a client requests >>them specifically? > >More than that. An IPP object must accept attributes-charset and >attributes-natural-language as operation attributes and take action as >specified >by the semantics of those operation attributes. But my question is specific to Job Description Attributes. Aren't those distinct from Operation attributes? > >> >>> >>>Keep those questions coming. We can always improve the spec and fix >>>bugs that you find. >>> >>>> >>>>Could it be that the word MANDATORY has different meanings in these two >>>>sections? >>> >>>See above. >>> >>>> >>>> 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects. >>>>If it is not indicated as MANDATORY, then it is OPTIONAL >>>> >>>> 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST >>>>support and that a client MUST supply >>> >>>I think I see the confusion. The entire section in 15.3.4.3 is: >>> >>>The following tables list all the attributes for all the operations by >>>attribute group in each request and each response. The left to right order >>>of the groups is the order that the client supplies the groups as specified >>>in Section 3.3. The order of the attributes within a group is arbitrary, >>>though the tables below lists the attributes in the following order with >>>the following notation: >>> >>>(M) MANDATORY attributes that an IPP object MUST support and that a >>client >>>MUST supply >>> >>>(M*) MANDATORY attributes that an IPP object MUST support, but that a >>>client may omit in a request or an IPP object may omit in a response >>> >>>(O) OPTIONAL attributes that an IPP object NEED NOT support >>> >>>(O*) OPTIONAL attributes that an IPP object NEED NOT support and a >>client >>>may omit in a request or an IPP object may omit in a response >>> >>>The first line is NOT the definition of MANDATORY, but is explaining >>>the notation (M) which means MANDATORY and that a client MUST supply From ipp-owner@pwg.org Tue Apr 7 15:41:46 1998 Delivery-Date: Tue, 07 Apr 1998 15:41:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09722 for ; Tue, 7 Apr 1998 15:41:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04931 for ; Tue, 7 Apr 1998 15:44:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA20918 for ; Tue, 7 Apr 1998 15:41:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 15:37:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20341 for ipp-outgoing; Tue, 7 Apr 1998 15:37:15 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Message-ID: <5030100019319493000002L032*@MHS> Date: Tue, 7 Apr 1998 15:36:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA09722 Bob- Looking back over your earlier reply, I'm still having trouble reconciling these sentences: > Note, even if it [attributes-charset] is present in a job attributes group it does not affect the charset of those attributes. All attributes in the entire response are in the charset specified by attributes-charset in the operations attribute group... >Note that in the example attributes-natural-language is in one of the job attribute groups in order to override the natural-language in the operation attributes. The attributes-charset in the operations attribute group cannot be overridden but the attributes-natural-language can? -Carl robert.herriot@Eng.Sun.COM on 04/06/98 05:18:21 PM Please respond to robert.herriot@Eng.Sun.COM To: robert.herriot@Eng.Sun.COM, Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Attributes-charset and attributes-natural-language must be in the operation attributes group for each request and each response. This implies that the Printer must support these job description attributes in order to show what values were sent with submit-job operations. Thus they are MANDATORY. The job attributes group contains values of job attributes. For the Print-Job, Print-URI, Create-Job, Send-Document, Send-URI operations, there is no need for the job attributes group to contain the attributes-charset and attributes-natural-language of the job because they normally have the same value the ones in the operation attributes group, and those are the important values for the response anyway. It was a judgement call as to which attributes to return automatically. We picked likely useful ones. For Get-Job-Attributes and Get-Jobs, attributes-charset and attributes-natural-language would be present in the job attributes group only if the client had named them explicitly or implicitly in the "requested-attributes" attribute in the request. Their values might differ from those in the operation attributes group, especially if the job belonged to someone else. Bob Herriot At 02:28 PM 4/6/98 , Carl Kugler wrote: >Thanks, Bob, I think I get it now. > >Maybe your answer also provides a clue to my next question: > >If attributes-charset and attributes-natural-language Job Description >Attributes are MANDATORY according to MOD/4.3, why aren't they shown as >MANDATORY in "Group 3: Job Object Attributes"* under > > Print-Job Response: > Print-URI Response: > Create-Job Response: > Send-Document Response: > Send-URI Response: > Get-Job-Attributes Response: > Get-Jobs Response: > >in MOD/15.3.4.3 "Validate the presence of a single occurrence of required >Operation attributes"? > >Could it be that the word MANDATORY has different meanings in these two >sections? > > 4.3:* MANDATORY ... attribute[s] MUST be supported by Printer objects From ipp-owner@pwg.org Tue Apr 7 15:54:30 1998 Delivery-Date: Tue, 07 Apr 1998 15:54:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA10087 for ; Tue, 7 Apr 1998 15:54:29 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04968 for ; Tue, 7 Apr 1998 15:56:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA21550 for ; Tue, 7 Apr 1998 15:54:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 15:50:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21007 for ipp-outgoing; Tue, 7 Apr 1998 15:49:58 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 07 Apr 1998 13:49:33 -0600 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> New Printer MIB to IPP mapping document Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA10087 I have posted my action item on showing a mapping of Printer MIB objects and tables to IPP objects and operations. FInd the doc at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-sub-units-980407.pdf I will try to bring paper copies to the meeting. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Tue Apr 7 16:03:51 1998 Delivery-Date: Tue, 07 Apr 1998 16:03:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10337 for ; Tue, 7 Apr 1998 16:03:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05001 for ; Tue, 7 Apr 1998 16:06:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22178 for ; Tue, 7 Apr 1998 16:03:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 15:59:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21630 for ipp-outgoing; Tue, 7 Apr 1998 15:59:23 -0400 (EDT) Message-Id: <199804071953.MAA27091@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 07 Apr 1998 12:55:21 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Cc: , In-Reply-To: <5030100019318974000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA10337 > >But my question is specific to Job Description Attributes.  Aren't those >distinct from Operation attributes? Job Description attributes are one of two categories of Job (Object) Attributes. The other category is job template attributes. Operation attributes (i.e. those attributes in the operation attributes group) are attributes that are passed as part of a request or response. Some of these attributes in a request set the values of job description attributes which have the same name but they never set job template attributes. Attributes in the job attributes group of a request cause job template attributes in the job object to be set, but not job description attributes. Now you're probably wondering why some job attributes are job template attributes and others are job description attributes. Some attributes have gone back and forth between these two categrories several times. The original idea was that job template attributes are those collection of job attributes which a client, even the end user, is allowed to modify. These attributes typically have a list of supported values for the client to choose from and a default value if the client doesn't choose a value. The job description attributes are either set by the printer with no input from the client, e.g. job-id, or they are characteristics of a job that a user has no choice about, e.g. job-k-octets and document-format. These latter attributes have supported values and sometimes a default, but a client doesn't have a choice. The number of octets and the document-format are inherent qualities of the document. > >Section 4.3 says that attributes-charset and attributes-natural-language >Job Description Attributes MUST be supported by printer objects. > >(M*) indicates MANDATORY attributes that an IPP object MUST support, but >that a client may omit in a request or an IPP object may omit in a response. > >Isn't that the case for these particular Job Description Attributes?  Or is >there some subtle difference between the "job-description" attribute group >described in section 4.3 and the "Group 3: Job Object Attributes" described in >15.3.4.3? I hope the above explanation clears up the difference between job object attributes and job description attributes for requests. For reponses, the job attributes group can contain any job attribute, including job description and job template attributes. From ipp-owner@pwg.org Tue Apr 7 17:37:31 1998 Delivery-Date: Tue, 07 Apr 1998 17:37:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA12912 for ; Tue, 7 Apr 1998 17:37:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05397 for ; Tue, 7 Apr 1998 17:40:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22914 for ; Tue, 7 Apr 1998 17:37:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Apr 1998 17:33:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22358 for ipp-outgoing; Tue, 7 Apr 1998 17:32:47 -0400 (EDT) From: Carl Kugler To: Cc: , Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica Message-ID: <5030100019323894000002L042*@MHS> Date: Tue, 7 Apr 1998 17:32:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA12912 Thanks for the lucid explanation of Job Object attributes! I think I've got it now. Let me run this past you to make sure. attributes-charset and attributes-natural-language only appear as Job Object Attributes (or, more specifically, Job Description Attributes) in responses to Get-Job-Attributes or Get-Jobs requests. They MUST be sent if the client requests them in requested-attributes, because they are MANDATORY Job Description Attributes and thus MUST be supported. Furthermore, attributes-natural-language (but not necessarily attributes-charset) MUST be sent in the Job Object attribute group returned for any job that was submitted with a natural language which differs from that specified in the attributes-natural-language Operation Attribute of the response. Right? -Carl ipp-owner@pwg.org on 04/07/98 02:01:15 PM Please respond to ipp-owner@pwg.org To: hastings@cp10.es.xerox.com, Carl Kugler/Boulder/IBM@ibmus cc: robert.herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica > >But my question is specific to Job Description Attributes.* Aren't those >distinct from Operation attributes? Job Description attributes are one of two categories of Job (Object) Attributes. The other category is job template attributes. Operation attributes (i.e. those attributes in the operation attributes group) are attributes that are passed as part of a request or response. Some of these attributes in a request set the values of job description attributes which have the same name but they never set job template attributes. Attributes in the job attributes group of a request cause job template attributes in the job object to be set, but not job description attributes. Now you're probably wondering why some job attributes are job template attributes and others are job description attributes. Some attributes have gone back and forth between these two categrories several times. The original idea was that job template attributes are those collection of job attributes which a client, even the end user, is allowed to modify. These attributes typically have a list of supported values for the client to choose from and a default value if the client doesn't choose a value. The job description attributes are either set by the printer with no input from the client, e.g. job-id, or they are characteristics of a job that a user has no choice about, e.g. job-k-octets and document-format. These latter attributes have supported values and sometimes a default, but a client doesn't have a choice. The number of octets and the document-format are inherent qualities of the document. > >Section 4.3 says that attributes-charset and attributes-natural-language >Job Description Attributes MUST be supported by printer objects. > >(M*) indicates MANDATORY attributes that an IPP object MUST support, but >that a client may omit in a request or an IPP object may omit in a response. > >Isn't that the case for these particular Job Description Attributes?* Or is >there some subtle difference between the "job-description" attribute group >described in section 4.3 and the "Group 3: Job Object Attributes" described in >15.3.4.3? I hope the above explanation clears up the difference between job object attributes and job description attributes for requests. For reponses, the job attributes group can contain any job attribute, including job description and job template attributes. From ipp-owner@pwg.org Fri Apr 10 01:58:46 1998 Delivery-Date: Fri, 10 Apr 1998 01:58:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA10968 for ; Fri, 10 Apr 1998 01:58:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA28625 for ; Fri, 10 Apr 1998 02:01:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA20780 for ; Fri, 10 Apr 1998 01:58:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Apr 1998 01:51:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA20229 for ipp-outgoing; Fri, 10 Apr 1998 01:51:32 -0400 (EDT) Date: Fri, 10 Apr 1998 01:49:10 -0400 (EDT) Message-Id: <199804100549.BAA20152@lists.underscore.com> To: adrory@earthlink.netsubscribe, ipp@lists.underscore.com, adrory@earthlink.net From: majordomo@pwg.org Subject: IPP> Welcome to fin Reply-To: majordomo@pwg.org Sender: ipp-owner@pwg.org -- Welcome to the fin mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "majordomo@pwg.org" with the following command in the body of your email message: unsubscribe fin adrory@earthlink.netsubscribe ipp adrory@earthlink.net Here's the general information for the list you've subscribed to, in case you don't already have it: ============================================================================= fin - Printer Finisher MIB Project (FIN) This the mailing list for the Printer Working Group (PWG) Printer Finisher MIB project. The PWG is an ad-hoc industry standards committee addressing the needs of the network printer community of vendors and and users. The PWG FTP archives are located at FTP://ftp.pwg.org/pub/pwg The PWG Web home page is located at HTTP://www.pwg.org The PWG FTP archives for the current Printer Finisher MIB project are located at FTP://ftp.pwg.org/pub/pwg/fin ============================================================================= From ipp-owner@pwg.org Fri Apr 10 21:04:17 1998 Delivery-Date: Fri, 10 Apr 1998 21:04:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id VAA27047 for ; Fri, 10 Apr 1998 21:04:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12496 for ; Fri, 10 Apr 1998 21:06:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00481 for ; Fri, 10 Apr 1998 21:04:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Apr 1998 20:55:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29888 for ipp-outgoing; Fri, 10 Apr 1998 20:54:50 -0400 (EDT) Message-Id: <199804110053.JAA12574@jci.co.jp> X-My-Real-Login-Name: sasaki; post.jci.co.jp MIME-Version: 1.0 X-Mailer: Denshin 8 Go V321.1b7 Date: Fri, 10 Apr 1998 17:54:09 -0700 From: Yuji SASAKI To: ipp@pwg.org Subject: IPP> About host-to-device protocol issue Sender: ipp-owner@pwg.org Dear all, I attended the last IPP meeting at Portland, and I thought there is terrible confusion about the host-to-device protocol. Although my English capability is not very good, I saw a lot of people were discussing about host-to-device protocol from different perspective. Even listing up the requirment had took hours and hardly finished. I want to make this clear...even if I'm misunderstanding about "host to device" issue because of my English capability. o Do we want to build a protocol which replaces IPP? I definately don't think so. IPP is a very good protocol for job submission use both on the Internet or Intranet. I think the "host-to-device" protocol would be more primitive, less inter- operable, less expandable but very lightweight and easy to implement protocol. o Why do we build a new protocol for such use? We will be able to make IPP to have same function using with SNMP(PrinterMIB, Job MIB etc) or expanding IPP(adding notifications or device management capabilities). o There are a lot of well-defined protocol which designed for "host-to-device" use, why do we want to build yet another one? With my understanding, PWG has never decided to build a new protocol for host-to-device use. What we have to do is clearify the "problem" in network printing environment(it does not mean IPP), and find the best way(develop a new protocol? pick one of them? or even do nothing would be best for us) to solve the problem. It is no use to discuess "IPP or NOT" without clearifing what problem sould be solved with. o What is the "problem"? This is most difficult issue at all. Somebody(like me) think IPP is too heavy for cheap device, like $250 print server unit equipped with 16MHz 80186 and 2Mbit(256Kbyte) ROM and RAM. But somebody else think it is not a problem, but providing two differnent protocols for network printing would be a deadly problem for PWG. Even somebody think the most important problem is why nobody recognize TIP/SI as the standard. I think almost everyone have problems in today's network printing environment, and wants to solve with ONE solution. Everybody is waiting for the ultimate network printing protocol...lightweight, easy to understand and implement, scaleable, flexible, expandable and also interpoerable, equipped with efficient directory scheme, runs on various physical layers... but I think it is virtually impossible to realize ONE solution which solves ALL problems. IPP is not also an ultimate printing protocol, it is just a better (but not the best) job submission protocol than regacy printing protocol such as LPR. I think the "host-to-device" protocol is something like "RS-232C over the network"(prease do not be persistant bout terminology...I know RS-232C is just a electorical/physical specification and not a protocol name, but it is practical and easy to understand my opinion). Today most of devices like printers, scanners, digital cameras could be connected to PCs with RS-232C serial wire, and most of customers satisfy with this even though RS-232C is far from the ultimate communication method. RS-232C is primitive, slow, ristricted to 1-to-1 connection, ristricted up to 15m, no interoperability, poor compatibility(Baud rate? Stop Bit? no way!), many unnessasary pins (RTS/CTS? CD/RI? what the heck are them?) but it is very easy to implement and it works at all. I think what should we do about "host-to-device" issue is to provide a good solution something like "RS-232C over the network". I know there are many protocols like that...you can use TELNET, bi- directional LPR, TIP/SI, even TFTP can be used, perhaps raw-TCP-socket is good solution , or you can modify IPP to have such capabilities. But what is the best solution for PWG? I think this is the issue what we have to discuess. -------- Yuji Sasaki Company E-Mail :sasaki@jci.co.jp Personal E-Mail:crazy17@ibm.net Nifty-Serve :PFG02524@niftyserve.or.jp From ipp-owner@pwg.org Tue Apr 14 08:18:08 1998 Delivery-Date: Tue, 14 Apr 1998 08:18:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA22388 for ; Tue, 14 Apr 1998 08:18:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA06757 for ; Tue, 14 Apr 1998 08:20:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA16734 for ; Tue, 14 Apr 1998 08:18:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 08:08:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA16179 for ipp-outgoing; Tue, 14 Apr 1998 08:08:09 -0400 (EDT) From: "Rajesh Chawla" To: "IPP Mailing List" Subject: IPP> Looking for IPP Servers Date: Tue, 14 Apr 1998 08:09:25 -0400 Message-ID: <01bd679e$2ad77960$8dc245c6@rajesh.ari.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org Hi folks, I'm looking for IPP servers to test my IPP client with. Any takers? Regards, Rajesh ================================================ Rajesh Chawla TR Computing Solutions (703)724-2533 (Voice) 13622 Flintwood Place (703) 904-9689 (Fax) Herndon VA 20171 From ipp-owner@pwg.org Tue Apr 14 17:58:59 1998 Delivery-Date: Tue, 14 Apr 1998 17:58:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA07077 for ; Tue, 14 Apr 1998 17:58:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09694 for ; Tue, 14 Apr 1998 18:01:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19268 for ; Tue, 14 Apr 1998 17:58:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 17:49:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18174 for ipp-outgoing; Tue, 14 Apr 1998 17:49:27 -0400 (EDT) Message-Id: <3.0.1.32.19980414140550.00be2980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Apr 1998 14:05:50 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 980415 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Hi, here the last minute information for tomorrow's phone conference. I expect us to do a little follw-up on the home work assignments from last week and see how we can get our remaining deliverables for the IETF together. We are NOT discussing about Server-to-device... The conference information is: Time: April 15, 10:00 am PDT (1:00 pm EDT) Number: 1-212-547 0290 (Xerox internal 5*535 5000) Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Apr 14 17:58:59 1998 Delivery-Date: Tue, 14 Apr 1998 17:58:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA07079 for ; Tue, 14 Apr 1998 17:58:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA09693 for ; Tue, 14 Apr 1998 18:01:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19265 for ; Tue, 14 Apr 1998 17:58:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 17:49:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18165 for ipp-outgoing; Tue, 14 Apr 1998 17:49:16 -0400 (EDT) Message-Id: <3.0.1.32.19980414134852.0099d430@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Apr 1998 13:48:52 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Minutes from PWG IPP Meeting in Portland, OR - April 8-9, 1998 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id NAA07544 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id RAA07079 Here are the "raw" minutes from last week. Thanks to Jay and Harry for taking notes. None seems to have captured the list of attendents. Has anybody got that list somewhere? Carl-Uno Minutes from PWG IPP Meeting in Portland, OR - April 8-9, 1998 =============================================================== Minutes taken by Jay Martin on April 8. The meeting started at approximately 8:30 am. Job openings Need a permanent, full-time secretary (not Jay!) Scott will chair the next PWG IPP meeting as Carl-Uno will be unable to attend. IETF Editing and maintenance Keith Moore wants to see a short document describing the minimal mandatory aspects and components of IPP, from the perspective of the server side implementation. No commitment made by any PWG participant to write such a document. Carl-Uno requested a volunteer to write the document. Peter reminded the group that the IPP testing document provides much of that kind of info. Tom suggested that he, Carl-Uno & Peter will review the testing document and perhaps deriving a document for Keith Moore’s use. Carl-Uno stated that IPP V1.0 will formally wrap up its effort by the August 98 IETF plenary. Carl-Uno announced that Steve Zilles will be asking to be relieved of his IETF WG co-chairperson position due to other commitments with the W3C. Scott brought up the fact that the WG has had several proposals for changes, yet no action has been taken to officially incorporate (or reject) those proposals into the formal documents, including: - Charset and natural language should always be the first and second attribute in every message in the operations group (affects the Model document) - All attributes should be lowercase only, including the values for language keywords; the document examples need to be updated - Tom raised the issue of mapping uppercase to lowercase to provide a more "forgiving" implementation; the group decided that this was not necessary, that specifying "always lowercase" is sufficient - Need to explain the table of attributes with respect to MANDATORY vs. "required" (section 15 of the Model document) - Changing URI to URL with respect to references to external IETF documents, since there is no IETF standards document for URI Decision: leave it as is (URI). Scott will look into adding some simple clarifying text in the Model document. IPP Notifications What can the IPP group do to satisfy its charter requirements wrt notifications? Randy reminded Roger that one of the published requirements was supposed to be removed: the ability for a client to specify which attributes should be returned in a notification. Rabid discussion followed, resulting in a decision to make this specific requirement optional rather mandatory. What will be mandatory is support for a fixed list of attributes in a notification message. Dictionary proposal Tom reviewed the recent proposal (v0.92, 3/31/98) Several people mentioned they have a problem with the term "dictionary", so the term was officially changed to "collection". The group did not wholeheartedly buy into this data typing and structuring approach due to its complexity and the lack of understanding of the requirements Review of "Notifications for the IPP print protocol" (ipp-job-proposal.doc by Hastings/Lewis) Consensus was to not provide "ala carte" specification for job event registrations; instead, events will be gathered into groups, and the client registers for one or more groups. As a result, job-notify-additional-attributes was removed. Accessing MIB data through IPP How to map and access Printer and Job MIB objects using IPP attributes Scott lead the discussion Rabid discussion followed resulting in the consensus that the concept and discussion should be deferred until we conduct more discussion on the host-to-device issue. Testing Peter will draw up and publish a list of the "Top 25" (or so) list of test scenarios. Harry pointed out that unless the group schedules a date for a bake-off, testing will languish. Carl-Uno is attempting to emancipate a test case generator/analyzer from the Xerox effort for public use. The meeting ended at approximately 5:30pm. -- Notes from April 9 taken by Harry Lewis The meeting started saty 8:30 am Host-to-Device protocol Carl-Uno tries to set the stage. Trying to get decision on general direction. Concerns. What’s happening with IPP? Not using HTTP? Drop IPP into TIPSI? Funny to run this discussion of Host-to-Device protocol on the IPP list. Worried about sabotaging peoples confidence in IPPv1. Change the name of this to Server to printer Review issues - from Paul. 1. IPP asymmetrical. No way to send asych alerts. We’re working on notification. 2. No peer conflict resolution. How does a non-spooling IPP printer resolve being asked to print by two clients. Like ticket number that tells you where you are in line. Randy - there are resources at every level of the protocol stack so you really can’t solve. Randy added two statuses in his paper to address this. 3. No way for printer to solicit data from the client (to throttle data transfers). All transport layers have a flow control mechanism underneath it. One connection for data and another for control. IPP doesn’t require this. Maybe we should require this? TCP can do this but IPP is not just TCP 4. Current security too complex? Would security to server and no security from server to device satisfy? Argued that basic authentication is not too complex. TLS is optional. 5. IPP is not transport neutral. Encoding is HTTP independent except for chinking. From a server standpoint, I want to be able to talk to my printers in whatever way they are connected using one protocol. 6. HTTP is heavy duty 7. No way to move data backward (scan, fax...). Embed IPP client in MFP? 8. No separate channel for control. We don’t make any statements right now but there should be no reason why we couldn’t allow or require two connections. Open channel for data, another channel for control. Print job sends status immediately otherwise can’t query. If IPP CREATE JOB was mandatory, then the job ID would be known early enough to allow queries over separate channel. Maybe in the v2 thing we’re talking about PrintJob isn’t even there and createJob is mandatory! 9. Detailed configuration and status not available. We kept discussing the scope, purpose etc. Need to start another project. Decided to start over. Actual proposals for TIPSI and IPP over TCP not reviewed in any organized manner. Implementers Guide. No one volunteered. Server to Device PWG meeting Lot’s of discussion about whether or not we need another protocol. What are the needs for a server to printer protocol? What are the compelling reasons for doing this. Does it deliver more to the customer? Does it deliver it cheaper? Is there competitive pressure? 1. Advantage of single protocol for driver like functions vs. a suite of protocols. - Keeping IP address and URL’s in synch 2. Advantage of multiple protocols. - Asymmetry maps better to actual communications needs. NEW LIST OF REQUIREMENTS 1. Need a protocol which delivers unsolicited real time status information (alerts). 2. Flexible security model 3. Transport independent 4. Need way to send FAX or SCAN data from device to server (for MFPs only) 5. Control channel can’t be blocked by data. Server can query and control with quick response. 6. Need configuration and status info like what’s provided in the printer MIB. 7. Ability to recover job accounting information 8. Device can retrieve resources like fonts and forms 9. Server to Device protocol must not significantly limit the function of any major existing client to server protocols and must accommodate IPP without any loss. 10. Must Cover the case of spooling both in the server and the device or other multiple levels. The user should get the same functionality (CANCEL, MODIFY etc.). 11. What layer are we at? - Application layer. 12. Submit Cancel and list jobs (end-user and administrator) Naming the new project SDP - Server device protocol. Jay is tentative Chair. SNMP v3 Traps and Informs Job MIB traps work is ongoing. Looked like a match with IPP notifications requirements. Notification MIB and Trap MIB as part of SNMPv3 introduced by Randy. Utility and applicability of SNMPv3 MIBs to what we are trying to do. Joe F. and Ira McD. put together proposal for registration. SNMPv3 128 octet OID string. Trap types or groups are given OIDs. "TargetSpinLock" keeps one agent from overwriting another agent’s entries. Randy recommends use the SNMPv3 target and notification MIBs, augmented, if necessary with additional function (i.e. Time to Live group indexed to the target). JAM MIB supports automatic trap de-registration. Keep alive etc. Is there stuff in the v3 MIBs that we don’t need? Should we create a hybrid? Basically, there is a lot of overlap with Xerox MIB and v3 MIB's so use v3 and augment. Thru IPP you can register on a per-job basis, but not with SNMP. There, only per time-out (all jobs). No disagreement regarding adoption of this approach. We should use Informs... not traps. For v1 it’s a trap. For v2-3 use inform. Need proposal to fit this together. Tom, Harry, Ron. Keep this at tail end of IPP for the next few meetings. Administrator register with time to live. Clients register with job. Need a way to manage reg table itself. Next highest index. Need to define trap informs (informational) Need to write augments for target and notification MIB's (stds track or experimental - might ultimately be subsumed by IETF cause they like this idea). The meeting closed at 5:30 pm. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Apr 14 19:29:43 1998 Delivery-Date: Tue, 14 Apr 1998 19:29:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08502 for ; Tue, 14 Apr 1998 19:29:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10001 for ; Tue, 14 Apr 1998 19:32:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20003 for ; Tue, 14 Apr 1998 19:29:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 19:25:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19473 for ipp-outgoing; Tue, 14 Apr 1998 19:25:32 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri Message-ID: <5030100019533288000002L082*@MHS> Date: Tue, 14 Apr 1998 19:24:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA08502 > IPP is not transport neutral. Encoding is HTTP independent except for > chinking. I assume you mean "chunking". In what way is IPP dependent on HTTP chunking? -Carl From ipp-owner@pwg.org Tue Apr 14 19:35:22 1998 Delivery-Date: Tue, 14 Apr 1998 19:35:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08558 for ; Tue, 14 Apr 1998 19:35:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10038 for ; Tue, 14 Apr 1998 19:37:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20600 for ; Tue, 14 Apr 1998 19:35:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 19:31:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20053 for ipp-outgoing; Tue, 14 Apr 1998 19:31:15 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri Date: Tue, 14 Apr 1998 16:32:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org The abstract IPP described in the model document is not dependent on HTTP chunking. The concrete transport/encoding IPP protocol document is VERY dependent on HTTP chunking. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Tuesday, April 14, 1998 4:25 PM To: ipp@pwg.org Subject: Re: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri > IPP is not transport neutral. Encoding is HTTP independent except for > chinking. I assume you mean "chunking". In what way is IPP dependent on HTTP chunking? -Carl From ipp-owner@pwg.org Tue Apr 14 23:51:08 1998 Delivery-Date: Tue, 14 Apr 1998 23:51:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA15913 for ; Tue, 14 Apr 1998 23:51:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA10609 for ; Tue, 14 Apr 1998 23:53:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA22851 for ; Tue, 14 Apr 1998 23:51:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Apr 1998 23:46:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA22326 for ipp-outgoing; Tue, 14 Apr 1998 23:46:07 -0400 (EDT) Message-Id: <1.5.4.32.19980415034327.0068aeec@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, 14 Apr 1998 20:43:27 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IPP already taken for Internet Project! Sender: ipp-owner@pwg.org While looking round on the web to see if I could find any recent mentioning about IPP, I ran across another IPP project on the Internet. http://www.lysator.liu.se/pinball/IPP/ Carl-Uno From ipp-owner@pwg.org Wed Apr 15 08:37:14 1998 Delivery-Date: Wed, 15 Apr 1998 08:37:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA28030 for ; Wed, 15 Apr 1998 08:37:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA11388 for ; Wed, 15 Apr 1998 08:39:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA04441 for ; Wed, 15 Apr 1998 08:37:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 08:27:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA03884 for ipp-outgoing; Wed, 15 Apr 1998 08:27:04 -0400 (EDT) Date: Wed, 15 Apr 1998 05:26:46 -0700 (PDT) X-Sender: szilles@elroy Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipp@pwg.org From: szilles@Adobe.COM (Steve Zilles) Subject: IPP> ADM - Steve Zilles resigning as co-chair of IPP Cc: szilles@Adobe.COM, bhunt@Adobe.COM Sender: ipp-owner@pwg.org With deep regret, I find it necessary to resign as co-chair of the IETF IPP Working Group. I had hoped that this would not be necessary before the IPP documents were published as RFC;s and the work was nearly completed. My assigned duties have shifted since the end of the year and I am much more involved with W3C. It is not fair to the many active participants of the IPP working group for me to occupy a position which requires an active participation which I can no longer sustain. I have discussed this decision with my co-chair and Keith Moore as Area Director; it is my understanding the the WG will continue under Carl-Uno's sole leadership. I will attempt to continue to participate at some level by e-mail, but due to meeting conflicts will not be able to participate in face-to-face meetings in the near future. I will miss the direct contact with a great working group. Sincerely, Steve Zilles -------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com | Adobe Systems Inc. | | Mailstop W14 | tel: (work) (408) 536-4766 | 345 Park Avenue | (Admin) (408) 536-4751 | San Jose, CA 95110-2704 | fax: (408) 537-4042 | -------------------------------------------------------------- From ipp-owner@pwg.org Wed Apr 15 12:27:22 1998 Delivery-Date: Wed, 15 Apr 1998 12:27:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04391 for ; Wed, 15 Apr 1998 12:27:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA12400 for ; Wed, 15 Apr 1998 12:29:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06348 for ; Wed, 15 Apr 1998 12:27:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 12:23:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05797 for ipp-outgoing; Wed, 15 Apr 1998 12:22:46 -0400 (EDT) From: Carl Kugler To: Subject: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Message-ID: <5030100019555053000002L032*@MHS> Date: Wed, 15 Apr 1998 12:21:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA04391 > The concrete transport/encoding IPP protocol document is VERY dependent > on HTTP chunking. I still don't get it. Could you please explain? The original statement is: > Encoding is HTTP independent except for chinking. This sentence, to me, implies that there is some aspect of the IPP encoding, apart from HTTP, that depends on chunking. This is suprising news to me. The only chunking-related requirements I've found in the Protocol document are: 1) the Server must support "chunked" Transfer-Encoding of Requests 2) the Client must support "chunked" Responses. These requirements derive directly from RFC 2068: "All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer coding..." Confused in Boulder, Carl-III ipp-owner@pwg.org on 04/14/98 05:34:03 PM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri The abstract IPP described in the model document is not dependent on HTTP chunking. The concrete transport/encoding IPP protocol document is VERY dependent on HTTP chunking. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Tuesday, April 14, 1998 4:25 PM To: ipp@pwg.org Subject: Re: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri > IPP is not transport neutral. Encoding is HTTP independent except for > chinking. I assume you mean "chunking". In what way is IPP dependent on HTTP chunking? -Carl From ipp-owner@pwg.org Wed Apr 15 12:37:37 1998 Delivery-Date: Wed, 15 Apr 1998 12:37:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04700 for ; Wed, 15 Apr 1998 12:37:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA12459 for ; Wed, 15 Apr 1998 12:39:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA07027 for ; Wed, 15 Apr 1998 12:37:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 12:32:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06408 for ipp-outgoing; Wed, 15 Apr 1998 12:32:24 -0400 (EDT) Message-Id: <3.0.1.32.19980415090410.00c0e1b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 15 Apr 1998 09:04:10 PDT To: szilles@Adobe.COM (Steve Zilles), ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM - Steve Zilles resigning as co-chair of IPP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Steve, It is with reget that I see you leaving your post. You have been a great support in helping me navigate the sometimes muddy waters of the IETF. Hope we will stay in touch, you never know when more people will start showing up in the W3C. Thanks, Carl-Uno At 05:26 AM 4/15/98 PDT, Steve Zilles wrote: >With deep regret, I find it necessary to resign as co-chair of the IETF IPP >Working Group. I had hoped that this would not be necessary before the IPP >documents were published as RFC;s and the work was nearly completed. My >assigned duties have shifted since the end of the year and I am much more >involved with W3C. It is not fair to the many active participants of the >IPP working group for me to occupy a position which requires an active >participation which I can no longer sustain. I have discussed this decision >with my co-chair and Keith Moore as Area Director; it is my understanding >the the WG will continue under Carl-Uno's sole leadership. I will attempt >to continue to participate at some level by e-mail, but due to meeting >conflicts will not be able to participate in face-to-face meetings in the >near future. > >I will miss the direct contact with a great working group. > Sincerely, > > Steve Zilles > >-------------------------------------------------------------- >Stephen N. Zilles | e-mail: szilles@adobe.com | >Adobe Systems Inc. | | >Mailstop W14 | tel: (work) (408) 536-4766 | >345 Park Avenue | (Admin) (408) 536-4751 | >San Jose, CA 95110-2704 | fax: (408) 537-4042 | >-------------------------------------------------------------- > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Apr 15 12:42:43 1998 Delivery-Date: Wed, 15 Apr 1998 12:42:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04823 for ; Wed, 15 Apr 1998 12:42:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA12465 for ; Wed, 15 Apr 1998 12:45:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA07638 for ; Wed, 15 Apr 1998 12:42:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 12:36:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06848 for ipp-outgoing; Wed, 15 Apr 1998 12:36:14 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking ? Was Message-ID: <5030300020032134000002L042*@MHS> Date: Wed, 15 Apr 1998 12:43:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA04823 I think whoever wrote > Encoding is HTTP independent except for chinking. should elaborate on what they meant. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Apr 15 12:49:25 1998 Delivery-Date: Wed, 15 Apr 1998 12:49:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05010 for ; Wed, 15 Apr 1998 12:49:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA12516 for ; Wed, 15 Apr 1998 12:51:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA08424 for ; Wed, 15 Apr 1998 12:49:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 12:41:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07492 for ipp-outgoing; Wed, 15 Apr 1998 12:41:08 -0400 (EDT) Message-Id: <3.0.1.32.19980415085532.00bb48d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 15 Apr 1998 08:55:32 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Server to Device Protocol DL now available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org All, Please note that the discussion of a future "Server to Device" printing protocol aka "Host to Device" has now been moved to another DL. This subject is outside the current scope of the IETF IPP WG. The new DL and group is a PWG initiative and is, at present, not part of the work in the IETF. However, anybody interested in the subject can sign up for the new DL. Carl-Uno >Date: Tue, 14 Apr 1998 18:48:38 PDT >From: Jeff Schnitzer >Reply-To: jds@underscore.com >Organization: Underscore, Inc. >To: pwg-announce@pwg.org >Subject: PWG-ANNOUNCE> New (Server to Device Protocol) DL now available >Sender: owner-pwg-announce@pwg.org > >The PWG's new Server-to-Device Printing Protocol mail >discussion list is now available. > >To begin your subscription, send mail to with the >following as the mail message body: > > subscribe sdp > end > > >I have also set up FTP://ftp.pwg.org/pub/pwg/sdp as the project >repository, and the Hypermail archives of the mailing list at >HTTP://www.pwg.org/hypermail/sdp > > >There is no SDP web page. Has someone taken that on? > > >/Jeff > >--------------------------------------------------------------- >Jeffrey D. Schnitzer | Email: jds@underscore.com >Underscore, Inc. | Voice: (603) 889-7000 >41-C Sagamore Park Rd | Fax: (603) 889-2699 >Hudson, NH 03051-4915 | Web: http://www.underscore.com >--------------------------------------------------------------- > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Apr 15 14:11:21 1998 Delivery-Date: Wed, 15 Apr 1998 14:11:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07364 for ; Wed, 15 Apr 1998 14:11:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA12865 for ; Wed, 15 Apr 1998 14:13:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09330 for ; Wed, 15 Apr 1998 14:11:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 14:06:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08762 for ipp-outgoing; Wed, 15 Apr 1998 14:06:22 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking ? Was Message-ID: <5030300020034930000002L002*@MHS> Date: Wed, 15 Apr 1998 14:13:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA07364 I don't know how to draw the picture "extracting-foot-from-mouth" in ASCII text... In reviewing the IPP minutes, I realize the source of the "chinking" statement... it was my own raw notes of the Portland meeting which I sent to Carl-Uno! This was an attempt, on my part, to capture the list of Paul Moore's concerns with IPP as we were discussing them in the "Server-to-Device" session. Pardon the typo... but I may also have inserted confusion regarding the whole topic by poorly capturing the initial concern. I tried to find Paul's original list and get his language, but I can't fine it. In general, we have an IPP model which is DEFINITELY transport and protocol independent. Then we have an IPP protocol document which is really made up of two parts, an ENCODING and a TRANSPORT. I BELIEVE the ENCODING is ALSO meant to be entirely transport independent. The published transport mapping is OBVIOUSLY transport dependent, because it represents a CHOICE to map to a particular transport. It should not, however, give the impression that the encoding is somehow bound to that transport - ONLY! I believe the goal, all along, was to anticipate mappings to additional transports. We just had to pick one to get the job done and we picked the one we thought would best scope the Internet at this point in time. So, again, I'm not sure what Paul's original concern was but it had something to do with his impression that IPP is not transport neutral. My guess is that Paul was trying to state his desire to have a printing protocol which runs over networks, local ports etc. Harry Lewis - IBM Printing Systems ipp-owner@pwg.org on 04/15/98 10:39:59 AM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking ? Was I think whoever wrote > Encoding is HTTP independent except for chinking. should elaborate on what they meant. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Apr 15 16:41:40 1998 Delivery-Date: Wed, 15 Apr 1998 16:41:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10574 for ; Wed, 15 Apr 1998 16:41:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA13623 for ; Wed, 15 Apr 1998 16:44:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA10301 for ; Wed, 15 Apr 1998 16:41:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 16:36:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09758 for ipp-outgoing; Wed, 15 Apr 1998 16:36:08 -0400 (EDT) From: Carl Kugler To: Cc: Subject: IPP> PRO Where are the operation-id enums specified? Message-ID: <5030100019565469000002L092*@MHS> Date: Wed, 15 Apr 1998 16:35:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA10574 Where are the operation-id enumerations specified? -Carl From ipp-owner@pwg.org Wed Apr 15 18:22:04 1998 Delivery-Date: Wed, 15 Apr 1998 18:22:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12164 for ; Wed, 15 Apr 1998 18:22:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA14009 for ; Wed, 15 Apr 1998 18:24:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11365 for ; Wed, 15 Apr 1998 18:21:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 18:17:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10839 for ipp-outgoing; Wed, 15 Apr 1998 18:17:25 -0400 (EDT) From: Harry Lewis To: , Subject: IPP> Charter eyeglasses Message-ID: <5030300020044033000002L032*@MHS> Date: Wed, 15 Apr 1998 18:24:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id SAA12164 We were having a "host-to-Device" discussion within IPP which, in Portland, got split off to become a separate, Server-to-Device, PWG group. Now, we have to debate which elements of printing belong to which protocol and which group and run the risk of channeling our discussion to one group while overlooking the other. The idea of splitting is supported by the notion that SDP like functions are not in the IPP charter and that the concept of a "unified" protocol is nonsense. Re-reading, and presenting excerpts from the charter with capitalization for emphasis, I see that the charter, itself, may contribute some of the confusion and frustration expressed in Portland... Group-A... Universal protocol, grow IPP to encompass SDP requirements. "There is currently NO UNIVERSAL STANDARD FOR PRINTING. Several protocols are in use, but each has limited applicability and none can be considered the prevalent one. This means that printer vendors have to implement and support a number of different protocols and protocol variants. There is a need to define a protocol which can cover the most common situations for printing on the Internet." "The further goal is to define a new application level Internet Printing Protocol for the following core functions: - for a user to find out about a PRINTER's CAPABILITIES - for a user to submit print jobs TO A PRINTER - for a user to find out the STATUS OF A PRINTER or a print job - for a user to cancel a previously submitted job" "The Internet Print Protocol is a client-server type protocol which should allow the server side to be either a separate print server or a PRINTER WITH EMBEDDED NETWORKING capabilities. The focus of this effort is optimized for PRINTERS, but might be applied to other OUTPUT DEVICES. These are outside the scope of this working group." Group-B... IPP to server only, Totally separate SDP discussion. "There is currently no universal standard for printing. Several protocols are in use, but each has limited applicability and none can be considered the prevalent one. This means that printer vendors have to implement and support a number of different protocols and protocol variants. There is a need to define a protocol which can cover the most common situations for printing on the INTERNET." "The further goal is to define a new APPLICATION LEVEL INTERNET PRINTING Protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job" "The Internet Print Protocol is a CLIENT-SERVER type protocol which should allow the server side to be either a separate print server or a printer with embedded networking capabilities. The focus of this effort is optimized for printers, but might be applied to other output devices. These are outside the scope of this working group." Granted... ALL THE WORDS are there - I'm not trying to imply that these are the ONLY words that people read and interpret. But, at least I see how my interpretation of the charter must differ greatly with some others and how the resulting mismatch in expectations is fueling many of our current disagreements. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Apr 15 19:25:12 1998 Delivery-Date: Wed, 15 Apr 1998 19:25:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12941 for ; Wed, 15 Apr 1998 19:25:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA14191 for ; Wed, 15 Apr 1998 19:27:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12524 for ; Wed, 15 Apr 1998 19:25:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 19:19:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11819 for ipp-outgoing; Wed, 15 Apr 1998 19:19:26 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: IPP> PRO Where are the operation-id enums specified? Message-ID: <5030100019570593000002L032*@MHS> Date: Wed, 15 Apr 1998 19:17:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA12941 Thanks! I was hunting in the wrong document. BTW while searching for operation-id I noticed a small document problem in MOD: 15.3.2 Validate operation identifier The Printer object checks to see if the "operation-id" attribute supplied by the client is supported as indicated in the Printer object's "printer-operations-supported" attribute. I don't think "printer-operations-supported" is a defined attribute. - Carl xriley@cp10.es.xerox.com on 04/15/98 04:19:59 PM Please respond to xriley@cp10.es.xerox.com To: Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> PRO Where are the operation-id enums specified? >Where are the operation-id enumerations specified? > > -Carl > > IPP/1.0: Model and Semantics 4.4.13 operations-supported (1setOf type2 enum) This MANDATORY Printer attribute specifies the set of supported operations for this Printer object and contained Job objects. No 32- bit enum value for this attribute SHALL exceed 0x8FFF, since these values are passed in two octets in each Protocol request [IPP-PRO]. The following standard values are defined: Value Operation Name ----------------- ------------------------------------- 0x0000 reserved, not used 0x0001 reserved, not used 0x0002 Print-Job 0x0003 Print-URI 0x0004 Validate-Job 0x0005 Create-Job 0x0006 Send-Document 0x0007 Send-URI 0x0008 Cancel-Job 0x0009 Get-Job-Attributes 0x000A Get-Jobs 0x000B Get-Printer-Attributes 0x000C-0x3FFF reserved for future operations 0x4000-0x8FFF reserved for private exteAt 01:35 PM 4/15/98 PDT, you wrote: From ipp-owner@pwg.org Wed Apr 15 19:29:11 1998 Delivery-Date: Wed, 15 Apr 1998 19:29:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12995 for ; Wed, 15 Apr 1998 19:29:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA14194 for ; Wed, 15 Apr 1998 19:31:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA13072 for ; Wed, 15 Apr 1998 19:29:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 19:22:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12179 for ipp-outgoing; Wed, 15 Apr 1998 19:22:26 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: IPP> Re: SDP> Charter eyeglasses Message-ID: <5030300020046446000002L062*@MHS> Date: Wed, 15 Apr 1998 19:29:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA12995 I agree with Don that IPP is not optimized for a print subsystem running on an embedded controller. And, I may even be convinced to focus on the merits of >a single..., well designed protocol to accomplish this goal and not >a conglomeration of protocols patched together. although not without pointing out that the Job MIB is receiving as much discredit, by those who have not made the effort to implement, as some feel TIPSI is receiving for similar reasons - the Job MIB being the more recently charted PWG effort. The more important point is... will this single protocol evolve from IPP or will we all be forced to adopt a standard with a control/command/response set which, while in it's own right may be fine for server-to-host printing, *is not* the same as the IPP operations and attributes we, collectively, have just completed defining! Harry Lewis - IBM Printing Systems don@lexmark.com on 04/15/98 04:54:54 PM Please respond to don@lexmark.com To: Harry Lewis/Boulder/IBM@ibmus cc: Sdp@Pwg.Org Subject: Re: SDP> Charter eyeglasses (I purposefully didn't sent this to the IPP group, anyone interested in SDP should be subscribed to this list.) I agree with Harry in that there are multiple ways to interpret the original IPP charter; however, rather than looking at the charter, I would like to look at the result. I content that IPP is not optimized for a print server/print subsystem running on a general computing platform to communicate with a printer/marking engine running on a separate piece of hardware, e.g. - long, internationalized, text-string parameter based commands and responses are not optimal for an embedded product. - no support for alerts, etc. - no detailed control and status information e.g. TIPSI's "gas gauge" supplies level reporting >From my perspective, this is clearly server to printer communications is the target of the SDP. It therefore needs to be optimized for: - delivering the job - reporting printer configuration and status - setting printer defaults - supporting alerts from the printer to the server - reporting the results of printing the job (accounting) I continue to maintain that we need a single large, well designed protocol to accomplish this goal and not a conglomeration of protocols patched together. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Apr 15 22:19:40 1998 Delivery-Date: Wed, 15 Apr 1998 22:19:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id WAA14928 for ; Wed, 15 Apr 1998 22:19:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA14559 for ; Wed, 15 Apr 1998 22:22:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA14411 for ; Wed, 15 Apr 1998 22:19:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Apr 1998 22:13:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA13678 for ipp-outgoing; Wed, 15 Apr 1998 22:13:37 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 15 Apr 1998 19:23:08 -0600 From: "Scott Isaacson" To: ipp@pwg.org, sdp@pwg.org, harryl@us.ibm.com Subject: Re: IPP> Charter eyeglasses Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id WAA14928 Harry, When I read: >>> Harry Lewis 04/15/98 04:24PM >>> >The Internet Print Protocol is a CLIENT-SERVER type protocol which >should allow the server side to be either a separate print server or >a printer with embedded networking capabilities. I assume CLIENT/SERVER in the distributed systems architecture sense NOT in the literal CLIENT = PC and SERVER = file server/printer server hardware box sense. I see client/server meaning request/response rather than distribute object remote methods, IIOP, RMI stuff. In other workds, I am not confused into thinking end-user to file server only (not server to device) when I see the term "client/server" Good reading of the charter thought, very helpful. Scott From ipp-owner@pwg.org Thu Apr 16 00:11:48 1998 Delivery-Date: Thu, 16 Apr 1998 00:11:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA20579 for ; Thu, 16 Apr 1998 00:11:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA14822 for ; Thu, 16 Apr 1998 00:14:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA15953 for ; Thu, 16 Apr 1998 00:11:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 00:07:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA15430 for ipp-outgoing; Thu, 16 Apr 1998 00:07:05 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Date: Wed, 15 Apr 1998 21:08:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org There is nothing in the existing encoding that allows a particular IPP message to be "fragmented" across multiple transport "packets". The encoding requires that a transport protocol provide some way to logically "connect" one message to another contiguously received message. In HTTP, this is accomplished with HTTP 1.1 chunking. With another transport, there would have to some equivalent capability. I'm not sure if I've adequately described the situation. Anything further I think would require me to draw a picture. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, April 15, 1998 9:22 AM To: ipp@pwg.org Subject: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi > The concrete transport/encoding IPP protocol document is VERY dependent > on HTTP chunking. I still don't get it. Could you please explain? The original statement is: > Encoding is HTTP independent except for chinking. This sentence, to me, implies that there is some aspect of the IPP encoding, apart from HTTP, that depends on chunking. This is suprising news to me. The only chunking-related requirements I've found in the Protocol document are: 1) the Server must support "chunked" Transfer-Encoding of Requests 2) the Client must support "chunked" Responses. These requirements derive directly from RFC 2068: "All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer coding..." Confused in Boulder, Carl-III ipp-owner@pwg.org on 04/14/98 05:34:03 PM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri The abstract IPP described in the model document is not dependent on HTTP chunking. The concrete transport/encoding IPP protocol document is VERY dependent on HTTP chunking. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Tuesday, April 14, 1998 4:25 PM To: ipp@pwg.org Subject: Re: IPP> Minutes from PWG IPP Meeting in Portland, OR - Apri > IPP is not transport neutral. Encoding is HTTP independent except for > chinking. I assume you mean "chunking". In what way is IPP dependent on HTTP chunking? -Carl From ipp-owner@pwg.org Thu Apr 16 00:32:25 1998 Delivery-Date: Thu, 16 Apr 1998 00:32:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA20941 for ; Thu, 16 Apr 1998 00:32:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA14859 for ; Thu, 16 Apr 1998 00:34:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA16613 for ; Thu, 16 Apr 1998 00:32:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 00:28:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA16058 for ipp-outgoing; Thu, 16 Apr 1998 00:27:59 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Re: SDP> Charter eyeglasses Date: Wed, 15 Apr 1998 21:28:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org I believe the IPP model document stands on its own merits. It defines the model for printing as we know it today. Whether your printer is on your wrist watch, or whether it fills a 10'x20' publishing room. I'm not sure I really care about how the SDP is transported, or what media is used to deliver it. Where I would be concerned is if someone decided to define another "model" for SDP; which I think would be extremely unfortunate, especially for the 99.9% of the printer industry that would be forced to write complicated gateways to connect these two paradigms. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Wednesday, April 15, 1998 4:29 PM To: don@lexmark.com Cc: sdp@pwg.org; ipp@pwg.org Subject: IPP> Re: SDP> Charter eyeglasses I agree with Don that IPP is not optimized for a print subsystem running on an embedded controller. And, I may even be convinced to focus on the merits of >a single..., well designed protocol to accomplish this goal and not >a conglomeration of protocols patched together. although not without pointing out that the Job MIB is receiving as much discredit, by those who have not made the effort to implement, as some feel TIPSI is receiving for similar reasons - the Job MIB being the more recently charted PWG effort. The more important point is... will this single protocol evolve from IPP or will we all be forced to adopt a standard with a control/command/response set which, while in it's own right may be fine for server-to-host printing, *is not* the same as the IPP operations and attributes we, collectively, have just completed defining! Harry Lewis - IBM Printing Systems don@lexmark.com on 04/15/98 04:54:54 PM Please respond to don@lexmark.com To: Harry Lewis/Boulder/IBM@ibmus cc: Sdp@Pwg.Org Subject: Re: SDP> Charter eyeglasses (I purposefully didn't sent this to the IPP group, anyone interested in SDP should be subscribed to this list.) I agree with Harry in that there are multiple ways to interpret the original IPP charter; however, rather than looking at the charter, I would like to look at the result. I content that IPP is not optimized for a print server/print subsystem running on a general computing platform to communicate with a printer/marking engine running on a separate piece of hardware, e.g. - long, internationalized, text-string parameter based commands and responses are not optimal for an embedded product. - no support for alerts, etc. - no detailed control and status information e.g. TIPSI's "gas gauge" supplies level reporting From my perspective, this is clearly server to printer communications is the target of the SDP. It therefore needs to be optimized for: - delivering the job - reporting printer configuration and status - setting printer defaults - supporting alerts from the printer to the server - reporting the results of printing the job (accounting) I continue to maintain that we need a single large, well designed protocol to accomplish this goal and not a conglomeration of protocols patched together. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Thu Apr 16 10:05:49 1998 Delivery-Date: Thu, 16 Apr 1998 10:05:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03639 for ; Thu, 16 Apr 1998 10:05:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA15854 for ; Thu, 16 Apr 1998 10:08:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA28370 for ; Thu, 16 Apr 1998 10:05:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 09:57:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA27700 for ipp-outgoing; Thu, 16 Apr 1998 09:57:37 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: IPP> Charter eyeglasses Message-ID: <5030300020064267000002L072*@MHS> Date: Thu, 16 Apr 1998 10:04:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ipp-owner@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id KAA03639 Scott, I agree with your interpretation 100% and believe this is the only valid interpretation. Otherwise, I think the overall charter would have been way too limiting - even if this is where we ended up for v1. I put the emphasis there to show how I think some must be reading the charter and the conclusions they must have made. Harry Lewis - IBM Printing Systems SISAACSON@novell.com on 04/15/98 08:15:10 PM Please respond to SISAACSON@novell.com To: Harry Lewis/Boulder/IBM@ibmus, sdp@pwg.org, ipp@pwg.org cc: Subject: Re: IPP> Charter eyeglasses Harry, When I read: >>> Harry Lewis 04/15/98 04:24PM >>> >The Internet Print Protocol is a CLIENT-SERVER type protocol which >should allow the server side to be either a separate print server or >a printer with embedded networking capabilities. I assume CLIENT/SERVER in the distributed systems architecture sense NOT in the literal CLIENT = PC and SERVER = file server/printer server hardware box sense. I see client/server meaning request/response rather than distribute object remote methods, IIOP, RMI stuff. In other workds, I am not confused into thinking end-user to file server only (not server to device) when I see the term "client/server" Good reading of the charter thought, very helpful. Scott From ipp-owner@pwg.org Thu Apr 16 16:20:14 1998 Delivery-Date: Thu, 16 Apr 1998 16:20:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA06368 for ; Thu, 16 Apr 1998 16:19:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA17872 for ; Thu, 16 Apr 1998 15:55:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00583 for ; Thu, 16 Apr 1998 15:53:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 15:49:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29247 for ipp-outgoing; Thu, 16 Apr 1998 15:40:19 -0400 (EDT) Message-Id: <3.0.1.32.19980416123114.00c8e5b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 16 Apr 1998 12:31:14 PDT To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Randy et al., Here is my take on the use of chunking for IPP: 1) Each HTTP 1.1 implementation is mandated to support chunking. 2) All POSTs are initiated by the client, which I assume also means that the client determines whether to use chunking for a particular HTTP request. 3) The only situation where chunking is absolutely necessary for IPP, is the case where the client does not know the document length when it starts sending the document. 4) With the exception of the situation in 3) the client can always decide not to use chunking, but send even long documents in one request. The downside of doing that is that if something goes wrong on the lower protocol layers, the client has to start over and send the whole document again from the beginning. The main advantage of using chunking is that if you get an error on the lower layers, you only have to resend the latest chunk, not the whole document. 5) Again, with the exception of the case in 3), you can in practise actually use HTTP 1.0, which does not support chunking, for most of your IPP transfers. Did I get this right? Carl-Uno At 09:08 PM 4/15/98 PDT, Turner, Randy wrote: > >There is nothing in the existing encoding that allows a particular IPP >message to be "fragmented" across multiple transport "packets". The >encoding requires that a transport protocol provide some way to >logically "connect" one message to another contiguously received >message. In HTTP, this is accomplished with HTTP 1.1 chunking. With >another transport, there would have to some equivalent capability. I'm >not sure if I've adequately described the situation. Anything further I >think would require me to draw a picture. > >Randy > > > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, April 15, 1998 9:22 AM > To: ipp@pwg.org > Subject: IPP> IPP, independently of HTTP, Requires >Chunking ? Was: Mi > > > The concrete transport/encoding IPP protocol document is VERY >dependent > > on HTTP chunking. > > I still don't get it. Could you please explain? > > The original statement is: > > Encoding is HTTP independent except for chinking. > > This sentence, to me, implies that there is some aspect of the >IPP encoding, > apart from HTTP, that depends on chunking. This is suprising >news to me. > > The only chunking-related requirements I've found in the >Protocol document are: > 1) the Server must support "chunked" Transfer-Encoding of >Requests > 2) the Client must support "chunked" Responses. > These requirements derive directly from RFC 2068: "All HTTP/1.1 >applications > MUST be able to receive and decode the "chunked" transfer >coding..." > > > Confused in Boulder, > > Carl-III > > > > ipp-owner@pwg.org on 04/14/98 05:34:03 PM > Please respond to ipp-owner@pwg.org > To: ipp@pwg.org > cc: > Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - >Apri > > > > The abstract IPP described in the model document is not >dependent on > HTTP chunking. > > The concrete transport/encoding IPP protocol document is VERY >dependent > on HTTP chunking. > > Randy > > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Tuesday, April 14, 1998 4:25 PM > To: ipp@pwg.org > Subject: Re: IPP> Minutes from PWG IPP Meeting in > Portland, OR - Apri > > > IPP is not transport neutral. Encoding is HTTP independent > except for > > chinking. > > I assume you mean "chunking". In what way is IPP dependent on > HTTP chunking? > > -Carl > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Apr 16 16:20:34 1998 Delivery-Date: Thu, 16 Apr 1998 16:20:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA06486 for ; Thu, 16 Apr 1998 16:20:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA17825 for ; Thu, 16 Apr 1998 15:50:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29867 for ; Thu, 16 Apr 1998 15:48:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 15:42:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29261 for ipp-outgoing; Thu, 16 Apr 1998 15:42:08 -0400 (EDT) Message-Id: <199804161938.MAA07985@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 16 Apr 1998 12:40:52 -0700 To: Harry Lewis , From: Robert Herriot Subject: Re: IPP> Charter eyeglasses Cc: , In-Reply-To: <5030300020064267000002L072*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id QAA06486 I agree with Scott's interpretation. I think we chartered IPP to solve communication among clients, servers and printers, not just between end users and print servers. I am concerned that SDP is a big mistake and will create yet another protocol, incompatible with all others including IPP. I think that it is reasonable to borrow ideas from other protocols, such as TIPSI, but I think we should continue along the IPP path we started. If IPP is not a reasonable embedded solution, I wonder why we are just now hearing that, nearly a year after we decided on the encoding. If IPP is really such a bad embedded solution, perhaps we should fix it before we all commit to supporting it and end up with support for both IPP and SDP. Bob Herriot At 07:04 AM 4/16/98 , Harry Lewis wrote: >Scott, I agree with your interpretation 100% and believe this is the only valid >interpretation. Otherwise, I think the overall charter would have been way too >limiting - even if this is where we ended up for v1. I put the emphasis there >to show how I think some must be reading the charter and the conclusions they >must have made. > >Harry Lewis - IBM Printing Systems > > > > >SISAACSON@novell.com on 04/15/98 08:15:10 PM >Please respond to SISAACSON@novell.com >To: Harry Lewis/Boulder/IBM@ibmus, sdp@pwg.org, ipp@pwg.org >cc: >Subject: Re: IPP> Charter eyeglasses > > >Harry, > >When I read: > >>>> Harry Lewis 04/15/98 04:24PM >>> >>The Internet Print Protocol is a CLIENT-SERVER type protocol which >>should allow the server side to be either a separate print server or >>a printer with embedded networking capabilities. > >I assume CLIENT/SERVER in the distributed systems architecture sense >NOT in the literal CLIENT = PC and SERVER = file server/printer server hardware >box sense.  I see client/server meaning request/response rather than distribute >object >remote methods, IIOP, RMI stuff. > >In other workds, I am not confused into thinking end-user to file server only >(not server >to device) when I see the term "client/server" > >Good reading of the charter thought, very helpful. > >Scott > From ipp-owner@pwg.org Thu Apr 16 23:37:38 1998 Delivery-Date: Thu, 16 Apr 1998 23:37:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA19372 for ; Thu, 16 Apr 1998 23:37:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19513 for ; Thu, 16 Apr 1998 23:40:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA02240 for ; Thu, 16 Apr 1998 23:37:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Apr 1998 23:32:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA01682 for ipp-outgoing; Thu, 16 Apr 1998 23:30:38 -0400 (EDT) Message-Id: <199804170324.UAA08304@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 16 Apr 1998 20:26:52 -0700 To: Carl-Uno Manros , "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi In-Reply-To: <3.0.1.32.19980416123114.00c8e5b0@garfield> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id XAA19372 Are you sure about #4 below? It doesn't sound right at all. My understanding of chunking is that it allows the sender to omit Content-Length and to instead supply length one chunk at a time. At the HTTP layer, the document is a series of chunks terminated by a zero length chunk. Bob Herriot At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. > >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. > >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. > >Did I get this right? > >Carl-Uno > >At 09:08 PM 4/15/98 PDT, Turner, Randy wrote: >> >>There is nothing in the existing encoding that allows a particular IPP >>message to be "fragmented" across multiple transport "packets".  The >>encoding requires that a transport protocol provide some way to >>logically "connect" one message to another contiguously received >>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With >>another transport, there would have to some equivalent capability. I'm >>not sure if I've adequately described the situation. Anything further I >>think would require me to draw a picture. >> >>Randy >> >> >> -----Original Message----- >> From: Carl Kugler [SMTP:kugler@us.ibm.com] >> Sent: Wednesday, April 15, 1998 9:22 AM >> To: ipp@pwg.org >> Subject: IPP> IPP, independently of HTTP, Requires >>Chunking ? Was: Mi >> >> > The concrete transport/encoding IPP protocol document is VERY >>dependent >> > on HTTP chunking. >> >> I still don't get it.  Could you please explain? >> >> The original statement is: >> > Encoding is HTTP independent except for chinking. >> >> This sentence, to me, implies that there is some aspect of the >>IPP encoding, >> apart from HTTP, that depends on chunking.  This is suprising >>news to me. >> >> The only chunking-related requirements I've found in the >>Protocol document are: >> 1) the Server must support "chunked" Transfer-Encoding of >>Requests >> 2) the Client must support "chunked" Responses. >> These requirements derive directly from RFC 2068:  "All HTTP/1.1 >>applications >> MUST be able to receive and decode the "chunked" transfer >>coding..." >> >> >> Confused in Boulder, >> >>   Carl-III >> >> >> >> ipp-owner@pwg.org on 04/14/98 05:34:03 PM >> Please respond to ipp-owner@pwg.org >> To: ipp@pwg.org >> cc: >> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - >>Apri >> >> >> >> The abstract IPP described in the model document is not >>dependent on >> HTTP chunking. >> >> The concrete transport/encoding IPP protocol document is VERY >>dependent >> on HTTP chunking. >> >> Randy >> >> -----Original Message----- >> From: Carl Kugler [SMTP:kugler@us.ibm.com] >> Sent: Tuesday, April 14, 1998 4:25 PM >> To: ipp@pwg.org >> Subject: Re: IPP> Minutes from PWG IPP Meeting in >> Portland, OR - Apri >> >> > IPP is not transport neutral. Encoding is HTTP independent >> except for >> > chinking. >> >> I assume you mean "chunking".  In what way is IPP dependent on >> HTTP chunking? >> >>   -Carl >> >> >> >> >> >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Fri Apr 17 03:29:14 1998 Delivery-Date: Fri, 17 Apr 1998 03:29:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id DAA26747 for ; Fri, 17 Apr 1998 03:29:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA19993 for ; Fri, 17 Apr 1998 03:31:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA08380 for ; Fri, 17 Apr 1998 03:29:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 03:22:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA07290 for ipp-outgoing; Fri, 17 Apr 1998 03:20:25 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 17 Apr 1998 01:16:37 -0600 From: "Scott Isaacson" To: robert.herriot@Eng.Sun.COM, harryl@us.ibm.com Cc: ipp@pwg.org, sdp@pwg.org Subject: Re: IPP> Charter eyeglasses Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id DAA26747 Thanks to Bob and Harry for these very reasonable, rationale points. My comments below are just 100% percent endorsements of their comments. >>> Robert Herriot 04/16/98 01:40PM >>> > I agree with Scott's interpretation. I think we chartered IPP to solve > communication among clients, servers and printers, not just between end > users and print servers. > I am concerned that SDP is a big mistake and will create yet another > protocol, incompatible with all others including IPP. I think that it is > reasonable to borrow ideas from other protocols, such as TIPSI, but I think > we should continue along the IPP path we started. SDP is a big mistake if it is not IPP with enhancements or it is not the ALREADY STANDARD SDP: TIPSI. If neither IPP nor TIPSI could not be enahanced to meet whatever the needs of a server to device protocol, then what makes someone thing that they can get a group of company reps together, start from scratch, and get it right?! given that is what we have done several times now. > If IPP is not a reasonable embedded solution, I wonder why we are just now > hearing that, nearly a year after we decided on the encoding. If IPP is > really such a bad embedded solution, perhaps we should fix it before we all > commit to supporting it and end up with support for both IPP and SDP. I feel that it is a reasonable embedded solution. Any "fixes" are just part of the process now to move IPP/1.0 to 1.1 and beyond. From ipp-owner@pwg.org Fri Apr 17 08:01:48 1998 Delivery-Date: Fri, 17 Apr 1998 08:01:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA29422 for ; Fri, 17 Apr 1998 08:01:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA20327 for ; Fri, 17 Apr 1998 08:04:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA14626 for ; Fri, 17 Apr 1998 08:01:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 07:52:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA13956 for ipp-outgoing; Fri, 17 Apr 1998 07:48:59 -0400 (EDT) Content-return: allowed Date: Fri, 17 Apr 1998 04:48:48 PDT From: "Zehler, Peter " Subject: RE: IPP> Charter eyeglasses To: ipp@pwg.org Cc: sdp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id IAA29422 All, I also believe it would be a mistake to create yet another protocol for printing. Some issues have been identified as shortcomings in the current IPP mapping. Those issues should be addressed. There are, of course, a number of ways to address them. We also have need of a richer printer model as we move IPP forward to monitor and control a print device. We already have a widely deployed model, the printer MIB. I do not believe IPP is unreasonable to embed in a device. We should keep the mandatory features focused on basic needs. This approach allows the model and protocol to scale. As of yet I have no trouble implementing IPP in a lower end device. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Thursday, April 16, 1998 3:41 PM To: Harry Lewis; SISAACSON@novell.com Cc: ipp@pwg.org; sdp@pwg.org Subject: Re: IPP> Charter eyeglasses I agree with Scott's interpretation. I think we chartered IPP to solve communication among clients, servers and printers, not just between end users and print servers. I am concerned that SDP is a big mistake and will create yet another protocol, incompatible with all others including IPP. I think that it is reasonable to borrow ideas from other protocols, such as TIPSI, but I think we should continue along the IPP path we started. If IPP is not a reasonable embedded solution, I wonder why we are just now hearing that, nearly a year after we decided on the encoding. If IPP is really such a bad embedded solution, perhaps we should fix it before we all commit to supporting it and end up with support for both IPP and SDP. Bob Herriot At 07:04 AM 4/16/98 , Harry Lewis wrote: >Scott, I agree with your interpretation 100% and believe this is the only valid >interpretation. Otherwise, I think the overall charter would have been way too >limiting - even if this is where we ended up for v1. I put the emphasis there >to show how I think some must be reading the charter and the conclusions they >must have made. > >Harry Lewis - IBM Printing Systems > > > > >SISAACSON@novell.com on 04/15/98 08:15:10 PM >Please respond to SISAACSON@novell.com >To: Harry Lewis/Boulder/IBM@ibmus, sdp@pwg.org, ipp@pwg.org >cc: >Subject: Re: IPP> Charter eyeglasses > > >Harry, > >When I read: > >>>> Harry Lewis 04/15/98 04:24PM >>> >>The Internet Print Protocol is a CLIENT-SERVER type protocol which >>should allow the server side to be either a separate print server or >>a printer with embedded networking capabilities. > >I assume CLIENT/SERVER in the distributed systems architecture sense >NOT in the literal CLIENT = PC and SERVER = file server/printer server hardware >box sense.  I see client/server meaning request/response rather than distribute >object >remote methods, IIOP, RMI stuff. > >In other workds, I am not confused into thinking end-user to file server only >(not server >to device) when I see the term "client/server" > >Good reading of the charter thought, very helpful. > >Scott > From ipp-owner@pwg.org Fri Apr 17 09:47:11 1998 Delivery-Date: Fri, 17 Apr 1998 09:47:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA00621 for ; Fri, 17 Apr 1998 09:47:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA20653 for ; Fri, 17 Apr 1998 09:49:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA15313 for ; Fri, 17 Apr 1998 09:46:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 09:42:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14786 for ipp-outgoing; Fri, 17 Apr 1998 09:40:36 -0400 (EDT) Content-return: allowed Date: Fri, 17 Apr 1998 06:23:10 PDT From: "Caruso, Angelo " Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi To: "'ipp@pwg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA00621 My understanding is that chunking offers a major performance enhancement. With chunking, the driver can send the PDL stream directly to the device, in chunks, as it is being generated. Without chunking, the driver needs to buffer the entire PDL stream on the local HD because it must determine the total size before sending. Thanks, Angelo -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Thursday, April 16, 1998 11:27 PM To: Carl-Uno Manros; Turner, Randy; 'ipp@pwg.org' Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Are you sure about #4 below? It doesn't sound right at all. My understanding of chunking is that it allows the sender to omit Content-Length and to instead supply length one chunk at a time. At the HTTP layer, the document is a series of chunks terminated by a zero length chunk. Bob Herriot At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. > >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. > >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. > >Did I get this right? > >Carl-Uno > >At 09:08 PM 4/15/98 PDT, Turner, Randy wrote: >> >>There is nothing in the existing encoding that allows a particular IPP >>message to be "fragmented" across multiple transport "packets".  The >>encoding requires that a transport protocol provide some way to >>logically "connect" one message to another contiguously received >>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With >>another transport, there would have to some equivalent capability. I'm >>not sure if I've adequately described the situation. Anything further I >>think would require me to draw a picture. >> >>Randy >> >> >> -----Original Message----- >> From: Carl Kugler [SMTP:kugler@us.ibm.com] >> Sent: Wednesday, April 15, 1998 9:22 AM >> To: ipp@pwg.org >> Subject: IPP> IPP, independently of HTTP, Requires >>Chunking ? Was: Mi >> >> > The concrete transport/encoding IPP protocol document is VERY >>dependent >> > on HTTP chunking. >> >> I still don't get it.  Could you please explain? >> >> The original statement is: >> > Encoding is HTTP independent except for chinking. >> >> This sentence, to me, implies that there is some aspect of the >>IPP encoding, >> apart from HTTP, that depends on chunking.  This is suprising >>news to me. >> >> The only chunking-related requirements I've found in the >>Protocol document are: >> 1) the Server must support "chunked" Transfer-Encoding of >>Requests >> 2) the Client must support "chunked" Responses. >> These requirements derive directly from RFC 2068:  "All HTTP/1.1 >>applications >> MUST be able to receive and decode the "chunked" transfer >>coding..." >> >> >> Confused in Boulder, >> >>   Carl-III >> >> >> >> ipp-owner@pwg.org on 04/14/98 05:34:03 PM >> Please respond to ipp-owner@pwg.org >> To: ipp@pwg.org >> cc: >> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - >>Apri >> >> >> >> The abstract IPP described in the model document is not >>dependent on >> HTTP chunking. >> >> The concrete transport/encoding IPP protocol document is VERY >>dependent >> on HTTP chunking. >> >> Randy >> >> -----Original Message----- >> From: Carl Kugler [SMTP:kugler@us.ibm.com] >> Sent: Tuesday, April 14, 1998 4:25 PM >> To: ipp@pwg.org >> Subject: Re: IPP> Minutes from PWG IPP Meeting in >> Portland, OR - Apri >> >> > IPP is not transport neutral. Encoding is HTTP independent >> except for >> > chinking. >> >> I assume you mean "chunking".  In what way is IPP dependent on >> HTTP chunking? >> >>   -Carl >> >> >> >> >> >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Fri Apr 17 10:06:54 1998 Delivery-Date: Fri, 17 Apr 1998 10:06:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA00881 for ; Fri, 17 Apr 1998 10:06:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA20727 for ; Fri, 17 Apr 1998 10:09:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15945 for ; Fri, 17 Apr 1998 10:06:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 10:02:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15412 for ipp-outgoing; Fri, 17 Apr 1998 10:01:53 -0400 (EDT) X-Sender: bva@pop.ma.ultranet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Apr 1998 10:01:02 -0400 To: ipp@pwg.org From: Bob Van Andel Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? Cc: Sender: owner-ipp@pwg.org All, Here is my understanding of what we are seeing in testing. (Peter, please correct me if I'm wrong). IPP is a request-response protocol that sits on top of HTTP (a request-response protocol) that sits on top of TCP (a connection protocol). TCP provides the end-to-end message integrity including packet retries for lost or mis-ordered transmissions. HTTP 1.0 uses a single TCP connection for each request-response transaction. In many cases, this is because the only way to signal the end-of-data is by closing the connection. (HTTP 1.0 is described in the Informational RFC 1945) HTTP 1.1 provides persistent connections (connections that stay intact for multiple request-response transactions for the same client-server). The technique for signalling end-of-data for objects whose length may not be known at the beginning of the transmission is chunked encoding. In HTTP 1.1, you may still signal end-of-data by closing the connection, but this is not recommended, since you will then lose the benefits of the persistent connection. (HTTP 1.1 is currently described in the Standards Track RFC 2068, but there will be a new RFC shortly reflecting implementation experience) At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. Yes, but all transactions do not need to use chunked encoding. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. > All transactions may use chunked encoding in either direction. The requesting client determines whether to use it for POST or PUT requests, and the responding server determines whether to use it for responses. >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. Strictly speaking, this is not a requirement, in that the client could close the connection to signal end-of-data. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. This is not correct. Lower layer transmission errors will be handled at the TCP layer regardless of whether chunked encoding is used. > >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. > Our current implementation of IPP transaction support requires that HTTP 1.1 support be turned on. In practice, Peter overrode this constraint and is successfully running IPP over HTTP 1.0 regardless of whether job size is known at the beginning. Bob ---------------------------------------- Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Information on the RomPager embedded web server toolkit is at From ipp-owner@pwg.org Fri Apr 17 10:31:39 1998 Delivery-Date: Fri, 17 Apr 1998 10:31:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA01495 for ; Fri, 17 Apr 1998 10:31:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA20870 for ; Fri, 17 Apr 1998 10:34:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA16574 for ; Fri, 17 Apr 1998 10:31:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 10:27:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16044 for ipp-outgoing; Fri, 17 Apr 1998 10:25:16 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? Date: Fri, 17 Apr 1998 07:25:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org One caveat with Bob's text. I am seeing that some HTTP 1.1 servers do not recognize chunked encodings for PUT operations. Aside from that, this is a pretty complete description of how transactions are occuring with IPP over HTTP. Randy > -----Original Message----- > From: Bob Van Andel [SMTP:bva@allegrosoft.com] > Sent: Friday, April 17, 1998 7:01 AM > To: ipp@pwg.org > Cc: Peter.Zehler@usa.xerox.com > Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? > > All, > > Here is my understanding of what we are seeing in testing. (Peter, > please > correct me if I'm wrong). > > IPP is a request-response protocol that sits on top of HTTP (a > request-response protocol) that sits on top of TCP (a connection > protocol). > > TCP provides the end-to-end message integrity including packet retries > for > lost or mis-ordered transmissions. > > HTTP 1.0 uses a single TCP connection for each request-response > transaction. In many cases, this is because the only way to signal > the > end-of-data is by closing the connection. (HTTP 1.0 is described in > the > Informational RFC 1945) > > HTTP 1.1 provides persistent connections (connections that stay intact > for > multiple request-response transactions for the same client-server). > The > technique for signalling end-of-data for objects whose length may not > be > known at the beginning of the transmission is chunked encoding. In > HTTP > 1.1, you may still signal end-of-data by closing the connection, but > this > is not recommended, since you will then lose the benefits of the > persistent > connection. (HTTP 1.1 is currently described in the Standards Track > RFC > 2068, but there will be a new RFC shortly reflecting implementation > experience) > > > At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: > >Randy et al., > > > >Here is my take on the use of chunking for IPP: > > > >1) Each HTTP 1.1 implementation is mandated to support chunking. > > Yes, but all transactions do not need to use chunked encoding. > > > > >2) All POSTs are initiated by the client, which I assume also means > that > >the client determines whether to use chunking for a particular HTTP > request. > > > > All transactions may use chunked encoding in either direction. The > requesting client determines whether to use it for POST or PUT > requests, > and the responding server determines whether to use it for responses. > > >3) The only situation where chunking is absolutely necessary for IPP, > is > >the case where the client does not know the document length when it > starts > >sending the document. > > Strictly speaking, this is not a requirement, in that the client could > close the connection to signal end-of-data. > > > > >4) With the exception of the situation in 3) the client can always > decide > >not to use chunking, but send even long documents in one request. The > >downside of doing that is that if something goes wrong on the lower > >protocol layers, the client has to start over and send the whole > document > >again from the beginning. The main advantage of using chunking is > that if > >you get an error on the lower layers, you only have to resend the > latest > >chunk, not the whole document. > > This is not correct. Lower layer transmission errors will be handled > at > the TCP layer regardless of whether chunked encoding is used. > > > > >5) Again, with the exception of the case in 3), you can in practise > >actually use HTTP 1.0, which does not support chunking, for most of > your > >IPP transfers. > > > > Our current implementation of IPP transaction support requires that > HTTP > 1.1 support be turned on. In practice, Peter overrode this constraint > and > is successfully running IPP over HTTP 1.0 regardless of whether job > size is > known at the beginning. > > Bob > > > > ---------------------------------------- > Bob Van Andel > Allegro Software Development Corporation > 43 Waite Road > Boxborough, MA 01719 > (978) 266-1375 > (978) 266-2839 fax > > Information on the RomPager embedded web server toolkit is at > > From ipp-owner@pwg.org Fri Apr 17 10:51:36 1998 Delivery-Date: Fri, 17 Apr 1998 10:51:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA01900 for ; Fri, 17 Apr 1998 10:51:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA21003 for ; Fri, 17 Apr 1998 10:54:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA17196 for ; Fri, 17 Apr 1998 10:51:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 10:47:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16666 for ipp-outgoing; Fri, 17 Apr 1998 10:45:11 -0400 (EDT) Date: Fri, 17 Apr 1998 10:45:08 -0400 (EDT) From: Scott Lawrence Reply-To: Scott Lawrence To: "Turner, Randy" cc: ipp@pwg.org Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org > One caveat with Bob's text. I am seeing that some HTTP 1.1 servers do > not recognize chunked encodings for PUT operations. Aside from that, > this is a pretty complete description of how transactions are occuring > with IPP over HTTP. That is just a bug is the server - receiving chunked encoding is a MUST for any 1.1 implementation. > > >3) The only situation where chunking is absolutely necessary for IPP, > > is > > >the case where the client does not know the document length when it > > starts > > >sending the document. > > > > Strictly speaking, this is not a requirement, in that the client could > > close the connection to signal end-of-data. That doesn't work for a request because then there is no connection on which to send the response. From ipp-owner@pwg.org Fri Apr 17 11:32:18 1998 Delivery-Date: Fri, 17 Apr 1998 11:32:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA03438 for ; Fri, 17 Apr 1998 11:32:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21205 for ; Fri, 17 Apr 1998 11:34:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17828 for ; Fri, 17 Apr 1998 11:32:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 11:27:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17304 for ipp-outgoing; Fri, 17 Apr 1998 11:25:32 -0400 (EDT) Message-Id: <3.0.1.32.19980417081138.009a8be0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Apr 1998 08:11:38 PDT To: Robert Herriot From: Carl-Uno Manros Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Cc: ipp@pwg.org In-Reply-To: <199804170324.UAA08304@woden.eng.sun.com> References: <3.0.1.32.19980416123114.00c8e5b0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA03438 At 08:26 PM 4/16/98 PDT, you wrote: >Are you sure about #4 below? It doesn't sound right at all. My >understanding of chunking is that it allows the sender to omit >Content-Length and to instead supply length one chunk at a time. At >the HTTP layer, the document is a series of chunks terminated by a zero >length chunk. > > >Bob Herriot > And how is that in conflict with what I stated in 4)? Carl-Uno >At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: >>Randy et al., >> >>Here is my take on the use of chunking for IPP: >> >>1) Each HTTP 1.1 implementation is mandated to support chunking. >> >>2) All POSTs are initiated by the client, which I assume also means that >>the client determines whether to use chunking for a particular HTTP request. >> >>3) The only situation where chunking is absolutely necessary for IPP, is >>the case where the client does not know the document length when it starts >>sending the document. >> >>4) With the exception of the situation in 3) the client can always decide >>not to use chunking, but send even long documents in one request. The >>downside of doing that is that if something goes wrong on the lower >>protocol layers, the client has to start over and send the whole document >>again from the beginning. The main advantage of using chunking is that if >>you get an error on the lower layers, you only have to resend the latest >>chunk, not the whole document. >> >>5) Again, with the exception of the case in 3), you can in practise >>actually use HTTP 1.0, which does not support chunking, for most of your >>IPP transfers. >> >>Did I get this right? >> >>Carl-Uno >> >>At 09:08 PM 4/15/98 PDT, Turner, Randy wrote: >>> >>>There is nothing in the existing encoding that allows a particular IPP >>>message to be "fragmented" across multiple transport "packets".  The >>>encoding requires that a transport protocol provide some way to >>>logically "connect" one message to another contiguously received >>>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With >>>another transport, there would have to some equivalent capability. I'm >>>not sure if I've adequately described the situation. Anything further I >>>think would require me to draw a picture. >>> >>>Randy >>> >>> >>> -----Original Message----- >>> From: Carl Kugler [SMTP:kugler@us.ibm.com] >>> Sent: Wednesday, April 15, 1998 9:22 AM >>> To: ipp@pwg.org >>> Subject: IPP> IPP, independently of HTTP, Requires >>>Chunking ? Was: Mi >>> >>> > The concrete transport/encoding IPP protocol document is VERY >>>dependent >>> > on HTTP chunking. >>> >>> I still don't get it.  Could you please explain? >>> >>> The original statement is: >>> > Encoding is HTTP independent except for chinking. >>> >>> This sentence, to me, implies that there is some aspect of the >>>IPP encoding, >>> apart from HTTP, that depends on chunking.  This is suprising >>>news to me. >>> >>> The only chunking-related requirements I've found in the >>>Protocol document are: >>> 1) the Server must support "chunked" Transfer-Encoding of >>>Requests >>> 2) the Client must support "chunked" Responses. >>> These requirements derive directly from RFC 2068:  "All HTTP/1.1 >>>applications >>> MUST be able to receive and decode the "chunked" transfer >>>coding..." >>> >>> >>> Confused in Boulder, >>> >>>   Carl-III >>> >>> >>> >>> ipp-owner@pwg.org on 04/14/98 05:34:03 PM >>> Please respond to ipp-owner@pwg.org >>> To: ipp@pwg.org >>> cc: >>> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - >>>Apri >>> >>> >>> >>> The abstract IPP described in the model document is not >>>dependent on >>> HTTP chunking. >>> >>> The concrete transport/encoding IPP protocol document is VERY >>>dependent >>> on HTTP chunking. >>> >>> Randy >>> >>> -----Original Message----- >>> From: Carl Kugler [SMTP:kugler@us.ibm.com] >>> Sent: Tuesday, April 14, 1998 4:25 PM >>> To: ipp@pwg.org >>> Subject: Re: IPP> Minutes from PWG IPP Meeting in >>> Portland, OR - Apri >>> >>> > IPP is not transport neutral. Encoding is HTTP independent >>> except for >>> > chinking. >>> >>> I assume you mean "chunking".  In what way is IPP dependent on >>> HTTP chunking? >>> >>>   -Carl >>> >>> >>> >>> >>> >>Carl-Uno Manros >>Principal Engineer - Advanced Printing Standards - Xerox Corporation >>701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >>Phone +1-310-333 8273, Fax +1-310-333 5514 >>Email: manros@cp10.es.xerox.com >> > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Apr 17 13:01:01 1998 Delivery-Date: Fri, 17 Apr 1998 13:01:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05567 for ; Fri, 17 Apr 1998 13:00:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21571 for ; Fri, 17 Apr 1998 13:03:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18513 for ; Fri, 17 Apr 1998 13:00:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 12:52:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17975 for ipp-outgoing; Fri, 17 Apr 1998 12:49:46 -0400 (EDT) X-Sender: bva@pop.ma.ultranet.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Apr 1998 12:45:54 -0400 To: Scott Lawrence From: Bob Van Andel Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? Cc: ipp@pwg.org Sender: owner-ipp@pwg.org > >> > >3) The only situation where chunking is absolutely necessary for IPP, >> > is >> > >the case where the client does not know the document length when it >> > starts >> > >sending the document. >> > >> > Strictly speaking, this is not a requirement, in that the client could >> > close the connection to signal end-of-data. > > That doesn't work for a request because then there is no connection on >which to send the response. That would be the "no response required" mode of operation. :.) ---------------------------------------- Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Information on the RomPager embedded web server toolkit is at From ipp-owner@pwg.org Fri Apr 17 13:10:34 1998 Delivery-Date: Fri, 17 Apr 1998 13:10:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05944 for ; Fri, 17 Apr 1998 13:10:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21638 for ; Fri, 17 Apr 1998 13:13:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19122 for ; Fri, 17 Apr 1998 13:10:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 13:02:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18535 for ipp-outgoing; Fri, 17 Apr 1998 13:01:01 -0400 (EDT) Content-return: allowed Date: Fri, 17 Apr 1998 07:45:31 PDT From: "Zehler, Peter " Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? To: ipp@pwg.org Cc: Bob Van Andel Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org All, Regarding IPP testing experience with chunking/IPP. I have not yet seen anyone that has tried this. The tests I have been involved in, up to very recently, used HTTP 1.0. This was due to the limitations of JDK. I have not yet pursued the added complexity of chunking. This is a function of IPP's underlying transport(HTTP 1.1). I have been concentrating on the IPP PAD and method invocation. I would love to hear anyone with some concrete experience with IPP and chunking. The interoperability test plans calls for a print submission with and without the client chunking its request. I had not thought of the server chunking its reply. Should this be added to the "top 25" IPP tests? I do not see where IPP requires chunking. I believe it currently is a requirement of IPP's protocol mapping to handle the situation where the size of the request/response is not known until the end. HTTP solved this by chunking data. If IPP were mapped to another protocol we would depend on the new protocol's method to handle this problem or pull the solution for the problem up into the IPP layer. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Bob Van Andel [SMTP:bva@allegrosoft.com] Sent: Friday, April 17, 1998 10:01 AM To: ipp@pwg.org Cc: Peter.Zehler@usa.xerox.com Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? All, Here is my understanding of what we are seeing in testing. (Peter, please correct me if I'm wrong). IPP is a request-response protocol that sits on top of HTTP (a request-response protocol) that sits on top of TCP (a connection protocol). TCP provides the end-to-end message integrity including packet retries for lost or mis-ordered transmissions. HTTP 1.0 uses a single TCP connection for each request-response transaction. In many cases, this is because the only way to signal the end-of-data is by closing the connection. (HTTP 1.0 is described in the Informational RFC 1945) HTTP 1.1 provides persistent connections (connections that stay intact for multiple request-response transactions for the same client-server). The technique for signalling end-of-data for objects whose length may not be known at the beginning of the transmission is chunked encoding. In HTTP 1.1, you may still signal end-of-data by closing the connection, but this is not recommended, since you will then lose the benefits of the persistent connection. (HTTP 1.1 is currently described in the Standards Track RFC 2068, but there will be a new RFC shortly reflecting implementation experience) At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. Yes, but all transactions do not need to use chunked encoding. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. > All transactions may use chunked encoding in either direction. The requesting client determines whether to use it for POST or PUT requests, and the responding server determines whether to use it for responses. >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. Strictly speaking, this is not a requirement, in that the client could close the connection to signal end-of-data. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. This is not correct. Lower layer transmission errors will be handled at the TCP layer regardless of whether chunked encoding is used. > >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. > Our current implementation of IPP transaction support requires that HTTP 1.1 support be turned on. In practice, Peter overrode this constraint and is successfully running IPP over HTTP 1.0 regardless of whether job size is known at the beginning. Bob ---------------------------------------- Bob Van Andel Allegro Software Development Corporation 43 Waite Road Boxborough, MA 01719 (978) 266-1375 (978) 266-2839 fax Information on the RomPager embedded web server toolkit is at From jmp-owner@pwg.org Fri Apr 17 14:00:07 1998 Delivery-Date: Fri, 17 Apr 1998 14:00:07 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06775 for ; Fri, 17 Apr 1998 14:00:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21937 for ; Fri, 17 Apr 1998 14:02:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19885 for ; Fri, 17 Apr 1998 13:59:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 13:56:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19241 for jmp-outgoing; Fri, 17 Apr 1998 13:52:37 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'pmp@pwg.org'" , "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: JMP> FW: I-D ACTION:draft-skreddy-enpreq-00.txt Date: Fri, 17 Apr 1998 10:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD6A29.BADD2360" Sender: jmp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD6A29.BADD2360 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Friday, April 17, 1998 7:28 AM Subject: I-D ACTION:draft-skreddy-enpreq-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Event Notification Protocol Author(s) : S. Reddy Filename : draft-skreddy-enpreq-00.txt Pages : 6 Date : 16-Apr-98 This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. 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-skreddy-enpreq-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-skreddy-enpreq-00.txt". NOTE: The mail server at ietf.org 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_000_01BD6A29.BADD2360 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Fri, 17 Apr 1998 10:53:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BD6A29.BADD2360" ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: text/plain ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: application/octet-stream; name="ATT03355.txt" Content-Disposition: attachment; filename="ATT03355.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980416102106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-skreddy-enpreq-00.txt ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: message/external-body; site="internet-drafts"; dir="draft-skreddy-enpreq-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BD6A29.BADD2360-- ------ =_NextPart_000_01BD6A29.BADD2360-- From pmp-owner@pwg.org Fri Apr 17 14:00:38 1998 Delivery-Date: Fri, 17 Apr 1998 14:00:38 -0400 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06797 for ; Fri, 17 Apr 1998 14:00:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21940 for ; Fri, 17 Apr 1998 14:03:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA19970 for ; Fri, 17 Apr 1998 14:00:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 13:57:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19228 for pmp-outgoing; Fri, 17 Apr 1998 13:52:28 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'pmp@pwg.org'" , "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: PMP> FW: I-D ACTION:draft-skreddy-enpreq-00.txt Date: Fri, 17 Apr 1998 10:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD6A29.BADD2360" Sender: pmp-owner@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD6A29.BADD2360 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Friday, April 17, 1998 7:28 AM Subject: I-D ACTION:draft-skreddy-enpreq-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Event Notification Protocol Author(s) : S. Reddy Filename : draft-skreddy-enpreq-00.txt Pages : 6 Date : 16-Apr-98 This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. 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-skreddy-enpreq-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-skreddy-enpreq-00.txt". NOTE: The mail server at ietf.org 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_000_01BD6A29.BADD2360 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Fri, 17 Apr 1998 10:53:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BD6A29.BADD2360" ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: text/plain ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: application/octet-stream; name="ATT03355.txt" Content-Disposition: attachment; filename="ATT03355.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980416102106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-skreddy-enpreq-00.txt ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: message/external-body; site="internet-drafts"; dir="draft-skreddy-enpreq-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BD6A29.BADD2360-- ------ =_NextPart_000_01BD6A29.BADD2360-- From ipp-owner@pwg.org Fri Apr 17 14:02:35 1998 Delivery-Date: Fri, 17 Apr 1998 14:02:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06835 for ; Fri, 17 Apr 1998 14:02:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21949 for ; Fri, 17 Apr 1998 14:05:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20209 for ; Fri, 17 Apr 1998 14:02:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 13:53:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19221 for ipp-outgoing; Fri, 17 Apr 1998 13:52:24 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'pmp@pwg.org'" , "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: FW: I-D ACTION:draft-skreddy-enpreq-00.txt Date: Fri, 17 Apr 1998 10:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD6A29.BADD2360" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD6A29.BADD2360 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Friday, April 17, 1998 7:28 AM Subject: I-D ACTION:draft-skreddy-enpreq-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Event Notification Protocol Author(s) : S. Reddy Filename : draft-skreddy-enpreq-00.txt Pages : 6 Date : 16-Apr-98 This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. 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-skreddy-enpreq-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-skreddy-enpreq-00.txt". NOTE: The mail server at ietf.org 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_000_01BD6A29.BADD2360 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Fri, 17 Apr 1998 10:53:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BD6A29.BADD2360" ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: text/plain ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: application/octet-stream; name="ATT03355.txt" Content-Disposition: attachment; filename="ATT03355.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980416102106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-skreddy-enpreq-00.txt ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: message/external-body; site="internet-drafts"; dir="draft-skreddy-enpreq-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BD6A29.BADD2360-- ------ =_NextPart_000_01BD6A29.BADD2360-- From ipp-owner@pwg.org Fri Apr 17 14:27:05 1998 Delivery-Date: Fri, 17 Apr 1998 14:27:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07440 for ; Fri, 17 Apr 1998 14:27:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22076 for ; Fri, 17 Apr 1998 14:29:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20870 for ; Fri, 17 Apr 1998 14:26:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Apr 1998 14:22:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20345 for ipp-outgoing; Fri, 17 Apr 1998 14:21:11 -0400 (EDT) Message-Id: <3.0.1.32.19980417104439.0098e580@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Apr 1998 10:44:39 PDT To: ipp@pwg.org From: Internet-Drafts@ns.ietf.org (by way of Carl-Uno Manros ) Subject: IPP> I-D ACTION:draft-skreddy-enpreq-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The following new I-D is addressing requirements for Notifications. It seems to reflect the needs of the WebDAV group, but we might be able to pick up a few useful ideas for IPP. Carl-Uno --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Event Notification Protocol Author(s) : S. Reddy Filename : draft-skreddy-enpreq-00.txt Pages : 6 Date : 16-Apr-98 This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. 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-skreddy-enpreq-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-skreddy-enpreq-00.txt". NOTE: The mail server at ietf.org 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. From ipp-owner@pwg.org Sun Apr 19 15:04:00 1998 Delivery-Date: Sun, 19 Apr 1998 15:04:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA10163 for ; Sun, 19 Apr 1998 15:03:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00867 for ; Sun, 19 Apr 1998 15:06:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14256 for ; Sun, 19 Apr 1998 15:03:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 19 Apr 1998 14:53:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13692 for ipp-outgoing; Sun, 19 Apr 1998 14:50:22 -0400 (EDT) Message-Id: <3.0.1.32.19980419114722.0126cb40@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 19 Apr 1998 11:47:22 PDT To: Carl Kugler , From: Tom Hastings Subject: Re: IPP> IPP: Job template attributes In-Reply-To: <5030100019191211000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I agree with Carl Kugler's understanding of IPP in his response to you. The client supplies Job Template attributes in order to affect the Printer's processing of the job, NOT to inform the Printer object of what is in the PDL. Here are some extracts of the specification to see if there is something mis-leading or ambiguous about the intended semantics of Job Template attributes: The introduction to Job Template Attributes in section 3.1.2 says: - Job Template Attributes: These attributes affect the processing of a job. A client OPTIONALLY supplies Job Template Attributes in a create request, and the receiving object MUST be prepared to receive all supported attributes. The Job object can later be queried to find out what Job Template attributes were originally requested in the create request, and such attributes are returned in the response as Job Object Attributes. The Printer object can be queried about its Job Template attributes to find out what type of job processing capabilities are supported and/or what the default job processing behaviors are, though such attributes are returned in the response as Printer Object Attributes. The "ipp-attribute-fidelity" operation attribute affects processing of all client supplied Job Template attributes (see section 15 for a full description of "ipp-attribute-fidelity" and its relationship to other attributes). In section 3.2.1.1, Print-Job Request, the "ipp-attribute-fidelity" is explained: "ipp-attribute-fidelity" (boolean): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. The value 'true' indicates that total fidelity to client supplied Job Template attributes and values is required, else the Printer object SHALL reject the Print-Job request. The value 'false' indicates that a reasonable attempt to print the Job object is acceptable and the Printer object SHALL accept the Print-job request. If not supplied, the Printer object assumes the value is 'false'. All Printer objects MUST support both types of job processing. See section 15 for a full description of "ipp-attribute-fidelity" and its relationship to other attributes, especially the Printer object's "pdl-override-supported" attribute. In section 4.2, Job Template attributes, we have: 4.2 Job Template Attributes Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 12.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests. Job Template attributes conform to the following rules. For each Job Template attribute called "xxx": What can we do to make it clearer? Thanks, Tom At 14:15 04/02/1998 PST, Carl Kugler wrote: >Henrik- > >My understanding is that the job template attributes specify requested >processing for a job. In your example the server makes n copies. However, the >J.T. attributes are OPTIONAL. Also, they can be ignored if >ipp-attribute-fidelity is false. > > -Carl > > > >ipp-owner@pwg.org on 04/01/98 01:59:01 AM >Please respond to ipp-owner@pwg.org >To: ipp@pwg.org >cc: >Subject: IPP> IPP: Job template attributes > > > >I am wondering, are the job template attributes only for information and >administration? >E.g. if an IPP Server recieves the job template attribute 'copies n' must >the IPP Server make >the n copies, or does the attribute only tell that the following job will >me maked in n copies. > >Henrik Holst > >___________________________________________________________ > Henrik Holst > Software engineer - developing embedded Printservers > i-data International > Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark > Voice: (+45) 44366271 > Fax: (+45) 44366111 > Email: henrik.holst@i-data.com > WEB: www.i-data.com > > > > > > > > From ipp-owner@pwg.org Mon Apr 20 10:10:14 1998 Delivery-Date: Mon, 20 Apr 1998 10:10:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02442 for ; Mon, 20 Apr 1998 10:10:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02738 for ; Mon, 20 Apr 1998 10:12:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA26041 for ; Mon, 20 Apr 1998 10:09:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 20 Apr 1998 09:58:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25458 for ipp-outgoing; Mon, 20 Apr 1998 09:55:41 -0400 (EDT) Message-Id: <3.0.2.32.19980420154956.00932df0@dokka.kvatro.no> X-Sender: hta@dokka.kvatro.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 20 Apr 1998 15:49:56 +0200 To: Carl-Uno Manros , "Turner, Randy" , "'ipp@pwg.org'" From: Harald Tveit Alvestrand Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi In-Reply-To: <3.0.1.32.19980416123114.00c8e5b0@garfield> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 12:31 16.04.98 PDT, Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. Right. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. Right, as far as it goes. And the server determines whether to use it for the response. > >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. For the generation: Right. For reception: Wrong. You're dependent on what the other guy does. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. Wrong. Since TCP is a reliable transfer protocol, there is basically only one thing that can go wrong: You lose the connection. There is no defined mechanism in HTTP that allows you to take advantage of the chunks you already sent when you retry the operation over a new connection. >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. True. With one caveat: If you depend on HTTP/1.0 without the Content-length: field to send data, you cannot tell the difference between the client crashing in mid-stream and the client finishing the document - both will show up as a "connection close". This can be annoying-but-harmless or relatively harmful, depending on your context. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From ipp-owner@pwg.org Mon Apr 20 10:42:28 1998 Delivery-Date: Mon, 20 Apr 1998 10:42:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03482 for ; Mon, 20 Apr 1998 10:42:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02916 for ; Mon, 20 Apr 1998 10:44:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA26703 for ; Mon, 20 Apr 1998 10:42:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 20 Apr 1998 10:38:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA26177 for ipp-outgoing; Mon, 20 Apr 1998 10:34:36 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Harald Tveit Alvestrand'" , "'ipp@pwg.org'" Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Date: Mon, 20 Apr 1998 07:35:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org One minor comment below.... Randy -----Original Message----- From: Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no] Sent: Monday, April 20, 1998 6:50 AM To: Carl-Uno Manros; Turner, Randy; 'ipp@pwg.org' Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi At 12:31 16.04.98 PDT, Carl-Uno Manros wrote: >Randy et al., > >Here is my take on the use of chunking for IPP: > >1) Each HTTP 1.1 implementation is mandated to support chunking. Right. > >2) All POSTs are initiated by the client, which I assume also means that >the client determines whether to use chunking for a particular HTTP request. Right, as far as it goes. And the server determines whether to use it for the response. > >3) The only situation where chunking is absolutely necessary for IPP, is >the case where the client does not know the document length when it starts >sending the document. For the generation: Right. For reception: Wrong. You're dependent on what the other guy does. > >4) With the exception of the situation in 3) the client can always decide >not to use chunking, but send even long documents in one request. The >downside of doing that is that if something goes wrong on the lower >protocol layers, the client has to start over and send the whole document >again from the beginning. The main advantage of using chunking is that if >you get an error on the lower layers, you only have to resend the latest >chunk, not the whole document. Wrong. Since TCP is a reliable transfer protocol, there is basically only one thing that can go wrong: You lose the connection. There is no defined mechanism in HTTP that allows you to take advantage of the chunks you already sent when you retry the operation over a new connection. >5) Again, with the exception of the case in 3), you can in practise >actually use HTTP 1.0, which does not support chunking, for most of your >IPP transfers. True. With one caveat: If you depend on HTTP/1.0 without the Content-length: field to send data, you cannot tell the difference between the client crashing in mid-stream and the client finishing the document - both will show up as a "connection close". This is not true in all cases. I seem to remember that some socket and TLI API implementations allow you to detect the difference between a remote endsystem crashing and a normal connection "close". This should be especially possible if the client had data in transit at the time the remote endsystem crashed. This can be annoying-but-harmless or relatively harmful, depending on your context. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From ipp-owner@pwg.org Mon Apr 20 13:18:19 1998 Delivery-Date: Mon, 20 Apr 1998 13:18:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA09294 for ; Mon, 20 Apr 1998 13:18:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03943 for ; Mon, 20 Apr 1998 13:20:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27446 for ; Mon, 20 Apr 1998 13:18:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 20 Apr 1998 13:13:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26927 for ipp-outgoing; Mon, 20 Apr 1998 13:11:57 -0400 (EDT) From: Carl Kugler To: Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking? Message-ID: <5030100019677311000002L012*@MHS> Date: Mon, 20 Apr 1998 13:11:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA09294 Peter- > > All, > Regarding IPP testing experience with chunking/IPP. I have not yet seen > anyone that has tried this. The tests I have been involved in, up to very > recently, used HTTP 1.0. This was due to the limitations of JDK. I have > not yet pursued the added complexity of chunking. This is a function of > IPP's underlying transport(HTTP 1.1). I have been concentrating on the IPP > PAD and method invocation. I would love to hear anyone with some concrete > experience with IPP and chunking. We have experience with IPP and chunking. IBM's Lotus Go Webserver replies with a chunked response when sent a request header like this one: POST /servlet/IPPServlet HTTP/1.1 Host: localhost Accept: application/ipp Content-type: application/ipp Content-length: 226 Also, we have interop tested with someone running the Microsoft web server. It, too, seems to reply with chunked Transfer-Encoding. I'm not positive about that (don't have the traces here), but I am sure that it always sends a 100 Continue before that actual response, and I think that implies chunking From ipp-owner@pwg.org Mon Apr 20 14:37:44 1998 Delivery-Date: Mon, 20 Apr 1998 14:37:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11541 for ; Mon, 20 Apr 1998 14:37:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04494 for ; Mon, 20 Apr 1998 14:40:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA28088 for ; Mon, 20 Apr 1998 14:37:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 20 Apr 1998 14:33:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27567 for ipp-outgoing; Mon, 20 Apr 1998 14:30:34 -0400 (EDT) Message-Id: <3.0.1.32.19980420112207.00c3b180@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 20 Apr 1998 11:22:07 PDT To: ipp@pwg.org From: The IESG (by way of Carl-Uno Manros ) Subject: IPP> Last Call: IETF Working Group Guidelines and Procedures to BCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi, There is a revised document describing the IETF WG rules, now out for IESG Last Call. If you are interested, please send your comments to the IESG. Carl-Uno -- The IESG has received a request from the Process for Organization of Internet StandardS ONgoing Working Group to consider IETF Working Group Guidelines and Procedures as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 4, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-poisson-wg-guide-02.txt From ipp-owner@pwg.org Tue Apr 21 10:25:03 1998 Delivery-Date: Tue, 21 Apr 1998 10:25:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26445 for ; Tue, 21 Apr 1998 10:24:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07752 for ; Tue, 21 Apr 1998 10:27:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10295 for ; Tue, 21 Apr 1998 10:24:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Apr 1998 10:13:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09709 for ipp-outgoing; Tue, 21 Apr 1998 10:10:51 -0400 (EDT) Message-Id: <199804211410.KAA14345@devnix.agranat.com> To: ipp@pwg.org Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking? In-reply-to: <5030100019677311000002L012*@MHS> Date: Tue, 21 Apr 1998 10:10:44 -0400 From: "Scott Lawrence" Sender: owner-ipp@pwg.org >>>>> "CK" == Carl Kugler writes: CK> it always sends a 100 Continue before that actual response, and I CK> think that implies chunking No, the only indication of chunking is the 'Transfer-Encoding: chunked' header field. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Tue Apr 21 12:13:51 1998 Delivery-Date: Tue, 21 Apr 1998 12:13:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA28468 for ; Tue, 21 Apr 1998 12:13:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08426 for ; Tue, 21 Apr 1998 12:16:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA11047 for ; Tue, 21 Apr 1998 12:13:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Apr 1998 12:08:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10471 for ipp-outgoing; Tue, 21 Apr 1998 12:08:16 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking? Message-ID: <5030100019708923000002L032*@MHS> Date: Tue, 21 Apr 1998 12:07:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id MAA28468 Agreed. I was confused about that. 100 Continue and Transfer-Encoding: chunked are independent except that they're both new features of HTTP 1.1. -Carl owner-ipp@pwg.org on 04/21/98 09:21:02 AM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking? >>>>> "CK" == Carl Kugler writes: CK> it always sends a 100 Continue before that actual response, and I CK> think that implies chunking No, the only indication of chunking is the 'Transfer-Encoding: chunked' header field. -- Scott Lawrence EmWeb Embedded Server Agranat Systems, Inc. Engineering http://www.agranat.com/ From ipp-owner@pwg.org Tue Apr 21 13:13:00 1998 Delivery-Date: Tue, 21 Apr 1998 13:13:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA29912 for ; Tue, 21 Apr 1998 13:12:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08771 for ; Tue, 21 Apr 1998 13:15:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA11660 for ; Tue, 21 Apr 1998 13:12:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Apr 1998 13:08:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA11135 for ipp-outgoing; Tue, 21 Apr 1998 13:08:07 -0400 (EDT) Message-Id: <3.0.2.32.19980421101404.00982600@dokka.kvatro.no> X-Sender: hta@dokka.kvatro.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 21 Apr 1998 10:14:04 +0200 To: "Turner, Randy" , "'ipp@pwg.org'" From: Harald Tveit Alvestrand Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 07:35 20.04.98 -0700, Turner, Randy wrote: > This is not true in all cases. I seem to remember that some socket >and TLI API implementations allow you to detect the difference between a >remote endsystem crashing and a normal connection "close". This should >be especially possible if the client had data in transit at the time the >remote endsystem crashed. Actually this depends on the endsystem implementation. There are 2 kinds of packets that can come across the wire: - A packet with the RST bit set. This indicates a crash. - A packet with the FIN bit set. This indicates normal close. But some endsystems will send FIN when the socket is closed, no matter why it is closed; this you cannot detect. Test with an UNIX box: Put a TCPDUMP on your LAN, telnet to some remote host, and kill the telnet client in various ways (kill -HUP, kill -9, EOF from client....), and see if the trace shows an R or an F in the last packet sent. If it's an F, the close is "normal". Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From ipp-owner@pwg.org Tue Apr 21 19:38:29 1998 Delivery-Date: Tue, 21 Apr 1998 19:38:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08846 for ; Tue, 21 Apr 1998 19:38:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10500 for ; Tue, 21 Apr 1998 19:40:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12763 for ; Tue, 21 Apr 1998 19:38:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Apr 1998 19:33:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA12241 for ipp-outgoing; Tue, 21 Apr 1998 19:31:29 -0400 (EDT) Message-Id: <3.0.1.32.19980421162247.00933210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Apr 1998 16:22:47 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - No PWG IPP Phone Conference April 22 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi all, As I have not seen any new input for discussion, and we have no feedback from the IESG, I decided to not hold a phone conference tomorrow. I expect that we will have at least some new input for next week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Apr 21 20:54:48 1998 Delivery-Date: Tue, 21 Apr 1998 20:54:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09634 for ; Tue, 21 Apr 1998 20:54:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA10676 for ; Tue, 21 Apr 1998 20:57:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14374 for ; Tue, 21 Apr 1998 20:54:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Apr 1998 20:48:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA13812 for ipp-outgoing; Tue, 21 Apr 1998 20:44:27 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B5CB8C85@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Carl-Uno Manros'" , Robert Herriot Cc: ipp@pwg.org Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi Date: Tue, 21 Apr 1998 17:44:15 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org the difference is that chunking doesnt really allow for resending only certain chunks instead of the whole thing. There is no chunk acknowledgement or chunk sequencing, which you would need to resume an aborted or failed transfer. In HTTP a way of resuming an aborted transfer is to use byte ranges to request the remainder of a resource. This seems like it would be difficult to use with IPP since you are posting data. Chunking is just for sending content of unknown length, not for retransmission stuff. > -----Original Message----- > From: Carl-Uno Manros [mailto:cmanros@cp10.es.xerox.com] > Sent: Friday, April 17, 1998 8:12 AM > To: Robert Herriot > Cc: ipp@pwg.org > Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: > Mi > > > At 08:26 PM 4/16/98 PDT, you wrote: > >Are you sure about #4 below? It doesn't sound right at all. My > >understanding of chunking is that it allows the sender to omit > >Content-Length and to instead supply length one chunk at a time. At > >the HTTP layer, the document is a series of chunks > terminated by a zero > >length chunk. > > > > > >Bob Herriot > > > > And how is that in conflict with what I stated in 4)? > > Carl-Uno > > > >At 12:31 PM 4/16/98 , Carl-Uno Manros wrote: > >>Randy et al., > >> > >>Here is my take on the use of chunking for IPP: > >> > >>1) Each HTTP 1.1 implementation is mandated to support chunking. > >> > >>2) All POSTs are initiated by the client, which I assume > also means that > >>the client determines whether to use chunking for a > particular HTTP request. > >> > >>3) The only situation where chunking is absolutely > necessary for IPP, is > >>the case where the client does not know the document length > when it starts > >>sending the document. > >> > >>4) With the exception of the situation in 3) the client can > always decide > >>not to use chunking, but send even long documents in one > request. The > >>downside of doing that is that if something goes wrong on the lower > >>protocol layers, the client has to start over and send the > whole document > >>again from the beginning. The main advantage of using > chunking is that if > >>you get an error on the lower layers, you only have to > resend the latest > >>chunk, not the whole document. > >> > >>5) Again, with the exception of the case in 3), you can in practise > >>actually use HTTP 1.0, which does not support chunking, for > most of your > >>IPP transfers. > >> > >>Did I get this right? > >> > >>Carl-Uno > >> > >>At 09:08 PM 4/15/98 PDT, Turner, Randy wrote: > >>> > >>>There is nothing in the existing encoding that allows a > particular IPP > >>>message to be "fragmented" across multiple transport > "packets".  The > >>>encoding requires that a transport protocol provide some way to > >>>logically "connect" one message to another contiguously received > >>>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With > >>>another transport, there would have to some equivalent > capability. I'm > >>>not sure if I've adequately described the situation. > Anything further I > >>>think would require me to draw a picture. > >>> > >>>Randy > >>> > >>> > >>> -----Original Message----- > >>> From: Carl Kugler [SMTP:kugler@us.ibm.com] > >>> Sent: Wednesday, April 15, 1998 9:22 AM > >>> To: ipp@pwg.org > >>> Subject: IPP> IPP, independently of HTTP, Requires > >>>Chunking ? Was: Mi > >>> > >>> > The concrete transport/encoding IPP protocol document is VERY > >>>dependent > >>> > on HTTP chunking. > >>> > >>> I still don't get it.  Could you please explain? > >>> > >>> The original statement is: > >>> > Encoding is HTTP independent except for chinking. > >>> > >>> This sentence, to me, implies that there is some aspect of the > >>>IPP encoding, > >>> apart from HTTP, that depends on chunking.  This is suprising > >>>news to me. > >>> > >>> The only chunking-related requirements I've found in the > >>>Protocol document are: > >>> 1) the Server must support "chunked" Transfer-Encoding of > >>>Requests > >>> 2) the Client must support "chunked" Responses. > >>> These requirements derive directly from RFC 2068:  "All HTTP/1.1 > >>>applications > >>> MUST be able to receive and decode the "chunked" transfer > >>>coding..." > >>> > >>> > >>> Confused in Boulder, > >>> > >>>   Carl-III > >>> > >>> > >>> > >>> ipp-owner@pwg.org on 04/14/98 05:34:03 PM > >>> Please respond to ipp-owner@pwg.org > >>> To: ipp@pwg.org > >>> cc: > >>> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR - > >>>Apri > >>> > >>> > >>> > >>> The abstract IPP described in the model document is not > >>>dependent on > >>> HTTP chunking. > >>> > >>> The concrete transport/encoding IPP protocol document is VERY > >>>dependent > >>> on HTTP chunking. > >>> > >>> Randy > >>> > >>> -----Original Message----- > >>> From: Carl Kugler [SMTP:kugler@us.ibm.com] > >>> Sent: Tuesday, April 14, 1998 4:25 PM > >>> To: ipp@pwg.org > >>> Subject: Re: IPP> Minutes from PWG IPP Meeting in > >>> Portland, OR - Apri > >>> > >>> > IPP is not transport neutral. Encoding is HTTP independent > >>> except for > >>> > chinking. > >>> > >>> I assume you mean "chunking".  In what way is IPP dependent on > >>> HTTP chunking? > >>> > >>>   -Carl > >>> > >>> > >>> > >>> > >>> > >>Carl-Uno Manros > >>Principal Engineer - Advanced Printing Standards - Xerox Corporation > >>701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > >>Phone +1-310-333 8273, Fax +1-310-333 5514 > >>Email: manros@cp10.es.xerox.com > >> > > > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Wed Apr 22 13:36:09 1998 Delivery-Date: Wed, 22 Apr 1998 13:36:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA03881 for ; Wed, 22 Apr 1998 13:36:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13912 for ; Wed, 22 Apr 1998 13:38:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27499 for ; Wed, 22 Apr 1998 13:36:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Apr 1998 13:29:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26820 for ipp-outgoing; Wed, 22 Apr 1998 13:26:09 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> ADM - IPP already taken for Internet Project! Message-ID: <5030100019745896000002L062*@MHS> Date: Wed, 22 Apr 1998 13:25:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA03881 And SDP is also Session Description Protocol ftp://ftp.isi.edu/in-notes/rfc2327.txt ipp-owner@pwg.org on 04/14/98 09:48:52 PM Please respond to ipp-owner@pwg.org To: ipp@pwg.org cc: Subject: IPP> ADM - IPP already taken for Internet Project! While looking round on the web to see if I could find any recent mentioning about IPP, I ran across another IPP project on the Internet. http://www.lysator.liu.se/pinball/IPP/ Carl-Uno From ipp-owner@pwg.org Wed Apr 22 13:39:43 1998 Delivery-Date: Wed, 22 Apr 1998 13:39:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA03998 for ; Wed, 22 Apr 1998 13:39:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13928 for ; Wed, 22 Apr 1998 13:42:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27984 for ; Wed, 22 Apr 1998 13:39:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Apr 1998 13:34:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27153 for ipp-outgoing; Wed, 22 Apr 1998 13:33:00 -0400 (EDT) Message-Id: <3.0.1.32.19980422102311.00c54100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 22 Apr 1998 10:23:11 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Reminder about job openings and home work assignments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org As we have cancelled the phone conference today, I wanted to give a reminder about current job openings and home work assignments: JOB OPENINGS 1) We still need a new permanent secretary for the IPP meetings and phone conferences. 2) We are still looking for an editor to start collecting questions and answers about IPP and to organize them for an Implementor's Guide document as soon as the RFCs are out. 3) We are looking for an editor for the IPP Notification document. (see below) HOME WORK ASSIGNMENTS 1) Write up a short informational I-D text describing what is mandatory to implement in an IPP Printer (Carl-Uno and Peter Z.) 2) Write up agreements on IPP Notfications from last PWG IPP meeting (Tom H. and Harry L.). By default these guys will be appointed editors for that document as well, unless somebody else steps up for the job opening as editor. 3) Make a draft for MIME registration of document types, based on current Printer MIB enum registrations (Tom H.) 4) Revised draft on getting MIB info over IPP - Uncertain whether this is still part of IPP or should be part of the SDP discussion? (Scott I.) 5) The Editors to collect and be prepared to submit minor fixes to the Model and Protocol drafts to the RFC editor, before publishing as RFCs. (Scott I. and Bob H.) Still very quiet from Keith Moore and the IESG, I keep on sending a reminder about once a week ;-). Latest excuse was that the TLS RFCs are not yet out - I suggested to Keith to change our references to SSL3 (but suspect that that proposal may not go down too well). Hope to have at least some of the home work assignments finished in time for discussion in next Wednesday'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 From shacham@cisco.com Wed Apr 22 14:55:03 1998 Delivery-Date: Wed, 22 Apr 1998 14:55:03 -0400 Return-Path: shacham@cisco.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07229 for ; Wed, 22 Apr 1998 14:55:03 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14223 for ; Wed, 22 Apr 1998 14:57:31 -0400 (EDT) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07220 for ; Wed, 22 Apr 1998 14:54:59 -0400 (EDT) Received: from shacham-home-pc-4.cisco.com ([171.71.69.80]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id LAA25400; Wed, 22 Apr 1998 11:54:30 -0700 (PDT) Message-Id: <3.0.2.32.19980422115240.006d40d4@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 22 Apr 1998 11:52:40 -0700 To: "'iesg@ns.ietf.org'" From: Avram Shacham Subject: RE: Last Call: IPSec DOI Proposed Standard Cc: ipsec@tis.com, ippcp@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" The document is inconsistent with the IP Payload Compression Protocol (IPComp) as defined in . Regards, avram 4.4.5 IPSEC IPCOMP Transform Identifiers The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP compression before ESP encryption. ^^^^^^^^^^^^^^^^^^^^^ Is this very partial definition needed? 6.6 IPSEC IPCOMP Transform Identifiers The IPSEC IPCOMP Transform Identifier is an 8-bit value which ^^^^^I-D defines 1-63(6 bit) identifier a particular algorithm to be used to provide IP-level compression before ESP. Requests for assignments of new IPCOMP ^^^^^^^^^^^^^^^^^^^^^^ see above transform identifiers must be accompanied by a standards-track RFC which describes how to use the algorithm within the IPCOMP framework ([IPCOMP]). In addition, the requested algorithm must be published and in the public domain. If the requested algorithm is not in the public domain, the addition must be approved by an IESG action. The values 249-255 are reserved for private use amongst cooperating ^^^^^^^ 58-63? systems. === end of comments === From ipp-owner@pwg.org Wed Apr 22 15:44:08 1998 Delivery-Date: Wed, 22 Apr 1998 15:44:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA08469 for ; Wed, 22 Apr 1998 15:44:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA14455 for ; Wed, 22 Apr 1998 15:46:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA28704 for ; Wed, 22 Apr 1998 15:44:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Apr 1998 15:39:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28118 for ipp-outgoing; Wed, 22 Apr 1998 15:36:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 22 Apr 1998 13:35:23 -0600 From: "Scott Isaacson" To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM - Reminder about job openings and home work assignments Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id PAA08469 >>> Carl-Uno Manros 04/22 11:23 AM >>> > (snip) >HOME WORK ASSIGNMENTS > > (snip) > > 4) Revised draft on getting MIB info over IPP - Uncertain whether this is > still part of IPP or should be part of the SDP discussion? (Scott I.) Unless this is still part of an IPP discussion, then I am not interested in participating. I plan to rev the document and post and an I-D (non-WG draft if necessary), but I would like for it to be a WG draft. Scott From tytso@MIT.EDU Wed Apr 22 22:48:18 1998 Delivery-Date: Wed, 22 Apr 1998 22:48:19 -0400 Return-Path: tytso@MIT.EDU Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id WAA14055 for ; Wed, 22 Apr 1998 22:48:18 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15653 for ; Wed, 22 Apr 1998 22:50:48 -0400 (EDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.ietf.org (8.8.5/8.8.7a) with SMTP id WAA14052 for ; Wed, 22 Apr 1998 22:48:07 -0400 (EDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA19871; Wed, 22 Apr 98 22:37:17 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id WAA16620; Wed, 22 Apr 1998 22:37:16 -0400 Date: Wed, 22 Apr 1998 22:37:16 -0400 Message-Id: <199804230237.WAA16620@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Wed, 22 Apr 1998 11:52:40 -0700, <3.0.2.32.19980422115240.006d40d4@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 22 Apr 1998 11:52:40 -0700 From: Avram Shacham The document is inconsistent with the IP Payload Compression Protocol (IPComp) as defined in . Thanks for catching this. I think that the draft we need to change is the IPComp draft, though. It assumes that the transform identifiers are 16-bits: 16-bit index. The CPI is stored in network order. The values 0-63 define well-known compression algorithms, which require no additional information, and are used for manual setup. The values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new values. The values 64-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. The values 61440-65535 are for private use among mutually consenting parties. However, ISAKMP only supports 8 bits worth of transform id's. Hence, the text in IPComp needs fixing. In harmonizing the IPComp draft with the DOI draft, it would seem to me that the way to do this is to adopt the IANA considerations in the DOI draft. The IPCOMP draft doesn't have an IANA considerations, and as stated previously, it incorrectly assumes that transform ID's were 16-bits instead of 8 bits in ISAKMP. Comments? - Ted From shacham@cisco.com Thu Apr 23 00:50:49 1998 Delivery-Date: Thu, 23 Apr 1998 00:50:49 -0400 Return-Path: shacham@cisco.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA19143 for ; Thu, 23 Apr 1998 00:50:48 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA15876 for ; Thu, 23 Apr 1998 00:53:13 -0400 (EDT) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA19140 for ; Thu, 23 Apr 1998 00:50:46 -0400 (EDT) Received: from shacham-home-pc-4.cisco.com (shacham-home-pc-4.cisco.com [171.69.149.181]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id VAA05413; Wed, 22 Apr 1998 21:50:14 -0700 (PDT) Message-Id: <3.0.2.32.19980422214828.006b0c78@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 22 Apr 1998 21:48:28 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804230237.WAA16620@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Theodore, In a simple analogy to IPSec, the 16-bit CPI of IPComp is the equivalent of the 32-bit SPI, and the 6-bit IPCOMP Transform Identifiers, which define well-known compression algorithms, are similar to the 8-bit ESP and AH Transform Identifiers. IPSec DOI provides the numeric and symbolic definitions for all those Identifiers. In IPComp, the Transform Identifiers can also serve as CPI, with the benefit of saving the receiving node the CPU cycles to locate the compression algorithm by CPI. This method is also handy for manually configured nodes. As for the numeric range of the IPComp Transform Identifiers - in Munich, the IPPCP working-group decided - given the number of existing compression algorithms - to allocate the IDs 1-63 for such known algorithms. The decision is reflected in the IPComp I-D. The DOI document did not follow this decision. In IPSec/IKE bakeoff in March 98, several vendors successfully negotiated IPComp using IKE, so I see no conflict here. Also, IANA did read and provided comments to the IPComp I-D and those comments were incorporated in the document. Therefore, the right way to go is to correct the DOI doc. Regards, avram At 10:37 PM 4/22/98 -0400, Theodore Y. Ts'o wrote: > Date: Wed, 22 Apr 1998 11:52:40 -0700 > From: Avram Shacham > > The document is inconsistent with the IP > Payload Compression Protocol (IPComp) as defined in > . > >Thanks for catching this. I think that the draft we need to change is >the IPComp draft, though. It assumes that the transform identifiers are >16-bits: > > 16-bit index. The CPI is stored in network order. The values > 0-63 define well-known compression algorithms, which require no > additional information, and are used for manual setup. The > values themselves are identical to IPCOMP Transform identifiers > as defined in [SECDOI]. Consult [SECDOI] for an initial set of > defined values and for instructions on how to assign new values. > The values 64-61439 are negotiated between the two nodes in > definition of an IPComp Association, as defined in section 4. > Note: When negotiating one of the well-known algorithms, the > nodes MAY select a CPI in the pre-defined range 0-63. The > values 61440-65535 are for private use among mutually consenting > parties. > >However, ISAKMP only supports 8 bits worth of transform id's. Hence, >the text in IPComp needs fixing. In harmonizing the IPComp draft with >the DOI draft, it would seem to me that the way to do this is to adopt >the IANA considerations in the DOI draft. The IPCOMP draft doesn't have >an IANA considerations, and as stated previously, it incorrectly assumes >that transform ID's were 16-bits instead of 8 bits in ISAKMP. > >Comments? > > - Ted > > From ddp@Network-Alchemy.COM Thu Apr 23 13:32:35 1998 Delivery-Date: Thu, 23 Apr 1998 13:32:36 -0400 Return-Path: ddp@Network-Alchemy.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA13126 for ; Thu, 23 Apr 1998 13:32:35 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18323 for ; Thu, 23 Apr 1998 13:35:01 -0400 (EDT) Received: from gallium.network-alchemy.com (Gallium.Network-Alchemy.COM [199.46.17.139]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA13118 for ; Thu, 23 Apr 1998 13:32:26 -0400 (EDT) Received: from gallium.network-alchemy.com (localhost.network-alchemy.com [127.0.0.1]) by gallium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id KAA05830; Thu, 23 Apr 1998 10:31:30 -0700 (PDT) (envelope-from ddp@network-alchemy.com) Message-Id: <199804231731.KAA05830@gallium.network-alchemy.com> To: "Theodore Y. Ts'o" cc: Avram Shacham , "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com Subject: Re: Last Call: IPSec DOI Proposed Standard In-reply-to: Your message of "Wed, 22 Apr 1998 22:37:16 EDT." <199804230237.WAA16620@dcl.MIT.EDU> Date: Thu, 23 Apr 1998 10:31:29 -0700 From: "Derrell D. Piper" All, The ISAKMP protocol defines the size of its Transform ID field as one octet. The IPSEC DOI defines the legal values for this field when using IPSEC with ISAKMP (as IPPCP does). If IPPCP wants to use only six bits of the octet for the compression transform identifier, that's fine, but it's still eight bits on the wire in ISAKMP. It can also be just six bits in the IPPCP protocol. The current IPSEC DOI says that the values not defined in the IPSEC DOI are reserved to IANA and that requests to IANA must be accompanied by a standards track RFC, like IPPCP, that details the use of the requested allocation. The only potential problem I see is that the IPSEC DOI does state that "the values 249-255 are reserved for use private use amongst cooperating systems." I will correct this in the next draft. Derrell From tytso@MIT.EDU Thu Apr 23 16:55:13 1998 Delivery-Date: Thu, 23 Apr 1998 16:55:13 -0400 Return-Path: tytso@MIT.EDU Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA18645 for ; Thu, 23 Apr 1998 16:55:12 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA19326 for ; Thu, 23 Apr 1998 16:57:40 -0400 (EDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ns.ietf.org (8.8.5/8.8.7a) with SMTP id QAA18636 for ; Thu, 23 Apr 1998 16:55:05 -0400 (EDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA12155; Thu, 23 Apr 98 16:55:09 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id QAA17248; Thu, 23 Apr 1998 16:55:03 -0400 Date: Thu, 23 Apr 1998 16:55:03 -0400 Message-Id: <199804232055.QAA17248@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Wed, 22 Apr 1998 21:48:28 -0700, <3.0.2.32.19980422214828.006b0c78@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 22 Apr 1998 21:48:28 -0700 From: Avram Shacham In a simple analogy to IPSec, the 16-bit CPI of IPComp is the equivalent of the 32-bit SPI, and the 6-bit IPCOMP Transform Identifiers, which define well-known compression algorithms, are similar to the 8-bit ESP and AH Transform Identifiers. IPSec DOI provides the numeric and symbolic definitions for all those Identifiers. Thanks for setting me straight for how the IPCOMP was used. It wasn't immediately obvious to me from reading the IPCOMP draft. Stupid question --- what was the reason why IPCOMP limited the number of transform identifiers to 6-bits? If we changed the number of transform identifiers to 8-bits, it decreases the number of CPI's available for dynamically assigned CPI's from 61,376 to 61,184. I wouldn't think that the range of dynamically assigned CPI's would be drastically decreased if we were to lower that range by 192 transforms. As for the numeric range of the IPComp Transform Identifiers - in Munich, the IPPCP working-group decided - given the number of existing compression algorithms - to allocate the IDs 1-63 for such known algorithms. The decision is reflected in the IPComp I-D. The DOI document did not follow this decision. Our apologies. Both I and the DOI editor were not aware of this decision. That being said, could you enlighten us as to why the ippcp wg made that decision? We can very easily make the DOI document state that the number of transforms is limited to the range 0-63 (despite the fact that the ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by the IANA, and 54-63 to be used by mutually consenting implementations. It would seem to me to be limiting the number space unnecessarily, though. Our other choice would be to change the IPCOMP draft to align with the DOI draft. This increases the number of static transforms from 64 to 256, and means that ISAKMP implementations should only hand out CPI's which are in the range 256 to 61439. (instead of using the range 63 to 61439). Although I'm not an expert on the issues which the ippcp group is facing, it would seem to me that increasing the number of static transforms would be a good thing. I've gotten nervous about the fact that we only have 8 bits for some of the other ISAKMP negotiated fields, which is why the IANA consideration is extremely miserly about how those numbers are handed out, lest we run out. However, if the IPPCP group feels strongly about this, we can go ahead and make the change to the DOI. (This is otherwise known as "your funeral, not mine, if we run out of ipcomp transform id's." :-) - Ted From shacham@cisco.com Fri Apr 24 00:55:17 1998 Delivery-Date: Fri, 24 Apr 1998 00:55:18 -0400 Return-Path: shacham@cisco.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA28165 for ; Fri, 24 Apr 1998 00:55:17 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA20488 for ; Fri, 24 Apr 1998 00:57:44 -0400 (EDT) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id AAA28161 for ; Fri, 24 Apr 1998 00:55:14 -0400 (EDT) Received: from shacham-home-pc-4.cisco.com (shacham-home-pc-4.cisco.com [171.69.149.181]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id VAA27218; Thu, 23 Apr 1998 21:54:42 -0700 (PDT) Message-Id: <3.0.2.32.19980423215251.006d74c0@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 23 Apr 1998 21:52:51 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804232055.QAA17248@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 04:55 PM 4/23/98 -0400, Theodore Y. Ts'o wrote: [...] > As for the numeric range of the IPComp Transform Identifiers - in Munich, > the IPPCP working-group decided - given the number of existing compression > algorithms - to allocate the IDs 1-63 for such known algorithms. The > decision is reflected in the IPComp I-D. The DOI document did not follow > this decision. > >Our apologies. Both I and the DOI editor were not aware of this >decision. The DOI editor _is_ a member of the IPPCP mailing list from day one, so he must have been aware of the wg decisions in Munich. Also, I pointed these inconsistencies to the DOI editor in several private email messages many weeks ago. >That being said, could you enlighten us as to why the ippcp >wg made that decision? Currently, the market offers 4 (four) compression algorithms. The IPPCP wg felt that less than 50 (fifty) new algorithms are expected in the foreseeable future. >We can very easily make the DOI document state that the number of >transforms is limited to the range 0-63 (despite the fact that the >ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by >the IANA, and 54-63 to be used by mutually consenting implementations. >It would seem to me to be limiting the number space unnecessarily, >though. Please do. After all, six weeks ago the IESG approved the publication of IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but waiting for two IPSec docs.) If future experience proves the IPCOMP Transform Identifiers range is too narrow, there is always room for improvements. Regards, avram From tytso@MIT.EDU Fri Apr 24 14:28:33 1998 Delivery-Date: Fri, 24 Apr 1998 14:28:33 -0400 Return-Path: tytso@MIT.EDU Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22410 for ; Fri, 24 Apr 1998 14:28:32 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22983 for ; Fri, 24 Apr 1998 14:31:00 -0400 (EDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.ietf.org (8.8.5/8.8.7a) with SMTP id OAA22405 for ; Fri, 24 Apr 1998 14:28:30 -0400 (EDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA02083; Fri, 24 Apr 98 14:28:31 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA17558; Fri, 24 Apr 1998 14:28:30 -0400 Date: Fri, 24 Apr 1998 14:28:30 -0400 Message-Id: <199804241828.OAA17558@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Thu, 23 Apr 1998 21:52:51 -0700, <3.0.2.32.19980423215251.006d74c0@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Thu, 23 Apr 1998 21:52:51 -0700 From: Avram Shacham Please do. After all, six weeks ago the IESG approved the publication of IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but waiting for two IPSec docs.) If future experience proves the IPCOMP Transform Identifiers range is too narrow, there is always room for improvements. Actually, it will be much, much harder to change this in the future if there are implementations which start assigning CPI's in the range 64-255. This will prevent us from expanding the range in the future for static transforms, since they will be used for dynamically assigned values. It's clear we will need to make a change to one or the other document, both of which have been voted on and approved by the IESG (the IPSEC documents modulo some fixups, including this one). One compromise position that we might explore would involve putting text in the IPSEC documents that reserve the range 64-255 for future expansion, and so implementations MUST NOT assign CPI's in that range. This at least gives us the opportunity to allow more "well-known" transforms in the future. What do people think about this? You're right that with only four compression algorithms, this isn't a big deal either way, and shouldn't be used to delay the documents. On the other hand, I can't think of any architectural justification to artificially constrain the ability to expand the number space at this point in time. It'd be like the original IP designers saying that IP addresses should be only 28 bits, instead 32, because surely we would *never* need 2**28 addresses --- never mind that 4 bytes gives you 32 bits and the cost is the same whether you use 28 or 32 bits. Taking the analogy back to IPPCP, if we have 1 full byte available to us, why not use the whole 8 bits, instead of stopping at 6? Surely we can spare 192 dynamically assigned CPI's out of over 61,000. (Note that the compromise I suggested above reserves these 192 dynamically assigned CPI's so that we have the option in the future to expand the range.) - Ted From shacham@cisco.com Fri Apr 24 15:15:52 1998 Delivery-Date: Fri, 24 Apr 1998 15:15:53 -0400 Return-Path: shacham@cisco.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24312 for ; Fri, 24 Apr 1998 15:15:51 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA23396 for ; Fri, 24 Apr 1998 15:18:19 -0400 (EDT) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24308 for ; Fri, 24 Apr 1998 15:15:49 -0400 (EDT) Received: from shacham-home-pc-4.cisco.com ([171.71.69.80]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id MAA08349; Fri, 24 Apr 1998 12:15:19 -0700 (PDT) Message-Id: <3.0.2.32.19980424121326.006a0da8@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 24 Apr 1998 12:13:26 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804241828.OAA17558@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ted, I agree that your compromise is more flexible for future changes. Unless other members of the IPPCP wg voice objections, I suggest that both documents (DOI and IPComp) will be modified to reflect your suggestion. Also, the DOI document should be modified to correct the non-accurate wording describing the IPComp protocol: (a) deleting the words "before ESP encryption" in section 4.4.5 and "before ESP" is 6.6, and (b) the term "IP compression" should be modified to "IP payload compression." I hope this process will not delay any of our documents. Comments? avram At 02:28 PM 4/24/98 -0400, Theodore Y. Ts'o wrote: > >Actually, it will be much, much harder to change this in the future if >there are implementations which start assigning CPI's in the range >64-255. This will prevent us from expanding the range in the future for >static transforms, since they will be used for dynamically assigned >values. > >It's clear we will need to make a change to one or the other document, >both of which have been voted on and approved by the IESG (the IPSEC >documents modulo some fixups, including this one). > >One compromise position that we might explore would involve putting text >in the IPSEC documents that reserve the range 64-255 for future >expansion, and so implementations MUST NOT assign CPI's in that range. >This at least gives us the opportunity to allow more "well-known" >transforms in the future. What do people think about this? > >You're right that with only four compression algorithms, this isn't a >big deal either way, and shouldn't be used to delay the documents. On >the other hand, I can't think of any architectural justification to >artificially constrain the ability to expand the number space at this >point in time. It'd be like the original IP designers saying that IP >addresses should be only 28 bits, instead 32, because surely we would >*never* need 2**28 addresses --- never mind that 4 bytes gives you 32 >bits and the cost is the same whether you use 28 or 32 bits. > >Taking the analogy back to IPPCP, if we have 1 full byte available to >us, why not use the whole 8 bits, instead of stopping at 6? Surely we >can spare 192 dynamically assigned CPI's out of over 61,000. (Note that >the compromise I suggested above reserves these 192 dynamically assigned >CPI's so that we have the option in the future to expand the range.) > > - Ted > > From naganand@BayNetworks.COM Fri Apr 24 16:42:24 1998 Delivery-Date: Fri, 24 Apr 1998 16:42:25 -0400 Return-Path: naganand@BayNetworks.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27821 for ; Fri, 24 Apr 1998 16:42:24 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA23955 for ; Fri, 24 Apr 1998 16:44:52 -0400 (EDT) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27816 for ; Fri, 24 Apr 1998 16:42:21 -0400 (EDT) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id NAA15171; Fri, 24 Apr 1998 13:39:28 -0700 (PDT) Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id NAA05381; Fri, 24 Apr 1998 13:39:54 -0700 (PDT) Received: from by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AD15118; Fri, 24 Apr 98 16:41:44 EDT for ippcp@external.cisco.com Received: from ndoraswa.corpeast.baynetworks.com ([192.32.242.16]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA12066; Fri, 24 Apr 1998 16:06:11 -0400 Message-Id: <3.0.32.19980424160740.00d1c35c@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Apr 1998 16:07:40 -0400 To: "Theodore Y. Ts'o" , Avram Shacham From: Naganand Doraswamy Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ted, I like the compromise you suggested of reserving values 64-255 for future use. I think we should change the documents to reflect this. Thanks, --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From ipp-owner@pwg.org Fri Apr 24 18:16:09 1998 Delivery-Date: Fri, 24 Apr 1998 18:16:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01267 for ; Fri, 24 Apr 1998 18:16:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA24261 for ; Fri, 24 Apr 1998 18:18:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00882 for ; Fri, 24 Apr 1998 18:16:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 18:07:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00345 for ipp-outgoing; Fri, 24 Apr 1998 18:06:23 -0400 (EDT) Message-ID: From: Frank Mason To: "'ipp@pwg.org'" Subject: IPP> ? on IPP direction concerning XML Date: Fri, 24 Apr 1998 16:06:04 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org IPP Subgroup, I'm trying to understand the article "Microsoft, HP Reverse Course on Internet Printing Protocol" March 98 Hardcopy Observer. The article states that "A meeting of the IPP subgroup during the week of March 2 in Austin, TX should shed more light on these issues". I have looked at the Minutes of the Austin IPP meeting (March 98) and didn't find any mention of a discussion. I'm new to the IPP group. So, would someone point me to the correct place? Thanks Frank Mason Frank I. Mason Frankm@extendsys.com http://www.extendsys.com Extended Systems Inc. 5777 N. Meeker Ave. Boise, ID 83713 208.322.7575 (voice) From jmp-owner@pwg.org Fri Apr 24 19:32:47 1998 Delivery-Date: Fri, 24 Apr 1998 19:32:47 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03594 for ; Fri, 24 Apr 1998 19:32:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA24439 for ; Fri, 24 Apr 1998 19:35:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01240 for ; Fri, 24 Apr 1998 19:32:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 19:30:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01023 for jmp-outgoing; Fri, 24 Apr 1998 19:29:21 -0400 (EDT) Message-Id: <3.0.1.32.19980424145819.01298470@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Apr 1998 14:58:19 PDT To: ipp@pwg.org From: Tom Hastings Subject: JMP> MOD - Updated notification proposal posted Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Harry and I have updated our IPP notification proposal based on the meeting consensus. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf The .pdf version should be used to make comments using the line numbers. We'd like to discuss this at the IPP telecon Wed, April 29, 10-12 PDT. It also lists the event groupings and notification content for use with the Job Monitoring MIB. Thanks, Tom and Harry From ipp-owner@pwg.org Fri Apr 24 19:36:58 1998 Delivery-Date: Fri, 24 Apr 1998 19:36:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03696 for ; Fri, 24 Apr 1998 19:36:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA24449 for ; Fri, 24 Apr 1998 19:39:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01751 for ; Fri, 24 Apr 1998 19:36:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 19:32:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01016 for ipp-outgoing; Fri, 24 Apr 1998 19:29:18 -0400 (EDT) Message-Id: <3.0.1.32.19980424145819.01298470@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Apr 1998 14:58:19 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated notification proposal posted Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Harry and I have updated our IPP notification proposal based on the meeting consensus. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf The .pdf version should be used to make comments using the line numbers. We'd like to discuss this at the IPP telecon Wed, April 29, 10-12 PDT. It also lists the event groupings and notification content for use with the Job Monitoring MIB. Thanks, Tom and Harry From ipp-owner@pwg.org Fri Apr 24 19:51:57 1998 Delivery-Date: Fri, 24 Apr 1998 19:52:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03980 for ; Fri, 24 Apr 1998 19:51:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA24494 for ; Fri, 24 Apr 1998 19:53:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02386 for ; Fri, 24 Apr 1998 19:51:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 19:47:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01856 for ipp-outgoing; Fri, 24 Apr 1998 19:42:09 -0400 (EDT) Message-ID: From: Kris Schoff To: "'SISAACSON@novell.com'" , "'ipp@pwg.org'" Subject: RE: IPP> ADM - Reminder about job openings and home work assignme nts Date: Fri, 24 Apr 1998 17:41:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Scott, I would be very interested in tunneling SNMP OID's through IPP for printer management. It seems like a very reasonable concept to do and it could allow for the enabling of millions of printers in existence today. I'd like to see you continue your effort within IPP. I am still a proponent that IPP was intended to become a universal, catch-all printing protocol - which is why I am not on the SDP mailing list. By definition of "Server-to-Device", it would seem as if the client is already being left out. I could have sworn that some people within the IPP WG were trying to limit the number of protocols that needed to be implemented.... Kris Schoff > -----Original Message----- > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] > Sent: Wednesday, April 22, 1998 1:58 PM > To: kschoff@hpb18423.boi.hp.com > Subject: Re: IPP> ADM - Reminder about job openings and home work > assignments > > Message-Id: > Date: Wed, 22 Apr 1998 13:35:23 -0600 > Subject: > Sender: > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > com@hpbs1480 > FROM: > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > com@hpbs1480 > TO: cmanros@cp10.es.xerox.com, > ipp@pwg.org > Encoding: 17 text > > > >>> Carl-Uno Manros 04/22 11:23 AM >>> > > (snip) > >HOME WORK ASSIGNMENTS > > > > (snip) > > > > 4) Revised draft on getting MIB info over IPP - Uncertain whether > this is > > still part of IPP or should be part of the SDP discussion? (Scott > I.) > > Unless this is still part of an IPP discussion, then I am not > interested in > participating. I plan to rev the document and post and an I-D (non-WG > draft if necessary), but I would like for it to be a WG draft. > > Scott > From ipp-owner@pwg.org Fri Apr 24 21:16:50 1998 Delivery-Date: Fri, 24 Apr 1998 21:16:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id VAA05768 for ; Fri, 24 Apr 1998 21:16:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24611 for ; Fri, 24 Apr 1998 21:19:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA03068 for ; Fri, 24 Apr 1998 21:16:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 21:12:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02542 for ipp-outgoing; Fri, 24 Apr 1998 21:11:16 -0400 (EDT) Message-Id: <3.0.1.32.19980424180314.00a49e80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Apr 1998 18:03:14 PDT To: Frank Mason , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> ? on IPP direction concerning XML In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The short answer is: Don't believe everything you read in the press. Representatives from Microsoft and HP have declared on this DL that they are implementing what the final decision from the IESG will be. Unfortunately, the IESG is dragging their feet with a proper feedback to this WG (they have had our final drafts since early February). So, we do not know the final outcome for sure, but you can rely on everybody implementing the same standard once it is frozen. Carl-Uno At 03:06 PM 4/24/98 PDT, Frank Mason wrote: >IPP Subgroup, >I'm trying to understand the article "Microsoft, HP Reverse Course on >Internet Printing Protocol" March 98 Hardcopy Observer. The article >states that "A meeting of the IPP subgroup during the week of March 2 >in Austin, TX should shed more light on these issues". I have looked >at the Minutes of the Austin IPP meeting (March 98) and didn't find >any mention of a discussion. > >I'm new to the IPP group. >So, would someone point me to the correct place? > >Thanks > Frank Mason > >Frank I. Mason >Frankm@extendsys.com >http://www.extendsys.com >Extended Systems Inc. >5777 N. Meeker Ave. >Boise, ID 83713 >208.322.7575 (voice) > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sat Apr 25 02:20:01 1998 Delivery-Date: Sat, 25 Apr 1998 02:20:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA23756 for ; Sat, 25 Apr 1998 02:20:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA24776 for ; Sat, 25 Apr 1998 00:00:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03860 for ; Fri, 24 Apr 1998 23:57:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Apr 1998 23:52:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA03306 for ipp-outgoing; Fri, 24 Apr 1998 23:48:17 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Kris Schoff'" , "'SISAACSON@novell.com'" , "'ipp@pwg.org'" Subject: RE: IPP> ADM - Reminder about job openings and home work assignme nts Date: Fri, 24 Apr 1998 20:42:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org I have some reservations about using the concept of using IPP to encapsulate OID to access SNMP MIB objects. I think we should be very careful about the scope and requirements for such a capability. The biggest problem I guess I have with this is that we MUST make sure that IPP is not used to circumvent or hack access to manageable objects which might otherwise be secured by standard SNMP security methods. There are other considerations such as the definition of request and response attributes, and whether or not we have a rich enough value syntax to describe current SMI data objects. I could go on but its Friday night and I'm getting dirty looks...;) Randy > -----Original Message----- > From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com] > Sent: Friday, April 24, 1998 4:41 PM > To: 'SISAACSON@novell.com'; 'ipp@pwg.org' > Subject: RE: IPP> ADM - Reminder about job openings and home work > assignme nts > > Scott, > > I would be very interested in tunneling SNMP OID's through IPP for > printer management. It seems like a very reasonable concept to do and > it could allow for the enabling of millions of printers in existence > today. I'd like to see you continue your effort within IPP. > > I am still a proponent that IPP was intended to become a universal, > catch-all printing protocol - which is why I am not on the SDP mailing > list. By definition of "Server-to-Device", it would seem as if the > client is already being left out. I could have sworn that some people > within the IPP WG were trying to limit the number of protocols that > needed to be implemented.... > > Kris Schoff > > > > > > -----Original Message----- > > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] > > Sent: Wednesday, April 22, 1998 1:58 PM > > To: kschoff@hpb18423.boi.hp.com > > Subject: Re: IPP> ADM - Reminder about job openings and home work > > assignments > > > > Message-Id: > > Date: Wed, 22 Apr 1998 13:35:23 -0600 > > Subject: > > Sender: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > FROM: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > TO: cmanros@cp10.es.xerox.com, > > ipp@pwg.org > > Encoding: 17 text > > > > > > >>> Carl-Uno Manros 04/22 11:23 AM >>> > > > (snip) > > >HOME WORK ASSIGNMENTS > > > > > > (snip) > > > > > > 4) Revised draft on getting MIB info over IPP - Uncertain whether > > this is > > > still part of IPP or should be part of the SDP discussion? (Scott > > I.) > > > > Unless this is still part of an IPP discussion, then I am not > > interested in > > participating. I plan to rev the document and post and an I-D > (non-WG > > draft if necessary), but I would like for it to be a WG draft. > > > > Scott > > From ipp-owner@pwg.org Mon Apr 27 09:49:30 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25291 for ; Mon, 27 Apr 1998 09:49:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA01656 for ; Mon, 27 Apr 1998 01:26:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA01274 for ; Mon, 27 Apr 1998 01:23:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 01:17:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA00366 for ipp-outgoing; Mon, 27 Apr 1998 01:16:29 -0400 (EDT) Message-Id: <199804270509.WAA20789@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 26 Apr 1998 22:33:51 -0700 To: ipp@pwg.org From: Randy Turner Subject: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Let me attempt to clarify my position on this effort to provide another mechanism for accessing MIB data from IPP/SDP. Philosophically, I would like to see only SNMP used to access MIB data through OID mechanisms. Technically, I understand that we can also implement tunnels or "backdoors" in other protocols that attempt to "hack" into the MIB data stream and take advantage of the OID naming scopes that are used currently to expose existing MIB data. If we were to define another naming scope, say "attributes", that reflected object-for-object, the data objects that are in our MIBs, then I would be less opposed. To some degree we have already started doing this that in the existing IPP 1.0 printer object attribute set. The fact that we are switching naming scopes (printer-attributes over to SNMP OIDs) in midstream seems a little odd, and emphasizes the technical "shortcut" we are attempting, thus confusing the IPP model. I would much prefer us to extend IPP the way we originally intended, through the use of additional printer attributes. I think I will always have reservations about doing this, but if the PWG decides they want to do this anyway, then I would urge the PWG to include text in whatever document is generated that says something like "If this mechanism is implemented co-resident with an existing SNMP agent, then the mechanism must support, at a minimum, the minimum level of security that the SNMP agent provides for the same objects". This should be a mandatory compliance statement, and not just a strongly worded suggestion. This would give future network administrators at least some comfort that there printer MIB data cannot be "hacked". From ipp-owner@pwg.org Mon Apr 27 09:49:29 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25285 for ; Mon, 27 Apr 1998 09:49:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02186 for ; Mon, 27 Apr 1998 08:10:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA11454 for ; Mon, 27 Apr 1998 08:07:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 07:57:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA10900 for ipp-outgoing; Mon, 27 Apr 1998 07:54:56 -0400 (EDT) Content-return: allowed Date: Mon, 27 Apr 1998 04:54:37 PDT From: "Zehler, Peter " Subject: RE: IPP> ADM - Reminder about job openings and home work assignme nts To: "Turner, Randy" , "'Kris Schoff'" , "'SISAACSON@novell.com'" , "'ipp@pwg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org All, I do not share most of Randy's concerns. I see the printer MIB as an agreed upon standard way of representing a printer. I believe it is rich enough to satisfy IPP's "host to device" needs. I am not concerned about circumventing standard SNMP security mechanisms. There are currently embedded web servers that also update the MIB objects. I see three views into the same data objects. The three are SNMP, Web Access and IPP. The implementers must insure that the model is not corrupted by multiple access methods. I see no difference between the "multiple view" scenario and multiple SNMP managers manipulating the printer object. I am also not concerned by the ability for IPP to carry SNMP syntax. As far as I know there is nothing in SMI that cannot be represented in IPP. The areas that I do have some concerns in is the definition of the req/resp for the printer MIB access operations. The other feature I am concerned with is the overlap of notification methods in SNMP and IPP. I have not yet seen if the overlap needs to be addressed. If the overlap needs to be addressed how will it be resolved? Pete -----Original Message----- From: Turner, Randy [SMTP:rturner@sharplabs.com] Sent: Friday, April 24, 1998 11:42 PM To: 'Kris Schoff'; 'SISAACSON@novell.com'; 'ipp@pwg.org' Subject: RE: IPP> ADM - Reminder about job openings and home work assignme nts I have some reservations about using the concept of using IPP to encapsulate OID to access SNMP MIB objects. I think we should be very careful about the scope and requirements for such a capability. The biggest problem I guess I have with this is that we MUST make sure that IPP is not used to circumvent or hack access to manageable objects which might otherwise be secured by standard SNMP security methods. There are other considerations such as the definition of request and response attributes, and whether or not we have a rich enough value syntax to describe current SMI data objects. I could go on but its Friday night and I'm getting dirty looks...;) Randy > -----Original Message----- > From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com] > Sent: Friday, April 24, 1998 4:41 PM > To: 'SISAACSON@novell.com'; 'ipp@pwg.org' > Subject: RE: IPP> ADM - Reminder about job openings and home work > assignme nts > > Scott, > > I would be very interested in tunneling SNMP OID's through IPP for > printer management. It seems like a very reasonable concept to do and > it could allow for the enabling of millions of printers in existence > today. I'd like to see you continue your effort within IPP. > > I am still a proponent that IPP was intended to become a universal, > catch-all printing protocol - which is why I am not on the SDP mailing > list. By definition of "Server-to-Device", it would seem as if the > client is already being left out. I could have sworn that some people > within the IPP WG were trying to limit the number of protocols that > needed to be implemented.... > > Kris Schoff > > > > > > -----Original Message----- > > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] > > Sent: Wednesday, April 22, 1998 1:58 PM > > To: kschoff@hpb18423.boi.hp.com > > Subject: Re: IPP> ADM - Reminder about job openings and home work > > assignments > > > > Message-Id: > > Date: Wed, 22 Apr 1998 13:35:23 -0600 > > Subject: > > Sender: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > FROM: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > TO: cmanros@cp10.es.xerox.com, > > ipp@pwg.org > > Encoding: 17 text > > > > > > >>> Carl-Uno Manros 04/22 11:23 AM >>> > > > (snip) > > >HOME WORK ASSIGNMENTS > > > > > > (snip) > > > > > > 4) Revised draft on getting MIB info over IPP - Uncertain whether > > this is > > > still part of IPP or should be part of the SDP discussion? (Scott > > I.) > > > > Unless this is still part of an IPP discussion, then I am not > > interested in > > participating. I plan to rev the document and post and an I-D > (non-WG > > draft if necessary), but I would like for it to be a WG draft. > > > > Scott > > From ipp-owner@pwg.org Mon Apr 27 09:49:31 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25295 for ; Mon, 27 Apr 1998 09:49:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA01392 for ; Sun, 26 Apr 1998 22:13:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29264 for ; Sun, 26 Apr 1998 22:11:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 26 Apr 1998 22:02:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA28703 for ipp-outgoing; Sun, 26 Apr 1998 22:02:01 -0400 (EDT) Message-Id: <199804270155.SAA20343@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 26 Apr 1998 19:18:08 -0700 To: don@lexmark.com From: Randy Turner Subject: RE: IPP> ADM - Reminder about job openings and home work ass Cc: Harryl@Us.Ibm.Com, Ipp@pwg.org, Kschoff@hpb18423.boi.hp.com, Sisaacson@novell.com In-Reply-To: <199804261901.AA05325@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The fact that no one is shipping SNMPv3 today in printers is irrevelant. No one is shipping IPP with security today either. We are designing protocols that will have to last for a number of years, so we have to consider the way networks are managed today, as well as how they are likely to be managed in the future. Also, because we chose to make security optional in IPP 1.0, this means that most embedded printer vendors probably will not implement it. And the available security methods available for SNMPv3 are more robust than "digest" or "basic" HTTP authentication, which even these security mechanisms wouldn't even be available in something as "lightweight" as SDP. Randy At 02:55 PM 4/26/98 -0400, don@lexmark.com wrote: > >Randy Turner said: > >>What I would not like to hear from folks is..."well,SNMP has no security", >and >>"well, SNMP doesn't do traps reliably". If you read the minutes from the >last >>IETF Plenary in L.A, specifically the SNMPv3 WG minutes, SNMPv3 >implementation >>and availability after 6 months at "proposed" is already past where v2 was >>after two years at "proposed". The point is, we're designing stuff that >probably >>won't be deployed until 1999, when in network management circles SNMPv3 >will reach >>the dominant position, if kept at its current pace of implementation. >> >>SNMPv3 has some of the same security mechanisms at IPP, and you are going >>to have to reconcile these two models if you provide a backdoor to MIB >>data, whether you are reading, or writing these objects. > >Gosh, let me count the number of printers that implement SNMPv3 .... > >-- ZERO !! > >Therefore if we allow access to the MIB Objects through IPP which includes >TLS, I contend there are no security problem. Accesssing MIB objects using >IPP would much, much more secure than accessing those same objects via the >currently popular SNMPv1 implementations. > > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > From ipp-owner@pwg.org Mon Apr 27 09:49:35 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25320 for ; Mon, 27 Apr 1998 09:49:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00871 for ; Sun, 26 Apr 1998 15:10:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA28258 for ; Sun, 26 Apr 1998 15:07:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 26 Apr 1998 15:02:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27695 for ipp-outgoing; Sun, 26 Apr 1998 15:02:27 -0400 (EDT) From: don@lexmark.com Message-Id: <199804261901.AA05324@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com Cc: Harryl@Us.Ibm.Com, Ipp@pwg.org, Kschoff@hpb18423.boi.hp.com, Sisaacson@novell.com Date: Sun, 26 Apr 1998 14:55:56 -0400 Subject: RE: IPP> ADM - Reminder about job openings and home work ass Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Randy Turner said: >What I would not like to hear from folks is..."well,SNMP has no security", and >"well, SNMP doesn't do traps reliably". If you read the minutes from the last >IETF Plenary in L.A, specifically the SNMPv3 WG minutes, SNMPv3 implementation >and availability after 6 months at "proposed" is already past where v2 was >after two years at "proposed". The point is, we're designing stuff that probably >won't be deployed until 1999, when in network management circles SNMPv3 will reach >the dominant position, if kept at its current pace of implementation. > >SNMPv3 has some of the same security mechanisms at IPP, and you are going >to have to reconcile these two models if you provide a backdoor to MIB >data, whether you are reading, or writing these objects. Gosh, let me count the number of printers that implement SNMPv3 .... -- ZERO !! Therefore if we allow access to the MIB Objects through IPP which includes TLS, I contend there are no security problem. Accesssing MIB objects using IPP would much, much more secure than accessing those same objects via the currently popular SNMPv1 implementations. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Apr 27 09:49:36 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25329 for ; Mon, 27 Apr 1998 09:49:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA00495 for ; Sun, 26 Apr 1998 09:25:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA27390 for ; Sun, 26 Apr 1998 09:22:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 26 Apr 1998 09:12:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26818 for ipp-outgoing; Sun, 26 Apr 1998 09:10:02 -0400 (EDT) Message-Id: <199804261302.GAA19403@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 26 Apr 1998 06:22:47 -0700 To: Harry Lewis , From: Randy Turner Subject: RE: IPP> ADM - Reminder about job openings and home work ass Cc: , In-Reply-To: <5030300020343413000002L032*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Just because you "can" do something doesn't necessarily mean you "should". What I would not like to hear from folks is..."well,SNMP has no security", and "well, SNMP doesn't do traps reliably". If you read the minutes from the last IETF Plenary in L.A, specifically the SNMPv3 WG minutes, SNMPv3 implementation and availability after 6 months at "proposed" is already past where v2 was after two years at "proposed". The point is, we're designing stuff that probably won't be deployed until 1999, when in network management circles SNMPv3 will reach the dominant position, if kept at its current pace of implementation. SNMPv3 has some of the same security mechanisms at IPP, and you are going to have to reconcile these two models if you provide a backdoor to MIB data, whether you are reading, or writing these objects. If SDP is only going to be implemented over direct-attach, point-to-point interfaces like RS232 or 1284, then I would relax my stance somewhat, but not much. Randy At 02:00 AM 4/26/98 -0400, Harry Lewis wrote: >With the goal of "IPP SDP" to have one protocol for submission and management, >I see two paths. > >1. Create an entirely redundant encoding of all the Printer MIB objects for >this new SDP protocol >2. Provide a way for the SDP to access the current MIB OIDs. > >Given that many (most?) of us already have the Printer MIB data representation >in our printers, I prefer (2). > >I can see Randy's point if the desire was to keep print submission and >management separate, but I think, if you accept the premise of SDP in the first >place, you must abandon this approach. > >As for security, this seems like an odd reasoning. Security was always one of >SNMP's weak points and something IPP has struggled to achieve. Besides, I don't >think Scott has recommended and SETs to the OIDs. > >One of the highlights of SENSE I remember Jay telling us about was that, with >one query, he could get the whole Printer MIB. It didn't seem like a threat >then. > >Harry Lewis - IBM Printing Systems > > > > >owner-ipp@pwg.org on 04/24/98 09:53:49 PM >Please respond to owner-ipp@pwg.org >To: ipp@pwg.org, SISAACSON@novell.com, kschoff@hpb18423.boi.hp.com >cc: >Subject: RE: IPP> ADM - Reminder about job openings and home work ass > > > >I have some reservations about using the concept of using IPP to >encapsulate OID to access SNMP MIB objects. I think we should be very >careful about the scope and requirements for such a capability. The >biggest problem I guess I have with this is that we MUST make sure that >IPP is not used to circumvent or hack access to manageable objects which >might otherwise be secured by standard SNMP security methods. There are >other considerations such as the definition of request and response >attributes, and whether or not we have a rich enough value syntax to >describe current SMI data objects. >I could go on but its Friday night and I'm getting dirty looks...;) > >Randy > >> -----Original Message----- >> From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com] >> Sent: Friday, April 24, 1998 4:41 PM >> To: 'SISAACSON@novell.com'; 'ipp@pwg.org' >> Subject: RE: IPP> ADM - Reminder about job openings and home work >> assignme nts >> >> Scott, >> >> I would be very interested in tunneling SNMP OID's through IPP for >> printer management. It seems like a very reasonable concept to do and >> it could allow for the enabling of millions of printers in existence >> today. I'd like to see you continue your effort within IPP. >> >> I am still a proponent that IPP was intended to become a universal, >> catch-all printing protocol - which is why I am not on the SDP mailing >> list. By definition of "Server-to-Device", it would seem as if the >> client is already being left out. I could have sworn that some people >> within the IPP WG were trying to limit the number of protocols that >> needed to be implemented.... >> >> Kris Schoff >> >> >> >> >> > -----Original Message----- >> > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] >> > Sent: Wednesday, April 22, 1998 1:58 PM >> > To: kschoff@hpb18423.boi.hp.com >> > Subject: Re: IPP> ADM - Reminder about job openings and home work >> > assignments >> > >> > Message-Id: >> > Date: Wed, 22 Apr 1998 13:35:23 -0600 >> > Subject: >> > Sender: >> > >> Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# >> > com@hpbs1480 >> > FROM: >> > >> Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# >> > com@hpbs1480 >> > TO: cmanros@cp10.es.xerox.com, >> > ipp@pwg.org >> > Encoding: 17 text >> > >> > >> > >>> Carl-Uno Manros 04/22 11:23 AM >>> >> > > (snip) >> > >HOME WORK ASSIGNMENTS >> > > >> > > (snip) >> > > >> > > 4) Revised draft on getting MIB info over IPP - Uncertain whether >> > this is >> > > still part of IPP or should be part of the SDP discussion? (Scott >> > I.) >> > >> > Unless this is still part of an IPP discussion, then I am not >> > interested in >> > participating. I plan to rev the document and post and an I-D >> (non-WG >> > draft if necessary), but I would like for it to be a WG draft. >> > >> > Scott >> > > From ipp-owner@pwg.org Mon Apr 27 09:49:37 1998 Delivery-Date: Mon, 27 Apr 1998 09:49:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25337 for ; Mon, 27 Apr 1998 09:49:37 -0400 (EDT) Received: from lists.underscore.com ([199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA26538 for ; Sun, 26 Apr 1998 02:08:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA18242 for ; Sun, 26 Apr 1998 02:06:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 26 Apr 1998 01:57:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA17685 for ipp-outgoing; Sun, 26 Apr 1998 01:53:18 -0400 (EDT) From: Harry Lewis To: , Cc: , Subject: RE: IPP> ADM - Reminder about job openings and home work ass Message-ID: <5030300020343413000002L032*@MHS> Date: Sun, 26 Apr 1998 02:00:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id JAA25337 With the goal of "IPP SDP" to have one protocol for submission and management, I see two paths. 1. Create an entirely redundant encoding of all the Printer MIB objects for this new SDP protocol 2. Provide a way for the SDP to access the current MIB OIDs. Given that many (most?) of us already have the Printer MIB data representation in our printers, I prefer (2). I can see Randy's point if the desire was to keep print submission and management separate, but I think, if you accept the premise of SDP in the first place, you must abandon this approach. As for security, this seems like an odd reasoning. Security was always one of SNMP's weak points and something IPP has struggled to achieve. Besides, I don't think Scott has recommended and SETs to the OIDs. One of the highlights of SENSE I remember Jay telling us about was that, with one query, he could get the whole Printer MIB. It didn't seem like a threat then. Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 04/24/98 09:53:49 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org, SISAACSON@novell.com, kschoff@hpb18423.boi.hp.com cc: Subject: RE: IPP> ADM - Reminder about job openings and home work ass I have some reservations about using the concept of using IPP to encapsulate OID to access SNMP MIB objects. I think we should be very careful about the scope and requirements for such a capability. The biggest problem I guess I have with this is that we MUST make sure that IPP is not used to circumvent or hack access to manageable objects which might otherwise be secured by standard SNMP security methods. There are other considerations such as the definition of request and response attributes, and whether or not we have a rich enough value syntax to describe current SMI data objects. I could go on but its Friday night and I'm getting dirty looks...;) Randy > -----Original Message----- > From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com] > Sent: Friday, April 24, 1998 4:41 PM > To: 'SISAACSON@novell.com'; 'ipp@pwg.org' > Subject: RE: IPP> ADM - Reminder about job openings and home work > assignme nts > > Scott, > > I would be very interested in tunneling SNMP OID's through IPP for > printer management. It seems like a very reasonable concept to do and > it could allow for the enabling of millions of printers in existence > today. I'd like to see you continue your effort within IPP. > > I am still a proponent that IPP was intended to become a universal, > catch-all printing protocol - which is why I am not on the SDP mailing > list. By definition of "Server-to-Device", it would seem as if the > client is already being left out. I could have sworn that some people > within the IPP WG were trying to limit the number of protocols that > needed to be implemented.... > > Kris Schoff > > > > > > -----Original Message----- > > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] > > Sent: Wednesday, April 22, 1998 1:58 PM > > To: kschoff@hpb18423.boi.hp.com > > Subject: Re: IPP> ADM - Reminder about job openings and home work > > assignments > > > > Message-Id: > > Date: Wed, 22 Apr 1998 13:35:23 -0600 > > Subject: > > Sender: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > FROM: > > > Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > com@hpbs1480 > > TO: cmanros@cp10.es.xerox.com, > > ipp@pwg.org > > Encoding: 17 text > > > > > > >>> Carl-Uno Manros 04/22 11:23 AM >>> > > > (snip) > > >HOME WORK ASSIGNMENTS > > > > > > (snip) > > > > > > 4) Revised draft on getting MIB info over IPP - Uncertain whether > > this is > > > still part of IPP or should be part of the SDP discussion? (Scott > > I.) > > > > Unless this is still part of an IPP discussion, then I am not > > interested in > > participating. I plan to rev the document and post and an I-D > (non-WG > > draft if necessary), but I would like for it to be a WG draft. > > > > Scott > > From ipp-owner@pwg.org Mon Apr 27 11:28:41 1998 Delivery-Date: Mon, 27 Apr 1998 11:28:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00998 for ; Mon, 27 Apr 1998 11:28:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03026 for ; Mon, 27 Apr 1998 11:30:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA12298 for ; Mon, 27 Apr 1998 11:28:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 11:23:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA11730 for ipp-outgoing; Mon, 27 Apr 1998 11:18:20 -0400 (EDT) Message-Id: <199804271458.HAA21986@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 27 Apr 1998 08:22:29 -0700 To: "Zehler, Peter " , "'Kris Schoff'" , "'SISAACSON@novell.com'" , "'ipp@pwg.org'" From: Randy Turner Subject: RE: IPP> ADM - Reminder about job openings and home work assignme nts In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I also agree that the Printer MIB is an agreed upon way to represent a Printer, and it, and SNMP, are rich enough to satisfy an IPP profile for a host-to-device managment protocol. I believe there are also embedded web servers that access (in a different way than OIDs), printer MIB objects. Very few of these servers allow you to "update" these objects, usually they just display them. And if these web servers do allow users to update these objects, and do NOT allow a way to secure updating these objects, then this system is broken. Especially if these are high-end departmental or enterprise printing facilities. At the end of Peter's message is the list of things he is concerned about. I think there are alot of other design issues that will have to be addressed. It seems to me that there were decisions made during the design of the Printer MIB, and its links to the host MIB, that presumed that the objects would be retrieved using SNMP mechanisms, and we might have relied on the fact that indices and other information are automatically returned by SNMP PDUs. My overall opinion is that its not entirely necessary to have one protocol (IPP) be good at everything, its just going to get very complex (and huge) to implement. We should use the best tool for the job and there are semantic and operational aspects of the IPP model that do not translate well (IMHO) to a robust device management protocol. Randy At 04:54 AM 4/27/98 -0700, Zehler, Peter wrote: >All, > I do not share most of Randy's concerns. I see the printer MIB as an >agreed upon standard way of representing a printer. I believe it is rich >enough to satisfy IPP's "host to device" needs. I am not concerned about >circumventing standard SNMP security mechanisms. There are currently >embedded web servers that also update the MIB objects. I see three views >into the same data objects. The three are SNMP, Web Access and IPP. The >implementers must insure that the model is not corrupted by multiple access >methods. I see no difference between the "multiple view" scenario and >multiple SNMP managers manipulating the printer object. I am also not >concerned by the ability for IPP to carry SNMP syntax. As far as I know >there is nothing in SMI that cannot be represented in IPP. > The areas that I do have some concerns in is the definition of the >req/resp for the printer MIB access operations. The other feature I am >concerned with is the overlap of notification methods in SNMP and IPP. I >have not yet seen if the overlap needs to be addressed. If the overlap >needs to be addressed how will it be resolved? >Pete > > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Friday, April 24, 1998 11:42 PM > To: 'Kris Schoff'; 'SISAACSON@novell.com'; 'ipp@pwg.org' > Subject: RE: IPP> ADM - Reminder about job openings and home >work assignme nts > > > I have some reservations about using the concept of using IPP to > encapsulate OID to access SNMP MIB objects. I think we should be >very > careful about the scope and requirements for such a capability. The > biggest problem I guess I have with this is that we MUST make sure >that > IPP is not used to circumvent or hack access to manageable objects >which > might otherwise be secured by standard SNMP security methods. There >are > other considerations such as the definition of request and response > attributes, and whether or not we have a rich enough value syntax to > describe current SMI data objects. > I could go on but its Friday night and I'm getting dirty looks...;) > > Randy > > > -----Original Message----- > > From: Kris Schoff [SMTP:kschoff@hpb18423.boi.hp.com] > > Sent: Friday, April 24, 1998 4:41 PM > > To: 'SISAACSON@novell.com'; 'ipp@pwg.org' > > Subject: RE: IPP> ADM - Reminder about job openings and home >work > > assignme nts > > > > Scott, > > > > I would be very interested in tunneling SNMP OID's through IPP for > > printer management. It seems like a very reasonable concept to do >and > > it could allow for the enabling of millions of printers in >existence > > today. I'd like to see you continue your effort within IPP. > > > > I am still a proponent that IPP was intended to become a >universal, > > catch-all printing protocol - which is why I am not on the SDP >mailing > > list. By definition of "Server-to-Device", it would seem as if >the > > client is already being left out. I could have sworn that some >people > > within the IPP WG were trying to limit the number of protocols >that > > needed to be implemented.... > > > > Kris Schoff > > > > > > > > > > > -----Original Message----- > > > From: SISAACSON@novell.com [SMTP:SISAACSON@novell.com] > > > Sent: Wednesday, April 22, 1998 1:58 PM > > > To: kschoff@hpb18423.boi.hp.com > > > Subject: Re: IPP> ADM - Reminder about job openings and home >work > > > assignments > > > > > > Message-Id: > > > Date: Wed, 22 Apr 1998 13:35:23 -0600 > > > Subject: > > > Sender: > > > > > >Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > > com@hpbs1480 > > > FROM: > > > > > >Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f# > > > com@hpbs1480 > > > TO: cmanros@cp10.es.xerox.com, > > > ipp@pwg.org > > > Encoding: 17 text > > > > > > > > > >>> Carl-Uno Manros 04/22 11:23 AM >>>> > > > > (snip) > > > >HOME WORK ASSIGNMENTS > > > > > > > > (snip) > > > > > > > > 4) Revised draft on getting MIB info over IPP - Uncertain >whether > > > this is > > > > still part of IPP or should be part of the SDP discussion? >(Scott > > > I.) > > > > > > Unless this is still part of an IPP discussion, then I am not > > > interested in > > > participating. I plan to rev the document and post and an I-D > > (non-WG > > > draft if necessary), but I would like for it to be a WG draft. > > > > > > Scott > > > > From ipp-owner@pwg.org Mon Apr 27 13:02:17 1998 Delivery-Date: Mon, 27 Apr 1998 13:02:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA04313 for ; Mon, 27 Apr 1998 13:02:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03589 for ; Mon, 27 Apr 1998 13:04:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA12989 for ; Mon, 27 Apr 1998 13:02:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 12:58:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA12449 for ipp-outgoing; Mon, 27 Apr 1998 12:55:05 -0400 (EDT) From: don@lexmark.com Message-Id: <199804271654.AA26187@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com Cc: Ipp@pwg.org Date: Mon, 27 Apr 1998 12:48:23 -0400 Subject: Re: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Randy Turner said >If we were to define another naming scope, say "attributes", that reflected >object-for-object, the data objects that are in our MIBs, then I would be >less opposed. To some degree we have already started doing this that in the >existing IPP 1.0 printer object attribute set. Randy, I can't believe you said this. Is this security by obscurity? OK, rather than call them OIDs will pick random series of numbers separated by periods (that happen to match the MIB) to identify the attributes we want and call them PORN - "Printer Object Random Numbers" Anyone object? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Apr 27 13:09:15 1998 Delivery-Date: Mon, 27 Apr 1998 13:09:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA04543 for ; Mon, 27 Apr 1998 13:09:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03623 for ; Mon, 27 Apr 1998 13:11:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA13938 for ; Mon, 27 Apr 1998 13:09:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 13:03:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA12899 for ipp-outgoing; Mon, 27 Apr 1998 13:01:29 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'don@lexmark.com'" , rturner@sharplabs.com Cc: Ipp@pwg.org Subject: RE: IPP> Using OID access with IPP/SDP Date: Mon, 27 Apr 1998 10:02:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Pick whatever naming scope you wish, just pick ONE. We already have printer attributes, why not stick with em'. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Monday, April 27, 1998 9:48 AM To: rturner@sharplabs.com Cc: Ipp@Pwg.Org Subject: Re: IPP> Using OID access with IPP/SDP Randy Turner said >If we were to define another naming scope, say "attributes", that reflected >object-for-object, the data objects that are in our MIBs, then I would be >less opposed. To some degree we have already started doing this that in the >existing IPP 1.0 printer object attribute set. Randy, I can't believe you said this. Is this security by obscurity? OK, rather than call them OIDs will pick random series of numbers separated by periods (that happen to match the MIB) to identify the attributes we want and call them PORN - "Printer Object Random Numbers" Anyone object? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Apr 27 13:27:02 1998 Delivery-Date: Mon, 27 Apr 1998 13:27:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05161 for ; Mon, 27 Apr 1998 13:27:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03726 for ; Mon, 27 Apr 1998 13:29:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15152 for ; Mon, 27 Apr 1998 13:26:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 13:23:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14617 for ipp-outgoing; Mon, 27 Apr 1998 13:19:41 -0400 (EDT) Message-Id: <3.0.1.32.19980427100717.00c36d40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 27 Apr 1998 10:07:17 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 980429 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org PWG IPP Phone Conference 980429 =============================== We will hold a phone conference this week. Main agenda point is to discuss the revised IPP Notifications proposal from Harry Lewis and Tom Hastings. I hope that we can get this out as an Internet-Draft after our review in the conference. We may also want to spend some time on the discussion about reaching MIB information over IPP. As usual, I think some initial agreements about scope and requirements would be useful... The conference information is: Time: April 29, 10:00 am PDT (1:00 pm EDT) Number: 1-800-857 5607 (Xerox internal 5*535 5000) Note FREE! Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 27 13:52:04 1998 Delivery-Date: Mon, 27 Apr 1998 13:52:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05811 for ; Mon, 27 Apr 1998 13:52:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03835 for ; Mon, 27 Apr 1998 13:54:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA15793 for ; Mon, 27 Apr 1998 13:51:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 13:48:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA15250 for ipp-outgoing; Mon, 27 Apr 1998 13:46:41 -0400 (EDT) From: Harry Lewis To: , Cc: , Subject: RE: IPP> Using OID access with IPP/SDP Message-ID: <5030300020373184000002L042*@MHS> Date: Mon, 27 Apr 1998 13:54:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id NAA05811 Randy said... >If we were to define another naming scope, say "attributes", >that reflected object-for-object, the data objects that are >in our MIBs, then I would be less opposed. To some degree >we have already started doing this in the >existing IPP 1.0 printer object attribute set. The main concern I have with using string named attributes rather than the distinguishing part of the Printer MIB OID is the processing required to differentiate strings vs. the (relatively short) OID stubs. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Apr 27 14:32:22 1998 Delivery-Date: Mon, 27 Apr 1998 14:32:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07265 for ; Mon, 27 Apr 1998 14:32:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04026 for ; Mon, 27 Apr 1998 14:34:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA16596 for ; Mon, 27 Apr 1998 14:32:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 14:28:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16073 for ipp-outgoing; Mon, 27 Apr 1998 14:27:40 -0400 (EDT) Message-Id: <3.0.1.32.19980427095229.00c36bc0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 27 Apr 1998 09:52:29 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-iesg-rfc-checklist-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org This document might be of special interst to the editors, but also for anybody else crafting texts for inclusion in our drafts. Carl-Uno Carl-Uno>To: IETF-Announce:; >Cc: iesg@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-iesg-rfc-checklist-00.txt >Date: Mon, 27 Apr 1998 07:13:13 PDT >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IETF Steering Group Working Group of the IETF. > > Title : (DRAFT) Checklist for RFC Authors > Author(s) : K. Moore > Filename : draft-iesg-rfc-checklist-00.txt > Pages : 6 > Date : 24-Apr-98 > >This is a list of things that often delay processing of RFCs by >IESG and/or the RFC Editor, and which are often preventable by RFC >authors. The purpose of this document is to list in one place the most >frequent causes of unnecessary delay, and thereby help RFC authors >minimize such delays when possible. > >This document is emphatically NOT an expression of IESG policy, >nor that of the RFC Editor, and is provided merely for informational >purposes. When appropriate, this document attempts to provide >references to other documents, some of which are expressions of >IESG, IETF, and/or RFC Editor policy and others which are merely >informational. Readers are advised to check the official status >of each reference. > >The RFC Editor's instructions to RFC Authors are >in [rfc-instructions]. > >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-iesg-rfc-checklist-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-iesg-rfc-checklist-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-iesg-rfc-checklist-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 27 14:57:17 1998 Delivery-Date: Mon, 27 Apr 1998 14:57:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08180 for ; Mon, 27 Apr 1998 14:57:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04180 for ; Mon, 27 Apr 1998 14:59:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17308 for ; Mon, 27 Apr 1998 14:56:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 14:53:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16777 for ipp-outgoing; Mon, 27 Apr 1998 14:48:07 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 27 Apr 1998 12:47:25 -0600 From: "Scott Isaacson" To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id OAA08180 My comments preceded by SAI> >>> Randy Turner 04/26 11:33 PM >>> > >Let me attempt to clarify my position on this effort to provide another >mechanism for accessing MIB data from IPP/SDP. Philosophically, I would >like to see only SNMP used to access MIB data through OID mechanisms. >Technically, I understand that we can also implement tunnels or "backdoors" >in other protocols that attempt to "hack" into the MIB data stream and take >advantage of the OID naming scopes that are used currently to expose >existing MIB data. SAI> I see SNMP being used to MANAGE the printer. I do not see using IPP SAI> to MANAGE the printer. I see IPP as being a protocol that an end user SAI> uses (or an application on behalf of an end user) to query the printer SAI> for characteristics and capabilities that help in requesting options or SAI> or formatting the job and then submitting the job and tracking and SAI> simple management of that job (just query and cancel). As Harry L. SAI> pointed out, I do not see MIB SETs in IPP, so I don't see a "hack" SAI> or a "back door". I see a simple IPP front door (with a video SAI> surveillance camera) just to see what the printer looks like. We SAI> can only WIN of the IPP model of the Printer is the same as SAI> SNMP Printer MIB model of the Printer! >If we were to define another naming scope, say "attributes", that reflected >object-for-object, the data objects that are in our MIBs, then I would be >less opposed. To some degree we have already started doing this that in the >existing IPP 1.0 printer object attribute set. > The fact that we are switching naming scopes (printer-attributes over to >SNMP OIDs) in midstream seems a little odd, and emphasizes the technical >"shortcut" we are attempting, thus confusing the IPP model. I would much >prefer us to extend IPP the way we originally intended, through the use of >additional printer attributes. SAI> I see both sides of this argument: we already picked named attributes SAI> for IPP, but in this case we are moving to querying already named SAI> MIB objects (the name is the OID) - so we are just stringifying that name. SAI> Seems consistent. > I think I will always have reservations about doing this, but if the PWG > decides they want to do this anyway, then I would urge the PWG to include > text in whatever document is generated that says something like "If this > mechanism is implemented co-resident with an existing SNMP agent, then the > mechanism must support, at a minimum, the minimum level of security that > the SNMP agent provides for the same objects". This should be a mandatory > compliance statement, and not just a strongly worded suggestion. This would > give future network administrators at least some comfort that there printer > MIB data cannot be "hacked". SAI> I agree with this compliance statement. SAI> If we allow access through two doors to view whats in SAI> the shop, we should have the two security guards at each door working SAI> off the same policy sheet that was passed out at the early morning staff SAI> meeting (i.e., if the sheet says "Don't let Scott Isaacson in here anymore, SAI> he causes problems" then neither guard should allow Scott in either door.) From ipp-owner@pwg.org Mon Apr 27 16:44:22 1998 Delivery-Date: Mon, 27 Apr 1998 16:44:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11310 for ; Mon, 27 Apr 1998 16:44:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04930 for ; Mon, 27 Apr 1998 16:46:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA18099 for ; Mon, 27 Apr 1998 16:43:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 16:38:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA17523 for ipp-outgoing; Mon, 27 Apr 1998 16:33:35 -0400 (EDT) Message-ID: From: Frank Mason To: "'Carl-Uno Manros'" , "'ipp@pwg.org'" Subject: RE: IPP> ? on IPP direction concerning XML Date: Mon, 27 Apr 1998 14:32:29 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Carl-Uno in general I agree with your statement to "Don't believe everything you read in the press" but the article has disturbing quotes (see below) from sources within IPP subgroup. If it is the case that these are misquotes then sorry for the extra traffic but, if these are true issues I have real concerns for the future of IPP. The article goes on to say that MS and HP seem willing to abide by whatever IPP standard is adopted. As you are skeptical of the Press I'm just as skeptical of Microsoft "abiding" by an outside bodies decisions. Please help me to understand this.... Frank Mason Quotes from March issue of THE HARD COPY OBSERVER: ----------------------------------------------------------------------- ----------------------- "At the January meeting of the IPP in Maui, Hawaii, Microsoft (with Hewlett-Packard's support) said it would OPPOSE the current draft standard if the group did not stop the process to consider the change." "Any printing standard that does not have the combined blessing of these two industry giants would be doomed from the start" IPP Member Jay Martin from Underscore "XML-based Internet Printing Solution could compromise the ability of developers to create lightweight implementations of IPP" IPP subgroup member David Kellerman from Northlake SW "Although members are skeptical about the XML proposal, most feel a reluctance and futility about opposing Microsoft and Hewlett-Packard" ----------------------------------------------------------------------- ----------------------- -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Friday, April 24, 1998 7:03 PM To: Frank Mason; 'ipp@pwg.org' Subject: Re: IPP> ? on IPP direction concerning XML The short answer is: Don't believe everything you read in the press. Representatives from Microsoft and HP have declared on this DL that they are implementing what the final decision from the IESG will be. Unfortunately, the IESG is dragging their feet with a proper feedback to this WG (they have had our final drafts since early February). So, we do not know the final outcome for sure, but you can rely on everybody implementing the same standard once it is frozen. Carl-Uno At 03:06 PM 4/24/98 PDT, Frank Mason wrote: >IPP Subgroup, >I'm trying to understand the article "Microsoft, HP Reverse Course on >Internet Printing Protocol" March 98 Hardcopy Observer. The article >states that "A meeting of the IPP subgroup during the week of March 2 >in Austin, TX should shed more light on these issues". I have looked >at the Minutes of the Austin IPP meeting (March 98) and didn't find >any mention of a discussion. > >I'm new to the IPP group. >So, would someone point me to the correct place? > >Thanks > Frank Mason > >Frank I. Mason >Frankm@extendsys.com >http://www.extendsys.com >Extended Systems Inc. >5777 N. Meeker Ave. >Boise, ID 83713 >208.322.7575 (voice) > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Apr 27 17:33:35 1998 Delivery-Date: Mon, 27 Apr 1998 17:33:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA12276 for ; Mon, 27 Apr 1998 17:33:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05221 for ; Mon, 27 Apr 1998 17:35:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA18809 for ; Mon, 27 Apr 1998 17:33:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 17:28:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18243 for ipp-outgoing; Mon, 27 Apr 1998 17:25:34 -0400 (EDT) Content-return: allowed Date: Mon, 27 Apr 1998 07:49:03 PDT From: "Caruso, Angelo " Subject: RE: IPP> Using OID access with IPP/SDP To: ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org Perhaps someone would please enlighten me as to why we need to build Printer MIB OID access into IPP. I thought the intent was to extend the IPP attribute list to eventually cover all the printer MIB stuff. Why is this so difficult? As for security, I guess I agree that IPP should afford the user the same level of security they could achieve using SNMP, but I think this may be a lot of unnecessary hand wringing. There is little that can be "hacked" in the Printer MIB since most of it is read-only. And the little bit that is writable is likely to be far less interesting to a hacker than the credit card account numbers flying over the wire this very minute. Thanks, Angelo From ipp-owner@pwg.org Mon Apr 27 19:47:34 1998 Delivery-Date: Mon, 27 Apr 1998 19:47:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id TAA14190 for ; Mon, 27 Apr 1998 19:47:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05669 for ; Mon, 27 Apr 1998 19:49:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19548 for ; Mon, 27 Apr 1998 19:47:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 19:43:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19013 for ipp-outgoing; Mon, 27 Apr 1998 19:41:10 -0400 (EDT) From: Harry Lewis To: Subject: RE: IPP> Using OID access with IPP/SDP Message-ID: <5030300020384285000002L052*@MHS> Date: Mon, 27 Apr 1998 19:48:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id TAA14190 Angelo asked - >Perhaps someone would please enlighten me as to why we need to build >Printer MIB OID access into IPP. I thought the intent was to extend >the IPP attribute list to eventually cover all the printer MIB stuff. >Why is this so difficult? If we would accept SNMP (v3 perhaps) as the secondary channel between Server and Device we wouldn't have to map OID's to IPP at all. The main convincing argument (aside from "don't like it") I've heard against this is the desire to have one solution for network and local attachments. Tail wagging dog, but still, a valid argument. Once we get to designing a single protocol for submission and monitoring, we wish to maintain use of the MIB datastructures which are already in the device for management purposes. Thus, we might want to extend the IPP attribute list to cover all the printer MIB objects, as you suggest. However, it has been observed that every printer MIB OID already has a unique, fairly terse "OID stub" (the unique part, not the fully qualified OID). Since a lot of effort goes into efficient use of controller MIPs, why make the device parse the longer IPP attribute strings when any IPP application can do the matching for human consumption? Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon Apr 27 23:33:36 1998 Delivery-Date: Mon, 27 Apr 1998 23:33:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA20705 for ; Mon, 27 Apr 1998 23:33:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA06119 for ; Mon, 27 Apr 1998 23:36:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA20485 for ; Mon, 27 Apr 1998 23:33:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 23:28:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA19866 for ipp-outgoing; Mon, 27 Apr 1998 23:26:02 -0400 (EDT) From: don@lexmark.com Message-Id: <199804280325.AA27337@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Ipp@pwg.org, sdp@pwg.org Date: Mon, 27 Apr 1998 23:18:02 -0400 Subject: RE: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Here's where I agree: IEEE Std 1284.1 uses the same concept to allow access to MIB objects. We including then entire OID string which allow access to any MIB including private extensionsm MIB 2, etc. This has worked out very well allowing using common code in the printer and presenting a single, unified presentation of printer status and configuration without having to worry about reconcilling two different name spaces. Additionally since the OID decoding code is already in the printer, the implementation was easy and small -- no need to carry lots of string constants around for comparisons. Here's where I disagree: Microsoft and many others need a single protocol to submit jobs and to manage printers from a server, no matter how the printer is connected: - Parallel - Serial - 1394 - IPX/SPX - TCP/IP - AppleTalk So how do we reconcile the need to submit jobs and manage the printers using one protocol and what Scott Isaacson said: SAI> I see SNMP being used to MANAGE the printer. I do not see using IPP SAI> to MANAGE the printer. I see IPP as being a protocol that an end user SAI> uses (or an application on behalf of an end user) to query the printer SAI> for characteristics and capabilities that help in requesting options or SAI> or formatting the job and then submitting the job and tracking and SAI> simple management of that job (just query and cancel). If everyone agrees that IPP should NOT be used to manage the printer, then we cannot meet the requirement stated above using IPP. That's why we called it SDP (Server to Device Protocol) -- it's got to be fully usable (read and write) so the server can fully understand and control the state of the printer. This really isn't hard. If we are going to meet the requirements then we have to either: 1) Extend IPP to allow job submission and full management and control 2) Document the straightforward mapping of IPP to IEEE Std 1284.1 which already provides the management and controls features needed 3) Create something new. Are there choices I'm missing? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Apr 27 23:47:17 1998 Delivery-Date: Mon, 27 Apr 1998 23:47:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id XAA20869 for ; Mon, 27 Apr 1998 23:47:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA06146 for ; Mon, 27 Apr 1998 23:49:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA21249 for ; Mon, 27 Apr 1998 23:47:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Apr 1998 23:43:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA20641 for ipp-outgoing; Mon, 27 Apr 1998 23:36:49 -0400 (EDT) From: don@lexmark.com Message-Id: <199804280335.AA27557@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: frankm@extendsys.com Cc: Cmanros@Cp10.Es.Xerox.Com, Ipp@pwg.org Date: Mon, 27 Apr 1998 23:32:31 -0400 Subject: RE: IPP> ? on IPP direction concerning XML Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Frank Mason said: Quotes from March issue of THE HARD COPY OBSERVER: ------------------------------------------------------ "At the January meeting of the IPP in Maui, Hawaii, Microsoft (with Hewlett-Packard's support) said it would OPPOSE the current draft standard if the group did not stop the process to consider the change." >FDW> True, I was there. The definition of "OPPOSE" is yet to be >FDW> determined but my memory was they said they would oppose it >FDW> WITHIN the IETF process. Subsequently, they have stated they >FDW> will comply with whatever comes out of the process. "Any printing standard that does not have the combined blessing of these two industry giants would be doomed from the start" IPP Member Jay Martin from Underscore >FDW> Jay's opinion and I agree "XML-based Internet Printing Solution could compromise the ability of developers to create lightweight implementations of IPP" IPP subgroup member David Kellerman from Northlake SW >FDW> David's opinion and I agree "Although members are skeptical about the XML proposal, most feel a reluctance and futility about opposing Microsoft and Hewlett-Packard" >FDW> True, witness the "wide-spread" adoption of IEEE Std 1284.1 ------------------------------------------------------- Oh, well. We might not like it but reality can be ugly at time. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Apr 28 02:18:44 1998 Delivery-Date: Tue, 28 Apr 1998 02:18:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA27602 for ; Tue, 28 Apr 1998 02:18:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06361 for ; Tue, 28 Apr 1998 02:21:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA24446 for ; Tue, 28 Apr 1998 02:18:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 02:13:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA23745 for ipp-outgoing; Tue, 28 Apr 1998 02:09:52 -0400 (EDT) Message-Id: <199804280602.XAA26434@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 27 Apr 1998 23:20:53 -0700 To: don@lexmark.com, Ipp@pwg.org, sdp@pwg.org From: Randy Turner Subject: RE: IPP> Using OID access with IPP/SDP In-Reply-To: <199804280325.AA27337@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org My comments are at the end of Don's last message below... R. At 11:18 PM 4/27/98 -0400, don@lexmark.com wrote: > >Here's where I agree: > >IEEE Std 1284.1 uses the same concept to allow access to MIB objects. We >including then entire OID string which allow access to any MIB including >private extensionsm MIB 2, etc. This has worked out very well allowing >using common code in the printer and presenting a single, unified >presentation of printer status and configuration without having to worry >about reconcilling two different name spaces. Additionally since the OID >decoding code is already in the printer, the implementation was easy and >small -- no need to carry lots of string constants around for comparisons. > >Here's where I disagree: > >Microsoft and many others need a single protocol to submit jobs and to >manage printers from a server, no matter how the printer is connected: > >- Parallel >- Serial >- 1394 >- IPX/SPX >- TCP/IP >- AppleTalk > >So how do we reconcile the need to submit jobs and manage the printers >using one protocol and what Scott Isaacson said: > >SAI> I see SNMP being used to MANAGE the printer. I do not see using IPP >SAI> to MANAGE the printer. I see IPP as being a protocol that an end user >SAI> uses (or an application on behalf of an end user) to query the printer >SAI> for characteristics and capabilities that help in requesting options >or >SAI> or formatting the job and then submitting the job and tracking and >SAI> simple management of that job (just query and cancel). > >If everyone agrees that IPP should NOT be used to manage the printer, then >we cannot meet the requirement stated above using IPP. That's why we >called it SDP (Server to Device Protocol) -- it's got to be fully usable >(read and write) so the server can fully understand and control the state >of the printer. > >This really isn't hard. If we are going to meet the requirements then we >have to either: > >1) Extend IPP to allow job submission and full management > and control >2) Document the straightforward mapping of IPP to IEEE Std 1284.1 > which already provides the management and controls features > needed >3) Create something new. I would add two other possible options...others on the DL are welcome to chime in with their own options. 4) Do nothing (for now). Deploy IPP 1.0 and let real world requirements start accumulating. I really prefer this option, since I think we are REALLY jumping the gun with this effort. With recent comments on the DL, I think its very important that we concentrate on getting IPP 1.0 "out the door" and deployed. We shouldn't appear to be splintering our focus. I do think we need to consider notifications for IPP, but beyond that I would say any presumptions on our part about what else is "needed" by customers is very premature. 5) Consider new transport mappings for IPP, possibly for interfaces such as 1284,1394, USB, and others for which IP is not yet ubiquitous. Randy > >Are there choices I'm missing? > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > From ipp-owner@pwg.org Tue Apr 28 02:43:01 1998 Delivery-Date: Tue, 28 Apr 1998 02:43:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA28340 for ; Tue, 28 Apr 1998 02:43:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06402 for ; Tue, 28 Apr 1998 02:45:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA26315 for ; Tue, 28 Apr 1998 02:42:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 02:38:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA25384 for ipp-outgoing; Tue, 28 Apr 1998 02:35:06 -0400 (EDT) Message-Id: <1.5.4.32.19980428063250.0072e4b4@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Apr 1998 23:32:50 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ? on IPP direction concerning XML Sender: owner-ipp@pwg.org Frank, Sorry if my earlier reply was a bit short and did not give the full story. I will make a new attempt: Officially, people working within the framework of the IETF only represent themselves as invidual experts, rather than the organization they happen to work for.... Having said that, it is clear that we will not get a standard successfully implemented unless the heavyweights support it. As chair of the group, I always have to make sure that we achieve good technical solutions as well as get majority support for these solutions. It is correct that a couple of experts, that happen to work for MS, did bring in a last minute rethink about how the IPP protocol encoding could be done. After intensive discussion within the group, a considerable majority felt that the new approach did not offer enough of an improvement to spend another 6 months or more to re-engiener the current solution, which by the way, had been heavily influenced by one of the experts that now had a different idea. As a result, the group decided to pass on the existing final drafts to the IESG for ratification. Experts from MS and HP made no secret of the fact that they would make use of the rights, that any expert has, to suggest to the IESG to once more consider their proposal. As I indicated in my earlier response, the IESG is still pondering whether to pass the final drafts as is, or ask the group to do further changes to the drafts before they get IESG approval. During the waiting period, some people like Jay Martin started speculating about what would happen if MS and HP decided not to support IPP. In response to that, experts from both MS and HP sent messages to the list confirming that they had no intension of splitting the market and would adhere to the version that gets approved by the IESG. If you happen to be a subscriber to the NT 5.0 betas, you can convince yourself about where these guys are right now. In correspondance with the editor of Hard Copy Observer, I have pointed out that although he has most of his facts correct, he has drawn the wrong conclusions and raised red flags, when in reality we keep on doing our work in the group in a highly cooperative and friendly atmosphere. In standards work, everybody wins a few and loses a few, otherwise we would never get any standards. Hope this gives you no more sleepless nights. Carl-Uno At 02:32 PM 4/27/98 -0600, you wrote: >Carl-Uno in general I agree with your statement to "Don't believe >everything you read in the press" but the article has disturbing >quotes (see below) from sources within IPP subgroup. If it is the >case that these are misquotes then sorry for the extra traffic but, if >these are true issues I have real concerns for the future of IPP. The >article goes on to say that MS and HP seem willing to abide by >whatever IPP standard is adopted. As you are skeptical of the Press >I'm just as skeptical of Microsoft "abiding" by an outside bodies >decisions. > >Please help me to understand this.... > >Frank Mason > From ipp-owner@pwg.org Tue Apr 28 11:11:10 1998 Delivery-Date: Tue, 28 Apr 1998 11:11:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07750 for ; Tue, 28 Apr 1998 11:11:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07759 for ; Tue, 28 Apr 1998 11:13:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA00496 for ; Tue, 28 Apr 1998 11:11:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 10:58:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA29844 for ipp-outgoing; Tue, 28 Apr 1998 10:56:11 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 28 Apr 1998 08:55:10 -0600 From: "Scott Isaacson" To: ipp@pwg.org, Angelo.Caruso@usa.xerox.com Subject: Re: RE: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA07750 Angelo, >>> "Caruso, Angelo " 04/27 8:49 AM >>> >Perhaps someone would please enlighten me as to why we need to build Printer >MIB OID access into IPP. I thought the intent was to extend the IPP >attribute list to eventually cover all the printer MIB stuff. Why is this so >difficult? In the original "Sub-Units" proposal that I presented in Portland, I showed a mapping from MIB OIDs to IPP attribute names. It not really a complete mapping, but examples and some rules of how to complete the mapping. This seemed simple enough to me. This is the direction that I thought we were going. Some of the comments on the proposal during the meeting were: 1. Since an implementation of IPP with Printer MIB sub-unit support will most likely be co-resident with a Printer MIB agent which already names things with OIDs, it would be a waste of resources to require that implementation and agent to translate back and forth between strings and OIDs. So, in order to "extend the IPP attribute list to eventually cover all the printer MIB stuff." the thought process was to name the new attributes by their stringified OIDs rather than some arbtrary symbolic name 2. The discussion seems to be focused on now "how hard can it be" but "is it necessary" since we already have SNMP. 3. If we stick with arbitrary new strings for attributes, it might be harder to get at other MIBs using the same mechanism without a full mapping document. For example, the Finishing MIB. If we just go with stringified OIDs we can easily extend that to any MIB object OID without having to show a mapping to the IPP attribute name. These are just the thoughts behind the disucsisons that I have heard. Scott From owner-mobile-ip@smallworks.com Tue Apr 28 11:16:36 1998 Delivery-Date: Tue, 28 Apr 1998 11:16:37 -0400 Return-Path: owner-mobile-ip@smallworks.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07966 for ; Tue, 28 Apr 1998 11:16:27 -0400 (EDT) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07791 for ; Tue, 28 Apr 1998 11:18:51 -0400 (EDT) Received: (from majordomo@localhost) by hosaka.smallworks.com (8.8.7/8.8.7) id IAA28836 for mobile-ip-dist; Tue, 28 Apr 1998 08:57:45 -0500 (CDT) X-Authentication-Warning: hosaka.smallworks.com: majordomo set sender to owner-mobile-ip using -f Received: from mephisto.inf.tu-dresden.de (mephisto.inf.tu-dresden.de [141.76.49.3]) by hosaka.smallworks.com (8.8.7/8.8.7) with ESMTP id IAA28831 for ; Tue, 28 Apr 1998 08:57:06 -0500 (CDT) Received: from ibdr.inf.tu-dresden.de (lc80.inf.tu-dresden.de [141.76.40.44]) by mephisto.inf.tu-dresden.de (8.8.7/8.8.7) with SMTP id PAA11730; Tue, 28 Apr 1998 15:56:33 +0200 (MET DST) Message-Id: <199804281356.PAA11730@mephisto.inf.tu-dresden.de> Date: Tue, 28 Apr 1998 15:53:40 +0200 From: Thomas Ziegert To: RMI-USERS@JAVASOFT.COM Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ieeetcpc@ccvm.sunysb.edu, multicomm@cc.bellcore.com, cnom@maestro.bellcore.com, hipparch@sophia.inria.fr, cost237-transport@comp.lancs.ac.uk Subject: (mobile-ip) CFP: Journal of Integrated Computer-Aided Engineering, Special Issue on Distributed X-Mailer: Thomas Ziegert's registered AK-Mail 3.0b [ger] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hosaka.smallworks.com id IAA28832 Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Thomas Ziegert Call for Papers Journal of Integrated Computer-Aided Engineering Special Issue on Distributed Computing and Networking The Journal of Integrated Computer-Aided Engineering has planned a special issue on Distributed Computing and Networking to be published in 1999. The interested authors are invited to submit manuscripts based on their recent results with special focus, but not limited to, the following areas: - Middleware Platforms (CORBA, DCOM, DCE, Java RMI etc.) - Distributed Systems Solutions - Distributed Multimedia Approaches - Distributed Computer-Aided Engineering - Quality of Service Support - Integrated Services Internet - Mobile Computing The submitted manuscripts should not have been previously or currently submitted for publication elsewhere. All manuscripts should include a title page containing the following information: the title of the paper, full names(s) and affiliation(s), complete postal and electronic (if available) address(es), and telephone and fax number(s) of the authors. The contacting author should be clearly identified on the title page as well. The manuscript should include a 300-word abstract and a list of keywords that identify the central issues of the manuscript contents. Deadline: July 31, 1998 Please, submit electronic manuscript(s), or direct your questions to the Guest Editor: Prof. Dr. Alexander Schill Dresden University of Technology Department of Computer Science 01062 Dresden Germany Phone: + 49 351 463 8261 Fax: + 49 351 463 8251 E-Mail: schill@ibdr.inf.tu-dresden.de ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com From ipp-owner@pwg.org Tue Apr 28 11:22:16 1998 Delivery-Date: Tue, 28 Apr 1998 11:22:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08207 for ; Tue, 28 Apr 1998 11:22:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07836 for ; Tue, 28 Apr 1998 11:24:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA01256 for ; Tue, 28 Apr 1998 11:22:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 11:16:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00442 for ipp-outgoing; Tue, 28 Apr 1998 11:10:22 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 28 Apr 1998 09:09:27 -0600 From: "Scott Isaacson" To: don@lexmark.com, Ipp@pwg.org, sdp@pwg.org, rturner@sharplabs.com Subject: Re: SDP> RE: IPP> Using OID access with IPP/SDP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id LAA08207 >>> Randy Turner 04/28 12:20 AM >>> > > >I would add two other possible options...others on the DL are welcome to >chime in with their own options. > >4) Do nothing (for now). Deploy IPP 1.0 and let real world requirements >start accumulating. I really prefer this option, since I think we are >REALLY jumping the gun with this effort. With recent comments on the DL, I >think its very important that we concentrate on getting IPP 1.0 "out the >door" and deployed. We shouldn't appear to be splintering our focus. I do >think we need to consider notifications for IPP, but beyond that I would >say any presumptions on our part about what else is "needed" by customers >is very premature. I have benefited from this discussion about MIB access, management, submission, SDP, etc. but I too sincerely hope that none of this discussion defocuses us from getting IPP/1.0 out the door and widely deployed. I don't get the feeling from this discussion that "we have done the wrong thing with IPP/1.0" or "we have painted ourselves into a corner". I get the feeling that there is good debate going on about the future relationships of various things that sometimes start to overlap. The discussion has been good. My biggest frustration is with the lack of forward motion by the IESG on IPP/1.0 in a timely manner, but that does not indicated a problem with the concept and model of IPP/1.0. The only comments that I have heard that cause the IESG any concern seem to come in on the mapping and use of HTTP/1.1. So I don't necessarily want to "do nothing (for now)", but if that is what it takes to show solidarity behind what we have done so far, then so be it. I always fall back to: "If you find that you have a widespead, well adopted protocol that is ubiquitously implemented and deployed and you find it difficult to rev to the next version because of the widespread deployment, you have done a GOOD thing. It must have been the right thing at the right time to fill a need." It is much better to grow from simple to complex and meet the real needs of the growth path, not the proposed needs of the proposed growth path. Scott From ipp-owner@pwg.org Tue Apr 28 11:42:29 1998 Delivery-Date: Tue, 28 Apr 1998 11:42:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08902 for ; Tue, 28 Apr 1998 11:42:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07941 for ; Tue, 28 Apr 1998 11:44:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA01971 for ; Tue, 28 Apr 1998 11:42:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 11:38:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01367 for ipp-outgoing; Tue, 28 Apr 1998 11:29:23 -0400 (EDT) Message-ID: <3545F560.7EA57A1A@underscore.com> Date: Tue, 28 Apr 1998 11:27:28 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Frank Mason CC: "'Carl-Uno Manros'" , "'ipp@pwg.org'" Subject: Re: IPP> ? on IPP direction concerning XML References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Frank, Earlier you wrote: > "Any printing standard that does not have the combined blessing of > these two industry giants would be doomed from the start" IPP Member > Jay Martin from Underscore For the record, this is *not* the quote as published in the March issue of the Hardcopy Observer. The actual text is: "Whether IPP (as currently defined) is better or worse than XML is a really useless discussion. Without Microsoft's agressive support, any pervasive deployment of an Internet-like printing protocol will likely fail within the general domain." I did not include Hewlett-Packard in this statement. And if Carl-Uno and others want to write off this statement as mere "speculation", then fine...they are certainly entitled to their opinions. As for me, I was simply stating obvious pragmatic reality. I wish it were not so, but it is. Since writing that statement on the IPP DL, Paul Moore reappeared on the DL to say that he believes Microsoft will indeed implement whatever the IETF ratifies as a proposed standard from the IPP WG. So, technically speaking, Frank, you shouldn't have to worry about IPP (in whatever form it finally takes) not being implemented by Microsoft. It should be noted, however, that if many more months go by, Microsoft may feel that it can change its position (as can any other player) and do something else. Only time will tell. ...jay --------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- --------------------------------------------------------------------- From ipp-owner@pwg.org Tue Apr 28 11:48:26 1998 Delivery-Date: Tue, 28 Apr 1998 11:48:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA09070 for ; Tue, 28 Apr 1998 11:47:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07968 for ; Tue, 28 Apr 1998 11:50:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA02581 for ; Tue, 28 Apr 1998 11:47:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 11:43:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA01427 for ipp-outgoing; Tue, 28 Apr 1998 11:37:41 -0400 (EDT) Message-ID: <3545F755.1E5F2270@underscore.com> Date: Tue, 28 Apr 1998 11:35:49 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Kris Schoff CC: "'SISAACSON@novell.com'" , "'ipp@pwg.org'" Subject: Re: IPP> ADM - Reminder about job openings and home work assignme nts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Now this is a truly different stance from HP than we have seen in the last several years, ever since HP (as a NPA charter member) pulled out of the NPA with Microsoft at the 11th hour. Recall that the official statement from HP and Microsoft (as quoted in the trades) was that "SNMP is the proper way to manage network printers". If HP is indeed willing to change its position--and this time really commit to implementing a more fully functional printer submission/management protocol--then this could be very good news for the Rest of Us. After all, no one is interested in spending another 4 years developing a protocol in which the leading players decommit in the 11th hour, relegating the standard to "legacy" before it even hits the streets. ...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 -- --------------------------------------------------------------------- Kris Schoff wrote: > > Scott, > > I would be very interested in tunneling SNMP OID's through IPP for > printer management. It seems like a very reasonable concept to do and > it could allow for the enabling of millions of printers in existence > today. I'd like to see you continue your effort within IPP. > > I am still a proponent that IPP was intended to become a universal, > catch-all printing protocol - which is why I am not on the SDP mailing > list. By definition of "Server-to-Device", it would seem as if the > client is already being left out. I could have sworn that some people > within the IPP WG were trying to limit the number of protocols that > needed to be implemented.... > > Kris Schoff From ipp-owner@pwg.org Tue Apr 28 12:43:23 1998 Delivery-Date: Tue, 28 Apr 1998 12:43:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA10890 for ; Tue, 28 Apr 1998 12:43:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08227 for ; Tue, 28 Apr 1998 12:45:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA03682 for ; Tue, 28 Apr 1998 12:43:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 12:38:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03102 for ipp-outgoing; Tue, 28 Apr 1998 12:36:39 -0400 (EDT) Content-return: allowed Date: Tue, 28 Apr 1998 09:03:26 PDT From: "Caruso, Angelo " Subject: RE: RE: IPP> Using OID access with IPP/SDP To: "'Scott Isaacson'" , ipp@pwg.org, Angelo.Caruso@usa.xerox.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org Scott, This is an excellent clarification for those, like myself, who have been trying to follow the discussion with minimal time invested. Thanks. Using "stringified OIDs" has at least one additional benefit that I can think of: it forces the implementation to maintain EXACTLY the same semantics for the attributes. Thus, there can be no temptation to fix or extend the semantics of those attributes that may be less than perfect in their current form. Thanks, Angelo -----Original Message----- From: Scott Isaacson [SMTP:SISAACSON@novell.com] Sent: Tuesday, April 28, 1998 10:55 AM To: ipp@pwg.org; Angelo.Caruso@usa.xerox.com Subject: Re: RE: IPP> Using OID access with IPP/SDP Angelo, >>> "Caruso, Angelo " 04/27 8:49 AM >>> >Perhaps someone would please enlighten me as to why we need to build Printer >MIB OID access into IPP. I thought the intent was to extend the IPP >attribute list to eventually cover all the printer MIB stuff. Why is this so >difficult? In the original "Sub-Units" proposal that I presented in Portland, I showed a mapping from MIB OIDs to IPP attribute names. It not really a complete mapping, but examples and some rules of how to complete the mapping. This seemed simple enough to me. This is the direction that I thought we were going. Some of the comments on the proposal during the meeting were: 1. Since an implementation of IPP with Printer MIB sub-unit support will most likely be co-resident with a Printer MIB agent which already names things with OIDs, it would be a waste of resources to require that implementation and agent to translate back and forth between strings and OIDs. So, in order to "extend the IPP attribute list to eventually cover all the printer MIB stuff." the thought process was to name the new attributes by their stringified OIDs rather than some arbtrary symbolic name 2. The discussion seems to be focused on now "how hard can it be" but "is it necessary" since we already have SNMP. 3. If we stick with arbitrary new strings for attributes, it might be harder to get at other MIBs using the same mechanism without a full mapping document. For example, the Finishing MIB. If we just go with stringified OIDs we can easily extend that to any MIB object OID without having to show a mapping to the IPP attribute name. These are just the thoughts behind the disucsisons that I have heard. Scott From ipp-owner@pwg.org Tue Apr 28 16:08:11 1998 Delivery-Date: Tue, 28 Apr 1998 16:08:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA17434 for ; Tue, 28 Apr 1998 16:08:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09204 for ; Tue, 28 Apr 1998 16:10:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA04886 for ; Tue, 28 Apr 1998 16:07:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 28 Apr 1998 16:03:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA04354 for ipp-outgoing; Tue, 28 Apr 1998 16:02:44 -0400 (EDT) Message-Id: <3.0.1.32.19980428110940.009a2b00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Apr 1998 11:09:40 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-hoffman-smtp-ssl-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org There is a new draft out on using TLS with SMTP. This might actually ccome in handy for our IPP Notifications document. Carl-Uno >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-hoffman-smtp-ssl-06.txt >Date: Tue, 28 Apr 1998 07:11:47 PDT >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SMTP Service Extension for Secure SMTP over TLS > Author(s) : P. Hoffman > Filename : draft-hoffman-smtp-ssl-06.txt > Pages : 4 > Date : 27-Apr-98 > >This document describes an extension to the SMTP service that allows an >SMTP server and client to use transport-layer security to provide private, >authenticated communication over the Internet. This gives SMTP agents the >ability to protect some or all of their communications from eavesdroppers >and attackers. > >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-hoffman-smtp-ssl-06.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-hoffman-smtp-ssl-06.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-hoffman-smtp-ssl-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Apr 29 04:25:13 1998 Delivery-Date: Wed, 29 Apr 1998 04:25:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id EAA07442 for ; Wed, 29 Apr 1998 04:25:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11150 for ; Wed, 29 Apr 1998 04:27:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA12048 for ; Wed, 29 Apr 1998 04:25:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Apr 1998 04:18:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA11500 for ipp-outgoing; Wed, 29 Apr 1998 04:16:10 -0400 (EDT) Message-Id: <3.0.1.32.19980429005704.01282270@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Apr 1998 00:57:04 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> Issues with the notification proposal - for Wed 4/29 telecon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Here are the list of issues from the notification white paper that Harry and I posted last Friday and some additional issues that Carl-Uno raised. We'd like to use this as an agenda for reviewing the notification proposal: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf The .pdf version should be used to make comments using the line numbers. Of coures other issues are welcome as well, via e-mail or during the telecon. Tom The line numbers refer to the .pdf version: 1. Line 89-91: ISSUE a: Should we keep the ability for the System Administrator to define default notification, if the client does not supply any? 2. Line 130-136: ISSUE b: Are we making the recipients job more difficult on a problem notification by sending the job-id of the job that had the problem, rather than the job-id of the job the requested the notification? 3. Line 130-136: ISSUE c: Is there a security problem with sending the job-id of a job that does not belong to the user that submitted the job to the designated notificatio recipient? We already allow the security policy to prevent a user from seeing any other jobs. 4. Line 210: ISSUE 1: Ok to have combined these two events into one event (and one event group) for simplicity and specified that the notification content is the same for all notification recipients receiving this event? 5. Line 223: ISSUE 2: Should we register a "job-deadline-to-start" Job Template attribute for use with IPP/1.0? 6. Lines 241-265: ISSUE d: What notification schemes do we want to include in our standards track notificaition RFC? Any that have not been approved should probably be in a separate document, in case they get held up with URL scheme registration bottlenecks. 7. Lines 241-265: ISSUE e: What notification schemes do we want to progress in parallel with this notification proposal? 8. Line 247: ISSUE f: For the 'tcp-ip-sockets' notifiation scheme, too many other IETF groups might like to get involved, slowing us down, even though the method is only appropriate for IPP. Perhaps we should change the name to represent a more limited scope, like 'ipp-tcp-ip-sockets'? Same for the snmpv1, snmpv2, and snmpv3 schemes. 8. Lines 241-265: ISSUE g: The representation for the notificatio content needs to be specified for each method. All should use the multipart/alernative, except for the three SNMP methods. 9. Lines 353-378: ISSUE h: Need to clarify that the validation is independent of the value of ipp-attribute-fidelity, like all Operation attributes, and unsupported values are ignored, rather than rejecting the request. 10. Line 404 and Table 1: ISSUE 3: Do we need/want to add the missing attributes to IPP as Printer object attributes that are indicated as "-" in the IPP attribute column to align with the Job Monitoring MIB? 11. Line 433: ISSUE 4 - Should we change the name that is reserved in the IPP/1.0: Protocol Specification from 'dictionary' to 'collection' before the RFC is published? From ipp-owner@pwg.org Wed Apr 29 04:30:59 1998 Delivery-Date: Wed, 29 Apr 1998 04:31:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id EAA07489 for ; Wed, 29 Apr 1998 04:30:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA11154 for ; Wed, 29 Apr 1998 04:33:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA12780 for ; Wed, 29 Apr 1998 04:30:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Apr 1998 04:25:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA11501 for ipp-outgoing; Wed, 29 Apr 1998 04:16:10 -0400 (EDT) Message-Id: <3.0.1.32.19980429001127.01282dc0@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Apr 1998 00:11:27 PDT To: don@lexmark.com From: Tom Hastings Subject: RE: IPP> Using OID access with IPP/SDP [for telecon discussion, Wed] Cc: Ipp@pwg.org, sdp@pwg.org In-Reply-To: <199804280325.AA27337@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Here are some alternatives to providing "stringified" OID access to MIBs. I'd like to discuss these at the Wednesday, 4/29, IPP telecon. At 20:18 04/27/1998 PDT, don@lexmark.com wrote: > >Here's where I agree: > >IEEE Std 1284.1 uses the same concept to allow access to MIB objects. We >including then entire OID string which allow access to any MIB including >private extensionsm MIB 2, etc. This has worked out very well allowing >using common code in the printer and presenting a single, unified >presentation of printer status and configuration without having to worry >about reconcilling two different name spaces. Additionally since the OID >decoding code is already in the printer, the implementation was easy and >small -- no need to carry lots of string constants around for comparisons. snip... I see two approach: 1. The full decimal OID as you suggest that allows any OID to be passed in any standard or private MIB. 2. A tailored set of shortened OIDs for the Printer MIB (as suggested by Harry). We could do both. Each have their advantages and disadvantages. Here are some issues with each approach: For approach 1, the values of the "requested-attributes" Operation attribute would be keywords. Keywords have to start with letters, so I suggest the prefix 'mib' for those that can reference any MIB. For example, to retrieve the prtInputMediumName object for the 3nd input tray if the hrDeviceIndex were, say, 20: 'mib-1.3.6.1.2.1.43.8.2.1.12.20.3' Issue 1: How would an application know that the printer device was hrDeviceIndex = 20 (assuming that it is a value 1 is not acceptable, though it might work for many implementations)? We could add an IPP Printer attribute: hr-device-index (1setOf integer(1:MAX)) which would be this value. The application would query to get the hrDeviceIndex value that it would insert as the second to last arc in most Printer MIB OIDs (last OID arc for the General Table). The 1setOf in needed for the case where an IPP Printer object is representing multiple devices as indicated in our Model document picture. Issue 1a: Or provide GetNext semantics to find the device (see Issue 2 also) Instead of adding a "hr-device-index" Printer attribute, if GetNexte semantics were used, instead of Get semantics, then the requester could request the first item in the Printer MIB as: 'mib-1.3.6.1.2.1.43.5.1.1' which would return the prtGeneralConfigChanges (column 1) with the hrDeviceIndex (20 in this example) tacked on the end: 'mib-1.3.6.1.2.1.43.5.1.1.1.20' = n Then the application would know what hrDeviceIndex to put into all future requests to that device. (Alternatively, the application could attempt to read the hr MIB to find the hrDeviceIndex for the printer device, but that seems pretty hard. Issue 2: How would an application read the alert table entries, since the OID index is steadily increasing as the Printer generates alerts? (The Alert Group is 18 and the prtAlertTime object is 9, and, say, the 500th alert) 'mib-1.3.6.1.2.1.43.18.1.1.9.20.500 Issue 2a: Use GetNext semantics, instead of Get? One solution would be to use the SNMP GetNext semantics, so that the requester could have supplied "requested-attributes" with: 'mib-1.3.6.1.2.1.43.18.1.1.9.20.1' (or 'mib-1.3.6.1.2.1.43.18.1.1.9.20') and get back: 'mib-1.3.6.1.2.1.43.18.1.1.9.20.500 = xxx in the response Issue 2b: Provide GetBulk semantics, instead of GetNext? It would be even more convenient if there was an input Operation attribute that said how many to return starting with the first one that exists, i.e., the SNMPv2 GetBulk semantics. GetBulk can be easily implemented by an IPP Printer with an SNMPv1 agent, by doing the requested number of GetNext operations and incrementing by 1 after each to the SNMPv1 agent. Approach 2 is to have shorter attribute keywords for just the Printer MIB of the form: 'prt-t-c' where t is the decimal table/group number and c is the column number. So for scheme 2, the values of the "requested-attributes" Operation attribute would be keywords, like the prtInputMediumName (column 12) for the 2nd input tray (table 8) if the hrDeviceIndex were, say, 20: 'prt-8-12' instead of: 'mib-1.3.6.1.2.1.43.8.2.1.12.20.2' Issue 3: How represent multiple devices? Add a "device-names-supported" Printer attribute which is the name(s) of the device(s) supported. An input Operation parameter is the name of the device (needed only if the IPP Printer object supports more than one device. Issue 4: How get prt table row instances? Issue 4a: Return all row instances as a multi-value attribute? To simplify, the return would be a multi-value attribute where each value corresponds to each table row. So that the results would be the media names for each of the input trays, no matter how many there were. For the General table (group 5), in order to get the (new) prtGeneralPrinterName object (column 16), the requester would provide: 'prt-5-16' instead of: 'mib-1.3.6.1.2.1.43.5.1.1.16.20' For the alerts (group 18), the requester would provide: 'prt-18-9' to get the prtAlertTime values (column 9) for all alerts in the table as a single multi-valued attribute, instead of: requesting, say, the next 10 values using GetBulk semantics: 'mib-1.3.6.1.2.1.43.18.1.1.9.20.1 Issue 4b: Or have the GetBulk semantics, instead of returning a multi-valued attribute? With approach 2, we could use the GetBulk semantics, instead of always returning all instances as a multi-valued attribute. That gives the requester more control of which instances to get and how many. Doing GetBulk also fits in nicely with SNMP semantics. Using GetBulk for both approaches 1 and 2 makes the most sense if we have both schemes. Comments? Tom From ipp-owner@pwg.org Wed Apr 29 12:03:38 1998 Delivery-Date: Wed, 29 Apr 1998 12:03:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA18646 for ; Wed, 29 Apr 1998 12:03:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA12722 for ; Wed, 29 Apr 1998 12:06:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA14330 for ; Wed, 29 Apr 1998 12:03:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Apr 1998 11:52:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA13557 for ipp-outgoing; Wed, 29 Apr 1998 11:48:00 -0400 (EDT) From: Roger K Debry To: , Cc: Harry Lewis Subject: IPP> Proposal posted Message-ID: <5030100019937078000002L082*@MHS> Date: Wed, 29 Apr 1998 11:46:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA18646 Harry Lewis and I have put together an SDP proposal for your review. We believe that this approach meets all of the main SDP requirements, while preserving the IPPv1 encoding and the work done to define Printer and Job Monitoring MIBs. The white paper is at ftp.pwg.org/pub/pwg/sdp/sdp-proposal.txt ftp.pwg.org/pub/pwg/sdp/sdp-proposal.pdf We would appreciate your reading this proposal and providing us with comments. Harry will present this proposal at the upcoming PWG meeting in Washington. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Apr 29 18:39:19 1998 Delivery-Date: Wed, 29 Apr 1998 18:39:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29589 for ; Wed, 29 Apr 1998 18:39:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA14652 for ; Wed, 29 Apr 1998 18:41:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16246 for ; Wed, 29 Apr 1998 18:38:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Apr 1998 18:33:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15678 for ipp-outgoing; Wed, 29 Apr 1998 18:28:37 -0400 (EDT) Message-Id: <3.0.1.32.19980429114844.00a92750@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Apr 1998 11:48:44 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-cohen-gena-p-base-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Please check this out, Carl-Uno >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-cohen-gena-p-base-00.txt >Date: Wed, 29 Apr 1998 07:01:29 PDT >Sender: cclark@CNRI.Reston.VA.US > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : General Event Notification Architecture Base > Author(s) : J. Cohen > Filename : draft-cohen-gena-p-base-00.txt > Pages : 16 > Date : 28-Apr-98 > > At an ever increasing rate, new protocols are being > designed which achieve their desired functionality by > building upon HTTP. Many of them make good use of the > functionality and flexibility of the HTTP model, however, > a theme that is becoming common is the cry for a common > event notification architecture. > > This specification defines a simple notification > architecture for URI addressable resources. URI > addressable resources can include, but are not limited to, > simple resources, html files, resources, URI addressable > objects, URI addressable process jobs or URI addressable > print jobs. > > >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-cohen-gena-p-base-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-cohen-gena-p-base-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-cohen-gena-p-base-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Apr 29 20:44:25 1998 Delivery-Date: Wed, 29 Apr 1998 20:44:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01767 for ; Wed, 29 Apr 1998 20:44:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA14898 for ; Wed, 29 Apr 1998 20:46:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17010 for ; Wed, 29 Apr 1998 20:44:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Apr 1998 20:38:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16445 for ipp-outgoing; Wed, 29 Apr 1998 20:38:10 -0400 (EDT) Message-Id: <3.0.1.32.19980429172146.00a48530@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Apr 1998 17:21:46 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 980429 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Minutes from PWG IPP Phone Conference 980429 ============================================= Notes taken by Lee Farrell The attendees included : Roger deBry IBM Lee Farrell Canon Information Systems Tom Hastings Xerox Scott Isaacson Novell Harry Lewis IBM Carl-Uno Manros* Xerox Paul Moore Microsoft Kris Schoff Hewlett Packard Peter Zehler Xerox * IPP Chairman Carl-Uno Manros led the meeting. His agenda topics were: "Main agenda point is to discuss the revised IPP Notifications proposal from Harry Lewis and Tom Hastings. I hope that we can get this out as an Internet-Draft after our review in the conference." "We may also want to spend some time on the discussion about reaching MIB information over IPP. As usual, I think some initial agreements about scope and requirements would be useful." Notifications for the IPP Print Protocol -- The group discussed the proposal that was issued last week by Harry Lewis and Tom Hastings [ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf] Tom provided a brief overview of the proposal. Paul Moore had several questions. He also pointed out that the document doesn't define the meaning of "Notification." Why have both human readable as well as machine readable formats? To avoid attempts to parse the human readable. The recipient can ignore the parts it doesn't understand. Who responds to the notification request? The IPP printer. There is no model where the IPP client sends the notification? Correct. I envisage a user wanting to be notified by e-mail, but the (inexpensive) printer doesn't support e-mail. Yes, but a server could handle this notification (by polling, for example) on behalf of the printer. This could be an issue for the SDP discussions. But this means that the server must "crack open" the packet being sent to the printer. Yes, but this is probably easier than a full mapping to some other protocol. Several other discussion points and questions were also raised -- Harry explained that the proposal attempts to address both IPP and SDP issues. Perhaps we should allow the client to specify if it wants either machine readable or human readable or both? Is it true that IPP "client-to-server" will need only human readable while IPP "server-to-device" will need machine readable? Not necessarily. The client might want to localize the received notification for display to the user. What if the printer sends the notification to the IPP client, and then the client translates to display for the user? This could remove the need for human readable form. We need to caution against having a one-to-one correspondence between each end-user feature and a related protocol structure. General caution: There is no "IPP Server" defined in the model. We should be very careful when we use this term. There should be more notification "flavors" than just specifying that a user wants to be notified at a given e-mail address. Perhaps (for clarification purposes) we should call human readable forms "messages" and machine readable forms "notifications." Their usage is sufficiently different that we should avoid giving them the same name. A "message" would refer to the high-level intent expressed by the user, and a "notification" would refer to the machine readable (and processable) form of the detailed event. Such a separation of "messages" and "notifications" might result in implementations trying to parse the human readable form. We would really like to avoid this if possible. Issue Review -- Several issues that were listed in Tom Hasting's e-mail on April 29 were reviewed and discussed. The conclusions for each item are given below: Issue a (lines 89-91): Should we keep the ability for the System Administrator to define default notification, if the client does not supply any? ---> Let's remove the defaulting altogether (and the associated attributes.) Issue b (lines 130-136): Are we making the recipients job more difficult on a problem notification by sending the job-id of the job that had the problem, rather than the job-id of the job the requested the notification? ---> Perhaps if the submitting client is interested in printer events (and related problems that could affect the print job progress), it should subscribe for notifications at that level, not just the (the user's) print job level? For all print jobs in the system that have subscribed to the printer problem event group, they will be notified. However, when the job is removed from the queue, the subscription will be terminated. [The above discussion raised a separate issue: What about subscribing for printer problems even when there is no active print job? This was considered "out-of-band" for IPP, and deferred for later discussion. Perhaps a new operation for requesting notification subscription services should be defined? This will probably require an "unsubscribe" operation as well. To properly address this issue, a review and update of the requirements may be necessary.] Issue c (lines 130-136): Is there a security problem with sending the job-id of a job that does not belong to the user that submitted the job to the designated notification recipient? We already allow the security policy to prevent a user from seeing any other jobs. ---> We should leave this up to the implementation. It will decide the security policy regarding how much information is provided about other jobs. Issue 1 (line 210): Ok to have combined these two events into one event (and one event group) for simplicity and specified that the notification content is the same for all notification recipients receiving this event? ---> See issue b discussion above. Issue 2 (line 223): Should we register a "job-deadline-to-start" Job Template attribute for use with IPP/1.0? ---> No. Let's remove it. Issues d through g were deferred for later discussion. Issue h (lines 353-378): Need to clarify that the validation is independent of the value of ipp-attribute-fidelity, like all Operation attributes, and unsupported values are ignored, rather than rejecting the request. ---> Agreed. Issue 3 (line 404 and Table 1): Do we need/want to add the missing attributes to IPP as Printer object attributes that are indicated as "-" in the IPP attribute column to align with the Job Monitoring MIB? ---> No, do it for later version. Issue 4 (line 433): Should we change the name that is reserved in the IPP/1.0: Protocol Specification from 'dictionary' to 'collection' before the RFC is published? ---> Yes. Sending MIB data over IPP -- The group reviewed Scott's Version 0.02 document on "IPP Sub-Unit Objects" [ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-sub-units-980407.pdf] What about printers that do not have MIBs? Scott says there is no requirement to have an SNMP agent in the printer. The proposal only discusses a mapping that is based on the Printer MIB. Should we incorporate the "uninteresting part" of the OID? Probably not. If any part of the OID is used, it should be limited to the part that doesn't change. The Finisher MIB is part of the Printer MIB. The Job MIB is separate. Perhaps we should add some of the desired content of the Job MIB to the IPP Job attributes? If there is an overlap between the Job attributes and the Job MIB, what should be done if the values are different? We should define the overlap to be identical, using the OID as an alias. However, Scott pointed out that "Printer_State" is (intentionally) different between the two. Any similar overlapping differences are probably minimal, and should be explicitly referenced and explained for interpretation. Carl-Uno asked if we have sufficient support for Scott's proposal. Everyone agreed that there is support for pursuing this concept further. There was one concern that we are taking "the obvious and easy way out" -- often the good solutions are the painful ones. However, no one had a better solution to propose. The discussion of how to "stringify" the OIDs will continue on the e-mail list. IPP Documents -- Carl-Uno and other IPP members continue to ask the IETF Area Director for a response on the IPP document drafts. However, there seems to be no tangible progress. Next week it will be three months since the documents were first submitted. Meeting adjourned. Next IPP Teleconference -- The next teleconference will be held on May 6 at 10:00am PST. For next week's teleconference, we will discuss the SDP proposal generated by Roger deBry [ftp://pwg.org/pub/pwg/sdp/sdp-proposal.pdf] +++ Regards, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Apr 30 15:26:41 1998 Delivery-Date: Thu, 30 Apr 1998 15:27:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06359 for ; Thu, 30 Apr 1998 15:26:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18274 for ; Thu, 30 Apr 1998 15:29:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00460 for ; Thu, 30 Apr 1998 15:26:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Apr 1998 15:13:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29873 for ipp-outgoing; Thu, 30 Apr 1998 15:13:02 -0400 (EDT) Message-Id: <3.0.1.32.19980430112858.00bf9620@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 30 Apr 1998 11:28:58 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Progressing IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I asked Larry Masinter's advice on how we can get the IPP process moving. Here is his sound advice, which I suggest that we should follow: My _recommendation_ is that you move forward with preparing IPP for DRAFT standard status: start trying to document tested, independent, interoperable implementations of EVERY FEATURE. A protocol that is widely implemented, interoperable, and succeeds at accomplishing its function is irresistable. -- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri May 1 08:08:37 1998 Delivery-Date: Fri, 01 May 1998 08:08:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA26001 for ; Fri, 1 May 1998 08:08:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA20440 for ; Fri, 1 May 1998 08:10:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA12327 for ; Fri, 1 May 1998 08:08:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 1 May 1998 07:53:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA11780 for ipp-outgoing; Fri, 1 May 1998 07:50:46 -0400 (EDT) Content-return: allowed Date: Fri, 1 May 1998 04:50:09 PDT From: "Zehler, Peter " Subject: RE: IPP> ADM - Progressing IPP To: ipp@pwg.org Cc: Carl-Uno Manros Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, To further progress IPP we should set a date, or week, of intense testing across the Internet. I propose the week of May 11 to 15 for our first round. I know there are some implementations out there. Its about time to see if they can interoperate at some level. I am ready to test immediately. I can use an IPP Client to talk to your IPP Printer or the other way around. (The first full scale test should also give us some TES business to discuss at the next IPP meeting.) If the proposed date is inappropriate someone pick another and we will do it then too. I want to see some movement. It appears that this may be the next step in the IPP standardization process. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Thursday, April 30, 1998 2:29 PM To: ipp@pwg.org Subject: IPP> ADM - Progressing IPP I asked Larry Masinter's advice on how we can get the IPP process moving. Here is his sound advice, which I suggest that we should follow: My _recommendation_ is that you move forward with preparing IPP for DRAFT standard status: start trying to document tested, independent, interoperable implementations of EVERY FEATURE. A protocol that is widely implemented, interoperable, and succeeds at accomplishing its function is irresistable. -- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri May 1 14:08:57 1998 Delivery-Date: Fri, 01 May 1998 14:08:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07333 for ; Fri, 1 May 1998 14:08:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21901 for ; Fri, 1 May 1998 14:11:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA14342 for ; Fri, 1 May 1998 14:08:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 1 May 1998 14:04:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA13817 for ipp-outgoing; Fri, 1 May 1998 14:02:46 -0400 (EDT) Message-ID: <003601bd752a$39b8a3c0$1e0564d2@tulip> From: "Peter Michalek" To: "Zehler, Peter " , Cc: "Carl-Uno Manros" Subject: Re: IPP> ADM - Progressing IPP Date: Fri, 1 May 1998 10:54:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org >across the Internet. I propose the week of May 11 to 15 for our first >round. I know there are some implementations out there. Its about time to I am in, I would also like to test both client and server. I'll be representing Auco Inc. in this test. If anyone is interested to do some initial tests even before this date, please let me know. Peter -----Original Message----- From: Zehler, Peter To: ipp@pwg.org Cc: Carl-Uno Manros Date: Friday, May 01, 1998 5:04 AM Subject: RE: IPP> ADM - Progressing IPP >All, > To further progress IPP we should set a date, or week, of intense testing >across the Internet. I propose the week of May 11 to 15 for our first >round. I know there are some implementations out there. Its about time to >see if they can interoperate at some level. I am ready to test immediately. >I can use an IPP Client to talk to your IPP Printer or the other way around. >(The first full scale test should also give us some TES business to discuss >at the next IPP meeting.) > If the proposed date is inappropriate someone pick another and we will do >it then too. I want to see some movement. It appears that this may be the >next step in the IPP standardization process. > >Pete > > Peter Zehler > XEROX > Networked Products Business Unit > Email: Peter.Zehler@usa.xerox.com > Voice: (716) 265-8755 > FAX: (716) 265-8792 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 111-02J > Webster NY, 14580-9701 > > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, April 30, 1998 2:29 PM > To: ipp@pwg.org > Subject: IPP> ADM - Progressing IPP > > I asked Larry Masinter's advice on how we can get the IPP process >moving. > > Here is his sound advice, which I suggest that we should follow: > > My _recommendation_ is that you move forward with preparing IPP for > DRAFT standard status: start trying to document tested, independent, > interoperable implementations of EVERY FEATURE. > > A protocol that is widely implemented, interoperable, and succeeds >at > accomplishing its function is irresistable. > > -- > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Fri May 1 20:20:35 1998 Delivery-Date: Fri, 01 May 1998 20:20:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA14532 for ; Fri, 1 May 1998 20:20:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA23209 for ; Fri, 1 May 1998 20:22:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA15813 for ; Fri, 1 May 1998 20:20:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 1 May 1998 20:14:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15257 for ipp-outgoing; Fri, 1 May 1998 20:11:32 -0400 (EDT) Message-Id: <3.0.1.32.19980501170229.00992370@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 1 May 1998 17:02:29 PDT To: chodongi@samsung.co.kr, manros@cp10.es.xerox.com From: Carl-Uno Manros Subject: IPP> Re: About IPP membership Cc: ipp@pwg.org In-Reply-To: <354A5A01.59CB2389@samsung.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org SungHyun, It is very simple. Anybody who is interested can join in the IPP discussions. The work really happens in two parallel forums: 1) The IETF IPP WG, which is open to everybody over email and by participation in the IETF meetings. This is where all formal decisions about the IPP standard happens. Make sure to subscribe to the WGs distribution list. 2) The Printer Working Group (PWG), in addition to the IETF activities, organizes weekly phone conferences and face-to-face meetings about every 6 weeks. The PWG is also open to everybody who wants to attend phone conferences or meetings. No membership is required, all you need is to join us at meetings or phone conferences. There are no membership fees, you only contribute to the costs for meeting rooms and refreshments during meetings. Most of the active members of the IETF IPP WG are also participating in the PWG. If you are interested to phone in for our phone conferences, I can organize to have an international number set up for you to dial in from Korea. Phone conferences are usually held at 10 am Pacific Daylight Time. You can find out more information about the IPP project and how to subscribe to our DL at our web site: http://www.pwg.org/ipp If you are interested to participate in our next face-to-face meeting, look up the web page: http://www.pwg.org/chair/washdc.html I wish you welcome to the group. Carl-Uno Manros Chair IETF IPP WG At 04:25 PM 5/1/98 PDT, SungHyun Kim wrote: >Hello, > > I'm SungHyun Kim and responsible for IPP at Samsung.I'd like to know >about IPP membership. > Please let me know IPP group. > > Q1) What kinds of memberships(grade) do you have? > > Q2) How do I apply for IPP membership? > > Q3) What kinds of duties and rights? > > Q4) What kinds of benefits for member? > > Q5) Please let me know about other rules for IPP? > > Wait for your quick answer and I'll very appreciate it. > > Best regards, > > SungHyun Kim. > > > chodongi@samsung.co.kr > Tel : +82 2 259 2458 > Fax: +82 2 259 2523 > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon May 4 13:10:07 1998 Delivery-Date: Mon, 04 May 1998 13:10:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA09846 for ; Mon, 4 May 1998 13:10:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03831 for ; Mon, 4 May 1998 13:12:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23137 for ; Mon, 4 May 1998 13:09:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 4 May 1998 12:59:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22559 for ipp-outgoing; Mon, 4 May 1998 12:56:15 -0400 (EDT) Message-Id: <3.0.1.32.19980504094557.00bf7210@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 4 May 1998 09:45:57 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 980506 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org PWG IPP Phone Conference 980506 =============================== We will hold our usual phone conference this week. I suggest that we carry on our discussion about the two subjects from last weeK; - IPP notifications - MIB info over IPP We are supposed to get new versions ofthe wehite papers on these subjects in time for the conference, check the DL. I also suggest that we start looking at the agenda for the Washington IPP meeting. The conference information is: Time: May 6, 10:00 am PDT (1:00 pm EDT) Number: 1-800-857 5607 (Xerox internal 5*535 5000) Note FREE! Passcode: cmanros NOTE: As I will be away next week, I have already boked the phone conference for next week too: Time: May 13, 10:00 am PDT (1:00 pm EDT) Number: 1-800-857 5607 (Xerox internal 5*535 5000) Note FREE! Passcode: cmanros -- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon May 4 16:20:00 1998 Delivery-Date: Mon, 04 May 1998 16:20:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13144 for ; Mon, 4 May 1998 16:19:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05276 for ; Mon, 4 May 1998 16:21:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA23853 for ; Mon, 4 May 1998 16:19:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 4 May 1998 16:14:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23335 for ipp-outgoing; Mon, 4 May 1998 16:13:23 -0400 (EDT) Message-Id: <3.0.1.32.19980504130358.00c94530@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 4 May 1998 13:03:58 PDT To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP> ADM - PWG IPP Phone Conference 980506 Cc: ipp@pwg.org In-Reply-To: <5030100020069220000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Roger, Sorry, that slipped my mind. Everybody, please add discussion of the proposal from Roger and Harry last week to Wednesday's agenda. Carl-Uno At 12:49 PM 5/4/98 PDT, Roger K Debry wrote: >Carl-Uno, > >I had hoped to get some comment on the SDP proposal Harry and I posted. > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > >---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/04/98 01:48 >PM --------------------------- > > >owner-ipp@pwg.org on 05/04/98 11:49:18 AM >Please respond to owner-ipp@pwg.org >To: ipp@pwg.org >cc: >Subject: IPP> ADM - PWG IPP Phone Conference 980506 > > >PWG IPP Phone Conference 980506 >=============================== > >We will hold our usual phone conference this week. > >I suggest that we carry on our discussion about the two subjects from last >weeK; > >- IPP notifications >- MIB info over IPP > >We are supposed to get new versions ofthe wehite papers on these subjects >in time for the conference, check the DL. >I also suggest that we start looking at the agenda for the Washington IPP >meeting. > >The conference information is: > >Time: May 6, 10:00 am PDT (1:00 pm EDT) >Number: 1-800-857 5607 (Xerox internal 5*535 5000) Note FREE! >Passcode: cmanros > >NOTE: As I will be away next week, I have already boked the phone >conference for next week too: > >Time: May 13, 10:00 am PDT (1:00 pm EDT) >Number: 1-800-857 5607 (Xerox internal 5*535 5000) Note FREE! >Passcode: cmanros > >-- > >Carl-Uno > > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From jmp-owner@pwg.org Tue May 5 17:33:33 1998 Delivery-Date: Tue, 05 May 1998 17:33:43 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA15657 for ; Tue, 5 May 1998 17:33:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10236 for ; Tue, 5 May 1998 17:35:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07881 for ; Tue, 5 May 1998 17:33:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 5 May 1998 17:30:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07461 for jmp-outgoing; Tue, 5 May 1998 17:28:34 -0400 (EDT) Message-Id: <3.0.1.32.19980505134731.0124b320@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 5 May 1998 13:47:31 PDT To: ipp@pwg.org From: Tom Hastings Subject: JMP> MOD - Updtaed notification proposal, V0.3 for 5/6 telecon Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org I've posted the updated notification white paper, V0.03. I've included the comments and agreements reached at the last telecon, 4/29/98. I checked the minutes as well as my notes. We'd like to discuss again at the 5/6/97 telecon. On terminology, I've included the terms from the requirements document. They are similar to the ones in Josh Cohen's notification I-D. Neither used the term "message". I've left the JMP stuff there as well, but put it inside [] so we can remove it when making an IPP I-D. The files are: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf Lets use the last file with line numbers for review at the telecon. Send any comments/issues ahead of time. There are a number of issues remaining that are highlighted. We should discuss them on the telecon, as well as any other issues that people have. Tom From ipp-owner@pwg.org Tue May 5 17:35:32 1998 Delivery-Date: Tue, 05 May 1998 17:35:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA15726 for ; Tue, 5 May 1998 17:35:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10243 for ; Tue, 5 May 1998 17:37:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08211 for ; Tue, 5 May 1998 17:35:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 5 May 1998 17:30:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07454 for ipp-outgoing; Tue, 5 May 1998 17:28:31 -0400 (EDT) Message-Id: <3.0.1.32.19980505134731.0124b320@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 5 May 1998 13:47:31 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updtaed notification proposal, V0.3 for 5/6 telecon Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I've posted the updated notification white paper, V0.03. I've included the comments and agreements reached at the last telecon, 4/29/98. I checked the minutes as well as my notes. We'd like to discuss again at the 5/6/97 telecon. On terminology, I've included the terms from the requirements document. They are similar to the ones in Josh Cohen's notification I-D. Neither used the term "message". I've left the JMP stuff there as well, but put it inside [] so we can remove it when making an IPP I-D. The files are: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf Lets use the last file with line numbers for review at the telecon. Send any comments/issues ahead of time. There are a number of issues remaining that are highlighted. We should discuss them on the telecon, as well as any other issues that people have. Tom From ipp-owner@pwg.org Wed May 6 05:00:52 1998 Delivery-Date: Wed, 06 May 1998 05:00:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA03425 for ; Wed, 6 May 1998 05:00:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA11476 for ; Wed, 6 May 1998 05:03:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA18747 for ; Wed, 6 May 1998 05:00:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 04:55:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA17821 for ipp-outgoing; Wed, 6 May 1998 04:52:50 -0400 (EDT) Message-Id: <3.0.1.32.19980506014536.01157100@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 6 May 1998 01:45:36 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated MIB Access paper posted, V0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Scott, Bob, Kris, and I finished the collaboration on the MIB access using IPP. We incorporated the agreements from last week's telecon. We'd like to present it at the telecon today, 10-12 PDT (1-3 EDT). There are a few minor issues highlighted in yellow. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.pdf Please use the last one for the telecon. Here is the abstract: IPP Device and MIB access Version 0.03 Abstract This document introduces a new Device object into the IPP object model. An IPP Printer object may support one or more Device objects which each represent a physical device as shown in the Internet Printing Protocol/1.0: Model and Semantics specification. This document provides read access to such Device objects by defining a mapping from table entries in the Printer MIB to new algorithmically generated attribute names. New algorithmically generated attribute group names allow convenient read-only access to any row, any column, and any entire table in the Printer MIB, as well as the entire Printer MIB. A general algorithmically generated attribute name provides access to any single SNMP object in any MIB. These new attribute names and attribute group names are supplied in the "requested-attributes" Operation attribute of the current Get-Printer-Attributes operation. A new OPTIONAL "which-device" Operation attribute permits the requester to select a particular device for the case where an IPP Printer object is supporting more than one device. From ipp-owner@pwg.org Wed May 6 07:48:33 1998 Delivery-Date: Wed, 06 May 1998 07:48:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA06200 for ; Wed, 6 May 1998 07:48:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA11732 for ; Wed, 6 May 1998 07:50:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA21271 for ; Wed, 6 May 1998 07:48:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 07:40:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA20715 for ipp-outgoing; Wed, 6 May 1998 07:39:41 -0400 (EDT) From: don@lexmark.com Message-Id: <199805061137.AA03326@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: cmanros@cp10.es.xerox.com, hastings@cp10.es.xerox.com Cc: Ipp@pwg.org Date: Wed, 6 May 1998 07:37:28 -0400 Subject: Re: IPP> MOD - Updated MIB Access paper posted, V0.3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Posting a paper and sending notice very early on the day of the conference call (3:45AM EDT) seems to me to be way to late to be included in discussions. While those of us on the east coast might have a little time for review, clearly others have almost no time. I think it would be appropriate to delay discussion on this until next week. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> MOD - Updated MIB Access paper posted, V0.3 Scott, Bob, Kris, and I finished the collaboration on the MIB access using IPP. We incorporated the agreements from last week's telecon. We'd like to present it at the telecon today, 10-12 PDT (1-3 EDT). There are a few minor issues highlighted in yellow. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.pdf Please use the last one for the telecon. Here is the abstract: IPP Device and MIB access Version 0.03 Abstract This document introduces a new Device object into the IPP object model. An IPP Printer object may support one or more Device objects which each represent a physical device as shown in the Internet Printing Protocol/1.0: Model and Semantics specification. This document provides read access to such Device objects by defining a mapping from table entries in the Printer MIB to new algorithmically generated attribute names. New algorithmically generated attribute group names allow convenient read-only access to any row, any column, and any entire table in the Printer MIB, as well as the entire Printer MIB. A general algorithmically generated attribute name provides access to any single SNMP object in any MIB. These new attribute names and attribute group names are supplied in the "requested-attributes" Operation attribute of the current Get-Printer-Attributes operation. A new OPTIONAL "which-device" Operation attribute permits the requester to select a particular device for the case where an IPP Printer object is supporting more than one device. From ipp-owner@pwg.org Wed May 6 10:45:23 1998 Delivery-Date: Wed, 06 May 1998 10:45:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA10282 for ; Wed, 6 May 1998 10:45:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA12705 for ; Wed, 6 May 1998 10:47:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA21991 for ; Wed, 6 May 1998 10:45:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 10:40:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21457 for ipp-outgoing; Wed, 6 May 1998 10:36:03 -0400 (EDT) Message-Id: <1.5.4.32.19980506142608.0072b7d4@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: Wed, 06 May 1998 07:26:08 -0700 To: don@lexmark.com, cmanros@cp10.es.xerox.com, hastings@cp10.es.xerox.com From: Carl-Uno Manros Subject: Re: IPP> MOD - Updated MIB Access paper posted, V0.3 Cc: Ipp@pwg.org Sender: owner-ipp@pwg.org Don, You are right. Tom and I have already spoken about that. We will just have a short introduction of the paper today, and leave the discussion for next week. Carl-Uno At 07:37 AM 5/6/98 -0400, don@lexmark.com wrote: > >Posting a paper and sending notice very early on the day of the conference >call (3:45AM EDT) seems to me to be way to late to be included in >discussions. While those of us on the east coast might have a little time >for review, clearly others have almost no time. I think it would be >appropriate to delay discussion on this until next week. > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > > > >To: ipp%pwg.org@interlock.lexmark.com >cc: (bcc: Don Wright) >bcc: Don Wright >Subject: IPP> MOD - Updated MIB Access paper posted, V0.3 > > > > >Scott, Bob, Kris, and I finished the collaboration on the MIB access using >IPP. We incorporated the agreements from last week's telecon. >We'd like to present it at the telecon today, 10-12 PDT (1-3 EDT). >There are a few minor issues highlighted in yellow. >Its available at: >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.pdf >Please use the last one for the telecon. > >Here is the abstract: > IPP Device and MIB access > Version 0.03 > Abstract >This document introduces a new Device object into the IPP object model. An >IPP Printer object may support one or more Device objects which each >represent a physical device as shown in the Internet Printing Protocol/1.0: >Model and Semantics specification. This document provides read access to >such Device objects by defining a mapping from table entries in the Printer >MIB to new algorithmically generated attribute names. New algorithmically >generated attribute group names allow convenient read-only access to any >row, any column, and any entire table in the Printer MIB, as well as the >entire Printer MIB. A general algorithmically generated attribute name >provides access to any single SNMP object in any MIB. These new attribute >names and attribute group names are supplied in the "requested-attributes" >Operation attribute of the current Get-Printer-Attributes operation. A new >OPTIONAL "which-device" Operation attribute permits the requester to select >a particular device for the case where an IPP Printer object is supporting >more than one device. > > > > > > > > > From ipp-owner@pwg.org Wed May 6 14:49:54 1998 Delivery-Date: Wed, 06 May 1998 14:49:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA18782 for ; Wed, 6 May 1998 14:49:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14014 for ; Wed, 6 May 1998 14:52:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22974 for ; Wed, 6 May 1998 14:49:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 14:45:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22447 for ipp-outgoing; Wed, 6 May 1998 14:44:37 -0400 (EDT) Message-Id: <3.0.5.32.19980506110404.00bd6100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 6 May 1998 11:04:04 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-webdav-enpreq-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, A new version of the WebDAV event notifications has just come out. We should take a new look at this as a possible candidate delivery mechanism for IPP notifications using HTTP. Carl-Uno >To: IETF-Announce:; >Cc: w3c-dist-auth@w3.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-webdav-enpreq-01.txt >Date: Wed, 6 May 1998 08:05:34 PDT >Sender: cclark@CNRI.Reston.VA.US > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the WWW Distributed Authoring and Versioning >Working Group of the IETF. > > Title : Requirements for Event Notification Protocol > Author(s) : M. Fisher, S. Reddy > Filename : draft-ietf-webdav-enpreq-01.txt > Pages : 7 > Date : 05-May-98 > > This document describes the requirements for an Event Notification > Protocol. The objective is to provide a simple, scalable and highly > efficient notification protocol while also providing the appropriate > flexibility to meet the needs of both the Internet and enterprise > environments. Intent of this document is to collect all notification > requirements in one place and leverage the work already done in other > working groups. > > This document is one of a set of documents which together describe > all aspects of a new Event Notification Protocol (ENP). ENP is an > application level protocol that can be used for distributed event > notification. The full set of ENP documents include: > > (1). Requirements for Event Notification Protocol > > (2). Model and Semantics Event Notification Protocol > > (3). Protocol Specification for Event Notification Protocol > > (4). Rationale for the Structure and Model for the Event > Notification Protocol > >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-webdav-enpreq-01.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-enpreq-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-webdav-enpreq-01.txt". > >NOTE: The mail server at ietf.org 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: <19980505145738.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-webdav-enpreq-01.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed May 6 19:31:37 1998 Delivery-Date: Wed, 06 May 1998 19:31:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26132 for ; Wed, 6 May 1998 19:31:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15263 for ; Wed, 6 May 1998 19:34:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA23877 for ; Wed, 6 May 1998 19:31:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 19:25:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23263 for ipp-outgoing; Wed, 6 May 1998 19:21:08 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Test Message-ID: <5030300020679002000002L022*@MHS> Date: Wed, 6 May 1998 19:28:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26132 I fear we had an IPP phone conference today and failed to mention the big bang theory of testing which we're about to engage in next week. Right? Maybe there is separate conversation on this which I am missing. If not, we probably need some kind of call to kick this off. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed May 6 19:35:20 1998 Delivery-Date: Wed, 06 May 1998 19:35:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26173 for ; Wed, 6 May 1998 19:35:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15286 for ; Wed, 6 May 1998 19:37:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA24470 for ; Wed, 6 May 1998 19:35:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 19:30:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23644 for ipp-outgoing; Wed, 6 May 1998 19:29:03 -0400 (EDT) Message-Id: <199805062326.QAA02783@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 06 May 1998 16:30:00 -0700 To: sdp@pwg.org From: Robert Herriot Subject: SDP, IPP>PRO Proposal for TIPSI-like protocol Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I just finished scanning IEEE 1284.3 and IEEE1284.4. The most interesting part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4. This chapter describes a "Berkeley Sockets-compatible interface for clients and servers to access the services provided by 1284.4". So if I understand the intent of 1284.4, it is to provide a layer that supports sockets over parallel connections. All we need to do in IPP is reference sockets for TCP/IP and 1284.4 and we don't have to worry about the issues at that layer. So, I conclude that we don't need to packetize IPP or do much of what is proposed in Roger and Harry's paper. Instead, we can send IPP directly on sockets layered on top of TCP/IP or 1284.4. There are a few easy-to-solve dangling issues, such as chunking for document data and intermediate acknowledgement when attributes are verified for PrintJob. But otherwise IPP stays as is. If you disagree with my conclusions, I would like to know what the TIPSI-like packetizing layer provides that sockets don't also provide? Bob Herriot From ipp-owner@pwg.org Wed May 6 19:54:22 1998 Delivery-Date: Wed, 06 May 1998 19:54:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26365 for ; Wed, 6 May 1998 19:54:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15328 for ; Wed, 6 May 1998 19:56:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA25380 for ; Wed, 6 May 1998 19:54:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 19:50:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA24716 for ipp-outgoing; Wed, 6 May 1998 19:45:06 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: SDP, IPP>PRO Proposal for TIPSI-like protocol Message-ID: <5030300020679727000002L072*@MHS> Date: Wed, 6 May 1998 19:52:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26365 One thing it would buy is a simpler (than 1284.4) way to flow IPP over bidi parallel - no? Isn't this basically what Lexmark has found? I'm confused why TIPSI has a packet structure, Lexmark was shipping it on parallel and then .4 was invented - maybe some background could help (I always thought it was to flow SNMP over parallel ;-). If it's true that the .1 packet is only still there for legacy I might buy Bob's argument. But I suspect .4 is a much more complex implementation. Bob, doesn't your proposal say we would have to invent a transport (if not already there) to "IPize" every physical layer (ex. serial)? Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 05/06/98 05:32:34 PM Please respond to owner-ipp@pwg.org To: sdp@pwg.org cc: ipp@pwg.org Subject: SDP, IPP>PRO Proposal for TIPSI-like protocol I just finished scanning IEEE 1284.3 and IEEE1284.4. The most interesting part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4. This chapter describes a "Berkeley Sockets-compatible interface for clients and servers to access the services provided by 1284.4". So if I understand the intent of 1284.4, it is to provide a layer that supports sockets over parallel connections. All we need to do in IPP is reference sockets for TCP/IP and 1284.4 and we don't have to worry about the issues at that layer. So, I conclude that we don't need to packetize IPP or do much of what is proposed in Roger and Harry's paper. Instead, we can send IPP directly on sockets layered on top of TCP/IP or 1284.4. There are a few easy-to-solve dangling issues, such as chunking for document data and intermediate acknowledgement when attributes are verified for PrintJob. But otherwise IPP stays as is. If you disagree with my conclusions, I would like to know what the TIPSI-like packetizing layer provides that sockets don't also provide? Bob Herriot From ipp-owner@pwg.org Wed May 6 20:35:41 1998 Delivery-Date: Wed, 06 May 1998 20:35:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26759 for ; Wed, 6 May 1998 20:35:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15421 for ; Wed, 6 May 1998 20:37:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26241 for ; Wed, 6 May 1998 20:35:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 20:30:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25661 for ipp-outgoing; Wed, 6 May 1998 20:29:03 -0400 (EDT) Message-Id: <199805070025.RAA02881@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 06 May 1998 17:29:35 -0700 To: Harry Lewis From: Robert Herriot Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol Cc: sdp@pwg.org, ipp@pwg.org In-Reply-To: <5030300020679727000002L072*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA26759 Harry, You are correct, my assumption is that there is a socket-like layer for any type of connection that we connect a printer to and that IPP rides on top of this layer. This assumption is true for TCP/IP and for parallel connection with 1284.4 support. If we encounter a connection, such as serial where that is not the case, then we must define a similar layer to implement sockets, which hopefully borrows a lot from 1284.4. [Question to 1284.4 experts: could it work with serial or USB with very few changes?] In effect, I want the socket layer to handle the issues of multiplexing and read/write blocking and let the IPP layer concentrate on printer operations transmitted over a virtual connection. Bob Herriot At 04:52 PM 5/6/98 , you wrote: >One thing it would buy is a simpler (than 1284.4) way to flow IPP over bidi >parallel - no? Isn't this basically what Lexmark has found? I'm confused why >TIPSI has a packet structure, Lexmark was shipping it on parallel and then .4 >was invented - maybe some background could help (I always thought it was to >flow SNMP over parallel ;-). If it's true that the .1 packet is only still >there for legacy I might buy Bob's argument. But I suspect .4 is a much more >complex implementation. > >Bob, doesn't your proposal say we would have to invent a transport (if not >already there) to "IPize" every physical layer (ex. serial)? > >Harry Lewis - IBM Printing Systems > > > >owner-ipp@pwg.org on 05/06/98 05:32:34 PM >Please respond to owner-ipp@pwg.org >To: sdp@pwg.org >cc: ipp@pwg.org >Subject: SDP,  IPP>PRO Proposal for TIPSI-like protocol > > >I just finished scanning IEEE 1284.3 and IEEE1284.4.  The most interesting >part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4.  This >chapter describes a "Berkeley Sockets-compatible interface for clients and >servers to access the services provided by 1284.4". > >So if I understand the intent of 1284.4, it is to provide a layer that >supports sockets over parallel connections. All we need to do in IPP is >reference sockets for TCP/IP and 1284.4 and we don't have to worry about the >issues at that layer. > >So, I conclude that we don't need to packetize IPP or do much of what is >proposed in Roger and Harry's paper. Instead, we can send IPP directly on >sockets layered on top of TCP/IP or 1284.4.  There are a few easy-to-solve >dangling >issues, such as chunking for document data and intermediate acknowledgement >when attributes are verified for PrintJob. But otherwise IPP stays as is. > >If you disagree with my conclusions, I would like to know what the >TIPSI-like packetizing layer provides that sockets don't also provide? > >Bob Herriot > From ipp-owner@pwg.org Wed May 6 23:21:19 1998 Delivery-Date: Wed, 06 May 1998 23:21:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA04883 for ; Wed, 6 May 1998 23:21:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA15730 for ; Wed, 6 May 1998 23:23:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA27298 for ; Wed, 6 May 1998 23:21:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 6 May 1998 23:16:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA26595 for ipp-outgoing; Wed, 6 May 1998 23:12:27 -0400 (EDT) From: Harry Lewis To: , Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol Message-ID: <5030300020684435000002L052*@MHS> Date: Wed, 6 May 1998 23:19:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04883 Bob, hypothetically, your approach seems ideal. I just wonder about the degree of difficulty we're placing on the embedded device. Is IP overkill? If IP is the natural solution for every type of physical layer, why isn't P1394 doing it (I think they are using a serial bus protocol)? Since we're only trying to accommodate printing, print control and notification... is a generalized communications protocol, like IP, really a better solution than a well defined SDP packet? Harry Lewis - IBM Printing Systems owner-sdp@pwg.org on 05/06/98 06:36:08 PM Please respond to owner-sdp@pwg.org To: Harry Lewis/Boulder/IBM@ibmus cc: ipp@pwg.org, sdp@pwg.org Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol Harry, You are correct, my assumption is that there is a socket-like layer for any type of connection that we connect a printer to and that IPP rides on top of this layer. This assumption is true for TCP/IP and for parallel connection with 1284.4 support. If we encounter a connection, such as serial where that is not the case, then we must define a similar layer to implement sockets, which hopefully borrows a lot from 1284.4. [Question to 1284.4 experts: could it work with serial or USB with very few changes?] In effect, I want the socket layer to handle the issues of multiplexing and read/write blocking and let the IPP layer concentrate on printer operations transmitted over a virtual connection. Bob Herriot At 04:52 PM 5/6/98 , you wrote: >One thing it would buy is a simpler (than 1284.4) way to flow IPP over bidi >parallel - no? Isn't this basically what Lexmark has found? I'm confused why >TIPSI has a packet structure, Lexmark was shipping it on parallel and then .4 >was invented - maybe some background could help (I always thought it was to >flow SNMP over parallel ;-). If it's true that the .1 packet is only still >there for legacy I might buy Bob's argument. But I suspect .4 is a much more >complex implementation. > >Bob, doesn't your proposal say we would have to invent a transport (if not >already there) to "IPize" every physical layer (ex. serial)? > >Harry Lewis - IBM Printing Systems > > > >owner-ipp@pwg.org on 05/06/98 05:32:34 PM >Please respond to owner-ipp@pwg.org >To: sdp@pwg.org >cc: ipp@pwg.org >Subject: SDP,* IPP>PRO Proposal for TIPSI-like protocol > > >I just finished scanning IEEE 1284.3 and IEEE1284.4.* The most interesting >part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4.* This >chapter describes a "Berkeley Sockets-compatible interface for clients and >servers to access the services provided by 1284.4". > >So if I understand the intent of 1284.4, it is to provide a layer that >supports sockets over parallel connections. All we need to do in IPP is >reference sockets for TCP/IP and 1284.4 and we don't have to worry about the >issues at that layer. > >So, I conclude that we don't need to packetize IPP or do much of what is >proposed in Roger and Harry's paper. Instead, we can send IPP directly on >sockets layered on top of TCP/IP or 1284.4.* There are a few easy-to-solve >dangling >issues, such as chunking for document data and intermediate acknowledgement >when attributes are verified for PrintJob. But otherwise IPP stays as is. > >If you disagree with my conclusions, I would like to know what the >TIPSI-like packetizing layer provides that sockets don't also provide? > >Bob Herriot > From ipp-owner@pwg.org Thu May 7 10:55:39 1998 Delivery-Date: Thu, 07 May 1998 10:55:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA18410 for ; Thu, 7 May 1998 10:55:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA17167 for ; Thu, 7 May 1998 10:58:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA10909 for ; Thu, 7 May 1998 10:55:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 7 May 1998 10:50:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA10330 for ipp-outgoing; Thu, 7 May 1998 10:47:31 -0400 (EDT) From: Carl Kugler To: Subject: IPP> PRO Job Object Attributes Message-ID: <5030100020200268000002L082*@MHS> Date: Thu, 7 May 1998 10:46:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18410 Is the following interpretation correct? Attributes-charset and attributes-natural-language only appear as Job Object Attributes (or, more specifically, Job Description Attributes) in responses to Get-Job-Attributes or Get-Jobs requests. They MUST be sent if the client requests them in requested-attributes, because they are MANDATORY Job Description Attributes and thus MUST be supported. Furthermore, attributes-natural-language (but not necessarily attributes-charset) MUST be sent in the Job Object attribute group returned for any job that was submitted with a natural language which differs from that specified in the attributes-natural-language Operation Attribute of the response. -Carl-3 ipp-owner@pwg.org on 04/07/98 02:01:15 PM Please respond to ipp-owner@pwg.org To: hastings@cp10.es.xerox.com, Carl Kugler/Boulder/IBM@ibmus cc: robert.herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica > >But my question is specific to Job Description Attributes.* Aren't those >distinct from Operation attributes? Job Description attributes are one of two categories of Job (Object) Attributes. The other category is job template attributes. Operation attributes (i.e. those attributes in the operation attributes group) are attributes that are passed as part of a request or response. Some of these attributes in a request set the values of job description attributes which have the same name but they never set job template attributes. Attributes in the job attributes group of a request cause job template attributes in the job object to be set, but not job description attributes. Now you're probably wondering why some job attributes are job template attributes and others are job description attributes. Some attributes have gone back and forth between these two categrories several times. The original idea was that job template attributes are those collection of job attributes which a client, even the end user, is allowed to modify. These attributes typically have a list of supported values for the client to choose from and a default value if the client doesn't choose a value. The job description attributes are either set by the printer with no input from the client, e.g. job-id, or they are characteristics of a job that a user has no choice about, e.g. job-k-octets and document-format. These latter attributes have supported values and sometimes a default, but a client doesn't have a choice. The number of octets and the document-format are inherent qualities of the document. > >Section 4.3 says that attributes-charset and attributes-natural-language >Job Description Attributes MUST be supported by printer objects. > >(M*) indicates MANDATORY attributes that an IPP object MUST support, but >that a client may omit in a request or an IPP object may omit in a response. > >Isn't that the case for these particular Job Description Attributes?* Or is >there some subtle difference between the "job-description" attribute group >described in section 4.3 and the "Group 3: Job Object Attributes" described in >15.3.4.3? I hope the above explanation clears up the difference between job object attributes and job description attributes for requests. For reponses, the job attributes group can contain any job attribute, including job description and job template attributes. From ipp-owner@pwg.org Thu May 7 15:35:50 1998 Delivery-Date: Thu, 07 May 1998 15:35:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA26783 for ; Thu, 7 May 1998 15:35:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18501 for ; Thu, 7 May 1998 15:38:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA12697 for ; Thu, 7 May 1998 15:35:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 7 May 1998 15:30:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12103 for ipp-outgoing; Thu, 7 May 1998 15:28:47 -0400 (EDT) Message-Id: <199805071925.MAA04525@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 07 May 1998 12:29:13 -0700 To: Harry Lewis , , From: Robert Herriot Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol In-Reply-To: <5030300020684435000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA26783 I am not suggesting that we define IP or TCP/IP over serial. Rather, I am suggesting that IPP be sent via sockets and that if sockets are not available for some connection, such as serial, that we define a lower layer that supports a sockets implementation. We then have two clean layers -- one that supports sockets and the other (IPP) that assumes socket support. As I said in my last email, I would hope that the 1284.4 design would work on serial and USB with very few changes. But I leave it to others to tell me how hard it would be to make 1284.4 work on serial and USB. Bob Herriot At 08:19 PM 5/6/98 , Harry Lewis wrote: >Bob, hypothetically, your approach seems ideal. I just wonder about the degree >of difficulty we're placing on the embedded device. Is IP overkill? If IP is >the natural solution for every type of physical layer, why isn't P1394 doing it >(I think they are using a serial bus protocol)? > >Since we're only trying to accommodate printing, print control and >notification... is a generalized communications protocol, like IP, really a >better solution than a well defined SDP packet? > >Harry Lewis - IBM Printing Systems > > > >owner-sdp@pwg.org on 05/06/98 06:36:08 PM >Please respond to owner-sdp@pwg.org >To: Harry Lewis/Boulder/IBM@ibmus >cc: ipp@pwg.org, sdp@pwg.org >Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol > > >Harry, > >You are correct, my assumption is that there is a socket-like layer for any >type of >connection that we connect a printer to and that IPP rides on top of this >layer.  This assumption is true for TCP/IP and for parallel connection with >1284.4 support. If we encounter a connection, such as serial where that is >not the case, then we must define a similar layer to implement sockets, which >hopefully borrows a lot from 1284.4. [Question to 1284.4 experts: could it >work with serial or USB with very few changes?] > >In effect, I want the socket layer to handle the issues of multiplexing and >read/write blocking and let the IPP layer concentrate on printer operations >transmitted over a virtual connection. > >Bob Herriot > >At 04:52 PM 5/6/98 , you wrote: >>One thing it would buy is a simpler (than 1284.4) way to flow IPP over bidi >>parallel - no? Isn't this basically what Lexmark has found? I'm confused why >>TIPSI has a packet structure, Lexmark was shipping it on parallel and then .4 >>was invented - maybe some background could help (I always thought it was to >>flow SNMP over parallel ;-). If it's true that the .1 packet is only still >>there for legacy I might buy Bob's argument. But I suspect .4 is a much more >>complex implementation. >> >>Bob, doesn't your proposal say we would have to invent a transport (if not >>already there) to "IPize" every physical layer (ex. serial)? >> >>Harry Lewis - IBM Printing Systems >> >> >> >>owner-ipp@pwg.org on 05/06/98 05:32:34 PM >>Please respond to owner-ipp@pwg.org >>To: sdp@pwg.org >>cc: ipp@pwg.org >>Subject: SDP,* IPP>PRO Proposal for TIPSI-like protocol >> >> >>I just finished scanning IEEE 1284.3 and IEEE1284.4.* The most interesting >>part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4.* This >>chapter describes a "Berkeley Sockets-compatible interface for clients and >>servers to access the services provided by 1284.4". >> >>So if I understand the intent of 1284.4, it is to provide a layer that >>supports sockets over parallel connections. All we need to do in IPP is >>reference sockets for TCP/IP and 1284.4 and we don't have to worry about the >>issues at that layer. >> >>So, I conclude that we don't need to packetize IPP or do much of what is >>proposed in Roger and Harry's paper. Instead, we can send IPP directly on >>sockets layered on top of TCP/IP or 1284.4.* There are a few easy-to-solve >>dangling >>issues, such as chunking for document data and intermediate acknowledgement >>when attributes are verified for PrintJob. But otherwise IPP stays as is. >> >>If you disagree with my conclusions, I would like to know what the >>TIPSI-like packetizing layer provides that sockets don't also provide? >> >>Bob Herriot >> > From ipp-owner@pwg.org Thu May 7 18:06:27 1998 Delivery-Date: Thu, 07 May 1998 18:06:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29256 for ; Thu, 7 May 1998 18:06:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19449 for ; Thu, 7 May 1998 18:08:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA13685 for ; Thu, 7 May 1998 18:06:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 7 May 1998 18:01:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12970 for ipp-outgoing; Thu, 7 May 1998 17:57:32 -0400 (EDT) Message-Id: <3.0.5.32.19980507145702.00a56490@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 7 May 1998 14:57:02 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 980506 Cc: sdp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Minutes from PWG IPP Phone Conference 980506 ============================================ Attending: Randy Turner Don Wright Jay Martin Carl-Uno Manros Tom Hastings Roger deBry Harry Lewis Bob Herriot Scott Isaacson Main agenda points: - Discussion of white paper "Print Server-to-Device Protocol Proposal" - New draft of white paper "Event notifications for the IPP print protocol" - New draft of white paper "IPP Device and MIB access" - Plans for PWG IPP meeting At Crystal City on May 20-21, 1998 Discussion of white paper "Print Server-to-Device Protocol Proposal" -------------------------------------------------------------------- Roger introduced the paper. Points raised in the discussion: - Don did not see an advantage to do things differently from TIP/SI. - Bob suggested that the proposal duplicates some TCP/IP functionality - Randy suggested that we need to define a transport independent solution, but document required properties of the transport - Randy suggested that IEEE 1284.4 could be used in combination with IPP semantics and syntax Further discussion is obviously needed, but there was a tendency to consider whether mapping of IPP semantics to a new transport independent layer and use of a TIP/SI subset might be an acceptable route. Conclusion to put the subject on the agenda for the upcoming IPP meeting, preferably on the Thursday as Randy may not be able to attend Wednesday. Harry will prepare a draft PWG charter for this work, and Randy will prepare short presentations on IEEE 1284.3 and 1284.4 for the meeting. Don will send out references to electronic copies of the 1284.3 and 1284.4 drafts. Finally, it was emphasised that this activity is: IN NO WAY INTENDED AS AN ALTERNIVE OR REPLACEMENT FOR IPP V1.0, but rather a natural extension and complement. The detailed further discussion will be held on the SDP DL. New draft of white paper "Event notifications for the IPP print protocol" ------------------------------------------------------------------------- Tom introduced the changes that had been done since the previous version. Remaining issues will be discussed in the upcoming IPP meeting. Tom and Harry will update the paper once more before the IPP meeting. The intension is to produce an IETF I-D after that meeting. Carl-Uno suggested to loook at Josh Cohen's draft on event notifications for WebDAV to determine if that might provide one future method for IPP notification delivery. New draft of white paper "IPP Device and MIB access" ---------------------------------------------------- A new draft had just been sent out. Scott introduced the paper briefly, but it was decided to leave all discussion until the IPP meeting. Final Editing ------------- Carl-Uno asked Scott and Bob as editors to pull together any small editorial fixes that we want to get into the RFC versions for IPP V1.0. Please send messages to the editors for any such things that you have discovered ASAP. Plans for PWG IPP meeting At Crystal City on May 20-21, 1998 ------------------------------------------------------------ Scott will prepare the final agenda and chair the next PWG IPP meeting as Carl-Uno will be on vacation. The agenda should include the subjects mentioned above plus any feedback from the IESG, and a session on IPP interoperability testing. Carl-Uno will be vacationing in Europe May 11-26, but is carrying a laptop, so do not get too wild... --- Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri May 8 18:40:37 1998 Delivery-Date: Fri, 08 May 1998 18:40:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA19061 for ; Fri, 8 May 1998 18:40:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA23765 for ; Fri, 8 May 1998 18:42:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA27041 for ; Fri, 8 May 1998 18:40:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 8 May 1998 18:35:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26513 for ipp-outgoing; Fri, 8 May 1998 18:31:52 -0400 (EDT) Message-Id: <3.0.5.32.19980508153056.00ab5210@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 8 May 1998 15:30:56 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - No PWG IPP Phone Conference 980513 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi, Please note that we decided to cancel the phone conference for 980513. Instead, use the time to read through new documents in time for the DC meeting on May 20-21. Have fun while I am away. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon May 11 07:27:18 1998 Delivery-Date: Mon, 11 May 1998 07:27:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA19871 for ; Mon, 11 May 1998 07:27:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA02000 for ; Mon, 11 May 1998 07:29:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA03383 for ; Mon, 11 May 1998 07:27:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 07:16:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA02810 for ipp-outgoing; Mon, 11 May 1998 07:13:47 -0400 (EDT) Content-return: allowed Date: Mon, 11 May 1998 04:12:54 PDT From: "Zehler, Peter " Subject: RE: IPP> Test To: Harry Lewis , ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org Harry, So far the only companies that have openly announced interest in testing this week are Auco, IBM, and Xerox. I have given IBM and AUCO the URL of Xerox's IPP Printer. This printer is (I hope) available anytime for running tests against. Anyone interested may contact me for the URL. This week you will need to contact me via phone. I will be out of the office and only able to respond by phone. I just want to get anyone who has something close to ready to give it a try. This is an opportunity to work out firewall, proxy, basic connectivity and simple IPP protocol issues prior to structured testing. At our upcoming meeting I hope we can finally get some interest in the group as a whole. We can then plan some testing methodology and scheduling to get us on our way. I will have an update to the test plan by then. I hope we can come away from that meeting with some concrete testing plans. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Wednesday, May 06, 1998 7:28 PM To: ipp@pwg.org Subject: IPP> Test I fear we had an IPP phone conference today and failed to mention the big bang theory of testing which we're about to engage in next week. Right? Maybe there is separate conversation on this which I am missing. If not, we probably need some kind of call to kick this off. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Mon May 11 15:06:16 1998 Delivery-Date: Mon, 11 May 1998 15:06:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25468 for ; Mon, 11 May 1998 15:06:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04254 for ; Mon, 11 May 1998 15:08:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA06233 for ; Mon, 11 May 1998 15:06:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 15:01:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05702 for ipp-outgoing; Mon, 11 May 1998 15:00:32 -0400 (EDT) From: Carl Kugler To: Subject: IPP>MOD Status code for URI's too long? Message-ID: <5030100020346851000002L012*@MHS> Date: Mon, 11 May 1998 14:59:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25468 If the case of an unknown or unsupported attribute with 'uri' syntax that fails the length (<= 1023) check, does the Printer return 'client-error-request-uri-too-long' or 'client-error-bad-request'? Reading section 15.3, I get the impression that the 'client-error-request-uri-too-long' only applies to the "document-uri" attribute. And in the particular case of unknown or unsupported attribute IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN 'client-error-bad-request'. -Carl From ipp-owner@pwg.org Mon May 11 15:20:52 1998 Delivery-Date: Mon, 11 May 1998 15:20:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25726 for ; Mon, 11 May 1998 15:20:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04379 for ; Mon, 11 May 1998 15:23:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA06860 for ; Mon, 11 May 1998 15:20:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 15:16:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06326 for ipp-outgoing; Mon, 11 May 1998 15:13:31 -0400 (EDT) From: Carl Kugler To: Subject: IPP>MOD Status code for URI's too long? Message-ID: <5030100020347391000002L012*@MHS> Date: Mon, 11 May 1998 15:11:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25726 P.S. My preference would be to always return 'client-error-request-uri-too-long' for any 'uri' that fails the length check. That way, the checking can be done in a lower layer that understands attributes syntaxes but not specific attributes. ----------------------------------------------------------------------- If the case of an unknown or unsupported attribute with 'uri' syntax that fails the length (<= 1023) check, does the Printer return 'client-error-request-uri-too-long' or 'client-error-bad-request'? Reading section 15.3, I get the impression that the 'client-error-request-uri-too-long' only applies to the "document-uri" attribute. And in the particular case of unknown or unsupported attribute IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN 'client-error-bad-request'. -Carl From ipp-owner@pwg.org Mon May 11 15:45:46 1998 Delivery-Date: Mon, 11 May 1998 15:45:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA26005 for ; Mon, 11 May 1998 15:45:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04546 for ; Mon, 11 May 1998 15:48:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA07503 for ; Mon, 11 May 1998 15:45:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 15:41:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06965 for ipp-outgoing; Mon, 11 May 1998 15:40:45 -0400 (EDT) Message-Id: <199805111937.MAA06696@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 11 May 1998 12:41:19 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD Status code for URI's too long? In-Reply-To: <5030100020346851000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipp@pwg.org I have assumed that  'client-error-bad-request' is the correct response for
an unknown or unsupported attribute with 'uri' syntax .  Though I think that
we should make 'client-error-bad-request'  be the response for a
document-uri that is too long as well because a length error is a low level
error which is likely to be detected out of the context of a particular
attribute.  So I see no value in making a special exception for one
attribute's length error.


Comment?

Bob Herriot

At 11:59 AM 5/11/98 , Carl Kugler wrote:
>If the case of an unknown or unsupported attribute with 'uri' syntax that fails
>the length (<=3D 1023) check, does the Printer return
>'client-error-request-uri-too-long' or 'client-error-bad-request'?=A0 Reading
>section 15.3, I get the impression that the 'client-error-request-uri-too-long'
>only applies to the "document-uri" attribute.=A0 And in the particular case of
>
>unknown or unsupported attribute
>IF the attribute syntax supplied by the client is supported but the length is
>not legal for that attribute syntax, REJECT/RETURN 'client-error-bad-request'.
>
>=A0 -Carl
>
From ipp-owner@pwg.org Mon May 11 15:53:58 1998 Delivery-Date: Mon, 11 May 1998 15:53:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA26072 for ; Mon, 11 May 1998 15:53:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04592 for ; Mon, 11 May 1998 15:56:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA08114 for ; Mon, 11 May 1998 15:53:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 15:49:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA07511 for ipp-outgoing; Mon, 11 May 1998 15:45:40 -0400 (EDT) Message-Id: <199805111942.MAA06710@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 11 May 1998 12:46:11 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD Status code for URI's too long? In-Reply-To: <5030100020347391000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipp@pwg.org I think that we are in agreement per my previous email except for  the error message. 
An error message that says bad length is more useful that 'client-error-bad-request',
but if we do this for uri's, why don't we do it for other types, especially text and name
types where the length can also be exceeded easily?

Bob Herriot

At 12:11 PM 5/11/98 , Carl Kugler wrote:
>P.S.=A0 My preference would be to always return
>'client-error-request-uri-too-long' for any 'uri' that fails the length check.
>That way, the checking can be done in a lower layer that understands attributes
>syntaxes but not specific=A0 attributes.
>
>-----------------------------------------------------------------------<= br> >
>If the case of an unknown or unsupported attribute with 'uri' syntax that fails
>the length (<=3D 1023) check, does the Printer return
>'client-error-request-uri-too-long' or 'client-error-bad-request'?=A0 Reading
>section 15.3, I get the impression that the 'client-error-request-uri-too-long'
>only applies to the "document-uri" attribute.=A0 And in the particular case of
>
>unknown or unsupported attribute
>IF the attribute syntax supplied by the client is supported but the length is
>not legal for that attribute syntax, REJECT/RETURN 'client-error-bad-request'.
>
>=A0 -Carl
>
From ipp-owner@pwg.org Mon May 11 16:55:57 1998 Delivery-Date: Mon, 11 May 1998 16:55:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26982 for ; Mon, 11 May 1998 16:55:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04867 for ; Mon, 11 May 1998 16:58:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08938 for ; Mon, 11 May 1998 16:55:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 16:51:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08407 for ipp-outgoing; Mon, 11 May 1998 16:50:38 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 11 May 1998 14:45:54 -0600 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> ADM - IPP agend for the 5/20-21 meetings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26982 I am trying to put together the agenda for the IPP meetings next week in DC. I publish this as a first draft to make sure that I have not forgotten anything. If you see a need to add something, please ping me. Scott I. Wednesday, 5/20 11:00 AM - 11:30 PM IPP Misc.(all) Agenda fixing, progress of IPP in the IETF report, etc. 11:30 AM - 12:00 PM Bug fixes in current IPP documentation (Scott, Bob) List of "minor editorial/bug fix changes" for Model and Semantics document (Scott) and the Transport and Encoding Document (Bob). Editors please post the list of proposed changes prior to the meeting and come ready to present the list and solicit input on additial needed fixes. 12:00 PM - 1:30 PM Lunch 1:30 PM - 2:30 PM Interoperability Testing (Pete Z.) Peter will report on the past, present, and future of interoperability testing and lead a discussion about how to proceed. One of our goals is to progress IPP as far down the IETF standards track as possible - this included demonstrating two or more interoperable implementations. It is hard to argue with a spec and products. 2:30 - 6:00 MIB Access (Scott, Tom) (including a break somewhere) Review the latest proposal on integrating MIB Table access into the IPP Get-Printer-Attributes operation. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.pdf The last one (ipp-mib-access-980505.pdf) will be used during the meeting, the other formats are included only for reference. We should work through some examples to check for understanding and to validate the completeness of the proposal. Thursday, 5/21 8:30 - 12:00 Notification (Tom, Harry) (including a break somewhere) Review the latest proposal on IPP event semantics and subcription and notification mechanisms. The current document is posted at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf Tom expects to post another version before the the face to face Look for a mail message on the mailing list announcing that the new version has been posted. We will review the non-revision marked file with line numbers. We should work through some examples to check for understanding and to validate the completeness of the proposal. 12:00 - 1:30 Lunch 1:30 - 6:00 Server to Device Issues (SDP) (Roger, Harry) (including a break somewhere) Review the proposal from Roger and Harry on "Printer Server-to-Device Protocol Proposal" See: ftp://ftp.pwg.org/pub/pwg/sdp/sdp-proposal.txt ftp://ftp.pwg.org/pub/pwg/sdp/sdp-proposal.pdf We should work through some examples to check for understanding and to validate the completeness of the proposal. Reference material can be found in Don's mail message "SDP> Pointers to P1284.3, P1284.4 and IEEE Std 1284.1-1997": http://www.pwg.org/hypermail/sdp/0024.html which in turn references: ftp://ftp.lexmark.com/pub/ieee/1284.3/d400.pdf ftp://ftp.lexmark.com/pub/ieee/1284.4/specification/draft170.pdf I can't remember if we decided that there would be a presentation on these by someone at the meeting? From ipp-owner@pwg.org Mon May 11 17:46:00 1998 Delivery-Date: Mon, 11 May 1998 17:46:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27868 for ; Mon, 11 May 1998 17:45:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05069 for ; Mon, 11 May 1998 17:48:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09704 for ; Mon, 11 May 1998 17:46:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 17:41:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09151 for ipp-outgoing; Mon, 11 May 1998 17:37:29 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP>MOD Status code for URI's too long? Message-ID: <5030100020354752000002L022*@MHS> Date: Mon, 11 May 1998 17:35:50 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100020354752" Sender: owner-ipp@pwg.org --Boundary=_0.0_=5030100020354752 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree that it would be simpler to return 'client-error-bad-request' w= henever an attribute fails the length test. Why was 'client-error-request-uri-too-long' introduced in the first place? If = there is strong consensus that we don't need it, can we change the document? -Carl = --Boundary=_0.0_=5030100020354752 Content-Type: application/octet-stream; name=xhtml Content-Transfer-Encoding: base64 PGh0bWw+DQo8Zm9udCBzaXplPTM+SSB0aGluayB0aGF0IHdlIGFyZSBpbiBhZ3JlZW1lbnQgcGVy IG15IHByZXZpb3VzIGVtYWlsDQpleGNlcHQgZm9yJm5ic3A7IHRoZSBlcnJvciBtZXNzYWdlLiZu YnNwOyA8YnI+DQpBbiBlcnJvciBtZXNzYWdlIHRoYXQgc2F5cyBiYWQgbGVuZ3RoIGlzIG1vcmUg dXNlZnVsIHRoYXQNCidjbGllbnQtZXJyb3ItYmFkLXJlcXVlc3QnLDxicj4NCmJ1dCBpZiB3ZSBk byB0aGlzIGZvciB1cmkncywgd2h5IGRvbid0IHdlIGRvIGl0IGZvciBvdGhlciB0eXBlcywNCmVz cGVjaWFsbHkgdGV4dCBhbmQgbmFtZTxicj4NCnR5cGVzIHdoZXJlIHRoZSBsZW5ndGggY2FuIGFs c28gYmUgZXhjZWVkZWQgZWFzaWx5Pzxicj4NCjxicj4NCkJvYiBIZXJyaW90PGJyPg0KPGJyPg0K QXQgMTI6MTEgUE0gNS8xMS85OCAsIENhcmwgS3VnbGVyIHdyb3RlOjxicj4NCiZndDtQLlMuoCBN eSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGFsd2F5cyByZXR1cm48YnI+DQomZ3Q7J2NsaWVudC1l cnJvci1yZXF1ZXN0LXVyaS10b28tbG9uZycgZm9yIGFueSAndXJpJyB0aGF0IGZhaWxzIHRoZQ0K bGVuZ3RoIGNoZWNrLjxicj4NCiZndDtUaGF0IHdheSwgdGhlIGNoZWNraW5nIGNhbiBiZSBkb25l IGluIGEgbG93ZXIgbGF5ZXIgdGhhdCB1bmRlcnN0YW5kcw0KYXR0cmlidXRlczxicj4NCiZndDtz eW50YXhlcyBidXQgbm90IHNwZWNpZmljoCBhdHRyaWJ1dGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0O0lmIHRoZSBjYXNlIG9mIGFuIHVua25v d24gb3IgdW5zdXBwb3J0ZWQgYXR0cmlidXRlIHdpdGggJ3VyaScgc3ludGF4DQp0aGF0IGZhaWxz PGJyPg0KJmd0O3RoZSBsZW5ndGggKCZsdDs9IDEwMjMpIGNoZWNrLCBkb2VzIHRoZSBQcmludGVy IHJldHVybjxicj4NCiZndDsnY2xpZW50LWVycm9yLXJlcXVlc3QtdXJpLXRvby1sb25nJyBvciAn Y2xpZW50LWVycm9yLWJhZC1yZXF1ZXN0Jz+gDQpSZWFkaW5nPGJyPg0KJmd0O3NlY3Rpb24gMTUu MywgSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUNCidjbGllbnQtZXJyb3ItcmVxdWVzdC11 cmktdG9vLWxvbmcnPGJyPg0KJmd0O29ubHkgYXBwbGllcyB0byB0aGUgJnF1b3Q7ZG9jdW1lbnQt dXJpJnF1b3Q7IGF0dHJpYnV0ZS6gIEFuZCBpbiB0aGUNCnBhcnRpY3VsYXIgY2FzZSBvZjxicj4N CiZndDs8YnI+DQomZ3Q7dW5rbm93biBvciB1bnN1cHBvcnRlZCBhdHRyaWJ1dGU8YnI+DQomZ3Q7 SUYgdGhlIGF0dHJpYnV0ZSBzeW50YXggc3VwcGxpZWQgYnkgdGhlIGNsaWVudCBpcyBzdXBwb3J0 ZWQgYnV0IHRoZQ0KbGVuZ3RoIGlzPGJyPg0KJmd0O25vdCBsZWdhbCBmb3IgdGhhdCBhdHRyaWJ1 dGUgc3ludGF4LCBSRUpFQ1QvUkVUVVJODQonY2xpZW50LWVycm9yLWJhZC1yZXF1ZXN0Jy48YnI+ DQomZ3Q7PGJyPg0KJmd0O6AgLUNhcmw8YnI+DQomZ3Q7IDwvZm9udD4NCjxCUj4NCjwvaHRtbD4N Cg== --Boundary=_0.0_=5030100020354752-- From ipp-owner@pwg.org Mon May 11 18:05:38 1998 Delivery-Date: Mon, 11 May 1998 18:05:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28030 for ; Mon, 11 May 1998 18:05:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05190 for ; Mon, 11 May 1998 18:08:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10388 for ; Mon, 11 May 1998 18:05:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 18:01:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09827 for ipp-outgoing; Mon, 11 May 1998 17:56:51 -0400 (EDT) Message-Id: <199805112153.OAA07000@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 11 May 1998 14:57:19 -0700 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD Status code for URI's too long? In-Reply-To: <5030100020354752000002L022*@MHS> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_12281369==_.ALT" Sender: owner-ipp@pwg.org --=====================_12281369==_.ALT Content-Type: text/plain; charset="us-ascii" I cannot remember why we introduced it. But after talking with Tom, I would support changing the message 'client-error-request-uri-too-long' to 'client-error-request-value-too-long' and have it apply to all types that are text-like, namely text, name, charset, language, keywork, uri, uri-scheme, mime-media-type, text-with-language, and name-with-language. This message would be returned like 'bad-request' and indicate that no processing was going to take place, but it would give a user a bit more information about why theclient isn't behaving. In the case of 'client-error-request-value-too-long', the user might realize that if he sent in a short text field, things would work. Bob Herriot At 02:35 PM 5/11/98 , Carl Kugler wrote: >I agree that it would be simpler to return 'client-error-bad-request' whenever >an attribute fails the length test. Why was >'client-error-request-uri-too-long' introduced in the first place? If there is >strong consensus that we don't need it, can we change the document? > > -Carl > > >C > --=====================_12281369==_.ALT Content-Type: text/html; charset="us-ascii" I cannot remember why we introduced it.  But after talking with Tom, I would
support changing the message 'client-error-request-uri-too-long'  to
'client-error-request-value-too-long' and have it apply to all types that
are text-like, namely text, name, charset, language, keywork, uri,
uri-scheme, mime-media-type, text-with-language, and name-with-language. 
This message would be returned like 'bad-request' and indicate that no
processing was going to take place, but it would give a user a bit more
information about why theclient isn't behaving.  In the case of
'client-error-request-value-too-long', the user might realize that if he
sent in a short text field, things would work.


Bob Herriot


At 02:35 PM 5/11/98 , Carl Kugler wrote:
>I agree that it would be simpler to return 'client-error-bad-request' whenever
>an attribute fails the length test.  Why was
>'client-error-request-uri-too-long' introduced in the first place?  If there is
>strong consensus that we don't need it, can we change the document?
>
> -Carl
>
>
>C
>
--=====================_12281369==_.ALT-- From ipp-owner@pwg.org Mon May 11 18:46:08 1998 Delivery-Date: Mon, 11 May 1998 18:46:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28633 for ; Mon, 11 May 1998 18:45:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05364 for ; Mon, 11 May 1998 18:48:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11101 for ; Mon, 11 May 1998 18:45:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 18:41:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10558 for ipp-outgoing; Mon, 11 May 1998 18:38:49 -0400 (EDT) Message-Id: <3.0.1.32.19980511151911.013327d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 11 May 1998 15:19:11 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD & PRO - "printer-uri" or "job-uri" in Operation Attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The IPP/1.0 Protocol document examples do not show the "printer-uri" or "job-uri" (or "printer-uri" and "job-id") as being one (two) of the Operation attributes in each request. The Model document is quite clear about the "Target" for each request being one or two Operation attributes. See section 3.1.3. I belive that we agreed at the end that in order to make our protocol independent of the transport, that the "target" of the request would be passed in the Operation Attribute group (as well as being in the HTTP/1.1 header). So we should add the "printer-uri", "job-uri", or "printer-uri"/"job-id" attributes to the request examples. ISSUE: where in the Operation attribute group, should these attributes go? We have already agreed that the "attributes-charset" and "attributes-natural-language" SHALL come first, in that order, since the charset is needed in order to be able to understand the subsequent attributes in the Operation Attributes group that have values that are text or name. And both attributes MUST be passed in every request and response. In talking with Bob Herriot, we suggest that the target come immediately after the "attributes-charset" and "attributes-natural-language attributes. Thus the next attribute SHALL be: "printer-uri" or "job-uri" or the next two attributes SHALL be: "printer-uri" and "job-id", depending on the operation. So the Model document needs to be updated to specify the order of the above Operation attributes, since the order applies to all protocol mappings. Ok? Tom From ipp-owner@pwg.org Mon May 11 19:40:56 1998 Delivery-Date: Mon, 11 May 1998 19:40:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28941 for ; Mon, 11 May 1998 19:40:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05582 for ; Mon, 11 May 1998 19:43:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA11968 for ; Mon, 11 May 1998 19:40:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 19:36:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11432 for ipp-outgoing; Mon, 11 May 1998 19:36:05 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> MOD & PRO - "printer-uri" or "job-uri" in Operation Message-ID: <5030100020360260000002L002*@MHS> Date: Mon, 11 May 1998 19:33:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28941 Maybe it's too late to question whether or not the Target should go outside of the operation layer as the request-URI on the Request-Line at the HTTP level AND into the Operation Attributes, but I can think of a couple downsides: 1) From a design perspective, it breaks the paradigm of invoking an operation (IPP Operation) on a specified object (Target), because the object reference is now part of the operation. This architectural impurity manifests itself as: 2) A practical problem: our testing methodology is broken, because binary IPP trace files will have to embed Target URIs. We will no longer be able to take an existing trace file and try it on different Printers (and so far that has been a useful capability). -Carl owner-ipp@pwg.org on 05/11/98 04:44:30 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> MOD & PRO - "printer-uri" or "job-uri" in Operation Att The IPP/1.0 Protocol document examples do not show the "printer-uri" or "job-uri" (or "printer-uri" and "job-id") as being one (two) of the Operation attributes in each request. The Model document is quite clear about the "Target" for each request being one or two Operation attributes. See section 3.1.3. I belive that we agreed at the end that in order to make our protocol independent of the transport, that the "target" of the request would be passed in the Operation Attribute group (as well as being in the HTTP/1.1 header). So we should add the "printer-uri", "job-uri", or "printer-uri"/"job-id" attributes to the request examples. ISSUE: where in the Operation attribute group, should these attributes go? We have already agreed that the "attributes-charset" and "attributes-natural-language" SHALL come first, in that order, since the charset is needed in order to be able to understand the subsequent attributes in the Operation Attributes group that have values that are text or name. And both attributes MUST be passed in every request and response. In talking with Bob Herriot, we suggest that the target come immediately after the "attributes-charset" and "attributes-natural-language attributes. Thus the next attribute SHALL be: "printer-uri" or "job-uri" or the next two attributes SHALL be: "printer-uri" and "job-id", depending on the operation. So the Model document needs to be updated to specify the order of the above Operation attributes, since the order applies to all protocol mappings. Ok? Tom From ipp-owner@pwg.org Tue May 12 13:12:56 1998 Delivery-Date: Tue, 12 May 1998 13:12:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19614 for ; Tue, 12 May 1998 13:12:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08367 for ; Tue, 12 May 1998 13:15:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17609 for ; Tue, 12 May 1998 13:12:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 12 May 1998 13:01:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17024 for ipp-outgoing; Tue, 12 May 1998 12:57:07 -0400 (EDT) Message-ID: <007701bd7dc6$304a6360$1e0564d2@tulip> From: "Peter Michalek" To: "Zehler, Peter " , "Harry Lewis" , Subject: Re: IPP> Test Date: Tue, 12 May 1998 09:50:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org If anyone else is interested in testing this week, client or server, please e-mail me. Thanks, Peter -----Original Message----- From: Zehler, Peter To: Harry Lewis ; ipp@pwg.org Date: Monday, May 11, 1998 4:24 AM Subject: RE: IPP> Test >Harry, >So far the only companies that have openly announced interest in testing >this week are Auco, IBM, and Xerox. I have given IBM and AUCO the URL of >Xerox's IPP Printer. This printer is (I hope) available anytime for running >tests against. Anyone interested may contact me for the URL. This week you >will need to contact me via phone. I will be out of the office and only >able to respond by phone. >I just want to get anyone who has something close to ready to give it a try. >This is an opportunity to work out firewall, proxy, basic connectivity and >simple IPP protocol issues prior to structured testing. >At our upcoming meeting I hope we can finally get some interest in the group >as a whole. We can then plan some testing methodology and scheduling to get >us on our way. I will have an update to the test plan by then. I hope we >can come away from that meeting with some concrete testing plans. >Pete Peter Michalek, peterm@shinesoft.com ShineSoft Systems (408) 446-5040 www.shinesoft.com From ipp-owner@pwg.org Tue May 12 15:26:44 1998 Delivery-Date: Tue, 12 May 1998 15:26:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22845 for ; Tue, 12 May 1998 15:26:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09191 for ; Tue, 12 May 1998 15:29:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA18744 for ; Tue, 12 May 1998 15:26:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 12 May 1998 15:21:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18183 for ipp-outgoing; Tue, 12 May 1998 15:19:38 -0400 (EDT) Date: Tue, 12 May 1998 12:18:54 -0700 (PDT) From: Van Dang Message-Id: <199805121918.MAA21944@gaia.ecs.csus.edu> To: ipp@pwg.org Subject: Re: IPP>MOD Status code for URI's too long? Sender: owner-ipp@pwg.org If I interpret the IPP/1.0 Model and Semantics document section 13.1.4.10 correctly, the error "client-error-request- uri-too-long (0x0409)", should be used when a uri attribute length is <= 1023 bytes but greater than the length that is supported by the IPP object. In the case where the uri attribute length actually exceeds 1023, the error returned should be "client-error-bad-request (0x0400)". We can change "client-error-request-uri-too-long" to "client-error-request-value-too-long" to include the cases for text and name attributes, but its use should indicate that the attribute value itself conforms to the IPP boundary limit, but might be too big for the IPP object to process. Van D. Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by thunder.rose.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA10416 for ; Mon, 11 May 1998 15:10:09 -0700 (PDT) Received: from atlrel2.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA157884600; Mon, 11 May 1998 15:10:01 -0700 Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA19071; Mon, 11 May 1998 18:09:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10084; Mon, 11 May 1998 18:03:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 18:01:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09827 for ipp-outgoing; Mon, 11 May 1998 17:56:51 -0400 (EDT) Message-Id: <199805112153.OAA07000@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 11 May 1998 14:57:19 -0700 To: Carl Kugler , >From: Robert Herriot Subject: Re: IPP>MOD Status code for URI's too long? In-Reply-To: <5030100020354752000002L022*@MHS> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_12281369==_.ALT" Sender: owner-ipp@pwg.org --=====================_12281369==_.ALT Content-Type: text/plain; charset="us-ascii" I cannot remember why we introduced it. But after talking with Tom, I would support changing the message 'client-error-request-uri-too-long' to 'client-error-request-value-too-long' and have it apply to all types that are text-like, namely text, name, charset, language, keywork, uri, uri-scheme, mime-media-type, text-with-language, and name-with-language. This message would be returned like 'bad-request' and indicate that no processing was going to take place, but it would give a user a bit more information about why theclient isn't behaving. In the case of 'client-error-request-value-too-long', the user might realize that if he sent in a short text field, things would work. Bob Herriot At 02:35 PM 5/11/98 , Carl Kugler wrote: >I agree that it would be simpler to return 'client-error-bad-request' whenever >an attribute fails the length test. Why was >'client-error-request-uri-too-long' introduced in the first place? If there is >strong consensus that we don't need it, can we change the document? > > -Carl > > >C > --=====================_12281369==_.ALT Content-Type: text/html; charset="us-ascii" I cannot remember why we introduced it.  But after talking with Tom, I would
support changing the message 'client-error-request-uri-too-long'  to
'client-error-request-value-too-long' and have it apply to all types that
are text-like, namely text, name, charset, language, keywork, uri,
uri-scheme, mime-media-type, text-with-language, and name-with-language. 
This message would be returned like 'bad-request' and indicate that no
processing was going to take place, but it would give a user a bit more
information about why theclient isn't behaving.  In the case of
'client-error-request-value-too-long', the user might realize that if he
sent in a short text field, things would work.


Bob Herriot


At 02:35 PM 5/11/98 , Carl Kugler wrote:
>I agree that it would be simpler to return 'client-error-bad-request' whenever
>an attribute fails the length test.  Why was
>'client-error-request-uri-too-long' introduced in the first place?  If there is
>strong consensus that we don't need it, can we change the document?
>
> -Carl
>
>
>C
>
--=====================_12281369==_.ALT-- From ipp-owner@pwg.org Tue May 12 15:50:44 1998 Delivery-Date: Tue, 12 May 1998 15:50:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23480 for ; Tue, 12 May 1998 15:50:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09304 for ; Tue, 12 May 1998 15:53:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA19345 for ; Tue, 12 May 1998 15:50:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 12 May 1998 15:46:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18816 for ipp-outgoing; Tue, 12 May 1998 15:41:44 -0400 (EDT) From: Carl Kugler To: Subject: IPP> MOD & PRO - Questions about "printer-uri" or "job-uri" Message-ID: <5030100020398311000002L012*@MHS> Date: Tue, 12 May 1998 15:39:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23480 The following statement from the PRO doc. seems to imply that the same target printer-uri is placed in the "printer-uri" operation attribute and the HTTP request-URI: * "printer-uri": When the target is a printer and the transport is HTTP or HTTP (for TLS), the target printer-uri defined in each operation in the IPP model document SHALL be an operation attribute called "printer-uri" and it SHALL also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. This Must these URIs be identical? HTTP/1.1 clients generate an abs_path (a relativeURI) as the Request-URI, which identifies a resource on a server, but does not include scheme, host or port. Are "printer-uri", "printer-uri-supported", and "job-uri" supposed to be absoluteURIs or abs_paths (see ftp://ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt for definitions) ? If "printer-uri-supported" is to specify host, scheme, or port, absoluteURIs are required. If "printer-uri" or "job-uri" are absoluteURIs, then the HTTP request-URI and the target Operation Attribute can't be identical. Which raises some questions: - Suppose the "printer-uri" (or "job-uri") and request-URI are not identical? Should the Printer a) Return an error status? Warning? b) Allow one to take precedence over the other? - Suppose even the "abs_path" part of the URIs differs? - Suppose they're not identical, but effectively point to the same resource because of: * An empty abs_path is equivalent to an abs_path of "/". * Characters other than those in the "reserved" and "unsafe" sets are equivalent to their ""%" HEX HEX" encoding. * As a result of an HTTP redirect? - Suppose one copy of the URI has been supplied, but not the other. Should the Printer a) Reject the request? b) Return an error status? Warning? c) Perform the operation? My preferences would be: - Make target URI Operation Attribute OPTIONAL when the transport is HTTP or HTTPS. - request-URI takes precedence over target Operational Attribute when the transport is HTTP or HTTPS. - "printer-uri" and "job-uri" have abs_path form. - "printer-uri-supported", "job-printer-uri", etc. have absoluteURI form Confused implementor in Boulder, Carl Kugler From jmp-owner@pwg.org Wed May 13 17:45:28 1998 Delivery-Date: Wed, 13 May 1998 17:45:28 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA24426 for ; Wed, 13 May 1998 17:45:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14853 for ; Wed, 13 May 1998 17:47:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02036 for ; Wed, 13 May 1998 17:45:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 13 May 1998 17:42:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01689 for jmp-outgoing; Wed, 13 May 1998 17:40:57 -0400 (EDT) Message-Id: <3.0.1.32.19980513142345.01196910@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) X-Priority: 2 (High) Date: Wed, 13 May 1998 14:23:45 PDT To: ipp@pwg.org From: Tom Hastings Subject: JMP> MOD & PRO - IPP Event Notification, V0.05, posted Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: jmp-owner@pwg.org Scott, Harry, and I have finished our action item to incorporate the agreements from the Portland meeting into the IPP notification proposal. Its version 0.05. Thanks go to Ron Bergman and Devon Taylor (of Novell) for additional review. I'm posting it for discussion at the upcoming IPP meeting, in Washington, 5/20 - 5/21: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.pdf Use the last one for making comments as it has line numbers. Please take the time to read the entire specification. We've seen it enough by now. Its grown to 50 pages, with the spec for the 'collection' attribute syntax included as an appendix as we agreed on the telecon. Is it ready to be made a first Internet-Draft? Please send any comments before the meeting (and bring your copy to the meeting). It also has the PWG Job Monitoring MIB (JMP) Notification Content (and 6 IPP Job object Description IPP attributes for event monitoring of job progress to align with the Job MIB). Here is the abstract and the summary from the paper: Event notifications for the IPP print protocol [and JMP] Version 0.05 The appendix has the full specification for the 'collection' attribute syntax, as agreed on our 5/6/98 telecon. [Items in square brackets relate to the PWG Standard Job Monitoring MIB [jmp-mib] trapping and will be removed when this document is made into an IPP Internet-Draft.] Status of this Memo This document is a PWG Working Draft. It is intended to become a first Internet-Draft when there is rough consensus that it is ready and then to proceed on the IETF standards track to be used with IPP/1.0. It is being developed under the charter for IPP/1.0 and meets the requirements in [req]. Abstract In IPP/1.0, the user can determine what is happening to submitted jobs by using the Get--Attributes and Get-Jobs operations to poll for results. This document describes an OPTIONAL extension to the IPP/1.0 Model document for subscribing for event notifications using IPP, but which are delivered over some other protocol, either by the IPP Printer object or by any notification service that the IPP Printer object implementation may employ. See [req] for the notification requirements. Two methods are provided for subscription for notification events: (1) as part of the job submission and (2) as a separate Subscribe-For-Event-Notifications operation. Both methods allow the requester to specify (1) about which event(s) to be notified, (2) which notification-recipient(s) are to receive the notification, (3) what content type is to be sent in the notification, and (4) which notification transport method is to be used. Both methods allow the requester to subscribe for job event groups, such as 'job-completion', and/or printer events, such as 'printer-errors'. The event notification subscription mechanism uses a new attribute syntax called a 'collection'. A 'collection' value is a set of attributes. See the Appendix of this document for the complete specification of the 'collection' attribute syntax. 1.1 Summary of the proposal for IPP Event Notification This paper proposes the following: 1. One OPTIONAL "job-notify" Operation attribute for use with the Print-Job, Print-URI, and Create-Job operation. The "job-notify" Operation attribute has an attribute syntax of '1setOf collection' (see Appendix) so that the client can request different events for different notification recipients for the same job. Each collection value SHALL contain the "notify-recipients" and MAY contain any of the following remaining member attributes with the indicated syntax and support by the IPP object if it supports the "job-notify" Operation attribute at all: Member attribute name syntax in request support ------------------- ---- ---------- ------ "notify-event-groups" 1setOf type2 keyword MAY mandatory "notify-recipients" 1setOf uri SHALL mandatory "notify-content-type" mimeMediaType MAY mandatory "notify-charset" charset MAY mandatory "notify-natural-language" naturalLanguage MAY optional "notify-additional-attributes" 1setOf keyword MAY optional 2. Two new OPTIONAL Subscribe-For-Event-Notifications and Unsubscribe-For-Event-Notifications operations on the Printer object. These operations are intended for operator/administrators and servers for long term subscription for Printer object events that are independent of job submission. The servers may be involved with (1) job submission to IPP Printer objects and/or (2) collecting accounting data using the event notification mechanism. An IPP Printer SHALL support both of these operations, if it supports either one. If an IPP Printer supports these operations, it SHALL also support the "job-notify" attribute in the create operations. 3. One "job-notify" Job object Description attribute which is populated with the collection value(s) supplied by the "job-notify" Operation attribute in a create operation. 4. Six Job object Description attributes for monitoring job progress at the sheet completed and collated document copy level to align with the PWG Job Monitoring MIB. 5. One new "printer-notify" Printer object Description attribute which is populated with the collection value supplied by the "printer-notify" Operation attribute in the Subscribe-For-Event-Notifications operation. Both attribute use the same collection as the "job-notify" Operation attribute. The "printer-notify" Printer Description attribute also has an additional "notify-subscription-id" member attribute which is an integer id for the subscription for use with the Unsubscribe-For-Event-Notification operation. 6. Six "xxx-supported" Printer object Description attributes that correspond to the six member attributes in the collection values of the "job-notify" and "printer-notify" Operation attributes. Tom Hastings From ipp-owner@pwg.org Wed May 13 17:51:13 1998 Delivery-Date: Wed, 13 May 1998 17:51:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA24506 for ; Wed, 13 May 1998 17:51:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14882 for ; Wed, 13 May 1998 17:53:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02424 for ; Wed, 13 May 1998 17:50:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 13 May 1998 17:42:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01682 for ipp-outgoing; Wed, 13 May 1998 17:40:53 -0400 (EDT) Message-Id: <3.0.1.32.19980513142345.01196910@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) X-Priority: 2 (High) Date: Wed, 13 May 1998 14:23:45 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD & PRO - IPP Event Notification, V0.05, posted Cc: jmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Scott, Harry, and I have finished our action item to incorporate the agreements from the Portland meeting into the IPP notification proposal. Its version 0.05. Thanks go to Ron Bergman and Devon Taylor (of Novell) for additional review. I'm posting it for discussion at the upcoming IPP meeting, in Washington, 5/20 - 5/21: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.pdf Use the last one for making comments as it has line numbers. Please take the time to read the entire specification. We've seen it enough by now. Its grown to 50 pages, with the spec for the 'collection' attribute syntax included as an appendix as we agreed on the telecon. Is it ready to be made a first Internet-Draft? Please send any comments before the meeting (and bring your copy to the meeting). It also has the PWG Job Monitoring MIB (JMP) Notification Content (and 6 IPP Job object Description IPP attributes for event monitoring of job progress to align with the Job MIB). Here is the abstract and the summary from the paper: Event notifications for the IPP print protocol [and JMP] Version 0.05 The appendix has the full specification for the 'collection' attribute syntax, as agreed on our 5/6/98 telecon. [Items in square brackets relate to the PWG Standard Job Monitoring MIB [jmp-mib] trapping and will be removed when this document is made into an IPP Internet-Draft.] Status of this Memo This document is a PWG Working Draft. It is intended to become a first Internet-Draft when there is rough consensus that it is ready and then to proceed on the IETF standards track to be used with IPP/1.0. It is being developed under the charter for IPP/1.0 and meets the requirements in [req]. Abstract In IPP/1.0, the user can determine what is happening to submitted jobs by using the Get--Attributes and Get-Jobs operations to poll for results. This document describes an OPTIONAL extension to the IPP/1.0 Model document for subscribing for event notifications using IPP, but which are delivered over some other protocol, either by the IPP Printer object or by any notification service that the IPP Printer object implementation may employ. See [req] for the notification requirements. Two methods are provided for subscription for notification events: (1) as part of the job submission and (2) as a separate Subscribe-For-Event-Notifications operation. Both methods allow the requester to specify (1) about which event(s) to be notified, (2) which notification-recipient(s) are to receive the notification, (3) what content type is to be sent in the notification, and (4) which notification transport method is to be used. Both methods allow the requester to subscribe for job event groups, such as 'job-completion', and/or printer events, such as 'printer-errors'. The event notification subscription mechanism uses a new attribute syntax called a 'collection'. A 'collection' value is a set of attributes. See the Appendix of this document for the complete specification of the 'collection' attribute syntax. 1.1 Summary of the proposal for IPP Event Notification This paper proposes the following: 1. One OPTIONAL "job-notify" Operation attribute for use with the Print-Job, Print-URI, and Create-Job operation. The "job-notify" Operation attribute has an attribute syntax of '1setOf collection' (see Appendix) so that the client can request different events for different notification recipients for the same job. Each collection value SHALL contain the "notify-recipients" and MAY contain any of the following remaining member attributes with the indicated syntax and support by the IPP object if it supports the "job-notify" Operation attribute at all: Member attribute name syntax in request support ------------------- ---- ---------- ------ "notify-event-groups" 1setOf type2 keyword MAY mandatory "notify-recipients" 1setOf uri SHALL mandatory "notify-content-type" mimeMediaType MAY mandatory "notify-charset" charset MAY mandatory "notify-natural-language" naturalLanguage MAY optional "notify-additional-attributes" 1setOf keyword MAY optional 2. Two new OPTIONAL Subscribe-For-Event-Notifications and Unsubscribe-For-Event-Notifications operations on the Printer object. These operations are intended for operator/administrators and servers for long term subscription for Printer object events that are independent of job submission. The servers may be involved with (1) job submission to IPP Printer objects and/or (2) collecting accounting data using the event notification mechanism. An IPP Printer SHALL support both of these operations, if it supports either one. If an IPP Printer supports these operations, it SHALL also support the "job-notify" attribute in the create operations. 3. One "job-notify" Job object Description attribute which is populated with the collection value(s) supplied by the "job-notify" Operation attribute in a create operation. 4. Six Job object Description attributes for monitoring job progress at the sheet completed and collated document copy level to align with the PWG Job Monitoring MIB. 5. One new "printer-notify" Printer object Description attribute which is populated with the collection value supplied by the "printer-notify" Operation attribute in the Subscribe-For-Event-Notifications operation. Both attribute use the same collection as the "job-notify" Operation attribute. The "printer-notify" Printer Description attribute also has an additional "notify-subscription-id" member attribute which is an integer id for the subscription for use with the Unsubscribe-For-Event-Notification operation. 6. Six "xxx-supported" Printer object Description attributes that correspond to the six member attributes in the collection values of the "job-notify" and "printer-notify" Operation attributes. Tom Hastings From ipp-owner@pwg.org Thu May 14 12:35:18 1998 Delivery-Date: Thu, 14 May 1998 12:35:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA15666 for ; Thu, 14 May 1998 12:35:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA18271 for ; Thu, 14 May 1998 12:37:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16095 for ; Thu, 14 May 1998 12:35:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 14 May 1998 12:27:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15372 for ipp-outgoing; Thu, 14 May 1998 12:22:21 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Notifications paper Message-ID: <5030100020498711000002L012*@MHS> Date: Thu, 14 May 1998 12:21:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15666 I have started to review the latest notification paper from Tom et al. This looks to be a fine example of design by committee, i.e. put everything in but the kitchen sink, so as to please everybody. Sorry, but I think it's rubbish -- if it takes 50 pages to describe it is way too complicated. If I can wade through the gory details, I'll make more substantive comments later. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Thu May 14 12:46:21 1998 Delivery-Date: Thu, 14 May 1998 12:46:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA15991 for ; Thu, 14 May 1998 12:46:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA18328 for ; Thu, 14 May 1998 12:48:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16697 for ; Thu, 14 May 1998 12:46:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 14 May 1998 12:42:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16165 for ipp-outgoing; Thu, 14 May 1998 12:39:18 -0400 (EDT) Message-ID: <355B1E26.5CD62BFE@underscore.com> Date: Thu, 14 May 1998 12:39:02 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Roger K Debry CC: ipp@pwg.org Subject: Re: IPP> Notifications paper References: <5030100020498711000002L012*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org What a refreshing point of view. I completely agree, but was afraid to say it, since all too many times I've been beaten down by suggesting a leaner, simpler approach. All too many times we approach a concept, only to find an 800 page "tome" in our mailboxes before things are really fleshed out (such as reasonable scenarios describing key application environments). I think this is why many (if not most) people in the PWG are actually in the dark about many things, since very few people have the time to read such horrific detail at the early stages of an effort. I wish we could find a way to change that. ...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 -- ---------------------------------------------------------------------- Roger K Debry wrote: > > I have started to review the latest notification paper from Tom et al. > This looks to be a fine example of design by committee, i.e. put > everything in but the kitchen sink, so as to please everybody. Sorry, > but I think it's rubbish -- if it takes 50 pages to describe it is way too > complicated. If I can wade through the gory details, I'll make more substantive > comments later. > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 From ipp-owner@pwg.org Thu May 14 19:07:52 1998 Delivery-Date: Thu, 14 May 1998 19:07:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA22392 for ; Thu, 14 May 1998 19:07:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20262 for ; Thu, 14 May 1998 19:10:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20640 for ; Thu, 14 May 1998 19:07:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 14 May 1998 19:02:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20072 for ipp-outgoing; Thu, 14 May 1998 19:01:09 -0400 (EDT) From: don@lexmark.com Message-Id: <199805142300.AA16400@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Ipp@pwg.org, rdebry@us.ibm.com Cc: hastings@cp10.es.xerox.com Date: Thu, 14 May 1998 18:57:46 -0400 Subject: IPP> Notifications paper Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org I agree with Roger on this one. I refuse to waste my time reading this stuff. Perhaps we have not scoped the effort correctly?!?! I don't want to belittle the efforts that have gone into this but I think those efforts were clearly pointed in the wrong direction. We have clearly strayed from the IETF's design strategy to something else. There are very few full IETF standards this long. HTTP/1.0 is only 60 pages. (I'll admit, HTTP/1.1 is a design-by-committee document from my perspective.) I still think IPP is GROSSLY over-designed. Fortunately we mandated only a small subset as a requirement. I predict that popular usage will be a minor subset of the total IPP definition. The rest will only be used by a very, very small number of the total printing devices that ship. Back to notification..... For example, I cannot imagine any reasonable scenario on notification that would require any use of printer resolution in notification. I notice in the document in the section on collections that printer resolutions are used. Even as an example, this is clearly not appropriate. If we can't do notifications in 10-20 pages (max) then it is clearly too heavy. As a user, all I really want to know is: 1) The job has printed page n 2) The job ended and the return code/error message was x 3) The output was printed on printer z As an administrator, etc., all I really want to know is: 1) The printer is down 2) The printer needs supplies now or soon I want to be able to choose between e-mail and a more immediate notification. Beyond this, the user and administrator need to use the printer management utilities and tools for that device to determine what to do next. We can always contrive scenarios where Joe wants to know about Bob's job but that is well past 6 sigma. Let's toss all that garbage. We're not doing accounting here, let's keep it simple. TIPSI does more than we need (it includes much of the MIB traps concepts) except e-mail and all the alerts sections total maybe 25 pages. It seems to work, my customers are happy. Everything else is superfluous and overkill. For once can't we design something simple and not aim it at the DOCUTECH environment. If Xerox needs something much heavier then you should go do it for your products. I'm not putting all this junk in my printers. Don ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> Notifications paper I have started to review the latest notification paper from Tom et al. This looks to be a fine example of design by committee, i.e. put everything in but the kitchen sink, so as to please everybody. Sorry, but I think it's rubbish -- if it takes 50 pages to describe it is way too complicated. If I can wade through the gory details, I'll make more substantive comments later. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From adm Fri May 15 10:16:46 1998 Delivery-Date: Fri, 15 May 1998 10:26:54 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA09331 for ietf-123-outbound.10@ietf.org; Fri, 15 May 1998 10:15:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA08337; Fri, 15 May 1998 09:50:25 -0400 (EDT) Message-Id: <199805151350.JAA08337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippcp@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-06.txt Date: Fri, 15 May 1998 09:50:25 -0400 Sender: cclark@CNRI.RESTON.VA.US --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) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-06.txt Pages : 8 Date : 14-May-98 This document describes a protocol intended to provide lossless compression for Internet Protocol 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-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippcp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980514134302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980514134302.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri May 15 11:36:57 1998 Delivery-Date: Fri, 15 May 1998 11:36:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA11755 for ; Fri, 15 May 1998 11:36:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22692 for ; Fri, 15 May 1998 11:39:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA05025 for ; Fri, 15 May 1998 11:36:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 15 May 1998 11:27:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04442 for ipp-outgoing; Fri, 15 May 1998 11:26:28 -0400 (EDT) Message-ID: <355C5E9F.20D64DA9@underscore.com> Date: Fri, 15 May 1998 11:26:23 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ipp@pwg.org Subject: Re: IPP> Notifications paper References: <199805142300.AA16400@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Don has done a great job of hitting the nail on the head with respect to the length and detail of the latest Notifications proposal. I respectfully submit that the Washington DC meeting spend the time NOT on reviewing the proposal (as submitted), but instead back off to the point of discussing reasonable *scenarios* for requiring notifications. All too many times we write up "requirements" documents that virtually hide the underlying scenarios with respect to firm, existing application environments. (By "application" I mean "how the concept is to be used", and not a particular piece of software or software category.) I'd like to discuss the usage and requirements for notifications at this kind of level: "I need a car for commuting to work. What kind of car would be appropriate?" Rather than discussing requirements like this: "The vehicle needs four tires, each rated at 40,000 miles/year." Skip the details. Let's talk about real-world, pragmatic environments and how notifications need to work in those environments. And during those discussions, if someone utters words to the effect of: "Perhaps someone someday somewhere needs to be able to..." then that person gets the AXE. (Literally... ;-) ...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 -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > I agree with Roger on this one. I refuse to waste my time reading this > stuff. > Perhaps we have not scoped the effort correctly?!?! I don't want to > belittle > the efforts that have gone into this but I think those efforts were clearly > pointed in the wrong direction. > > We have clearly strayed from the IETF's design strategy to something else. > There are very few full IETF standards this long. HTTP/1.0 is only 60 > pages. (I'll admit, HTTP/1.1 is a design-by-committee document from > my perspective.) I still think IPP is GROSSLY over-designed. Fortunately > we mandated only a small subset as a requirement. I predict that popular > usage will be a minor subset of the total IPP definition. The rest will > only > be used by a very, very small number of the total printing devices that > ship. > > Back to notification..... > > For example, I cannot imagine any reasonable scenario on notification that > would > require any use of printer resolution in notification. I notice in the > document in the > section on collections that printer resolutions are used. Even as an > example, > this is clearly not appropriate. If we can't do notifications in 10-20 > pages (max) > then it is clearly too heavy. > > As a user, all I really want to know is: > > 1) The job has printed page n > 2) The job ended and the return code/error message was x > 3) The output was printed on printer z > > As an administrator, etc., all I really want to know is: > > 1) The printer is down > 2) The printer needs supplies now or soon > > I want to be able to choose between e-mail and a more immediate > notification. Beyond > this, the user and administrator need to use the printer management > utilities and tools > for that device to determine what to do next. We can always contrive > scenarios where > Joe wants to know about Bob's job but that is well past 6 sigma. Let's > toss all that > garbage. > > We're not doing accounting here, let's keep it simple. TIPSI does more > than we need (it includes much of the MIB traps concepts) except e-mail and > all > the alerts sections total maybe 25 pages. It seems to work, my customers > are happy. > > Everything else is superfluous and overkill. For once can't we design > something simple > and not aim it at the DOCUTECH environment. If Xerox needs something much > heavier > then you should go do it for your products. I'm not putting all this junk > in my printers. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > To: ipp%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright) > bcc: Don Wright > Subject: IPP> Notifications paper > > I have started to review the latest notification paper from Tom et al. > This looks to be a fine example of design by committee, i.e. put > everything in but the kitchen sink, so as to please everybody. Sorry, > but I think it's rubbish -- if it takes 50 pages to describe it is way too > complicated. If I can wade through the gory details, I'll make more > substantive > comments later. > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 From ipp-owner@pwg.org Fri May 15 11:41:59 1998 Delivery-Date: Fri, 15 May 1998 11:41:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA11865 for ; Fri, 15 May 1998 11:41:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22719 for ; Fri, 15 May 1998 11:44:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA05624 for ; Fri, 15 May 1998 11:41:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 15 May 1998 11:37:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04818 for ipp-outgoing; Fri, 15 May 1998 11:32:53 -0400 (EDT) From: Harry Lewis To: Cc: , , , Roger K Debry Subject: Re: IPP> Notifications paper Message-ID: <5030300020954604000002L042*@MHS> Date: Fri, 15 May 1998 11:40:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11865 I'm not defending the length or complexity of the Notifications document, although I am co-author. My contributions are mainly in defining a limited set of event types, some optimized, guaranteed content, and attempting to stem the tide of desire for COMPLETE flexibility... wherein any recipient could request any content for any type of event. I am a bit surprised, however, at the focus of this argument ON the notifications document. Maybe it's just like a dam breaking or something but, I'll tell you, IPP certainly is no joy to try to read and understand! I think we witnessed the numbing effects of deep and detailed cryptics best when the PWG was simultaneously developing the Job MIB and IPP. Anyone who was not right on top of either one had a very difficult time crossing over. I think Tom and Scott (mainly) did an excellent job preserving compatibility of attributes between the two, but I would wager most people don't really know this or understand it's value. Any detailed technical specification can be imposing when you crack the cover. (TIPSI is a bit daunting to the uninitiated). The other side of the coin is a sparse skeleton... yes... most of the IETF documents are un-illustrative... then again... see how well some of them are understood, like LPR or DHCP... oh...and cross platform, cross product e-mail really works fine, too. I support this plea for improved documentation. I agree that we tend to jump in too deep too fast, before many people have even grasped the concepts. My pet peeve is all the mandated SHOULDs and SHALLs that only bog down the cognitive process. And all these ipp-dash-linked-names... one at a time they're OK, but try to read a paragraph! I'd rather someone speak to me in HEX! In Virginia, I will be presenting our first attempt to establish a bona-fide PWG standards development process. In our process, we are recommending distinct periods for brainstorming, white papers, proposals, drafts, standards etc. with established exit criteria. I hope that, as a PWG - unfettered by the rules of another standards committee - we will discipline ourselves to make sure we have appropriate documentation. The process is open to your input and approval... so please give some thought and contribute your ideas! One thing I might suggest is that, whenever we find ourselves developing a specification where the 80/20 rule favors OPTIONAL elements, such a project should be accompanied (I know I said should but I guess I really mean shall ;-) by a separate spec which distills and represents only the MANDATORY parts... and THIS spec SHALL be called the STANDARD! Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri May 15 12:06:26 1998 Delivery-Date: Fri, 15 May 1998 12:06:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12302 for ; Fri, 15 May 1998 12:06:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA22830 for ; Fri, 15 May 1998 12:08:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06646 for ; Fri, 15 May 1998 12:06:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 15 May 1998 12:02:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05735 for ipp-outgoing; Fri, 15 May 1998 11:46:51 -0400 (EDT) Message-ID: <355C635C.35E3833C@underscore.com> Date: Fri, 15 May 1998 11:46:36 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org, don@lexmark.com, hastings@cp10.es.xerox.com, Roger K Debry Subject: Re: IPP> Notifications paper References: <5030300020954604000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Harry, You speak wisdom here, and I tend to agree with you entirely. One statement in the first paragraph, though, deserves a brief follow-up: "My contributions are mainly in ... attempting to stem the tide of desire for COMPLETE flexibility..." Sorry, but characterizing this desire as "a tide" is outright wrong. There is NO tide here, just one person's (continual) desire to throw in the kitchen sink at every turn of the road and at every opportunity. This kind of approach must be stopped NOW, or the PWG will continue to sink into a sloth-like mode in which specs take, say, 8 YEARS to complete. And by then the market will have changed so much as to make the spec useless. We should be learning more from DPA's mistakes, rather than from its "successes". ...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 -- ---------------------------------------------------------------------- Harry Lewis wrote: > > I'm not defending the length or complexity of the Notifications document, > although I am co-author. My contributions are mainly in defining a limited set > of event types, some optimized, guaranteed content, and attempting to stem the > tide of desire for COMPLETE flexibility... wherein any recipient could request > any content for any type of event. > > I am a bit surprised, however, at the focus of this argument ON the > notifications document. Maybe it's just like a dam breaking or something but, > I'll tell you, IPP certainly is no joy to try to read and understand! I think > we witnessed the numbing effects of deep and detailed cryptics best when the > PWG was simultaneously developing the Job MIB and IPP. Anyone who was not right > on top of either one had a very difficult time crossing over. I think Tom and > Scott (mainly) did an excellent job preserving compatibility of attributes > between the two, but I would wager most people don't really know this or > understand it's value. > > Any detailed technical specification can be imposing when you crack the cover. > (TIPSI is a bit daunting to the uninitiated). The other side of the coin is a > sparse skeleton... yes... most of the IETF documents are un-illustrative... > then again... see how well some of them are understood, like LPR or DHCP... > oh...and cross platform, cross product e-mail really works fine, too. > > I support this plea for improved documentation. I agree that we tend to jump in > too deep too fast, before many people have even grasped the concepts. My pet > peeve is all the mandated SHOULDs and SHALLs that only bog down the cognitive > process. And all these ipp-dash-linked-names... one at a time they're OK, but > try to read a paragraph! I'd rather someone speak to me in HEX! > > In Virginia, I will be presenting our first attempt to establish a bona-fide > PWG standards development process. In our process, we are recommending distinct > periods for brainstorming, white papers, proposals, drafts, standards etc. with > established exit criteria. > I hope that, as a PWG - unfettered by the rules of another standards committee > - we will discipline ourselves to make sure we have appropriate documentation. > The process is open to your input and approval... so please give some thought > and contribute your ideas! > > One thing I might suggest is that, whenever we find ourselves developing a > specification where the 80/20 rule favors OPTIONAL elements, such a project > should be accompanied (I know I said should but I guess I really mean shall ;-) > by a separate spec which distills and represents only the MANDATORY parts... > and THIS spec SHALL be called the STANDARD! > > Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Fri May 15 17:26:53 1998 Delivery-Date: Fri, 15 May 1998 17:26:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA17086 for ; Fri, 15 May 1998 17:26:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA24390 for ; Fri, 15 May 1998 17:29:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09617 for ; Fri, 15 May 1998 17:26:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 15 May 1998 17:22:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08955 for ipp-outgoing; Fri, 15 May 1998 17:18:00 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 15 May 1998 15:17:25 -0600 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> NOT - Smaller Notification Documents Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17086 Since there has been some fairly negative reaction to such a long, detailed, all rolled up proposal for IPP Event Notifications, I have posted some very short, overview descriptions of the concept that can be reviewed in a matter of minutes (not hours or day). I also removed all features that were specified as "optional to implement" and raised them as issues of the type "Do we even want to do specify this feature independent of whether it is optional to implement". I took the files that Tom posted and simplified and shortened the basic proposal into an 8 page document called IPP Event Notification (Very Short) and posted it as: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.pdf I separated out the proposal for new Subscribe/Unsubscribe operations into a separate 4 page document called "Printer Events for IPP" and posted it as: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.pdf I hope that these higher level, less detail oriented overviews are more palatable to a wide audience and help in the communication process. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Mon May 18 06:12:25 1998 Delivery-Date: Mon, 18 May 1998 06:12:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA20279 for ; Mon, 18 May 1998 06:12:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA02238 for ; Mon, 18 May 1998 06:14:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id GAA17946 for ; Mon, 18 May 1998 06:12:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 18 May 1998 06:03:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA17404 for ipp-outgoing; Mon, 18 May 1998 06:02:06 -0400 (EDT) From: Ravi S Date: Mon, 18 May 1998 15:31:46 +0530 Message-Id: <199805181001.PAA03138@kepler.india.ti.com> To: ipp@pwg.org Subject: IPP> 1284.3 and 1284.4 Sender: owner-ipp@pwg.org How do I get the specs for 1284.3 and 1284.4? Is a draft for these available on the Web? Best Regards, Ravi +--------------------------------------------------------------------+ | Ravi Subramanian | Email: ravi@india.ti.com | | Texas Instruments Inc | +--------------------------------------------------------------------+ ----- Begin Included Message ----- >From ipp-owner@pwg.org Thu May 7 05:21:37 1998 From: Harry Lewis To: Cc: , Subject: Re: SDP, IPP>PRO Proposal for TIPSI-like protocol Date: Wed, 6 May 1998 19:52:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-ipp@pwg.org One thing it would buy is a simpler (than 1284.4) way to flow IPP over = bidi parallel - no? Isn't this basically what Lexmark has found? I'm confuse= d why TIPSI has a packet structure, Lexmark was shipping it on parallel and t= hen .4 was invented - maybe some background could help (I always thought it wa= s to flow SNMP over parallel ;-). If it's true that the .1 packet is only st= ill there for legacy I might buy Bob's argument. But I suspect .4 is a much= more complex implementation. Bob, doesn't your proposal say we would have to invent a transport (if = not already there) to "IPize" every physical layer (ex. serial)? Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 05/06/98 05:32:34 PM Please respond to owner-ipp@pwg.org To: sdp@pwg.org cc: ipp@pwg.org Subject: SDP, IPP>PRO Proposal for TIPSI-like protocol I just finished scanning IEEE 1284.3 and IEEE1284.4. The most interest= ing part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4. T= his chapter describes a "Berkeley Sockets-compatible interface for clients = and servers to access the services provided by 1284.4". So if I understand the intent of 1284.4, it is to provide a layer that supports sockets over parallel connections. All we need to do in IPP is= reference sockets for TCP/IP and 1284.4 and we don't have to worry abou= t the issues at that layer. So, I conclude that we don't need to packetize IPP or do much of what i= s proposed in Roger and Harry's paper. Instead, we can send IPP directly = on sockets layered on top of TCP/IP or 1284.4. There are a few easy-to-so= lve dangling issues, such as chunking for document data and intermediate acknowledge= ment when attributes are verified for PrintJob. But otherwise IPP stays as i= s. If you disagree with my conclusions, I would like to know what the TIPSI-like packetizing layer provides that sockets don't also provide? Bob Herriot = ----- End Included Message ----- From cclark Mon May 18 15:21:25 1998 Delivery-Date: Mon, 18 May 1998 15:28:00 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA28912 for ietf-outbound.10@ietf.org; Mon, 18 May 1998 15:20:03 -0400 (EDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28844 for ; Mon, 18 May 1998 15:17:10 -0400 (EDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id OAA07430; Mon, 18 May 1998 14:11:38 -0500 (CDT) Received: from dal-tx10-57.ix.netcom.com(207.94.124.121) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma006946; Mon May 18 14:08:24 1998 Message-ID: <35602316.75B9E2F2@ix.netcom.com> Date: Mon, 18 May 1998 13:01:28 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: David Elliott CC: Salvador Vidal , Jay Fenello , DOMAIN-POLICY@LISTS.INTERNIC.NET, "Antitrust DEPT. DOJ Justice" , Arin Council , ARIN list , "Clough, Christopher" , DNS comment mailing list , Don Heath , GIG-Vote , "Global TLD's discuss" , IETF ORG , Ira Magaziner , Jon Postel Subject: Re: What is this dribble? + Whining References: <001701bd828e$e1dbfea0$792b63c3@shipping> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David and all, David Elliott wrote: > Surely you mean DRIVEL?? Dribble = a small amount of leaking liquid, for > example from the corner of your mouth, or other orifice........ Please use > your spell checker before posting messages. the rest of us get sick and > tired of reading this nonsense. No I do mean DRIBBLE! Because that is exactly what it is by your definition (See above your comment), that Salvador posted. BTW, my spell checker works fine. Does yours, by any chance. Many of us tire of your continued whining. > > > -----Original Message----- > From: Jeff Williams > To: Salvador Vidal > Cc: Jay Fenello ; DOMAIN-POLICY@LISTS.INTERNIC.NET > ; Antitrust DEPT. DOJ Justice > ; Arin Council ; ARIN list > ; Clough, Christopher ; DNS comment > mailing list ; Don Heath ; GIG-Vote > ; Global TLD's discuss ; IETF > ORG ; Ira Magaziner ; Jon Postel > > Date: 18 May 1998 15:15 > Subject: What is this dribble? > > >Salvador and all, > > > >Salvador Vidal wrote: > > > >> Hello all, > >> > >> At 15:29 14/05/98 +0100, Jeff Williams wrote: > >> >Jay and all, > >> > > >> >Jay Fenello wrote: > >> > > >> >> At 01:53 PM 5/14/98 -0400, Perry E. Metzger wrote: > >> >> > > >> >> >Jay Fenello writes: > >> >> >> Based on your tone, it looks like > >> >> >> I have hit a nerve ;-) > >> >> > > >> >> >Who's hit a nerve for whom, Mr. Fenello? Nervous smiley there, > >> >> >perhaps? > >> >> > > >> >> >I've got logs, Mr. Fenello, of your machines being used to launch an > >> >> >attack on mine. Bla bla bla ... > >> > >> Still playing? > > > > Playing what Sal? SOunds like ole PErry is doing some playing, yet > again. > >But than again we are all used to this from Perry Metzger. It is an all to > >familiar pattern of his. > > > >> > >> > >> Please begin discussion about general interest: Internet users rights, > >> childrens protection ... > >> > >> If you change on secret, as usual, where is the change? > > > > God knows what this comment refers to! > > > >> > >> > >> Best Regards, > >> Salvador Vidal > > > > regards, > > > Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com From ipp-owner@pwg.org Mon May 18 18:03:41 1998 Delivery-Date: Mon, 18 May 1998 18:03:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA00776 for ; Mon, 18 May 1998 18:03:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05122 for ; Mon, 18 May 1998 18:06:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21147 for ; Mon, 18 May 1998 18:03:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 18 May 1998 17:58:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20593 for ipp-outgoing; Mon, 18 May 1998 17:57:57 -0400 (EDT) Message-Id: <3.0.1.32.19980518145344.01334190@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 18 May 1998 14:53:44 PDT To: don@lexmark.com From: Tom Hastings Subject: Re: IPP> Notifications paper Cc: Ipp@pwg.org, rdebry@us.ibm.com In-Reply-To: <199805142300.AA16400@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 15:57 05/14/1998 PDT, don@lexmark.com wrote: > >I agree with Roger on this one. I refuse to waste my time reading this >stuff. >Perhaps we have not scoped the effort correctly?!?! I don't want to >belittle >the efforts that have gone into this but I think those efforts were clearly >pointed in the wrong direction. > >We have clearly strayed from the IETF's design strategy to something else. >There are very few full IETF standards this long. HTTP/1.0 is only 60 >pages. (I'll admit, HTTP/1.1 is a design-by-committee document from >my perspective.) I still think IPP is GROSSLY over-designed. Fortunately >we mandated only a small subset as a requirement. I predict that popular >usage will be a minor subset of the total IPP definition. The rest will >only >be used by a very, very small number of the total printing devices that >ship. > >Back to notification..... > >For example, I cannot imagine any reasonable scenario on notification that >would >require any use of printer resolution in notification. I notice in the >document in the >section on collections that printer resolutions are used. Even as an >example, >this is clearly not appropriate. If we can't do notifications in 10-20 >pages (max) >then it is clearly too heavy. You are correct that printer resolutions have no business in notification. The section you cited on printer resolution is in the 9-page Appendix. That Appendix is about collections, not notification. At the IPP telecon the participants wanted the collection attribute syntax added as an Appendix, rather than a separate document. On the other hand, the IETF often breaks down their standards into separate documents. You have to retrieve 5 to 10 documents sometimes to understand one interface. But we could put the collection attribute syntax into a separate document, like the IETF. Should we? Also the authors wanted some examples (often not included in IETF documents), so page 41-44 are two examples, totalling 4 pages. Also the authors wanted to add the Job Monitoring MIB attributes that are used for job progress monitoring. This added 6 pages (28-33). There is a one page summary as well. So if you remove the 9-page Appendix, the 4-page example, and the 6 pages of Job Monitoring MIB attribute additions, and the one page summary, we are down to 36 pages. Scott has done some good work in further simplifying the proposal and tightning up the text. > >As a user, all I really want to know is: > >1) The job has printed page n >2) The job ended and the return code/error message was x >3) The output was printed on printer z > >As an administrator, etc., all I really want to know is: > >1) The printer is down >2) The printer needs supplies now or soon > >I want to be able to choose between e-mail and a more immediate >notification. Beyond >this, the user and administrator need to use the printer management >utilities and tools >for that device to determine what to do next. We can always contrive >scenarios where >Joe wants to know about Bob's job but that is well past 6 sigma. Let's >toss all that >garbage. That "so-called garbage" is in the Notification Requirements document. > >We're not doing accounting here, let's keep it simple. TIPSI does more >than we need (it includes much of the MIB traps concepts) except e-mail and >all >the alerts sections total maybe 25 pages. It seems to work, my customers >are happy. Lets discuss whether we want to do accounting or not. Currently, the PWG Job Monitoring MIB has accounting as one of its usages. There are those who are concerned that SNMP is a fairly fragile way to do reliable accounting. Is there a need to also provide a more robust way with IPP? Or should implementors add private extensions for accounting with IPP? > >Everything else is superfluous and overkill. For once can't we design >something simple >and not aim it at the DOCUTECH environment. If Xerox needs something much >heavier >then you should go do it for your products. I'm not putting all this junk >in my printers. Please identify which "junk" you would like to get rid of. Then we can have a more constructive discussion. The whole idea of the authors was to see what stuff we wanted to keep and what wasn't necessary. It is far easier for a committee to delete from a spec, then it is to invent on the fly. > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > > > > >To: ipp%pwg.org@interlock.lexmark.com >cc: (bcc: Don Wright) >bcc: Don Wright >Subject: IPP> Notifications paper > > > > >I have started to review the latest notification paper from Tom et al. >This looks to be a fine example of design by committee, i.e. put >everything in but the kitchen sink, so as to please everybody. Sorry, >but I think it's rubbish -- if it takes 50 pages to describe it is way too >complicated. If I can wade through the gory details, I'll make more >substantive >comments later. >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > > > > > > > > From ipp-owner@pwg.org Tue May 19 02:54:56 1998 Delivery-Date: Tue, 19 May 1998 02:54:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA14177 for ; Tue, 19 May 1998 02:54:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06679 for ; Tue, 19 May 1998 02:57:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA26275 for ; Tue, 19 May 1998 02:54:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 19 May 1998 02:43:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA24909 for ipp-outgoing; Tue, 19 May 1998 02:38:48 -0400 (EDT) Message-Id: <3.0.1.32.19980518233458.01350b50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 18 May 1998 23:34:58 PDT To: "Scott Isaacson" From: Tom Hastings Subject: Re: IPP> NOT - Smaller Notification Documents Cc: ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Scott, Roger, and Jay, These proposals look real good! Thanks for making the effort. Several more issues for the IPP Event Notification paper to be added on to the end of the list: 8. Which notification mechanisms for delivery should we require for conformance in order to improve interoperability? 9. Should make the "subscriptions" attribute be a Job Description attribute as well, so that the create operation copies the "subscription" operation attribute to the job object. 10. As it says on lines 222-223, there are Printer events which are not Printer MIB alerts. I suggest adding the "event keyword" for Printer Events after line 274, just like there is for Job Events. Then there can be other Printer events added in the future that are not Printer MIB alerts too. 11. Also a client might be subscribing to multiple Printers, so need to add printer-uri to both Job Events at line 270 and Printer Events at line 274. 12. For Job events, the notification-recipient needs to know the job-id, so add the job-id at line 272. Several issues for the Printer Subscriptions for IPP to add to the one about unscribing to a non-existent subscription: 2. Should we simplify Subscribe and only allow a single collection value in the Subscribe operation? Then the error handling is much easier; if there is only one subscription we can't have one value succeed and one fail. Also the Printer can add the subscription-id as a collection member attribute (to the single value). 3. Similarly, why allow multiple Unsubscribe subscription-ids in a single call? It would also complicate the error return if some succeed and some fail. At 14:17 05/15/1998 PDT, Scott Isaacson wrote: >Since there has been some fairly negative reaction to such a long, detailed, all rolled up proposal for IPP Event Notifications, I have posted some very short, overview descriptions of the concept that can be reviewed in a matter of minutes (not hours or day). > >I also removed all features that were specified as "optional to implement" and raised them as issues of the type "Do we even want to do specify this feature independent of whether it is optional to implement". > >I took the files that Tom posted and simplified and shortened the basic proposal into an 8 page document called IPP Event Notification (Very Short) and posted it as: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.pdf > >I separated out the proposal for new Subscribe/Unsubscribe operations into a separate 4 page document called "Printer Events for IPP" and posted it as: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.doc >ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.pdf > >I hope that these higher level, less detail oriented overviews are more palatable to a wide audience and help in the communication process. > > >Scott > > > >************************************************************ >Scott A. Isaacson >Corporate Architect >Novell Inc., M/S PRV-C-121 >122 E 1700 S, Provo, UT 84606 >voice: (801) 861-7366, (800) 453-1267 x17366 >fax: (801) 861-2517 >email: sisaacson@novell.com >web: http://www.novell.com >************************************************************ > > > > From ipp-owner@pwg.org Tue May 19 16:18:59 1998 Delivery-Date: Tue, 19 May 1998 16:19:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26166 for ; Tue, 19 May 1998 16:18:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09456 for ; Tue, 19 May 1998 16:21:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07143 for ; Tue, 19 May 1998 16:18:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 19 May 1998 16:13:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06588 for ipp-outgoing; Tue, 19 May 1998 16:11:04 -0400 (EDT) From: Carl Kugler To: Subject: IPP> MOD> 'naturalLanguage' Message-ID: <5030100020678059000002L092*@MHS> Date: Tue, 19 May 1998 16:10:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26166 MOD says: 'naturalLanguage' The 'naturalLanguage' attribute syntax is a standard identifier for a natural language and optionally a country. The values for this syntax type are taken from RFC 1766 [RFC1766]... Examples include: 'en': for English 'en-us': for US English 'fr': for French 'de': for German but RFC1766 doesn't give values; it only describes a language tag. Are the values actually given by ISO 639? -Carl Kugler From ipp-owner@pwg.org Wed May 20 11:54:41 1998 Delivery-Date: Wed, 20 May 1998 11:54:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA16540 for ; Wed, 20 May 1998 11:54:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA12717 for ; Wed, 20 May 1998 11:57:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19701 for ; Wed, 20 May 1998 11:54:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 20 May 1998 11:43:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19146 for ipp-outgoing; Wed, 20 May 1998 11:42:52 -0400 (EDT) From: Carl Kugler To: Subject: IPP> ADM> IPP 1.0 Issues List? Message-ID: <5030100020714915000002L052*@MHS> Date: Wed, 20 May 1998 11:41:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16540 Is anyone keeping track of outstanding issues with IPP 1.0, or has the group moved on to IPP 2.0 completely? I'm looking for something like http://www.w3.org/Protocols/HTTP/Issues/ for example. Some specific issues I'm wondering about as we continue implementation and interoperability testing: 1. "printer-uri" or "job-uri" mandatory and required op att? Form? 2. Mixed case allowed in 'naturalLanguage' and 'charset' values? 3. 'client-error-request-uri-too-long' vs. 'client-error-request-value-too-long' ? Types applied to? 4. "attributes-charset" and "attributes-natural-language" must always be positioned up front? Are these still outstanding issues or have they been resolved and I've missed something? -Carl From ipp-owner@pwg.org Wed May 20 18:08:27 1998 Delivery-Date: Wed, 20 May 1998 18:08:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA21847 for ; Wed, 20 May 1998 18:08:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA14431 for ; Wed, 20 May 1998 18:10:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA20523 for ; Wed, 20 May 1998 18:08:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 20 May 1998 18:03:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20005 for ipp-outgoing; Wed, 20 May 1998 18:02:23 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Notifications Date: Wed, 20 May 1998 14:57:16 -0700 X-Mailer: Internet Mail Service (5.5.2217.0) Sender: owner-ipp@pwg.org I still suggest that we are mixing two different things under the same title. Notifications: A user making known to the system their desire that a message be sent when some action occurs on their job (ie.e 'email me when this job finishes') Events: an IPP Client asking an IPP Printer to send it information regarding errors, jobs, .etc. These may operate independantly, in tandem or in parallel. I suggest that the behaviours need to be something like: Notifications: Human readable, sent by a mechanism that is non-IPP (i.e email, ftp,....). The content is user defined (or can be). The only protocl addition we need is that there needs to be job attributes thats convey the users request. There may well be a standard set of mechanisms by which a notification can be sent. They are bound to jobs. Events: Machine readable. Carried in an IPP specified way using the same basic protocol as the commands and jobs. The content is defined. A client can request that they be generated for a specific job. In addition a client can subscribe to events. Usage scenario. A user asks for email when a job has finished printing. The IPP request to the server has the attribute set saying 'notify when printed'. The server queues the job up. When the job is sent to the printer it sets the attribute saying 'send me an event when this job completes'. (In fact a server may well be subscribed full-time to job completion events). When the server receives the event is goes into its job end process and recalls that the user requested email - so it sends a message. From ipp-owner@pwg.org Wed May 20 22:23:28 1998 Delivery-Date: Wed, 20 May 1998 22:23:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA23389 for ; Wed, 20 May 1998 22:23:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15016 for ; Wed, 20 May 1998 22:25:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA21336 for ; Wed, 20 May 1998 22:23:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 20 May 1998 22:19:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA20818 for ipp-outgoing; Wed, 20 May 1998 22:17:27 -0400 (EDT) From: don@lexmark.com Message-Id: <199805210217.AA20326@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: paulmo@microsoft.com Cc: Ipp@pwg.org Date: Wed, 20 May 1998 22:13:33 -0400 Subject: IPP> Notifications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org This is remarkedly similar to my description of what I wanted that I kept trying to get across in the meeting today. 1) A simple, limited flexibility, basically "hard-coded" set of information (Job Complete, Job Cancelled, Job aborted, etc.) that is provided largely tuned for human consumption that is requested in the IPP job submission command. 2) A more complex, flexible solution for machine consumption that is achieved through the addition of something like "Subscribe" and "Unsubscribe" operations to IPP. A richer, more robust set of events and attributes (groups?, collections?, individual attributes?, etc.) can be requested with the information send in several different ways (i.e TCP port, SNMP trap, etc.) Too bad you could be here to join in!! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> Notifications I still suggest that we are mixing two different things under the same title. Notifications: A user making known to the system their desire that a message be sent when some action occurs on their job (ie.e 'email me when this job finishes') Events: an IPP Client asking an IPP Printer to send it information regarding errors, jobs, .etc. These may operate independantly, in tandem or in parallel. I suggest that the behaviours need to be something like: Notifications: Human readable, sent by a mechanism that is non-IPP (i.e email, ftp,....). The content is user defined (or can be). The only protocl addition we need is that there needs to be job attributes thats convey the users request. There may well be a standard set of mechanisms by which a notification can be sent. They are bound to jobs. Events: Machine readable. Carried in an IPP specified way using the same basic protocol as the commands and jobs. The content is defined. A client can request that they be generated for a specific job. In addition a client can subscribe to events. Usage scenario. A user asks for email when a job has finished printing. The IPP request to the server has the attribute set saying 'notify when printed'. The server queues the job up. When the job is sent to the printer it sets the attribute saying 'send me an event when this job completes'. (In fact a server may well be subscribed full-time to job completion events). When the server receives the event is goes into its job end process and recalls that the user requested email - so it sends a message. From ipp-owner@pwg.org Thu May 21 12:16:54 1998 Delivery-Date: Thu, 21 May 1998 12:16:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11719 for ; Thu, 21 May 1998 12:16:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA16839 for ; Thu, 21 May 1998 12:19:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA03808 for ; Thu, 21 May 1998 12:16:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 21 May 1998 12:09:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03259 for ipp-outgoing; Thu, 21 May 1998 12:08:31 -0400 (EDT) Message-ID: From: Paul Moore To: "'don@lexmark.com'" Cc: Ipp@pwg.org Subject: RE: IPP> Notifications Date: Thu, 21 May 1998 09:08:35 -0700 X-Mailer: Internet Mail Service (5.5.2217.0) Sender: owner-ipp@pwg.org I would not necessarily agree about one being limited and the other being flexible. They are just different in intent and behavior. I would have been there If I could - I was there in spirit :-) > -----Original Message----- > From: don@lexmark.com [SMTP:don@lexmark.com] > Sent: Wednesday, May 20, 1998 7:14 PM > To: Paul Moore > Cc: Ipp@pwg.org > Subject: IPP> Notifications > > > This is remarkedly similar to my description of what I wanted that I kept > trying to get across in the meeting today. > > 1) A simple, limited flexibility, basically "hard-coded" set of > information > (Job Complete, Job Cancelled, Job aborted, etc.) that is provided largely > tuned for human consumption that is requested in the IPP job submission > command. > > 2) A more complex, flexible solution for machine consumption that is > achieved through the addition of something like "Subscribe" and > "Unsubscribe" operations to IPP. A richer, more robust set of events and > attributes (groups?, collections?, individual attributes?, etc.) can be > requested with the information send in several different ways (i.e TCP > port, SNMP trap, etc.) > > Too bad you could be here to join in!! > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > > > > > > > To: ipp%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright) > bcc: Don Wright > Subject: IPP> Notifications > > > > > I still suggest that we are mixing two different things under the same > title. > Notifications: A user making known to the system their desire that a > message > be sent when some action occurs on their job (ie.e 'email me when this job > finishes') > Events: an IPP Client asking an IPP Printer to send it information > regarding > errors, jobs, .etc. > These may operate independantly, in tandem or in parallel. > I suggest that the behaviours need to be something like: > Notifications: Human readable, sent by a mechanism that is non-IPP (i.e > email, ftp,....). The content is user defined (or can be). The only > protocl > addition we need is that there needs to be job attributes thats convey > the > users request. There may well be a standard set of mechanisms by which a > notification can be sent. They are bound to jobs. > Events: Machine readable. Carried in an IPP specified way using the same > basic protocol as the commands and jobs. The content is defined. A client > can request that they be generated for a specific job. In addition a > client > can subscribe to events. > Usage scenario. A user asks for email when a job has finished printing. > The > IPP request to the server has the attribute set saying 'notify when > printed'. The server queues the job up. When the job is sent to the > printer > it sets the attribute saying 'send me an event when this job completes'. > (In > fact a server may well be subscribed full-time to job completion events). > When the server receives the event is goes into its job end process and > recalls that the user requested email - so it sends a message. > > > > > > > From ipp-owner@pwg.org Thu May 21 14:23:55 1998 Delivery-Date: Thu, 21 May 1998 14:23:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA13619 for ; Thu, 21 May 1998 14:23:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA17597 for ; Thu, 21 May 1998 14:26:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA04498 for ; Thu, 21 May 1998 14:23:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 21 May 1998 14:19:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03948 for ipp-outgoing; Thu, 21 May 1998 14:15:43 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> Notifications Message-ID: <5030100020771424000002L042*@MHS> Date: Thu, 21 May 1998 14:14:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13619 > Events: Machine readable. Carried in an IPP specified way using the same > basic protocol as the commands and jobs. This implies something other than HTTP used as the basic protocol for commands and jobs. -Carl owner-ipp@pwg.org on 05/20/98 04:07:12 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> Notifications I still suggest that we are mixing two different things under the same title. Notifications: A user making known to the system their desire that a message be sent when some action occurs on their job (ie.e 'email me when this job finishes') Events: an IPP Client asking an IPP Printer to send it information regarding errors, jobs, .etc. These may operate independantly, in tandem or in parallel. I suggest that the behaviours need to be something like: Notifications: Human readable, sent by a mechanism that is non-IPP (i.e email, ftp,....). The content is user defined (or can be). The only protocl addition we need is that there needs to be job attributes thats convey the users request. There may well be a standard set of mechanisms by which a notification can be sent. They are bound to jobs. Events: Machine readable. Carried in an IPP specified way using the same basic protocol as the commands and jobs. The content is defined. A client can request that they be generated for a specific job. In addition a client can subscribe to events. Usage scenario. A user asks for email when a job has finished printing. The IPP request to the server has the attribute set saying 'notify when printed'. The server queues the job up. When the job is sent to the printer it sets the attribute saying 'send me an event when this job completes'. (In fact a server may well be subscribed full-time to job completion events). When the server receives the event is goes into its job end process and recalls that the user requested email - so it sends a message. From ipp-owner@pwg.org Thu May 21 21:09:44 1998 Delivery-Date: Thu, 21 May 1998 21:09:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA18080 for ; Thu, 21 May 1998 21:09:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA19145 for ; Thu, 21 May 1998 21:12:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA05910 for ; Thu, 21 May 1998 21:09:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 21 May 1998 21:04:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05360 for ipp-outgoing; Thu, 21 May 1998 21:00:09 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: IPP> Notifications Date: Thu, 21 May 1998 18:00:26 -0700 X-Mailer: Internet Mail Service (5.5.2217.0) Sender: owner-ipp@pwg.org not necessarily > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Thursday, May 21, 1998 11:14 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > > Events: Machine readable. Carried in an IPP specified way using the same > > basic protocol as the commands and jobs. > > This implies something other than HTTP used as the basic protocol for > commands > and jobs. > > -Carl > > > > > owner-ipp@pwg.org on 05/20/98 04:07:12 PM > Please respond to owner-ipp@pwg.org > To: ipp@pwg.org > cc: > Subject: IPP> Notifications > > > I still suggest that we are mixing two different things under the same > title. > > Notifications: A user making known to the system their desire that a > message > be sent when some action occurs on their job (ie.e 'email me when this job > finishes') > > Events: an IPP Client asking an IPP Printer to send it information > regarding > errors, jobs, .etc. > > These may operate independantly, in tandem or in parallel. > > I suggest that the behaviours need to be something like: > > Notifications: Human readable, sent by a mechanism that is non-IPP (i.e > email, ftp,....). The content is user defined (or can be). The only > protocl > addition we need is that there needs to be job attributes thats convey > the > users request. There may well be a standard set of mechanisms by which a > notification can be sent. They are bound to jobs. > > Events: Machine readable. Carried in an IPP specified way using the same > basic protocol as the commands and jobs. The content is defined. A client > can request that they be generated for a specific job. In addition a > client > can subscribe to events. > > Usage scenario. A user asks for email when a job has finished printing. > The > IPP request to the server has the attribute set saying 'notify when > printed'. The server queues the job up. When the job is sent to the > printer > it sets the attribute saying 'send me an event when this job completes'. > (In > fact a server may well be subscribed full-time to job completion events). > When the server receives the event is goes into its job end process and > recalls that the user requested email - so it sends a message. > > > > > From ipp-owner@pwg.org Fri May 22 11:11:16 1998 Delivery-Date: Fri, 22 May 1998 11:11:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04891 for ; Fri, 22 May 1998 11:11:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20783 for ; Fri, 22 May 1998 11:13:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA18665 for ; Fri, 22 May 1998 11:11:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 22 May 1998 10:59:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA18104 for ipp-outgoing; Fri, 22 May 1998 10:55:43 -0400 (EDT) From: Carl Kugler To: Cc: Subject: RE: IPP> Notifications Message-ID: <5030100020808882000002L022*@MHS> Date: Fri, 22 May 1998 10:54:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04891 Care to elaborate? I guess I should have been more specific and said "HTTP/1.1". -Carl paulmo@microsoft.com on 05/21/98 07:01:54 PM Please respond to paulmo@microsoft.com To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus cc: Subject: RE: IPP> Notifications not necessarily > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Thursday, May 21, 1998 11:14 AM > To: ipp@pwg.org > Subject: Re: IPP> Notifications > > > Events: Machine readable. Carried in an IPP specified way using the same > > basic protocol as the commands and jobs. > > This implies something other than HTTP used as the basic protocol for > commands > and jobs. > > -Carl > > > > > owner-ipp@pwg.org on 05/20/98 04:07:12 PM > Please respond to owner-ipp@pwg.org > To: ipp@pwg.org > cc: > Subject: IPP> Notifications > > > I still suggest that we are mixing two different things under the same > title. > > Notifications: A user making known to the system their desire that a > message > be sent when some action occurs on their job (ie.e 'email me when this job > finishes') > > Events: an IPP Client asking an IPP Printer to send it information > regarding > errors, jobs, .etc. > > These may operate independantly, in tandem or in parallel. > > I suggest that the behaviours need to be something like: > > Notifications: Human readable, sent by a mechanism that is non-IPP (i.e > email, ftp,....). The content is user defined (or can be). The only > protocl > addition we need is that there needs to be job attributes thats convey > the > users request. There may well be a standard set of mechanisms by which a > notification can be sent. They are bound to jobs. > > Events: Machine readable. Carried in an IPP specified way using the same > basic protocol as the commands and jobs. The content is defined. A client > can request that they be generated for a specific job. In addition a > client > can subscribe to events. > > Usage scenario. A user asks for email when a job has finished printing. > The > IPP request to the server has the attribute set saying 'notify when > printed'. The server queues the job up. When the job is sent to the > printer > it sets the attribute saying 'send me an event when this job completes'. > (In > fact a server may well be subscribed full-time to job completion events). > When the server receives the event is goes into its job end process and > recalls that the user requested email - so it sends a message. > > > > > From ipp-owner@pwg.org Wed May 27 12:00:53 1998 Delivery-Date: Wed, 27 May 1998 12:00:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05033 for ; Wed, 27 May 1998 12:00:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11103 for ; Wed, 27 May 1998 12:03:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA07526 for ; Wed, 27 May 1998 12:00:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 27 May 1998 11:55:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06971 for ipp-outgoing; Wed, 27 May 1998 11:50:39 -0400 (EDT) Message-Id: <3.0.5.32.19980527084916.009a9810@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 08:49:16 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-stdguide-ops-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi folks, I am back. Here yet another document on how to write IETF standrads. Carl-Uno --- >To: IETF-Announce:; >Cc: stdguide@midnight.com >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-stdguide-ops-07.txt >Date: Thu, 21 May 1998 06:41:04 PDT >Sender: cclark@CNRI.Reston.VA.US > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Guide for Internet Standards Writers Working Group >of the IETF. > > Title : Guide for Internet Standards Writers > Author(s) : G. Scott > Filename : draft-ietf-stdguide-ops-07.txt > Pages : 20 > Date : 20-May-98 > > This document is a guide for Internet standard writers. It defines > those characteristics that make standards coherent, unambiguous, and > easy to interpret. In addition, it singles out usage believed to > have led to unclear specifications, resulting in non-interoperable > interpretations in the past. These guidelines are to be used with > RFC 2223, 'Instructions to RFC Authors.' > > This version of the document is a draft. > >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-stdguide-ops-07.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-stdguide-ops-07.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-stdguide-ops-07.txt". > >NOTE: The mail server at ietf.org 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: <19980520154740.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-stdguide-ops-07.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed May 27 12:14:34 1998 Delivery-Date: Wed, 27 May 1998 12:14:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05328 for ; Wed, 27 May 1998 12:14:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11218 for ; Wed, 27 May 1998 12:16:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA08117 for ; Wed, 27 May 1998 12:14:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 27 May 1998 12:10:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07587 for ipp-outgoing; Wed, 27 May 1998 12:05:12 -0400 (EDT) Message-Id: <3.0.5.32.19980527090405.009abca0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 09:04:05 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-reddy-scap-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, The Calendaring folks are joining the HTTP wave. Carl-Uno --- >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-reddy-scap-00.txt >Date: Fri, 22 May 1998 07:13:57 PDT >Sender: cclark@CNRI.Reston.VA.US > >Note: This announcement is being re-sent with a new filename. > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Web based Simple Calendar Access Protocol - SCAP > Author(s) : S. Reddy > Filename : draft-reddy-scap-00.txt > Pages : 45 > Date : 27-Apr-98 > > Distributed calendaring is gradually becoming more demanding than > standalone calendaring and scheduling. The use of calendaring and > scheduling has grown exponentially and enterprise and inter- > enterprise business has become so dependent on group scheudling > applications. But there is no Internet standard to provide > interoperability among various calendaring applications. > Consequently, user need to install different conduit programs to > access these calendaring stores. This memo proposes a HTTP based > simple calendaring access protocol which allows web, email and any > HTTP compliant clients to access and manipulate calendar store. > > The motivation for this proposal is the expanded scope and diversity > of the World Wide Web. The World Wide Web provides a simple and > effective means for users to search, browse, retrieve, and publish > information of their own available for others. Now that Web browsers > and servers are ubiquitous on the Internet, it is worthwhile to use > HTTP as transport protocol and XML to encode calendar objects. The > power and extensibility of XML allows us to represent calendar data > objects as well-formed XML documents. > > Simple Calendar Access Protocol(SCAP) allows exchanging calendaring > information between scheduling systems using the Hypertext Transfer > Protocol (HTTP). This allows users to schedule meetings with anyone > else, no matter what scheduling software they use. > > This document specifies a set of methods, headers, and content-types > ancillary to HTTP/1.1 for the management of calender properties, > creation and management of calendar objects, and namespace > manipulation. > >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-reddy-scap-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-reddy-scap-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-reddy-scap-00.txt". > >NOTE: The mail server at ietf.org 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: <19980521104128.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-reddy-scap-00.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed May 27 12:29:35 1998 Delivery-Date: Wed, 27 May 1998 12:29:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05602 for ; Wed, 27 May 1998 12:29:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA11292 for ; Wed, 27 May 1998 12:31:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA08739 for ; Wed, 27 May 1998 12:29:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 27 May 1998 12:25:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08213 for ipp-outgoing; Wed, 27 May 1998 12:20:30 -0400 (EDT) Message-Id: <3.0.5.32.19980527091919.012c6e60@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 09:19:19 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-iesg-iana-considerations-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FUI, More guidelines.... Carl-Uno -- >To: IETF-Announce:; >Cc: iesg@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-iesg-iana-considerations-04.txt >Date: Tue, 26 May 1998 07:16:23 PDT >Sender: cclark@CNRI.Reston.VA.US > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IETF Steering Group Working Group of the IETF. > > Title : Guidelines for Writing an IANA Considerations > Section in RFCs > Author(s) : H. Alvestrand, T. Narten > Filename : draft-iesg-iana-considerations-04.txt > Pages : 10 > Date : 22-May-98 > > Many protocols make use of identifiers consisting of constants and > other well-known values. Even after a protocol has been defined and > deployment has begun, new values may need to be assigned (e.g., for > a new option type in DHCP, or a new encryption or authentication > algorithm for IPSec). To insure that such quantities have consistent > values and interpretations in different implementations, their > assignment must be administered by a central authority. For IETF > protocols, that role is provided by the Internet Assigned Numbers > Authority (IANA). > > In order for the IANA to manage a given numbering space prudently, it > needs guidelines describing the conditions under which new values can > be assigned. If the IANA is expected to play a role in the management > of a numbering space, the IANA must be given clear and concise > instructions describing that role. This document discusses issues > that should be considered in formulating an identifier assignment > policy and provides guidelines to document authors on the specific > text that must be included in documents that place demands on the > IANA. > >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-iesg-iana-considerations-04.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-04.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-iesg-iana-considerations-04.txt". > >NOTE: The mail server at ietf.org 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: <19980522101444.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-iesg-iana-considerations-04.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed May 27 14:49:34 1998 Delivery-Date: Wed, 27 May 1998 14:49:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07869 for ; Wed, 27 May 1998 14:49:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA12189 for ; Wed, 27 May 1998 14:51:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10472 for ; Wed, 27 May 1998 14:49:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 27 May 1998 14:45:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09953 for ipp-outgoing; Wed, 27 May 1998 14:42:09 -0400 (EDT) Message-Id: <3.0.5.32.19980527114059.009af380@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 11:40:59 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> ADM> IPP 1.0 Issues List? In-Reply-To: <5030100020714915000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 08:41 AM 5/20/98 PDT, you wrote: >Is anyone keeping track of outstanding issues with IPP 1.0, or has the group >moved on to IPP 2.0 completely? I'm looking for something like > > http://www.w3.org/Protocols/HTTP/Issues/ > >for example. Some specific issues I'm wondering about as we continue >implementation and interoperability testing: > >1. "printer-uri" or "job-uri" mandatory and required op att? Form? >2. Mixed case allowed in 'naturalLanguage' and 'charset' values? >3. 'client-error-request-uri-too-long' vs. >'client-error-request-value-too-long' ? Types applied to? >4. "attributes-charset" and "attributes-natural-language" must always be >positioned up front? > >Are these still outstanding issues or have they been resolved and I've missed >something? > > -Carl > Carl, A very good question. I have tried for the last couple of PWG meetings to get somebody to take on this job, but so far nobody has stood up to take it on. I do not know if anything happened on this in the PWG meeting last week. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu May 28 11:47:31 1998 Delivery-Date: Thu, 28 May 1998 11:47:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA01867 for ; Thu, 28 May 1998 11:47:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA16150 for ; Thu, 28 May 1998 11:49:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25540 for ; Thu, 28 May 1998 11:47:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 28 May 1998 11:35:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA24955 for ipp-outgoing; Thu, 28 May 1998 11:34:28 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 28 May 1998 09:33:31 -0600 From: "Scott Isaacson" To: manros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM> IPP 1.0 Issues List? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01867 I wouldn't mind an issues list, but the ones that you mentioned were all raised and discussed at the last meeting. See comments below. >1. "printer-uri" or "job-uri" mandatory and required op att? Form? Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29.. Meeting notes due out soon. >2. Mixed case allowed in 'naturalLanguage' and 'charset' values? What is the issue? The model document syntax rules for charset and naturalLanguage state that IPP does not allow mixed case. 4.1.9 'charset' currently says: "Though RFC 2046 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." 4.1.10 'naturalLanguage' currently says: "Though RFC 1766 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." >3. 'client-error-request-uri-too-long' vs. >'client-error-request-value-too-long' ? Types applied to? Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes due out soon. >4. "attributes-charset" and "attributes-natural-language" must always be >positioned up front? Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes due out soon. From ipp-owner@pwg.org Thu May 28 12:06:32 1998 Delivery-Date: Thu, 28 May 1998 12:06:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA02407 for ; Thu, 28 May 1998 12:06:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA16226 for ; Thu, 28 May 1998 12:08:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26175 for ; Thu, 28 May 1998 12:06:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 28 May 1998 12:02:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25601 for ipp-outgoing; Thu, 28 May 1998 11:51:14 -0400 (EDT) Message-ID: <356D871F.DF5BD7F8@underscore.com> Date: Thu, 28 May 1998 11:47:43 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Scott Isaacson CC: manros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM> IPP 1.0 Issues List? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Given the importance of reconciling outstanding issues, as well as maintaining an easy-to-follow thread on the IPP Hypermail archives, would it be in our best interest to extract the issue resolutions from the meeting notes and post them as a follow-up to this thread? If this effort is too much for the IPP worker bees to assume, I'll be more than happy to do the extract/post myself, if you'd prefer. ...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 -- ---------------------------------------------------------------------- Scott Isaacson wrote: > > I wouldn't mind an issues list, but the ones that you mentioned were all raised and discussed at the last meeting. See comments below. > > >1. "printer-uri" or "job-uri" mandatory and required op att? Form? > > Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29.. Meeting notes > due out soon. > > >2. Mixed case allowed in 'naturalLanguage' and 'charset' values? > > What is the issue? The model document syntax rules for charset and naturalLanguage state that IPP does not allow mixed case. 4.1.9 'charset' currently says: > > "Though RFC 2046 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." > > 4.1.10 'naturalLanguage' currently says: > > "Though RFC 1766 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." > > >3. 'client-error-request-uri-too-long' vs. > >'client-error-request-value-too-long' ? Types applied to? > > Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes > due out soon. > > >4. "attributes-charset" and "attributes-natural-language" must always be > >positioned up front? > > Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes > due out soon. From ipp-owner@pwg.org Thu May 28 12:39:52 1998 Delivery-Date: Thu, 28 May 1998 12:39:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA03491 for ; Thu, 28 May 1998 12:39:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA16394 for ; Thu, 28 May 1998 12:42:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26851 for ; Thu, 28 May 1998 12:39:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 28 May 1998 12:35:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26317 for ipp-outgoing; Thu, 28 May 1998 12:33:11 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> ADM> IPP 1.0 Issues List? Message-ID: <5030100021040613000002L032*@MHS> Date: Thu, 28 May 1998 12:31:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03491 >Subject: Re: IPP> ADM> IPP 1.0 Issues List? > > >I wouldn't mind an issues list, but the ones that you mentioned were all >raised and discussed at the last meeting. See comments below. I'm glad to see these were discussed at the meeting! Some of these issues have been around a while and wasn't aware of a plan or process in place for resolving them so I piped up. > >>1. "printer-uri" or "job-uri" mandatory and required op att? Form? > >Discussed and resolved at the 5/20-21 meeting. See new text to be >published by 5/29.. Meeting notes >due out soon. > >>2. Mixed case allowed in 'naturalLanguage' and 'charset' values? > >What is the issue? The model document syntax rules for charset and >naturalLanguage state that IPP does not allow mixed case. 4.1.9 >'charset' currently says: The issue is that the protocol document shows mixed case used for 'naturalLanguage' and 'charset' values in the examples. Does the MOD doc take precedence over PRO? Anyway, I'd bet that most existing implementations are based more on the examples than anything else. "Be conservative in what you send, lenient in what you accept, yada, yada, yada." > >"Though RFC 2046 requires that the values be case-insensitive US-ASCII, >IPP requires all lower case to simplify comparing by IPP clients and >Printer objects." > >4.1.10 'naturalLanguage' currently says: > >"Though RFC 1766 requires that the values be case-insensitive US-ASCII, >IPP requires all lower case to simplify comparing by IPP clients and >Printer objects." > >>3. 'client-error-request-uri-too-long' vs. >>'client-error-request-value-too-long' ? Types applied to? > >Discussed and resolved at the 5/20-21 meeting. See new text to be >published by 5/29 Meeting notes >due out soon. > >>4. "attributes-charset" and "attributes-natural-language" must always be >>positioned up front? > >Discussed and resolved at the 5/20-21 meeting. See new text to be >published by 5/29 Meeting notes >due out soon. > > > > From ipp-owner@pwg.org Thu May 28 22:15:23 1998 Delivery-Date: Thu, 28 May 1998 22:15:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA15291 for ; Thu, 28 May 1998 22:15:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA18787 for ; Thu, 28 May 1998 22:17:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA28765 for ; Thu, 28 May 1998 22:15:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 28 May 1998 22:10:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA28243 for ipp-outgoing; Thu, 28 May 1998 22:10:06 -0400 (EDT) Message-Id: <3.0.1.32.19980528190530.0108c000@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 28 May 1998 19:05:30 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - IPP Minutes posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I've posted the IPP minutes from the 5/20-21 IPP meeting: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-minutes-980520.doc ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-minutes-980520.pdf ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-minutes-980520.txt Thanks for Scott and Harry for their notes. Agenda Wednesday, 5/20: 11:00 AM - 11:30 PM Agenda fixing, progress of IPP in the IETF report, etc. 11:30 AM - 12:00 PM Bug fixes in current IPP/1.0 documentation (Scott, Bob) 1:30 PM - 2:30 PM Interoperability Testing (Pete Z.) 2:30 - 6:00 MIB Access (Scott) Thursday, 5/21: 8:30 - 12:00 Notification (Scott) The minutes contain a lot of issues relating to notification. While the minutes indicate considerable consensus, especially on the general approach, we think that the best way to nail down the details is to send out a set of questions and get each participant (by organization) to respond with yes, no, don't care. Then it will be straight forward to finish the spec. Look for that questionaire next week. Tom From ipp-owner@pwg.org Fri May 29 11:08:39 1998 Delivery-Date: Fri, 29 May 1998 11:08:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04833 for ; Fri, 29 May 1998 11:08:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA20658 for ; Fri, 29 May 1998 11:11:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA07692 for ; Fri, 29 May 1998 11:08:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 10:56:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA06576 for ipp-outgoing; Fri, 29 May 1998 10:54:06 -0400 (EDT) Message-Id: <3.0.1.32.19980529074910.0117ce88@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 29 May 1998 07:49:10 PDT To: Jay Martin From: Tom Hastings Subject: Re: IPP> ADM> IPP 1.0 Issues List? [extracted from 5/20 minutes] Cc: Scott Isaacson , manros@cp10.es.xerox.com, ipp@pwg.org In-Reply-To: <356D871F.DF5BD7F8@underscore.com> References: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipp@pwg.org Here are the extracted issue resolutions from the IPP .txt minutes of the 5/20 meeting: 3 Bug fixes in current IPP/1.0 documentation The current IPP/1.0 documentation is defined by a suite of Internet- Drafts as submitted to the IESG: Requirements for an Internet Printing Protocol (104985 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-req-01.txt Internet Printing Protocol/1.0: Model and Semantics (435327 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-09.txt Mapping between LPD and IPP Protocols (52648 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-map-03.txt Internet Printing Protocol/1.0: Protocol Specification (75544 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-protocol-05.txt Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (23639 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-rat-02.txt 3.1 Model Document changes ACTION ITEM (Scott): Make these changes while working with the RFC editor to turn the Model specification into an RFC: 3.1.1Clarify that the success status code doesn't mean job has printed A sentence will be added to clarify that the .Success. status code does not mean the print operation was entirely successful. It means that the request has been received, is valid and a job object was created. 3.1.2No further clarifications of the 'stopped' Printer state needed There was a question about whether or not the .Stopped. Printer State needs clarification. New wording, added since Portland, was agreed to be sufficient and no further changes are anticipated. 3.1.3Remove type4 keywords and use type3 keywords (and names) instead There was a question about the purpose and value of Type-4 keywords. Keyword types were explained, as follows: 1 - Must republish the standard to extend. Example - Job States. 2 - Extended or enhance with PWG approval. 3 - Extended or enhanced via registration (IANA) w/o PWG approval. 4 - Not registered. Only applicable to local administrative domains. Example of attributes using type 4 keywords: "media", "job-sheets", and "job-hold-until". They all have the syntax: (type4 keyword | name(MAX)). Because we also allow 'name' syntax, we decided it is best to eliminate the Type-4 enumeration from the specification and to change these three attributes to: (type3 keyword | name(MAX)). Administrators 2 PWG Internet Printing Project - Minutes May 20-21, 1998 may supply localized names within their own domains. So a system manager can only defined names, not keywords. It seems too difficult for a client to have to discover new keywords have been added by the system administrator and then obtain their localization (somehow) in different languages for display to the end-user. Instead, the 'name' attribute syntax will be clarified to indicate that the "name" exists for administrator to add values that are not supported by the implementation. See Bob Herriot's email of March 18 and 19 for a complete discussion. 3.1.4Order of "charset", "natural-language", and Target operation attributes There was a clarification about the order of operation attributes in IPP requests and responses. The "charset" attribute must come first followed by the "natural-language" attribute. For requests, the target attribute(s): "printer-uri", "job-uri", or "printer-uri followed by job-id" must come next. This ordering facilitates processing of the remaining operation attributes by the server. 3.1.5Clarify that the syntax of "printer-uri" and "job-uri" is 'uri' Clarify that the attribute syntax of "printer-uri" and "job-uri" is 'uri'. 3.1.6Clarify that the simplest PrintJob must include the target operation attributes An inconsistency was identified within the Operations attribute group of the PrintJob section in that the simplest operation is defined as the set of document content, "charset" and "natural-language" operation attributes. This section will be revised to include the target attribute(s). 3.1.7Clarify the notation for Mandatory and Optional in Section 15.3. The mandatory table in Section 15.3 is ambiguous. Tom proposed a clarification that, when talking about mandatory and optional, here, we are not defining the terms mandatory and optional, rather we are defining which things must be implemented and which things may be supplied. Tom.s clarifying text (as posted in previous e-mail) will be added. 3.1.8Keep 'uri' syntax and attribute names; don't change to 'url' syntax In Portland, we agreed to continue to use URI syntax name but note that these are really URL.s. Now, there is some question whether this is appropriate in light of some new RFC related to URI.s. ACTION ITEM (Bob Herriott): research and report. 3.1.9Redefine 'client-error-uri-too-long' to be 'client-error-too-long' There were questions about two, potentially redundant, client status error codes 1. client-error-request-uri-too-long 3 PWG Internet Printing Project - Minutes May 20-21, 1998 2. client-error-bad-request Do we need both? Which one do you use if URI is too long? Do they apply to all URI.s or just the "document-uri" attribute? Should .too long. apply to ANY attribute that is string-like? We decided that an error with semantics .Too Long. should be defined for any data type that is a variable number of octets with a maximum length. 3.1.10 ISSUE: Some text and name attributes are constrained to be shorter than MAX We further addressed the problem of string overrun in constrained resource implementations by proposing additional syntax types such as 'shortName', and 'shortText' which would be 63 and 127 bytes, respectively, for example). The goal is to allow the length syntax checking to be solely based on attribute syntax code, and not depend on which attribute is being supplied. To accomplish this goal will require the addition of at least one new attribute syntax. ACTION ITEM (Scott or Bob): Need a detailed proposal. 3.1.11 Reaffirmed that target attributes must be supplied in the request redundantly We agreed that target attributes should be redundantly carried inside the IPP operation as well as externally in the HTTP request header. This redundancy is necessary to keep the IPP MIME media type transport- independent. There was debate over the architectural soundness of this proposal, as it would prevent simple re-routing of the job to a new target based on information from the request header. Instead, to re- route, the embedded target must be learned from examination of the IPP stream. It also complicates test. Following discussion, there was strong opinion not to change anything so the decision to adopt this change (which had already been made - target attributes inside the operation) stands as is and test tools must deal with the situation as required. 3.1.12 Clarified that the target URI are absolute form Per above, suppose we have printer URI inside the operation, but also have it in the HTTP request header mapping. There is the issue of Absolute vs. Relative addressing of the target. Internal to the IPP operation, only Absolute URL.s apply. But, in the HTTP header, it might be Relative. We reiterated that the internal URI is mandatory but the server does not need to check it for routing. In fact, the HTTP request header URI, if present, takes precedence. The internal URI should reference the same URI as the one in the HTTP header (should not be garbage). The external URI may be Relative. 3.1.13 Clarify that the reference to RFC 1766 includes the ISO standards that it references Inside the model document, we talk about natural language syntax from RFC1766: 'en', 'fr', etc. But RFC1766 doesn.t give these values it just references two other ISO standards. We resolved clarify the reference 4 PWG Internet Printing Project - Minutes May 20-21, 1998 to RFC1766 as pertaining to syntax, and add a reference to the proper references for the actual values: [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology (principles and coordination). [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15. 3.2 Protocol Document changes ACTION ITEM (Bob): Make these changes while working with the RFC editor to turn the Model specification into an RFC: 3.2.1Change name from "Protocol" to "Encoding and Transport" Name should be changed from "Protocol" to "Encoding and Transport". 3.2.2Add "printer-uri" operation attribute to examples Add "printer-uri" operation attribute to examples to agree with the Model document. 3.2.3Change all attributes to lower case in examples Change some upper case to lower case to agree with the Model document. 3.2.4Change the reserved 'dictionary' attribute syntax to 'collection' Change the name of the reserved 34 attribute syntax code from 'dictionary' to 'collection'. At 08:47 05/28/1998 PDT, Jay Martin wrote: >Given the importance of reconciling outstanding issues, >as well as maintaining an easy-to-follow thread on the >IPP Hypermail archives, would it be in our best interest >to extract the issue resolutions from the meeting notes >and post them as a follow-up to this thread? > >If this effort is too much for the IPP worker bees to >assume, I'll be more than happy to do the extract/post >myself, if you'd prefer. > > ...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 -- >---------------------------------------------------------------------- > > >Scott Isaacson wrote: >> >> I wouldn't mind an issues list, but the ones that you mentioned were all raised and discussed at the last meeting. See comments below. >> >> >1. "printer-uri" or "job-uri" mandatory and required op att? Form? >> >> Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29.. Meeting notes >> due out soon. >> >> >2. Mixed case allowed in 'naturalLanguage' and 'charset' values? >> >> What is the issue? The model document syntax rules for charset and naturalLanguage state that IPP does not allow mixed case. 4.1.9 'charset' currently says: >> >> "Though RFC 2046 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." >> >> 4.1.10 'naturalLanguage' currently says: >> >> "Though RFC 1766 requires that the values be case-insensitive US-ASCII, IPP requires all lower case to simplify comparing by IPP clients and Printer objects." >> >> >3. 'client-error-request-uri-too-long' vs. >> >'client-error-request-value-too-long' ? Types applied to? >> >> Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes >> due out soon. >> >> >4. "attributes-charset" and "attributes-natural-language" must always be >> >positioned up front? >> >> Discussed and resolved at the 5/20-21 meeting. See new text to be published by 5/29 Meeting notes >> due out soon. > > From ipp-owner@pwg.org Fri May 29 12:15:32 1998 Delivery-Date: Fri, 29 May 1998 12:15:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA06867 for ; Fri, 29 May 1998 12:15:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA20957 for ; Fri, 29 May 1998 12:17:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA08796 for ; Fri, 29 May 1998 12:15:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 12:11:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08247 for ipp-outgoing; Fri, 29 May 1998 12:10:28 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> ADM - IPP Minutes posted: questions about 3.1.11 an Message-ID: <5030100021089257000002L072*@MHS> Date: Fri, 29 May 1998 12:08:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06867 > 3.1.11 Reaffirmed that target attributes must be supplied in the request redundantly > We agreed that target attributes should be redundantly carried inside the IPP operation as well as externally in the HTTP request header. > This redundancy is necessary to keep the IPP MIME media type transport-independent. > There was debate over the architectural soundness of this proposal, as it would prevent simple re-routing of the job to a new target based on information from the request header. > Instead, to re-route, the embedded target must be learned from examination of the IPP stream. I don't understand the re-route mechanism. Is HTTP REDIRECT involved? Is an HTTP proxy required to open up the application/ipp body and rewrite it? Could someone please give some re-route scenarios? > It also complicates test. > Following discussion, there was strong opinion not to change anything so the decision to adopt this change (which had already been made - target attributes inside the operation) stands as is and test tools must deal with the situation as required. > > 3.1.12 Clarified that the target URI are absolute form > Per above, suppose we have printer URI inside the operation, but also have it in the HTTP request header mapping. > There is the issue of Absolute vs. Relative addressing of the target. > Internal to the IPP operation, only Absolute URL's apply. ALL internal URIs are absolute? > But, in the HTTP header, it might be Relative. MUST be, unless you're talking to an HTTP proxy server. > We reiterated that the internal URI is mandatory but the server does not need to check it for routing. > In fact, the HTTP request header URI, if present, takes precedence. > The internal URI should reference the same URI as the one in the HTTP header (should not be garbage). What is the rationale for this? (Esp. given that the server does not need to check it for routing and that the HTTP request URI takes precedence.) Could you elaborate on what's required to satisfy this? Suppose the two URIs effectively reference the same resource but they are significantly different (say, as the result of an HTTP redirect)? Leniency on this requirement would facilitate testing with binary trace files. > The external URI may be Relative. MUST be, unless you're talking to an HTTP proxy server. From ipp-owner@pwg.org Fri May 29 14:48:44 1998 Delivery-Date: Fri, 29 May 1998 14:48:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09901 for ; Fri, 29 May 1998 14:48:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21690 for ; Fri, 29 May 1998 14:51:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09790 for ; Fri, 29 May 1998 14:48:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 14:41:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09033 for ipp-outgoing; Fri, 29 May 1998 14:39:10 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> MOD> Another IPP 1.0 issue Message-ID: <5030100021096638000002L082*@MHS> Date: Fri, 29 May 1998 14:37:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09901 I think this text from MOD section 3.1.4.1 is misleading: "The IPP object SHALL remember that natural language for all client supplied attributes, and when returning those attributes in response to a query, the IPP object SHALL indicate that natural language. "For example, the "job-name" attribute MAY be supplied by the client in a create request. The text value for this attribute will be in the natural language identified by the "attribute-natural-language" attribute, or if different, as identified by the Natural Language Override mechanism. If supplied, the IPP object will use the value of the "job-name" attribute to populate the Job object's "job-name" attribute. Whenever any client queries the Job object's "job-name" attribute, the IPP object returns the attribute as stored and uses the Natural Language Override mechanism to specify the natural language, if it is different from that reported in the "attributes-natural-language" operation attribute of the response. It subtly conflicts with this text from MOD section 3.2.6.2: "For any job submitted in a different natural language than the natural language that the Printer object is returning in the "attributes-natural-language" operation attribute in the Get-Jobs response, the Printer SHALL indicate the submitted natural language by returning the Job object's "attributes-natural-language" as the first Job object attribute, which overrides the "attributes-natural-language" operation attribute value being returned by the Printer object. If any returned 'text' or 'name' attribute includes a Natural Language Override as described in the sections 4.1.2 and 4.1.4, the Natural Language Override overrides the Job object's "attributes-natural-language" value and/or the "attributes-natural-language" operation attribute value. There is a precedence hierarchy here: 1. Natural Language Override 2. Job object's "attributes-natural-language" value 3. "attributes-natural-language" operation attribute of the response. 1 overrides 2 and 3, 2 overrides 3. So this statement in 3.1.4.1: "Whenever any client queries the Job object's "job-name" attribute, the IPP object returns the attribute as stored and uses the Natural Language Override mechanism to specify the natural language, if it is different from that reported in the "attributes-natural-language" operation attribute of the response. and this one in 3.1.4.2: "For any 'text' or 'name' attribute or status message in the response that is in a different natural language than the value returned in the "attributes-natural-language" operation attribute, the IPP object SHALL use the Natural Language Override mechanism (see sections 4.1.2 and 4.1.4) on each attribute value returned. are incorrect. The IPP object uses the Natural Language Override mechanism to specify the natural language if it is different from Job object's "attributes-natural-language" value, which is the case only when the client used the Natural Language Override at submission time. The Printer never needs to use the Natural Language Override in a response except for those attributes that the client supplied with Natural Language Override. Somewhat related question: is it ALLOWABLE for an IPP object to use the Natural Language Override mechanism in cases where it is NOT necessary (i.e., would be redundant with a default specified by a Job object's "attributes-natural-language" value or the "attributes-natural-language" operation attribute of the response)? Could a printer convert all 'text' and 'name' attributes into 'textWithLanguage' and 'nameWithLanguage'? From ipp-owner@pwg.org Fri May 29 14:51:48 1998 Delivery-Date: Fri, 29 May 1998 14:51:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA10107 for ; Fri, 29 May 1998 14:51:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21705 for ; Fri, 29 May 1998 14:54:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10224 for ; Fri, 29 May 1998 14:51:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 14:46:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09047 for ipp-outgoing; Fri, 29 May 1998 14:40:45 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 29 May 1998 12:40:10 -0600 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> MOD - new model document with fixes for typos and minor issues Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10107 Since there has not be a new model document for 4 months now, and n an attempt to get the Model document ready for eventual publication as an RFC, I have fixed all known (to me) types, bug fixes, and minor issues by documenting the changes in a new version of the model document. There is one exception: there is one known outstanding issue wrt variable length max values for text and name. The issue is a known issue, but this version contains no fixes for the issue -a real solution needs to be worked in. The new I-D, if ever published as an I-D, would be model-10.txt, but I will not publish it as an I-D since we have passed final call. The new document can be found at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980529-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980529.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980529.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980529.txt Changes made: 1. Clarified that even though the term "URI" is used, what we really mean is "URL" 2. Fixed the order of "attributes-charset", "attributes-natural-language" and target ("printer-uri", "job-uri", "job-id") attributes. 1st "attributes-charset" 2nd "attributes-natural-language" 3rd target ("printer-uri", "job-uri", or "printer-uri" followed by "job-id") 3. Clarified the conflict between MANDATORY attributes and the "simplest" Print-Job request. 4. Added (uri) syntax for "printer-uri" and "job-uri" and added (integer(1:MAX)) for "job-id" 5. Clarified that HTTP layer URLs might be relative URI and that URLs in IPP operation attributes must be absolute URLs. I added this to section 4.1.7. Should this text go into the protocol spec instead of the model document? 6. Clarified that RFC 1776 defines the tags used for natural language attributes, not necessarily enumerates them all (RFC 1766 actually just references other ISO standards) 7. Changed "type 4 | name" to "type 3 | name" 8. Removed the whole notion of type 4 9. Fixed type in number-up (from 0:MAX to 1:MAX) 10. Clarified that "successful-ok" for Print-Job just means that the job object was created, not printed. 11. Noted that "client-error-bad-request" error code should be used for fixed length values that are not of the expected fixed length. 12. Changed "uri-too-long" to "value-too-long" to indicate that it can be used for any variable length attribute is too long and for some reason can not be ignored because it is just too big. 13. Added "server-error-busy" as a solution for the "server contention" problem 14. In section 15.3.4.3, clarified what is MANDATORY or OPTIONAL to support and what MUST be supplied (sent in the operation request or response) and what MAY be supplied. 15. Also in section 15.3.4.3 changed Job Template attributes from (M*) to (O*) 16. Also in section 15.3.4.3, showed the correct order of 1st "attributes-charset" 2nd "attributes-natural-language" 3rd target ("printer-uri", "job-uri", or "printer-uri" followed by "job-id") 17. Added "charset-supported", "generated-natural-language-supported" to the Generic Directory Schema to align with what was added to the SLP Printer template 18. Fixed syntax discrepancies between headers and tables Fixes still needed - 1. Proposal for name, text, textShort ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Fri May 29 16:35:21 1998 Delivery-Date: Fri, 29 May 1998 16:35:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11744 for ; Fri, 29 May 1998 16:35:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA22199 for ; Fri, 29 May 1998 16:37:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11186 for ; Fri, 29 May 1998 16:35:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 16:31:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA10647 for ipp-outgoing; Fri, 29 May 1998 16:29:43 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> MOD - new model document with fixes for typos and m Message-ID: <5030100021102529000002L092*@MHS> Date: Fri, 29 May 1998 16:28:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA11744 I question this new definition: "13.1.2.1 successful-ok (0x0000) "The request has succeeded. In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, validated, processed, and that the Job object has been created; it does not indicate that the job has been printed. The transition of the Job object into the 'completed' state is the only indicator that the job has been printed. given the definition of 'processing' in section 3.1.7: "Job submission time is the point in time when a client issues a create request. The initial state of every Job object is the 'pending' or 'pending-held' state. Later, the Printer object begins processing the print job. At this point in time, the Job object's state moves to 'processing'. This is known as job processing time. There are validation checks that must be done at job submission time and others that must be performed at job processing time. I don't believe that successful-ok (0x0000) really indicates that the request was successfully "processed". Or at least there is the danger of confusion here between "request processing" and "job processing". Perhaps "request processing" needs a definition. -Carl From ipp-owner@pwg.org Fri May 29 16:40:46 1998 Delivery-Date: Fri, 29 May 1998 16:40:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11804 for ; Fri, 29 May 1998 16:40:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA22232 for ; Fri, 29 May 1998 16:43:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11797 for ; Fri, 29 May 1998 16:40:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 16:36:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA10656 for ipp-outgoing; Fri, 29 May 1998 16:29:48 -0400 (EDT) Message-Id: <199805292029.QAA02901@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> review of IPP documents cc: moore@cs.utk.edu From: Keith Moore Date: Fri, 29 May 1998 16:29:31 -0400 Sender: owner-ipp@pwg.org At long last I've completed my review of the IPP documents. My comments follow. Please note that we're still waiting for the TLS document to clear (sigh)... things that depend on TLS can't go through until TLS is finished. Last I heard they were waiting on resolution of some patent issues and/or an X.509 profile that allowed use of UTF-8 in printable strings. (yeech) I apologize for this haven taken so long. Keith summary: Basically I think the protocols are mostly sound, though the documents need some editorial cleanup. There are some minor technical tweaks here and there. The biggest change that I think is needed, is that IPP's use of HTTP doesn't allow a firewall to distinguish between IPP traffic and ordinary HTTP traffic. Also, IPP's insistence on using port 80 could conflict with ordinary use of that port, in those cases where the IPP server was not designed to "plug in" to the HTTP server. For these reasons, I suggest that a separate port be allocated for IPP, and an "ipp" URL defined which defaults to the IPP port rather than port 80. An alternative would be to have IPP use the PRINT method rather than POST, but to me the separate port seems cleaner and more likely to be compatible with firewalls. One could still use IPP on port 80, by using the port override notation: ipp://hostname:80/etc. Note that we now have in effect a policy of not allocating separate ports for with/without TLS. (I've asked the security ADs in IESG to review this policy, but I think it will be upheld.) Someone has an internet-draft which attempts to define a way to negotiate TLS in-band over HTTP; you might want to look at that. similarly, using the "s" suffix on the URI type to indicate TLS/ is considered by many to be a Bad Idea; if it's necessary to specify a particular authentication and/or encryption type, it should probably be done using a URI parameter. (and it should probably be more flexible than just ";security=tls") detailed comments follow; I apologize for mixing the purely editorial (most of the comments) with the technical issues, and thus making this unnecessarily tedious to read for anyone other than the authors. but this way, I get to cross this off my list today! general: 1. In addition to the keywords defined in RFC 2119, the documents use a number of upper case terms like SHALL, SHALL NOT, NEED NOT, etc. If these terms are in upper case because they have special meanings, those meanings need to be defined somewhere, and each document that uses those terms needs to have a prominent notice (i.e. near the beginning of the document) pointing to those definitions. If the terms have their normal meanings (which from my reading seems to be the case), they should be spelled in lower case, unless there is some reason to emphasize a particular use of a term. On the other hand, it appears that SHALL etc. are sometimes used when one of the words in RFC 2119 would do just as well. It would be better to keep consistent technology unless there's a good reason not to do so. Note that the keywords in RFC 2119 are generally used to indicate implementation choices that would affect compliance with a standard, or very occasionally, requirements for operation of the service (as in "SMTP servers MUST accept mail addressed to Postmaster") Other uses of "MUST", "SHOULD", etc. should generally use lower case letters. For instance, the IPP design goals "MUST" be satisfied in IPP/1.0...this is not a requirement on implementation, and should be spelled "must". Finally, if you need to use one of these upper cased keywords with "not", it should be "MUST NOT" or "SHALL NOT", rather than "MUST not" or SHALL not (or even "SHALL also not") to have one word upper cased and the other not, is confusing. 2. there appear to be a number of artifacts in the plain text versions of the documents, which may have resulted from conversion to text from some other format. For instance, tables are poorly formatted in the text version, I saw at least one instance of overprinting, and there appear to be missing pieces of text here and there. Since the plain text versions are considered authoritative, they need to be carefully proofread. draft-ietf-ipp-rat-02.txt: 1. the last paragraph (9) of section 4 may need tweaking depending on whether IPP is revised to use a different default port than HTTP< or if it's revised to use PRINT instead of POST. 2. section 7 is actually missing the copyright notice; it only contains the license. draft-ietf-ipp-req-01.txt: 1. Even though the IPP WG was told to write a requirements document, some IESG folks have pushed back on using the word "requirements" in a document title. My guess is that the title should be changed to something like "Design Goals for an Internet Printing Protocol". Either that, or many of the "requirements" need more justification to convince the reader that they're obviously requirements and not merely goals. 2. Section 1: It's not clear how or why a web browser is part of a complete Internet Printing system. 3. Section 2.1.4: it's not clear why a user needs to have the ability to submit a print job by reference. 4. Section 2.2: change "the user may only see his own jobs" to "the user might only be able to see his own jobs". 5. Section 3, third paragraph, last sentence. Seems like "must properly handle this methodology" should be "must properly handle either methodology". 6. Section 3.1, first paragraph. "Whenever possible, IPP ought to make use of ..." should perhaps be "Whenever reasonable,..." 7. 3.1, second paragraph. "printing environments describes"... should be "printing environments described"; "document to be printed may all exist" should be "document to be printed may each exist" ; "protection are much stronger" should be "protection may be much stronger" 8. 3.3, first paragraph. "shall be extensible by several means that facilitates interoperability and prevents"... should be "facilitate" and "prevent" 9. section 3.3: the structure of the bulleted list is confusing; some of the bullets should apparently be subordinate to the others. 4th bullet: needs a space between "attributes" and "and" 10. section 4.2. there are significant security risks associated with driver installation; I don't see any discussion of those risks. 11. section 7. there appears to be overprinting in the acknowledgements section (at least, enscript didn't handle it right) 12. the document seems to assume that users will download a driver to talk to a particular printer; there's no requirement that users be able to talk to printers -- even in reduced functionality mode -- without downloading a driver. this would seem to constrain the cross-platform portability of the standard, as well as introducing security risks. (which is not to say that IPP itself has problems with this ... I think it's okay .. but the assumption that everyone who wants to talk to a printer can download and install a driver is not a valid one...it's too windows centric) 13. section 9.23. do we have permission to use Kinko's and Sir Speedy's names/trademarks? If not, should probably substitute generic names. 14. document is missing a security considerations section at the end. it can refer to section 4.1 but should also mention security problems related to downloading drivers. draft-ietf-ipp-model-09.txt: 1. Section 2.4: should refer to TLS, not SSL3. Also, the "https" URL prefix is nonstandard. 2. at the end of section 3.1.3, this is misstated: if the URL type allows a port number and one is specified, that port number must be used. if no port number is specified, the default port must be used. (if the URL type doesn't allow a port number and one is specified anyway, it's arguably a parse error on the URL and the whole operation should fail) 3. section 3.1.4.1, last paragraph: "object SHALL NOT change either of these attributes and SHALL except them as if they were valid." it's not clear (to me) what this means: doesn't this put the printer in a position where it cannot report errors in the natural language? I understand not allowing the printer to change the request, but shouldn't this be an error condition, and if so, how should it be reported? 4. section 3.2.1.2, under "Group 3: Job Object Attributes" "Printer object always uses is" should be "Printer object always uses its" 5. section 4.1.1 it's not clear to me why, if anything defined as 'text' is also allowed to use 'textWithLanguage' syntax, that there are separate syntaxes for text vs. textWithLanguage. Why not either do: text = textWithLanguage | textUsingImplicitLanguage and just call everything 'text' from then on out? (which would be a purely editorial simplification) or just elimiate the implicit language form altogether? (which would be a protocol simplification) 6. 4.1.2, 5th paragraph "SHALL accept, support, and return both the 'text' and 'textWithLanguage' reads as if objects are requried to *return* both syntaxes for every text attribute...not one or the other. 7. section 4.1.8. if you must refer to https, please refer to it as non-standard. 8. section 4.1.9 what does it mean to restrict the use of utf-8 to iso 10646? why do you want to impose such a restriction? 9. section 4.1.11 'mimeMediaType' is too short, especially given that it contains the parameters also. 127 octets would be marginal. 255 would be a lot better. (is there a reason to use 2**n-1?) 10. section 4.2.7 does the page-ranges count page images rather than docuemnt page numbers (say in eps or pdf?) 11. section 4.3.1 despite widespread use of "https" etc, the URI "access method" shouldn't be used to indicate the presense or lack of "security"; when necessary to specify a particular security technology in a URI, that should be a done with a paramter (e.g. ";auth-type=digest"). 12. section 4.3.7 for the case where there is an IPP front-end to some other kind of printer queue, and it's not possible for the front-end to determine whether the job is 'completed' according to the IPP definition, what status should it report when the job is finished as best as can be determined? it seems like 'completed' is the right thing to do here, but this would be inconsistent with the definition. 13. section 4.4.2 the example makes it appear as if "password-printer" is a magic string in a URL, which indicates that a printer is to use basic or digest authenticaiton 14. section 4.4.24 cleartext passwords are no longer allowed in URLs 15. section 5.1, last paragraph "Clients may choose to ignore any parameters that it does not understand" should be "...that they do not understand". 16. section 5.4 Conforming clients MUST (not SHOULD) support TLS access. 17. section 6.1 If I'm not mistaken, it's inappropriate for the IPP RFC to actually name the experts. Nor do I think it's okay to have PWG "specify a replacement [expert] at any time", because PWG isn't responsible to IETF in any way. Nor do I think it's okay to give PWG control over the keywoard/enum value space. IANA can delegate to PWG, but IANA should have ultimate authority. This section needs to be reviewed by IANA. draft-ietf-ipp-protocol-05.txt: 1. Section 3.2. I probably haven't grokked how these are used, but are there enough attribute tags and value tags to have room for future expansion? 2. Section 3.9 some text appears to be missing 3. section 3.11 The table in the text version is illegible. 4. section 4 IPP needs its own default port and url scheme. Support for port 80 should be optional. 5. section 4.1 table is difficult to read 6. section 4.2 it looks like there might be missing information in the accept-language row of the table. 7. section 5 IPP needs its own port; support for port 80 should be optional. draft-ietf-ipp-lpd-ipp-map-03.txt 1. section 4.3 table is difficult to read in the text version 2. section 7 change title to "Security Considerations". yes, some folks are picky about this. From ipp-owner@pwg.org Fri May 29 16:50:18 1998 Delivery-Date: Fri, 29 May 1998 16:50:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11888 for ; Fri, 29 May 1998 16:50:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA22281 for ; Fri, 29 May 1998 16:52:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12451 for ; Fri, 29 May 1998 16:50:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 16:46:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11894 for ipp-outgoing; Fri, 29 May 1998 16:43:37 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> MOD> More internationalization questions Message-ID: <5030100021103092000002L022*@MHS> Date: Fri, 29 May 1998 16:41:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA11888 More internationalization questions: According to MOD 3.2.6.2: "For any job submitted in a different natural language than the natural language that the Printer object is returning in the "attributes-natural-language" operation attribute in the Get-Jobs response, the Printer SHALL indicate the submitted natural language by returning the Job object's "attributes-natural-language" as the first Job object attribute, which overrides the "attributes-natural-language" operation attribute value being returned by the Printer object. MAY a Printer return the Job object's "attributes-natural-language" as the first Job object attribute when the job was submitted in the same natural language that the Printer object is returning in the "attributes-natural-language" operation attribute in the Get-Jobs response (even if it's not one of the "requested-attributes")? WHY is "attributes-charset" a mandatory Job Description attribute when all attributes in a response are returned in the charset indicated in the "attributes-charset" operation attribute of the response, regardless of the charset they were submitted in? From ipp-owner@pwg.org Fri May 29 17:20:25 1998 Delivery-Date: Fri, 29 May 1998 17:20:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA12088 for ; Fri, 29 May 1998 17:20:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA22404 for ; Fri, 29 May 1998 17:22:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13125 for ; Fri, 29 May 1998 17:20:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 17:16:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12607 for ipp-outgoing; Fri, 29 May 1998 17:13:18 -0400 (EDT) Message-ID: <19980529211305.19431.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> New IPP Model Document Content-Type: text/plain Date: Fri, 29 May 1998 14:13:05 PDT Sender: owner-ipp@pwg.org Greetings. From: "Scott Isaacson" :: Clarified that HTTP layer URLs might be relative URI and that :: URLs in IPP operation attributes must be absolute URLs. :: I added this to section 4.1.7. I did not understand the reason to make URLs in IPP opearion attributes absolute URLs. An IPP printer object already knows its host-name, port-number etc. Also, in Get-Printer-Attribute response, an IPP server sends the "printer-uri-supported". The printer-uri attribute supplied by an IPP client should match that supplied in the Get-Printer-Attribute response. Considering these, can we make the IPP operation attribute URIs relative URIs instead of absoulte? >From "Tom Hastings" :: In fact, the HTTP request header URI, if persent, takes precedence" (over printer-uri/job-uri operation attributes). I think it should be the other way around. I feel the printer-uri/job-uri, supplied by IPP client, should have higher precedence to an IPP server than the HTTP header URI. Please respond to these doubts/clarifications. -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-owner@pwg.org Fri May 29 17:40:04 1998 Delivery-Date: Fri, 29 May 1998 17:40:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA12193 for ; Fri, 29 May 1998 17:40:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA22483 for ; Fri, 29 May 1998 17:42:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13752 for ; Fri, 29 May 1998 17:40:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 17:36:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13234 for ipp-outgoing; Fri, 29 May 1998 17:34:14 -0400 (EDT) Message-ID: <356F29CE.8DB20785@underscore.com> Date: Fri, 29 May 1998 17:34:06 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Puru Bish Subject: Re: IPP> New IPP Model Document References: <19980529211305.19431.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org After thinking about this, I tend to agree with Puru's statement: >From "Tom Hastings" > > :: In fact, the HTTP request header URI, if persent, takes precedence" > (over printer-uri/job-uri operation attributes). > > I think it should be the other way around. I feel the > printer-uri/job-uri, supplied by IPP client, should have higher > precedence to an IPP server than the HTTP header URI. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 17:49:57 1998 Delivery-Date: Fri, 29 May 1998 17:49:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA12230 for ; Fri, 29 May 1998 17:49:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA22525 for ; Fri, 29 May 1998 17:52:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14358 for ; Fri, 29 May 1998 17:49:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 17:46:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13836 for ipp-outgoing; Fri, 29 May 1998 17:41:16 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" , ipp@pwg.org Cc: Puru Bish Subject: RE: IPP> New IPP Model Document Date: Fri, 29 May 1998 14:41:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org This may be a difficult requirement to meet if an IPP implementation is built as an extension to a generic web server (like Apache). Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:34 PM To: ipp@pwg.org Cc: Puru Bish Subject: Re: IPP> New IPP Model Document After thinking about this, I tend to agree with Puru's statement: >From "Tom Hastings" > > :: In fact, the HTTP request header URI, if persent, takes precedence" > (over printer-uri/job-uri operation attributes). > > I think it should be the other way around. I feel the > printer-uri/job-uri, supplied by IPP client, should have higher > precedence to an IPP server than the HTTP header URI. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 18:00:02 1998 Delivery-Date: Fri, 29 May 1998 18:00:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12279 for ; Fri, 29 May 1998 18:00:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22543 for ; Fri, 29 May 1998 18:02:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14967 for ; Fri, 29 May 1998 18:00:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 17:56:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14440 for ipp-outgoing; Fri, 29 May 1998 17:51:30 -0400 (EDT) Message-ID: <356F2DCD.C02B6B1F@underscore.com> Date: Fri, 29 May 1998 17:51:09 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org, Puru Bish Subject: Re: IPP> New IPP Model Document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 18:15:10 1998 Delivery-Date: Fri, 29 May 1998 18:15:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12362 for ; Fri, 29 May 1998 18:15:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22585 for ; Fri, 29 May 1998 18:17:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA15602 for ; Fri, 29 May 1998 18:15:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:11:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15067 for ipp-outgoing; Fri, 29 May 1998 18:06:10 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> New IPP Model Document Date: Fri, 29 May 1998 15:06:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Absolutely, I see the advantage of having the IPP information take precedence, I'm just not sure of the impact of having the two headers (HTTP and IPP-body) be different, and actually getting this to work in a CGI/NSAPI/ISAPI-based implementation. The generic web server will dispatch to the HTTP header-specified URI (I'm assuming, someone correct me if this is not the case). Once this dispatch occurs, the target in the HTTP header better be able to handle whatever is coming in the application/ipp body part. In this scenario, its too late to apply any precedence. Has someone identified a case where the two headers have to be different? (I may have missed some email...) Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:51 PM To: Turner, Randy Cc: ipp@pwg.org; Puru Bish Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 18:20:02 1998 Delivery-Date: Fri, 29 May 1998 18:20:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12385 for ; Fri, 29 May 1998 18:20:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22605 for ; Fri, 29 May 1998 18:22:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16186 for ; Fri, 29 May 1998 18:20:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:16:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA15352 for ipp-outgoing; Fri, 29 May 1998 18:13:09 -0400 (EDT) Message-Id: <3.0.5.32.19980529151138.00927db0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 May 1998 15:11:38 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org PWG IPP Phone Conference on 980603, 10:00 AM PDT ================================================ By now I hope that everybody has seen the feedback information from Keith Moore. In response to that I want to dedicate the next phone conference to sort out trivial vs. more complex tasks to resolve the listed issues. Please read Keith's message beforehand, so we can get straight into the discussion. You can obvioiusly express views also beforehand on the DL. Dial-in Information: Time: June 3, 10:00 - 12:00 PDT Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri May 29 18:30:04 1998 Delivery-Date: Fri, 29 May 1998 18:30:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12419 for ; Fri, 29 May 1998 18:30:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22630 for ; Fri, 29 May 1998 18:32:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA16825 for ; Fri, 29 May 1998 18:30:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:26:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16289 for ipp-outgoing; Fri, 29 May 1998 18:22:38 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> New IPP Model Document Message-ID: <5030100021107942000002L022*@MHS> Date: Fri, 29 May 1998 18:21:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12419 > why are we specifying printer-uri/job-uri at all at the IPP protocol level? Only to allow future deployment of the IPP Model over non-HTTP protocols. owner-ipp@pwg.org on 05/29/98 03:59:00 PM Please respond to owner-ipp@pwg.org To: rturner@sharplabs.com cc: purub@hotmail.com, ipp@pwg.org Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 18:39:00 1998 Delivery-Date: Fri, 29 May 1998 18:39:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12465 for ; Fri, 29 May 1998 18:38:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22649 for ; Fri, 29 May 1998 18:41:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA17934 for ; Fri, 29 May 1998 18:39:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:31:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16273 for ipp-outgoing; Fri, 29 May 1998 18:20:48 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 29 May 1998 16:19:56 -0600 From: "Scott Isaacson" To: rturner@sharplabs.com, jkm@underscore.com Cc: purub@hotmail.com, ipp@pwg.org Subject: Re: IPP> New IPP Model Document Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12465 As I recall, the only reason that the printer-uri/job-uri attributes are in protocol at the IPP layer, is because we wanted to be consistent with possibly future mappings of IPP onto protocols other than HTTP where we didn't have equivalent routing info. These attributes in the IPP payload are totally redundant and they are not needed in the HTTP mapping. Maybe it was a bad idea to add them, since many server implementations behind a generic web server (as Randy points out) will work fine even if it never even validates the values of these attributes that are internal to the application/ipp blob. Scott >>> Jay Martin 05/29 3:51 PM >>> > snip... >On the other hand, if the HTTP request header takes precedent, >then why are we specifying printer-uri/job-uri at all at the >IPP protocol level? Aren't we asking for trouble when the >HTTP request header and the corresponding IPP attributes don't >match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 18:39:31 1998 Delivery-Date: Fri, 29 May 1998 18:39:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12470 for ; Fri, 29 May 1998 18:39:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22652 for ; Fri, 29 May 1998 18:41:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18003 for ; Fri, 29 May 1998 18:39:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:31:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16468 for ipp-outgoing; Fri, 29 May 1998 18:27:24 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" , ipp@pwg.org Subject: RE: IPP> review of IPP documents Date: Fri, 29 May 1998 15:29:06 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org Aha the good old POST vs PRINT issue. REQUIRING a different port number would be wrong. We dont preclude this however (we have tested our implementations with non port 80 IPP agents). As you kow MS proposed using PRINT instead of POST. > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Friday, May 29, 1998 1:30 PM > To: ipp@pwg.org > Cc: moore@cs.utk.edu > Subject: IPP> review of IPP documents > > At long last I've completed my review of the IPP documents. > My comments follow. > > Please note that we're still waiting for the TLS document > to clear (sigh)... things that depend on TLS can't go > through until TLS is finished. Last I heard they were waiting > on resolution of some patent issues and/or an X.509 profile > that allowed use of UTF-8 in printable strings. (yeech) > > I apologize for this haven taken so long. > > Keith > > > > summary: > > Basically I think the protocols are mostly sound, though the > documents need some editorial cleanup. There are some minor > technical tweaks here and there. > > The biggest change that I think is needed, is that IPP's use > of HTTP doesn't allow a firewall to distinguish between IPP > traffic and ordinary HTTP traffic. Also, IPP's insistence on > using port 80 could conflict with ordinary use of that port, in > those cases where the IPP server was not designed to "plug in" to > the HTTP server. For these reasons, I suggest that a separate > port be allocated for IPP, and an "ipp" URL defined which defaults > to the IPP port rather than port 80. An alternative would be to > have IPP use the PRINT method rather than POST, but to me the > separate port seems cleaner and more likely to be compatible > with firewalls. One could still use IPP on port 80, by using > the port override notation: ipp://hostname:80/etc. > > Note that we now have in effect a policy of not allocating > separate ports for with/without TLS. (I've asked the security > ADs in IESG to review this policy, but I think it will be upheld.) > Someone has an internet-draft which attempts to define a way > to negotiate TLS in-band over HTTP; you might want to look at that. > > similarly, using the "s" suffix on the URI type to indicate TLS/ > is considered by many to be a Bad Idea; if it's necessary to specify > a particular authentication and/or encryption type, it should > probably be done using a URI parameter. (and it should probably > be more flexible than just ";security=tls") > > detailed comments follow; I apologize for mixing the purely > editorial (most of the comments) with the technical issues, > and thus making this unnecessarily tedious to read for anyone > other than the authors. but this way, I get to cross this off > my list today! > > > general: > > 1. In addition to the keywords defined in RFC 2119, the documents > use a number of upper case terms like SHALL, SHALL NOT, NEED NOT, > etc. If these terms are in upper case because they have special > meanings, those meanings need to be defined somewhere, and each > document that uses those terms needs to have a prominent notice > (i.e. near the beginning of the document) pointing to those > definitions. If the terms have their normal meanings (which > from my reading seems to be the case), they should be spelled in > lower case, unless there is some reason to emphasize a particular > use of a term. > > On the other hand, it appears that SHALL etc. are sometimes used > when one of the words in RFC 2119 would do just as well. It would > be better to keep consistent technology unless there's a good reason > not to do so. > > Note that the keywords in RFC 2119 are generally used to indicate > implementation choices that would affect compliance with a standard, > or very occasionally, requirements for operation of the service > (as in "SMTP servers MUST accept mail addressed to Postmaster") > Other uses of "MUST", "SHOULD", etc. should generally use lower > case letters. For instance, the IPP design goals "MUST" be > satisfied in IPP/1.0...this is not a requirement on implementation, > and should be spelled "must". > > Finally, if you need to use one of these upper cased keywords > with "not", it should be "MUST NOT" or "SHALL NOT", rather > than "MUST not" or SHALL not (or even "SHALL also not") > to have one word upper cased and the other not, is confusing. > > 2. there appear to be a number of artifacts in the plain text > versions of the documents, which may have resulted from > conversion to text from some other format. For instance, tables > are poorly formatted in the text version, I saw at least one > instance of overprinting, and there appear to be missing pieces > of text here and there. > > Since the plain text versions are considered authoritative, they > need to be carefully proofread. > > > draft-ietf-ipp-rat-02.txt: > > 1. the last paragraph (9) of section 4 may need tweaking depending > on whether IPP is revised to use a different default port than > HTTP< or if it's revised to use PRINT instead of POST. > > 2. section 7 is actually missing the copyright notice; it only > contains the license. > > draft-ietf-ipp-req-01.txt: > > 1. Even though the IPP WG was told to write a requirements document, > some IESG folks have pushed back on using the word "requirements" > in a document title. My guess is that the title should be changed > to something like "Design Goals for an Internet Printing Protocol". > Either that, or many of the "requirements" need more justification > to convince the reader that they're obviously requirements and > not merely goals. > > 2. Section 1: It's not clear how or why a web browser is part of a > complete Internet Printing system. > > 3. Section 2.1.4: it's not clear why a user needs to have the ability > to submit a print job by reference. > > 4. Section 2.2: change "the user may only see his own jobs" to > "the user might only be able to see his own jobs". > > 5. Section 3, third paragraph, last sentence. Seems like > "must properly handle this methodology" should be "must properly > handle either methodology". > > 6. Section 3.1, first paragraph. "Whenever possible, IPP ought > to make use of ..." should perhaps be "Whenever reasonable,..." > > 7. 3.1, second paragraph. "printing environments describes"... > should be "printing environments described"; > > "document to be printed may all exist" should be > "document to be printed may each exist" ; > > "protection are much stronger" should be > "protection may be much stronger" > > 8. 3.3, first paragraph. "shall be extensible by several > means that facilitates interoperability and prevents"... > should be "facilitate" and "prevent" > > 9. section 3.3: the structure of the bulleted list is confusing; > some of the bullets should apparently be subordinate to the others. > > 4th bullet: needs a space between "attributes" and "and" > > 10. section 4.2. there are significant security risks associated > with driver installation; I don't see any discussion of those risks. > > 11. section 7. there appears to be overprinting in the > acknowledgements section (at least, enscript didn't handle it right) > > 12. the document seems to assume that users will download a driver > to talk to a particular printer; there's no requirement that users > be able to talk to printers -- even in reduced functionality > mode -- without downloading a driver. this would seem to constrain > the cross-platform portability of the standard, as well as introducing > security risks. (which is not to say that IPP itself has problems > with this ... I think it's okay .. but the assumption that everyone > who wants to talk to a printer can download and install a driver > is not a valid one...it's too windows centric) > > 13. section 9.23. do we have permission to use Kinko's and Sir Speedy's > names/trademarks? If not, should probably substitute generic names. > > 14. document is missing a security considerations section at the end. > it can refer to section 4.1 but should also mention security problems > related to downloading drivers. > > draft-ietf-ipp-model-09.txt: > > 1. Section 2.4: should refer to TLS, not SSL3. Also, the > "https" URL prefix is nonstandard. > > 2. at the end of section 3.1.3, this is misstated: > if the URL type allows a port number and one is specified, > that port number must be used. if no port number is specified, > the default port must be used. (if the URL type doesn't > allow a port number and one is specified anyway, it's arguably > a parse error on the URL and the whole operation should fail) > > 3. section 3.1.4.1, last paragraph: > > "object SHALL NOT change either of these attributes and SHALL > except them as if they were valid." it's not clear (to me) > what this means: doesn't this put the printer in a position > where it cannot report errors in the natural language? > I understand not allowing the printer to change the request, > but shouldn't this be an error condition, and if so, how should > it be reported? > > 4. section 3.2.1.2, under "Group 3: Job Object Attributes" > > "Printer object always uses is" should be > "Printer object always uses its" > > 5. section 4.1.1 > > it's not clear to me why, if anything defined as 'text' is also > allowed to use 'textWithLanguage' syntax, that there are separate > syntaxes for text vs. textWithLanguage. Why not either do: > > text = textWithLanguage | textUsingImplicitLanguage > > and just call everything 'text' from then on out? > (which would be a purely editorial simplification) > > or just elimiate the implicit language form altogether? > (which would be a protocol simplification) > > 6. 4.1.2, 5th paragraph > > "SHALL accept, support, and return both the 'text' and 'textWithLanguage' > > reads as if objects are requried to *return* both syntaxes > for every text attribute...not one or the other. > > 7. section 4.1.8. > > if you must refer to https, please refer to it as non-standard. > > 8. section 4.1.9 > > what does it mean to restrict the use of utf-8 to iso 10646? > why do you want to impose such a restriction? > > 9. section 4.1.11 > > 'mimeMediaType' is too short, especially given that it contains > the parameters also. 127 octets would be marginal. 255 would > be a lot better. (is there a reason to use 2**n-1?) > > 10. section 4.2.7 > > does the page-ranges count page images rather than docuemnt > page numbers (say in eps or pdf?) > > 11. section 4.3.1 > > despite widespread use of "https" etc, the URI "access method" > shouldn't be used to indicate the presense or lack of "security"; > when necessary to specify a particular security technology in > a URI, that should be a done with a paramter (e.g. ";auth-type=digest"). > > 12. section 4.3.7 > > for the case where there is an IPP front-end to some other kind > of printer queue, and it's not possible for the front-end > to determine whether the job is 'completed' according to the > IPP definition, what status should it report when the job > is finished as best as can be determined? > > it seems like 'completed' is the right thing to do here, > but this would be inconsistent with the definition. > > 13. section 4.4.2 > > the example makes it appear as if "password-printer" is a magic > string in a URL, which indicates that a printer is to use > basic or digest authenticaiton > > 14. section 4.4.24 > > cleartext passwords are no longer allowed in URLs > > 15. section 5.1, last paragraph > > "Clients may choose to ignore any parameters that it does not understand" > should be "...that they do not understand". > > 16. section 5.4 > > Conforming clients MUST (not SHOULD) support TLS access. > > 17. section 6.1 > > If I'm not mistaken, it's inappropriate for the IPP RFC to actually > name the experts. > > Nor do I think it's okay to have PWG "specify a replacement > [expert] at any time", because PWG isn't responsible to IETF in any way. > > Nor do I think it's okay to give PWG control over the keywoard/enum > value space. IANA can delegate to PWG, but IANA should have ultimate > authority. > > This section needs to be reviewed by IANA. > > > draft-ietf-ipp-protocol-05.txt: > > 1. Section 3.2. > > I probably haven't grokked how these are used, but are there enough > attribute tags and value tags to have room for future expansion? > > 2. Section 3.9 > > some text appears to be missing > > 3. section 3.11 > > The table in the text version is illegible. > > 4. section 4 > > IPP needs its own default port and url scheme. Support for port 80 > should be optional. > > 5. section 4.1 > > table is difficult to read > > 6. section 4.2 > > it looks like there might be missing information in the > accept-language row of the table. > > 7. section 5 > > IPP needs its own port; support for port 80 should be optional. > > > draft-ietf-ipp-lpd-ipp-map-03.txt > > 1. section 4.3 > > table is difficult to read in the text version > > 2. section 7 > > change title to "Security Considerations". yes, some folks are picky > about this. > From ipp-owner@pwg.org Fri May 29 18:56:01 1998 Delivery-Date: Fri, 29 May 1998 18:56:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12561 for ; Fri, 29 May 1998 18:56:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA22706 for ; Fri, 29 May 1998 18:58:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA18673 for ; Fri, 29 May 1998 18:56:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 18:51:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18118 for ipp-outgoing; Fri, 29 May 1998 18:49:28 -0400 (EDT) Message-Id: <199805292249.SAA10518@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> review of IPP documents In-reply-to: Your message of "Fri, 29 May 1998 15:29:06 PDT." Date: Fri, 29 May 1998 18:49:05 -0400 Sender: owner-ipp@pwg.org > Aha the good old POST vs PRINT issue. > > REQUIRING a different port number would be wrong. We dont preclude this > however (we have tested our implementations with non port 80 IPP agents). I disagree. IPP is a different service than vanilla HTTP; there's nothing wrong with having separate default ports for each, any more than having different default ports for telnet and whois. (Nobody's required to prevent the use of port 80; it's just that IPP needs its own default port assigned to it, and the IPP URI needs to default to that port) I think this is cleaner overall than using a new HTTP method on port 80. Keith From ipp-owner@pwg.org Fri May 29 19:05:25 1998 Delivery-Date: Fri, 29 May 1998 19:05:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12611 for ; Fri, 29 May 1998 19:05:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22737 for ; Fri, 29 May 1998 19:07:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19266 for ; Fri, 29 May 1998 19:05:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:01:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA18727 for ipp-outgoing; Fri, 29 May 1998 18:57:47 -0400 (EDT) Message-Id: <3.0.1.32.19980529155318.01172cf8@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 29 May 1998 15:53:18 PDT To: Carl Kugler From: Tom Hastings Subject: Re: IPP> MOD - new model document with fixes for typos and m Cc: In-Reply-To: <5030100021102529000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org A simpler clarification fix would be to delete the word "processed" in "received, validated, processed, ..." so that it would read: In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, and validated, and that the Job object has been created; it does not indicate that the job has been printed. Tom At 13:28 05/29/1998 PDT, Carl Kugler wrote: >I question this new definition: >"13.1.2.1 successful-ok (0x0000) >"The request has succeeded. In the case of a Print-Job operation, the >'successful-ok' status code indicates that the request was successfully >received, validated, processed, and that the Job object has been created; it >does not indicate that the job has been printed. The transition of the Job >object into the 'completed' state is the only indicator that the job has been >printed. > >given the definition of 'processing' in section 3.1.7: >"Job submission time is the point in time when a client issues a create >request. The initial state of every Job object is the 'pending' or >'pending-held' state. Later, the Printer object begins processing the print >job. At this point in time, the Job object's state moves to 'processing'. >This is known as job processing time. There are validation checks that must be >done at job submission time and others that must be performed at job processing >time. > >I don't believe that successful-ok (0x0000) really indicates that the request >was successfully "processed". Or at least there is the danger of confusion >here between "request processing" and "job processing". Perhaps "request >processing" needs a definition. > -Carl > > From ipp-owner@pwg.org Fri May 29 19:10:24 1998 Delivery-Date: Fri, 29 May 1998 19:10:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12647 for ; Fri, 29 May 1998 19:10:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22756 for ; Fri, 29 May 1998 19:12:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA19856 for ; Fri, 29 May 1998 19:10:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:06:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18749 for ipp-outgoing; Fri, 29 May 1998 19:01:08 -0400 (EDT) From: Carl Kugler To: Subject: RE: IPP> New IPP Model Document Message-ID: <5030100021109707000002L072*@MHS> Date: Fri, 29 May 1998 18:59:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12647 > Has someone identified a case where the two headers have to be > different? (I may have missed some email...) They certainly will be literally different if the client is talking directly to the origin server (Request-URI must be an abs_path URI: Relative) and IPP mandates Absolute URIs in application/ipp. Speculation: they might also be different: After TLS negotiation? Where the URIs are semantically the same but syntactically different, e.g.: - Absolute vs. Relative - host.domain vs dotted-ip - Default port specified vs. port omitted - UPPERCASE/lowercase in hostname - URI translation using equivalent escape codes After an HTTP redirect handled automatically by an HTTP layer in the client stack that doesn't know about IPP? Maybe an HTTP proxy server handles a redirect invisibly to the client? owner-ipp@pwg.org on 05/29/98 04:13:56 PM Please respond to owner-ipp@pwg.org To: jkm@underscore.com cc: ipp@pwg.org Subject: RE: IPP> New IPP Model Document Absolutely, I see the advantage of having the IPP information take precedence, I'm just not sure of the impact of having the two headers (HTTP and IPP-body) be different, and actually getting this to work in a CGI/NSAPI/ISAPI-based implementation. The generic web server will dispatch to the HTTP header-specified URI (I'm assuming, someone correct me if this is not the case). Once this dispatch occurs, the target in the HTTP header better be able to handle whatever is coming in the application/ipp body part. In this scenario, its too late to apply any precedence. Has someone identified a case where the two headers have to be different? (I may have missed some email...) Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:51 PM To: Turner, Randy Cc: ipp@pwg.org; Puru Bish Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 19:25:04 1998 Delivery-Date: Fri, 29 May 1998 19:25:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12711 for ; Fri, 29 May 1998 19:25:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22774 for ; Fri, 29 May 1998 19:27:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA20514 for ; Fri, 29 May 1998 19:25:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:21:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19983 for ipp-outgoing; Fri, 29 May 1998 19:18:38 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" Cc: ipp@pwg.org Subject: RE: IPP> review of IPP documents Date: Fri, 29 May 1998 16:20:18 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org We can recommend a different port. The point is that people can still use port 80. Making it a new method FORCES the protocol to be different and hence detectable by firewalls (the merit of this I am not discussing). The point was that we used HTTP so that it would go through proxies (definitely a good thing) as much as going through firewalls (debatable). Many proxies only carry port 80. > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Friday, May 29, 1998 3:49 PM > To: Paul Moore > Cc: 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> review of IPP documents > > > Aha the good old POST vs PRINT issue. > > > > REQUIRING a different port number would be wrong. We dont preclude this > > however (we have tested our implementations with non port 80 IPP > agents). > > I disagree. IPP is a different service than vanilla HTTP; there's > nothing wrong with having separate default ports for each, > any more than having different default ports for telnet and whois. > > (Nobody's required to prevent the use of port 80; it's just that > IPP needs its own default port assigned to it, and the IPP URI > needs to default to that port) > > I think this is cleaner overall than using a new HTTP method on port 80. > > Keith From ipp-owner@pwg.org Fri May 29 19:30:13 1998 Delivery-Date: Fri, 29 May 1998 19:30:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12724 for ; Fri, 29 May 1998 19:30:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22777 for ; Fri, 29 May 1998 19:32:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA21098 for ; Fri, 29 May 1998 19:30:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:26:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20046 for ipp-outgoing; Fri, 29 May 1998 19:21:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 29 May 1998 17:20:44 -0600 From: "Scott Isaacson" To: hastings@cp10.es.xerox.com, kugler@us.ibm.com Cc: ipp@pwg.org Subject: Re: IPP> MOD - new model document with fixes for typos and m Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12724 Carl - Yes, there is a difference between "request processing" and "job processing". This is what I tried to make clear. Do you agree with Tom's suggestion, or do we need to do something else. I propose changing the last word in Tom's new definition to In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, and validated, and that the Job object has been created; it does not indicate that the job has been (old: printed) (new: processed). >>> Tom Hastings 05/29 4:53 PM >>> A simpler clarification fix would be to delete the word "processed" in "received, validated, processed, ..." so that it would read: In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, and validated, and that the Job object has been created; it does not indicate that the job has been printed. Tom At 13:28 05/29/1998 PDT, Carl Kugler wrote: >I question this new definition: >"13.1.2.1 successful-ok (0x0000) >"The request has succeeded. In the case of a Print-Job operation, the >'successful-ok' status code indicates that the request was successfully >received, validated, processed, and that the Job object has been created; it >does not indicate that the job has been printed. The transition of the Job >object into the 'completed' state is the only indicator that the job has been >printed. > >given the definition of 'processing' in section 3.1.7: >"Job submission time is the point in time when a client issues a create >request. The initial state of every Job object is the 'pending' or >'pending-held' state. Later, the Printer object begins processing the print >job. At this point in time, the Job object's state moves to 'processing'. >This is known as job processing time. There are validation checks that must be >done at job submission time and others that must be performed at job processing >time. > >I don't believe that successful-ok (0x0000) really indicates that the request >was successfully "processed". Or at least there is the danger of confusion >here between "request processing" and "job processing". Perhaps "request >processing" needs a definition. > -Carl > > From ipp-owner@pwg.org Fri May 29 19:40:01 1998 Delivery-Date: Fri, 29 May 1998 19:40:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12777 for ; Fri, 29 May 1998 19:40:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22802 for ; Fri, 29 May 1998 19:42:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA21720 for ; Fri, 29 May 1998 19:40:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:36:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA21185 for ipp-outgoing; Fri, 29 May 1998 19:32:40 -0400 (EDT) Message-Id: <199805292332.TAA12056@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> review of IPP documents In-reply-to: Your message of "Fri, 29 May 1998 16:20:18 PDT." Date: Fri, 29 May 1998 19:32:23 -0400 Sender: owner-ipp@pwg.org Please explain why it's useful to be able to send IPP through proxies that don't act as firewalls. If you don't have a firewall in the way, why not just talk directly to the IPP server? Keith From ipp-owner@pwg.org Fri May 29 19:44:59 1998 Delivery-Date: Fri, 29 May 1998 19:44:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12788 for ; Fri, 29 May 1998 19:44:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA22808 for ; Fri, 29 May 1998 19:47:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA22315 for ; Fri, 29 May 1998 19:44:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 19:40:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA21195 for ipp-outgoing; Fri, 29 May 1998 19:35:20 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 29 May 1998 17:34:39 -0600 From: "Scott Isaacson" To: ipp@pwg.org, kugler@us.ibm.com Subject: Re: RE: IPP> New IPP Model Document Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12788 Carl, You provide good examples of why two URLs might refer to the same IPP object yet might be literally different (this gets back to the classical problems with equality - syntactically, semantically, instance vs class, type vs value, etc). Do we need to put any of them in the document as examples? Can we live with the fairly simple statement that is in the document: " 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they must both reference the same IPP object." or is the statement too simple? I also think that most of the text that I added to the model document on this subject should be moved to the encoding and transport document. The model document should not care about all of the reasons why 2 HTTP URLs might not be identical and yet refer to the "same" resource. What do you think? Scott >>> Carl Kugler 05/29 4:59 PM >>> Speculation: they might also be different: After TLS negotiation? Where the URIs are semantically the same but syntactically different, e.g.: - Absolute vs. Relative - host.domain vs dotted-ip - Default port specified vs. port omitted - UPPERCASE/lowercase in hostname - URI translation using equivalent escape codes After an HTTP redirect handled automatically by an HTTP layer in the client stack that doesn't know about IPP? Maybe an HTTP proxy server handles a redirect invisibly to the client? owner-ipp@pwg.org on 05/29/98 04:13:56 PM Please respond to owner-ipp@pwg.org To: jkm@underscore.com cc: ipp@pwg.org Subject: RE: IPP> New IPP Model Document Absolutely, I see the advantage of having the IPP information take precedence, I'm just not sure of the impact of having the two headers (HTTP and IPP-body) be different, and actually getting this to work in a CGI/NSAPI/ISAPI-based implementation. The generic web server will dispatch to the HTTP header-specified URI (I'm assuming, someone correct me if this is not the case). Once this dispatch occurs, the target in the HTTP header better be able to handle whatever is coming in the application/ipp body part. In this scenario, its too late to apply any precedence. Has someone identified a case where the two headers have to be different? (I may have missed some email...) Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:51 PM To: Turner, Randy Cc: ipp@pwg.org; Puru Bish Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 20:05:07 1998 Delivery-Date: Fri, 29 May 1998 20:05:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12858 for ; Fri, 29 May 1998 20:05:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA22836 for ; Fri, 29 May 1998 20:07:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA22966 for ; Fri, 29 May 1998 20:05:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:01:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22431 for ipp-outgoing; Fri, 29 May 1998 19:59:17 -0400 (EDT) Date: 29 May 1998 23:56:52 -0000 Message-ID: <19980529235652.1349.qmail@m1.findmail.com> From: "List Manager" Subject: IPP> Please join arabia@makelist.com Reply-To: arabia-sc.896486212.aoknhfeljinboggpngeh-ipp=pwg.org@makelist.com To: ipp@pwg.org Sender: owner-ipp@pwg.org Hi, this is an invitation to join the arabia mailing list. Here is a welcome statement provided by the list manager: --- Welcome to the Arabia.On.Line Daily Dispatch. Recently, you have expressed interest in receiving updated news and information from Arabia.On.Line via email. --- To accept this invitation, please just send any reply to this message; your mail program should have a 'reply' feature that inserts the correct subscription address automatically. Or accept by going to the following Web location: http://www.makelist.com/subscribe?email=ipp@pwg.org&list=arabia&code=7930167 If you do not wish to join, please just discard this invitation. If you have questions, please feel free to contact the manager of this list at Khaldoon@arabia.com --- A mailing list hosted at MakeList! by FindMail. From ipp-owner@pwg.org Fri May 29 20:10:09 1998 Delivery-Date: Fri, 29 May 1998 20:10:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12892 for ; Fri, 29 May 1998 20:10:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA22851 for ; Fri, 29 May 1998 20:12:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA23554 for ; Fri, 29 May 1998 20:10:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:05:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22414 for ipp-outgoing; Fri, 29 May 1998 19:56:27 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Scott Isaacson'" , ipp@pwg.org, kugler@us.ibm.com Subject: RE: RE: IPP> New IPP Model Document Date: Fri, 29 May 1998 16:56:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org It is becoming clear to me that the two URI(URLs) actually mean different things, and that each URI should be handled by different pieces of the system; the HTTP header should be handled by the outer HTTP processing code, while the inner URI should be handled by the core IPP code. Its almost like the HTTP URI is really the transport URI, and the IPP URI really points to the IPP object to which we are communicating (the application layer object). Randy -----Original Message----- From: Scott Isaacson [SMTP:SISAACSON@novell.com] Sent: Friday, May 29, 1998 4:35 PM To: ipp@pwg.org; kugler@us.ibm.com Subject: Re: RE: IPP> New IPP Model Document Carl, You provide good examples of why two URLs might refer to the same IPP object yet might be literally different (this gets back to the classical problems with equality - syntactically, semantically, instance vs class, type vs value, etc). Do we need to put any of them in the document as examples? Can we live with the fairly simple statement that is in the document: " 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they must both reference the same IPP object." or is the statement too simple? I also think that most of the text that I added to the model document on this subject should be moved to the encoding and transport document. The model document should not care about all of the reasons why 2 HTTP URLs might not be identical and yet refer to the "same" resource. What do you think? Scott >>> Carl Kugler 05/29 4:59 PM >>> Speculation: they might also be different: After TLS negotiation? Where the URIs are semantically the same but syntactically different, e.g.: - Absolute vs. Relative - host.domain vs dotted-ip - Default port specified vs. port omitted - UPPERCASE/lowercase in hostname - URI translation using equivalent escape codes After an HTTP redirect handled automatically by an HTTP layer in the client stack that doesn't know about IPP? Maybe an HTTP proxy server handles a redirect invisibly to the client? owner-ipp@pwg.org on 05/29/98 04:13:56 PM Please respond to owner-ipp@pwg.org To: jkm@underscore.com cc: ipp@pwg.org Subject: RE: IPP> New IPP Model Document Absolutely, I see the advantage of having the IPP information take precedence, I'm just not sure of the impact of having the two headers (HTTP and IPP-body) be different, and actually getting this to work in a CGI/NSAPI/ISAPI-based implementation. The generic web server will dispatch to the HTTP header-specified URI (I'm assuming, someone correct me if this is not the case). Once this dispatch occurs, the target in the HTTP header better be able to handle whatever is coming in the application/ipp body part. In this scenario, its too late to apply any precedence. Has someone identified a case where the two headers have to be different? (I may have missed some email...) Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:51 PM To: Turner, Randy Cc: ipp@pwg.org; Puru Bish Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 20:33:36 1998 Delivery-Date: Fri, 29 May 1998 20:33:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13015 for ; Fri, 29 May 1998 20:33:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA22889 for ; Fri, 29 May 1998 20:35:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25141 for ; Fri, 29 May 1998 20:33:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:29:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA24573 for ipp-outgoing; Fri, 29 May 1998 20:23:24 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" Cc: ipp@pwg.org Subject: RE: IPP> review of IPP documents Date: Fri, 29 May 1998 17:25:07 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Typically (take MS for example). The firewall and the proxy are quite differnt things. The proxy is an enabler and the firewall is a protector. None of our internal network has 'real' IP addresses -I can, however use our proxies to browse anywhere on the net. Our firewall has the task of prtecting only a limited number of servers that are connected to the Internet (mail gateways fore xample and the proxies). today I can use IPP from my desktop machine to print to an IPP printer on the INternet using our proxy. If I were to move to a different port then I would not be able to do this - most proxies only work with a defined set of protocols on well-known ports (HTTP, FTP mainly) > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Friday, May 29, 1998 4:32 PM > To: Paul Moore > Cc: 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> review of IPP documents > > Please explain why it's useful to be able to send IPP through > proxies that don't act as firewalls. If you don't have a firewall > in the way, why not just talk directly to the IPP server? > > Keith From ipp-owner@pwg.org Fri May 29 20:40:14 1998 Delivery-Date: Fri, 29 May 1998 20:40:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13035 for ; Fri, 29 May 1998 20:40:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA22905 for ; Fri, 29 May 1998 20:42:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25737 for ; Fri, 29 May 1998 20:40:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:36:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA24820 for ipp-outgoing; Fri, 29 May 1998 20:31:09 -0400 (EDT) Message-Id: <199805300030.UAA12326@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> review of IPP documents In-reply-to: Your message of "Fri, 29 May 1998 17:25:07 PDT." Date: Fri, 29 May 1998 20:30:50 -0400 Sender: owner-ipp@pwg.org > Typically (take MS for example). The firewall and the proxy are quite > differnt things. The proxy is an enabler and the firewall is a protector. okay...slightly different use of terminology. insisting on IPP using port 80 just to be able to tunnel through firewalls/proxies simply will not fly ...it leads to an arms race. (not to mention that everybody will want to use port 80, which is clearly unworkable) if your employer wants you to be able to use external printers, they can punch a hole in their firewall, or add a proxy, to allow you to talk to the default IPP port. we can't let the existence of NAT boxes dictate the whole architecture. Keith From ipp-owner@pwg.org Fri May 29 20:45:21 1998 Delivery-Date: Fri, 29 May 1998 20:45:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA13063 for ; Fri, 29 May 1998 20:45:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA22921 for ; Fri, 29 May 1998 20:47:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA26333 for ; Fri, 29 May 1998 20:45:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:41:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25632 for ipp-outgoing; Fri, 29 May 1998 20:39:26 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" Cc: ipp@pwg.org Subject: RE: IPP> review of IPP documents Date: Fri, 29 May 1998 17:41:07 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org You miss the point - I agree totally about the penetration issue. I think this is a bad reason for doing anything. The proxy issue is quite different - the most common scenario in commercial networks is that the users are not connected to the Internet at all (hence firewalls dont enter the debate). Proxies enable these users to access internet resources. (this is not a terminology issue - they are fundamentally differnt things). By making IPP use http:80 then IPP printer become another Internet resource accessible via my proxy. Punching a hole in the firewall is missing the point - they can do whatever they like to the firewall - it does not change what I can access from my desktop. My PC can only reach those things that my proxy knows how to deal with. If I took the proxy away I could not reach anything. This is the inverse case from the case where my desktop is connected to the internet via a firewall - I you take the firewall out of the loop I would be able to do anything. I cannot ping your machine from my desktop, this has nothing to do with the MS firewall settings. > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Friday, May 29, 1998 5:31 PM > To: Paul Moore > Cc: 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> review of IPP documents > > > Typically (take MS for example). The firewall and the proxy are quite > > differnt things. The proxy is an enabler and the firewall is a > protector. > > okay...slightly different use of terminology. > > insisting on IPP using port 80 just to be able to tunnel through > firewalls/proxies simply will not fly ...it leads to an arms race. > (not to mention that everybody will want to use port 80, which > is clearly unworkable) > > if your employer wants you to be able to use external printers, > they can punch a hole in their firewall, or add a proxy, to > allow you to talk to the default IPP port. > > we can't let the existence of NAT boxes dictate the whole architecture. > > Keith From ipp-owner@pwg.org Fri May 29 21:00:07 1998 Delivery-Date: Fri, 29 May 1998 21:00:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA13098 for ; Fri, 29 May 1998 21:00:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA22959 for ; Fri, 29 May 1998 21:02:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA26970 for ; Fri, 29 May 1998 21:00:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 20:56:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26444 for ipp-outgoing; Fri, 29 May 1998 20:52:37 -0400 (EDT) Message-Id: <199805300052.UAA12530@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> review of IPP documents In-reply-to: Your message of "Fri, 29 May 1998 17:41:07 PDT." Date: Fri, 29 May 1998 20:52:20 -0400 Sender: owner-ipp@pwg.org You miss the point. The fact that people already have port 80 proxies installed doesn't matter. There's no way that we're going to standardize IPP on port 80 - HTTP already has that port, and IPP is a different service than HTTP. Once upon a time, a lot of people had email only access to the Internet. That wasn't an good reason for forcing every service to run over email. Keith From ipp-owner@pwg.org Fri May 29 21:36:12 1998 Delivery-Date: Fri, 29 May 1998 21:36:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA13206 for ; Fri, 29 May 1998 21:36:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA23068 for ; Fri, 29 May 1998 21:38:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA27653 for ; Fri, 29 May 1998 21:36:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 21:31:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27104 for ipp-outgoing; Fri, 29 May 1998 21:28:47 -0400 (EDT) Message-ID: <356F60C4.6FFE4154@underscore.com> Date: Fri, 29 May 1998 21:28:36 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org Subject: Re: IPP> New IPP Model Document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Randy, > It is becoming clear to me that the two URI(URLs) actually mean > different things, and that each URI should be handled by different > pieces of the system; the HTTP header should be handled by the outer > HTTP processing code, while the inner URI should be handled by the core > IPP code. Its almost like the HTTP URI is really the transport URI, and > the IPP URI really points to the IPP object to which we are > communicating (the application layer object). Ok, then I guess we're back to Puru's basic inquiry revolving around precedence between the two URLs. Based on your above statement, it sounds like we must have NO precedence whatsoever, right? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri May 29 21:55:07 1998 Delivery-Date: Fri, 29 May 1998 21:55:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA13257 for ; Fri, 29 May 1998 21:55:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA23108 for ; Fri, 29 May 1998 21:57:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28259 for ; Fri, 29 May 1998 21:55:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 29 May 1998 21:51:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27741 for ipp-outgoing; Fri, 29 May 1998 21:50:39 -0400 (EDT) Date: Fri, 29 May 1998 18:49:12 -0700 (PDT) From: Ned Freed Subject: Re: IPP> review of IPP documents In-reply-to: "Your message dated Fri, 29 May 1998 20:52:20 -0400" <199805300052.UAA12530@spot.cs.utk.edu> To: Keith Moore Cc: Paul Moore , "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Message-id: <01IXM6R8X7328WWC78@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: Sender: owner-ipp@pwg.org > You miss the point. The fact that people already have port 80 proxies > installed doesn't matter. There's no way that we're going to standardize > IPP on port 80 - HTTP already has that port, and IPP is a different > service than HTTP. > Once upon a time, a lot of people had email only access to the Internet. > That wasn't an good reason for forcing every service to run over email. My favorite example is email over FTP. We'd still be doing email that way if we hadn't deployed a new email service on a separate port. Ned From ipp-owner@pwg.org Sat May 30 00:52:32 1998 Delivery-Date: Sat, 30 May 1998 00:52:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA21015 for ; Sat, 30 May 1998 00:52:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA23423 for ; Sat, 30 May 1998 00:54:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA29779 for ; Sat, 30 May 1998 00:52:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 May 1998 00:46:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29234 for ipp-outgoing; Sat, 30 May 1998 00:42:53 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Jay Martin '" , "Turner, Randy" Cc: "'ipp@pwg.org '" Subject: RE: IPP> New IPP Model Document Date: Fri, 29 May 1998 21:43:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org I think in the case of IPP behind a generic web server, the two headers are entirely different, and precedence does not apply. I'm pretty sure it applies in all cases, even a dedicated IPP/HTTP server, but give me the weekend to mull it over ;) Randy -----Original Message----- From: Jay Martin To: Turner, Randy Cc: ipp@pwg.org Sent: 5/29/98 6:28 PM Subject: Re: IPP> New IPP Model Document Randy, > It is becoming clear to me that the two URI(URLs) actually mean > different things, and that each URI should be handled by different > pieces of the system; the HTTP header should be handled by the outer > HTTP processing code, while the inner URI should be handled by the core > IPP code. Its almost like the HTTP URI is really the transport URI, and > the IPP URI really points to the IPP object to which we are > communicating (the application layer object). Ok, then I guess we're back to Puru's basic inquiry revolving around precedence between the two URLs. Based on your above statement, it sounds like we must have NO precedence whatsoever, right? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Sat May 30 02:51:02 1998 Delivery-Date: Sat, 30 May 1998 02:51:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA25208 for ; Sat, 30 May 1998 02:51:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA23672 for ; Sat, 30 May 1998 02:53:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA00589 for ; Sat, 30 May 1998 02:51:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 30 May 1998 02:46:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA29990 for ipp-outgoing; Sat, 30 May 1998 02:44:07 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CD83@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Keith Moore'" , Paul Moore Cc: ipp@pwg.org Subject: RE: IPP> review of IPP documents Date: Fri, 29 May 1998 23:45:56 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think there is a disconnect here. Its perfectly legitimate for IPP to have a default port other than 80. That default port refers to the dest port on an IPP server/printer. This is the case for HTTP. The proxy service port is independent of the IPP URI as well as the IPP default port. It really seems that HTTP based proxy services proxy more than just HTTP. HTTP proxy services arent standardized on port 80. If there is a 'defacto standard' I would say it is 8080, as coined by Ari Luotonen, the original author of the CERN HTTPD Proxy. Today, common practice is that this HTTP based proxy service on port 8080 (or whatever an org chooses to configure their clients with) does more than proxy HTTP. Most proxies can proxy FTP, SSL via CONNECT, gopher, and some others. If your behind a proxy and you FTP a file with a browser, your speaking HTTP proxy 'protocol' from your client to the proxy, and FTP from the proxy to the FTP server.. While Microsoft may use port 80, having been at other places, its my impression that the standard proxy services are not 80, but 8080. This means nothing, however, the default port of IPP will not affect its ability to go through proxies. The http based "proxy service" should be considered its own default port as well. Given an IPP URI: http://myprinter.com:9999/printer5 Pretty much any proxy will pass this. The port that the proxy is listening on is indicated in the proxy settings, and is independent of the actual protocol destination. The main place where trouble can be found I can think of is when a filtering firewall (not proxy) is used and it only allows traffic on port 80. As time moves on, and more and more URLS refer to other ports than 80, this type of firewall IMHO has become less popular in favor of proxy servers. So, my beleif is that picking a new standard destination port for IPP will make no difference in its ability to be passed (and filtered) by proxy servers. This is just the same as why picking a method other than POST is also possible with todays proxies, but thats another discussion.. :) > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, May 29, 1998 5:52 PM > To: Paul Moore > Cc: 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> review of IPP documents > > > You miss the point. The fact that people already have port 80 proxies > installed doesn't matter. There's no way that we're going to > standardize > IPP on port 80 - HTTP already has that port, and IPP is a different > service than HTTP. > > Once upon a time, a lot of people had email only access to > the Internet. > That wasn't an good reason for forcing every service to run > over email. > > Keith > From ipp-owner@pwg.org Mon Jun 1 11:12:46 1998 Delivery-Date: Mon, 01 Jun 1998 11:12:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26559 for ; Mon, 1 Jun 1998 11:12:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03106 for ; Mon, 1 Jun 1998 11:14:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA04570 for ; Mon, 1 Jun 1998 11:12:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 11:01:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03985 for ipp-outgoing; Mon, 1 Jun 1998 10:59:14 -0400 (EDT) From: Carl Kugler To: Subject: Re: IPP> MOD - new model document with fixes for typos and m Message-ID: <5030100021169467000002L072*@MHS> Date: Mon, 1 Jun 1998 10:58:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26559 I quite agree. -Carl owner-ipp@pwg.org on 05/29/98 05:03:59 PM Please respond to owner-ipp@pwg.org To: Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org Subject: Re: IPP> MOD - new model document with fixes for typos and m A simpler clarification fix would be to delete the word "processed" in "received, validated, processed, ..." so that it would read: In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, and validated, and that the Job object has been created; it does not indicate that the job has been printed. Tom At 13:28 05/29/1998 PDT, Carl Kugler wrote: >I question this new definition: >"13.1.2.1 successful-ok (0x0000) >"The request has succeeded. In the case of a Print-Job operation, the >'successful-ok' status code indicates that the request was successfully >received, validated, processed, and that the Job object has been created; it >does not indicate that the job has been printed. The transition of the Job >object into the 'completed' state is the only indicator that the job has been >printed. > >given the definition of 'processing' in section 3.1.7: >"Job submission time is the point in time when a client issues a create >request. The initial state of every Job object is the 'pending' or >'pending-held' state. Later, the Printer object begins processing the print >job. At this point in time, the Job object's state moves to 'processing'. >This is known as job processing time. There are validation checks that must be >done at job submission time and others that must be performed at job processing >time. > >I don't believe that successful-ok (0x0000) really indicates that the request >was successfully "processed". Or at least there is the danger of confusion >here between "request processing" and "job processing". Perhaps "request >processing" needs a definition. > -Carl > > From ipp-owner@pwg.org Mon Jun 1 11:29:08 1998 Delivery-Date: Mon, 01 Jun 1998 11:29:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26756 for ; Mon, 1 Jun 1998 11:29:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03312 for ; Mon, 1 Jun 1998 11:31:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA05173 for ; Mon, 1 Jun 1998 11:29:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 11:25:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04257 for ipp-outgoing; Mon, 1 Jun 1998 11:06:28 -0400 (EDT) From: Carl Kugler To: Cc: , Subject: Re: IPP> MOD - new model document with fixes for typos and m Message-ID: <5030100021169828000002L082*@MHS> Date: Mon, 1 Jun 1998 11:04:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26756 If "request processing" is a significant concept not covered by "received, and validated, and ... Job object has been created", then I think it needs a definition. I myself don't know what it means (but I understand that it is distinct from "job processing"). -Carl SISAACSON@novell.com on 05/29/98 05:21:57 PM Please respond to SISAACSON@novell.com To: Carl Kugler/Boulder/IBM@ibmus, hastings@cp10.es.xerox.com cc: ipp@pwg.org Subject: Re: IPP> MOD - new model document with fixes for typos and m Carl - Yes, there is a difference between "request processing" and "job processing". This is what I tried to make clear. Do you agree with Tom's suggestion, or do we need to do something else. I propose changing the last word in Tom's new definition to In the case of a Print-Job operation, the 'successful-ok' status code indicates that the request was successfully received, and validated, and that the Job object has been created; it does not indicate that the job has been (old: printed) (new: processed) From ipp-owner@pwg.org Mon Jun 1 12:36:13 1998 Delivery-Date: Mon, 01 Jun 1998 12:36:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA27619 for ; Mon, 1 Jun 1998 12:36:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03710 for ; Mon, 1 Jun 1998 12:38:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA06878 for ; Mon, 1 Jun 1998 12:36:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 12:31:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06349 for ipp-outgoing; Mon, 1 Jun 1998 12:30:00 -0400 (EDT) Message-ID: From: Paul Moore To: "'Ned Freed'" , Keith Moore Cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: RE: IPP> review of IPP documents Date: Mon, 1 Jun 1998 09:32:05 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Excellent point. So why the heck are we using HTTP for IPP? > -----Original Message----- > From: Ned Freed [SMTP:Ned.Freed@innosoft.com] > Sent: Friday, May 29, 1998 6:49 PM > To: Keith Moore > Cc: Paul Moore; 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> review of IPP documents > > > You miss the point. The fact that people already have port 80 proxies > > installed doesn't matter. There's no way that we're going to > standardize > > IPP on port 80 - HTTP already has that port, and IPP is a different > > service than HTTP. > > > Once upon a time, a lot of people had email only access to the Internet. > > That wasn't an good reason for forcing every service to run over email. > > My favorite example is email over FTP. We'd still be doing email that way > if we hadn't deployed a new email service on a separate port. > > Ned From ipp-owner@pwg.org Mon Jun 1 13:31:11 1998 Delivery-Date: Mon, 01 Jun 1998 13:31:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA28111 for ; Mon, 1 Jun 1998 13:31:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04007 for ; Mon, 1 Jun 1998 13:33:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA07979 for ; Mon, 1 Jun 1998 13:31:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 13:26:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA07431 for ipp-outgoing; Mon, 1 Jun 1998 13:22:22 -0400 (EDT) Message-Id: <3.0.5.32.19980601102001.00a0b510@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 1 Jun 1998 10:20:01 PDT To: http-wg@cuckoo.hpl.hp.com From: Carl-Uno Manros Subject: IPP> Implications of introducing new scheme and port for existing HTTP servers Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi, As most of you know already, the Internet Printing Protocol (IPP) WG has suggested using HTTP as "transport", with the payload in the form of a MIME object passed with the POST method. As part of the onging IESG review process, the Application Area Director Keith Moore has suggested to distinguish IPP traffic from "normal" HTTP traffic by: 1) the introduction of a new scheme called "ipp" 2) the introduction a new default port number for IPP servers. Before the IPP WG responds to those suggestions, the IPP WG would like to get some advice from the HTTP WG on the implications of such a change. In particular, we want some feedback on how easy or difficult it would be to configure existing web servers to accomodate the suggested changes. Please note that many printer vendors are not in the business of developing web servers or HTTP servers and are dependent on getting those compoments from other vendors. Please respond back to the IPP DL at: ipp@pwg.org Thanks, Carl-Uno Manros Chair of the IETF IPP WG From ipp-owner@pwg.org Mon Jun 1 13:44:40 1998 Delivery-Date: Mon, 01 Jun 1998 13:44:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA28289 for ; Mon, 1 Jun 1998 13:44:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04067 for ; Mon, 1 Jun 1998 13:47:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA08693 for ; Mon, 1 Jun 1998 13:44:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 13:40:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08067 for ipp-outgoing; Mon, 1 Jun 1998 13:32:43 -0400 (EDT) Date: Mon, 1 Jun 1998 10:31:03 -0700 From: hardie@thornhill.arc.nasa.gov (Ted Hardie) Message-Id: <9806011031.ZM8242@thornhill.arc.nasa.gov> In-Reply-To: Carl-Uno Manros "Implications of introducing new scheme and port for existing HTTP servers" (Jun 1, 10:20am) References: <3.0.5.32.19980601102001.00a0b510@garfield> Reply-To: hardie@nic.nasa.gov X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Carl-Uno Manros , http-wg@hplb.hpl.hp.com Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipp@pwg.org Carl-Uno, By "scheme" in the text below, do you mean a new HTTP method, parallel to GET and POST, or something else? regards, Ted Hardie NASA NIC > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult it would be > to configure existing web servers to accomodate the suggested changes. From ipp-owner@pwg.org Mon Jun 1 13:59:28 1998 Delivery-Date: Mon, 01 Jun 1998 13:59:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA28475 for ; Mon, 1 Jun 1998 13:59:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04175 for ; Mon, 1 Jun 1998 14:01:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09346 for ; Mon, 1 Jun 1998 13:59:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 13:55:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08789 for ipp-outgoing; Mon, 1 Jun 1998 13:49:59 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CDA4@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'hardie@nic.nasa.gov'" , Carl-Uno Manros , http-wg@hplb.hpl.hp.com Cc: ipp@pwg.org, "'moore@cs.utk.edu'" Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Date: Mon, 1 Jun 1998 10:51:56 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think its fine to have a new default dest port associated with IPP, but a new URL scheme seems like more trouble than may be apparent. For one, even though IPP is a different service than HTTP, an IPP client *is* speaking HTTP, IMHO. HTTP is used as a layer underneath IPP. So, I think the URL scheme should continue to be http://.. Using a new URL scheme will certainly break compatibility with existing proxies. Proxy server's encountering a new scheme will fail unless they are modified to understand it. As I've stated before, I think the best way to differentiate the service and remain compatible with existing proxy servers is to use a new method on the request line. > -----Original Message----- > From: hardie@thornhill.arc.nasa.gov > [mailto:hardie@thornhill.arc.nasa.gov] > Sent: Monday, June 01, 1998 10:31 AM > To: Carl-Uno Manros; http-wg@hplb.hpl.hp.com > Cc: ipp@pwg.org > Subject: IPP> Re: Implications of introducing new scheme and port for > existing HTTP servers > > > Carl-Uno, > By "scheme" in the text below, do you mean a > new HTTP method, parallel to GET and POST, or something > else? > regards, > Ted Hardie > NASA NIC > > > 1) the introduction of a new scheme called "ipp" > > 2) the introduction a new default port number for IPP servers. > > > > Before the IPP WG responds to those suggestions, the IPP WG > would like to > > get some advice from the HTTP WG on the implications of > such a change. > > In particular, we want some feedback on how easy or > difficult it would be > > to configure existing web servers to accomodate the > suggested changes. > From ipp-owner@pwg.org Mon Jun 1 14:06:07 1998 Delivery-Date: Mon, 01 Jun 1998 14:06:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28560 for ; Mon, 1 Jun 1998 14:06:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04202 for ; Mon, 1 Jun 1998 14:08:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09970 for ; Mon, 1 Jun 1998 14:06:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 14:01:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09198 for ipp-outgoing; Mon, 1 Jun 1998 13:58:13 -0400 (EDT) Message-Id: <3.0.5.32.19980601103614.00a17630@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 1 Jun 1998 10:36:14 PDT To: hardie@nic.nasa.gov, http-wg@hplb.hpl.hp.com From: Carl-Uno Manros Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Cc: ipp@pwg.org In-Reply-To: <9806011031.ZM8242@thornhill.arc.nasa.gov> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: <3.0.5.32.19980601102001.00a0b510@garfield> ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org By scheme in this context is meant "ipp" vs. "htpp" or "ftp". Carl-Uno At 10:31 AM 6/1/98 PDT, Ted Hardie wrote: >Carl-Uno, > By "scheme" in the text below, do you mean a >new HTTP method, parallel to GET and POST, or something >else? > regards, > Ted Hardie > NASA NIC > >> 1) the introduction of a new scheme called "ipp" >> 2) the introduction a new default port number for IPP servers. >> >> Before the IPP WG responds to those suggestions, the IPP WG would like to >> get some advice from the HTTP WG on the implications of such a change. >> In particular, we want some feedback on how easy or difficult it would be >> to configure existing web servers to accomodate the suggested changes. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 1 14:15:00 1998 Delivery-Date: Mon, 01 Jun 1998 14:15:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28614 for ; Mon, 1 Jun 1998 14:15:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04247 for ; Mon, 1 Jun 1998 14:17:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10650 for ; Mon, 1 Jun 1998 14:15:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 14:10:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09429 for ipp-outgoing; Mon, 1 Jun 1998 14:01:56 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Re: Implications of introducing new scheme and port for existin g HTTP servers Date: Mon, 1 Jun 1998 11:02:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org If this gets down to a point where we HAVE to modify our specification, then I agree with Josh, it would be much better to differentiate based on HTTP method than on URL scheme, (IMHO). (But I think its ok as it stands now) Randy -----Original Message----- From: Josh Cohen [SMTP:joshco@MICROSOFT.com] Sent: Monday, June 01, 1998 10:54 AM To: 'http-wg@cuckoo.hpl.hp.com' Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers I think its fine to have a new default dest port associated with IPP, but a new URL scheme seems like more trouble than may be apparent. For one, even though IPP is a different service than HTTP, an IPP client *is* speaking HTTP, IMHO. HTTP is used as a layer underneath IPP. So, I think the URL scheme should continue to be http://. . Using a new URL scheme will certainly break compatibility with existing proxies. Proxy server's encountering a new scheme will fail unless they are modified to understand it. As I've stated before, I think the best way to differentiate the service and remain compatible with existing proxy servers is to use a new method on the request line. > From ipp-owner@pwg.org Mon Jun 1 14:19:47 1998 Delivery-Date: Mon, 01 Jun 1998 14:19:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28672 for ; Mon, 1 Jun 1998 14:19:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04275 for ; Mon, 1 Jun 1998 14:22:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA11248 for ; Mon, 1 Jun 1998 14:19:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 14:15:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA10036 for ipp-outgoing; Mon, 1 Jun 1998 14:06:29 -0400 (EDT) Message-Id: <3.0.5.32.19980601105604.009e0440@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 1 Jun 1998 10:56:04 PDT To: ipp@pwg.org From: Josh Cohen (by way of Carl-Uno Manros ) Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I think its fine to have a new default dest port associated with IPP, but a new URL scheme seems like more trouble than may be apparent. For one, even though IPP is a different service than HTTP, an IPP client *is* speaking HTTP, IMHO. HTTP is used as a layer underneath IPP. So, I think the URL scheme should continue to be http://.. Using a new URL scheme will certainly break compatibility with existing proxies. Proxy server's encountering a new scheme will fail unless they are modified to understand it. As I've stated before, I think the best way to differentiate the service and remain compatible with existing proxy servers is to use a new method on the request line. > -----Original Message----- > From: hardie@thornhill.arc.nasa.gov > [mailto:hardie@thornhill.arc.nasa.gov] > Sent: Monday, June 01, 1998 10:31 AM > To: Carl-Uno Manros; http-wg@hplb.hpl.hp.com > Cc: ipp@pwg.org > Subject: IPP> Re: Implications of introducing new scheme and port for > existing HTTP servers > > > Carl-Uno, > By "scheme" in the text below, do you mean a > new HTTP method, parallel to GET and POST, or something > else? > regards, > Ted Hardie > NASA NIC > > > 1) the introduction of a new scheme called "ipp" > > 2) the introduction a new default port number for IPP servers. > > > > Before the IPP WG responds to those suggestions, the IPP WG > would like to > > get some advice from the HTTP WG on the implications of > such a change. > > In particular, we want some feedback on how easy or > difficult it would be > > to configure existing web servers to accomodate the > suggested changes. > From ipp-owner@pwg.org Mon Jun 1 15:01:25 1998 Delivery-Date: Mon, 01 Jun 1998 15:01:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29124 for ; Mon, 1 Jun 1998 15:01:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04539 for ; Mon, 1 Jun 1998 15:03:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11975 for ; Mon, 1 Jun 1998 15:01:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 14:56:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11438 for ipp-outgoing; Mon, 1 Jun 1998 14:54:19 -0400 (EDT) From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com X-OpenMail-Hops: 1 Date: Mon, 1 Jun 1998 11:53:53 -0700 Message-Id: In-Reply-To: <3.0.5.32.19980601102001.00a0b510@garfield> Subject: Re: IPP> Implications of introducing new scheme and port f MIME-Version: 1.0 TO: manros@cp10.es.xerox.com CC: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="IPP>" Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Regarding item #2, Use of alternative HTTP ports, other than port 80, effects the ability to move through proxies and firewalls. Using alternative port #'s will require reconfiguration of security infrastructure in order to allow for HTTP connections. HP has gone through similar work in the definition and standardization of HTTP port 280 for Web Based Management Purposes ( see IANA port list ). Currently port 280 is IANA approved for usage of HTTP for network management. This works fine for Intranet usage, but issues as described above result when operating in a secure environments. The other issue is that of configuring HTTP servers and proxies to listen on alternative port #s. While easy to do programatically, not all commercial HTTP servers allow listening on multiple ports concurrently. Considering these two issues, partitioning of the URI space for IPP on HTTP port 80 or HTTP-S (HTTP/(SSL |TLS)) on port 443 makes better sense. Peter ______________________________ Reply Separator _________________________________ Subject: IPP> Implications of introducing new scheme and port for e Author: Non-HP-manros (manros@cp10.es.xerox.com) at HP-Roseville,mimegw4 Date: 6/1/98 10:20 AM Hi, As most of you know already, the Internet Printing Protocol (IPP) WG has suggested using HTTP as "transport", with the payload in the form of a MIME object passed with the POST method. As part of the onging IESG review process, the Application Area Director Keith Moore has suggested to distinguish IPP traffic from "normal" HTTP traffic by: 1) the introduction of a new scheme called "ipp" 2) the introduction a new default port number for IPP servers. Before the IPP WG responds to those suggestions, the IPP WG would like to get some advice from the HTTP WG on the implications of such a change. In particular, we want some feedback on how easy or difficult it would be to configure existing web servers to accomodate the suggested changes. Please note that many printer vendors are not in the business of developing web servers or HTTP servers and are dependent on getting those compoments from other vendors. Please respond back to the IPP DL at: ipp@pwg.org Thanks, Carl-Uno Manros Chair of the IETF IPP WG From ipp-owner@pwg.org Mon Jun 1 15:26:25 1998 Delivery-Date: Mon, 01 Jun 1998 15:26:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29394 for ; Mon, 1 Jun 1998 15:26:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04664 for ; Mon, 1 Jun 1998 15:28:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13188 for ; Mon, 1 Jun 1998 15:26:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 15:17:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12114 for ipp-outgoing; Mon, 1 Jun 1998 15:10:38 -0400 (EDT) Message-ID: <3572FC93.5825C2B@underscore.com> Date: Mon, 01 Jun 1998 15:10:11 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Josh Cohen CC: ipp@pwg.org Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers References: <8B57882C41A0D1118F7100805F9F68B502D2CDA4@red-msg-45.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Josh, > Using a new URL scheme will certainly break compatibility > with existing proxies. Proxy server's encountering a new > scheme will fail unless they are modified to understand it. > > As I've stated before, I think the best way to differentiate > the service and remain compatible with existing proxy servers > is to use a new method on the request line. How would a typical proxy server deal with a new method? (Please forgive my ignorance here.) Or do proxies handle data entirely by port number such that the proxied request is opaque? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Jun 1 15:28:38 1998 Delivery-Date: Mon, 01 Jun 1998 15:28:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29408 for ; Mon, 1 Jun 1998 15:28:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04667 for ; Mon, 1 Jun 1998 15:31:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA13560 for ; Mon, 1 Jun 1998 15:28:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 15:18:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12069 for ipp-outgoing; Mon, 1 Jun 1998 15:02:09 -0400 (EDT) Date: Mon, 1 Jun 1998 15:01:56 -0400 (EDT) From: Scott Lawrence To: ipp@pwg.org Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: <3.0.5.32.19980601102001.00a0b510@garfield> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org On Mon, 1 Jun 1998, Carl-Uno Manros wrote: > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult it would be > to configure existing web servers to accomodate the suggested changes. Answering for EmWeb, our embedded web server: The new scheme (1) would require a very minor change from our existing product, which requires that he scheme be 'http' if it is present at all. We'd need to allow 'ipp', and perhaps add a check to ensure that it is being used on the proper port (if that is deemed to be important). If the client does not send the scheme, then there would be no change. The new port (2) would be no change at all, since it can already operate on any port. One might wish to recognize that the default port for an 'ipp:' scheme redirect would be different than for an 'http:' redirect, but that's a very minor matter. From ipp-owner@pwg.org Mon Jun 1 15:56:42 1998 Delivery-Date: Mon, 01 Jun 1998 15:56:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29654 for ; Mon, 1 Jun 1998 15:56:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04813 for ; Mon, 1 Jun 1998 15:59:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA14365 for ; Mon, 1 Jun 1998 15:56:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 15:51:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13786 for ipp-outgoing; Mon, 1 Jun 1998 15:50:03 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CDAD@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com'" , manros@cp10.es.xerox.com Cc: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org Subject: RE: IPP> Implications of introducing new scheme and port f Date: Mon, 1 Jun 1998 12:52:07 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org To restate, I disagree. Standardizing a default destination port for IPP doesnt affect routing through proxy servers. The proxy listening port doesnt need to change. Just like when doing 'normal' http, the proxy listening port has nothing to do with the destination port in the URL. If you have a URL: http://mywebserver.domain.com:8000/index.html or http://myprinter:5150/queue1/ and a proxy setting of http://myproxy:8080/ the proxy's listening port typically is 8080 or 80, but does not matter. The client http library knows via some config setting which port and host to connect to when speaking the 'http proxy mechanism'. The only restraint is if your proxy is configured to restrict URLS to only port 80. eg proxied URLs of the type: http://server/index.html or http://server:80/index.html which due to the popularity of servers running on ports other than 80 (perhaps for a user non-root server on a unix machine), is difficult to maintain. > -----Original Message----- > From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com > [mailto:PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com] > Sent: Monday, June 01, 1998 11:54 AM > To: manros@cp10.es.xerox.com > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org > Subject: Re: IPP> Implications of introducing new scheme and port f > > > Regarding item #2, > > Use of alternative HTTP ports, other than port 80, > effects the ability > to move through proxies and firewalls. Using alternative > port #'s will > require reconfiguration of security infrastructure in > order to allow > for HTTP connections. > > HP has gone through similar work in the definition and > standardization > of HTTP port 280 for Web Based Management Purposes ( see > IANA port > list ). Currently port 280 is IANA approved for usage of > HTTP for > network management. This works fine for Intranet usage, > but issues as > described above result when operating in a secure environments. > > The other issue is that of configuring HTTP servers and > proxies to > listen on alternative port #s. While easy to do > programatically, not > all commercial HTTP servers allow listening on multiple ports > concurrently. > > Considering these two issues, partitioning of the URI > space for IPP on > HTTP port 80 or HTTP-S (HTTP/(SSL |TLS)) on port 443 > makes better > sense. > > Peter > > > ______________________________ Reply Separator > _________________________________ > Subject: IPP> Implications of introducing new scheme and port for e > Author: Non-HP-manros (manros@cp10.es.xerox.com) at > HP-Roseville,mimegw4 > Date: 6/1/98 10:20 AM > > > Hi, > > As most of you know already, the Internet Printing Protocol > (IPP) WG has > suggested using HTTP as "transport", with the payload in the > form of a MIME > object passed with the POST method. > > As part of the onging IESG review process, the Application > Area Director > Keith Moore has suggested to distinguish IPP traffic from > "normal" HTTP > traffic by: > > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG > would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult > it would be > to configure existing web servers to accomodate the suggested changes. > > Please note that many printer vendors are not in the business > of developing > web servers or HTTP servers and are dependent on getting > those compoments > from other vendors. > > Please respond back to the IPP DL at: > > ipp@pwg.org > > Thanks, > > Carl-Uno Manros > Chair of the IETF IPP WG > From ipp-owner@pwg.org Mon Jun 1 16:51:22 1998 Delivery-Date: Mon, 01 Jun 1998 16:51:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA01641 for ; Mon, 1 Jun 1998 16:51:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05065 for ; Mon, 1 Jun 1998 16:53:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA15191 for ; Mon, 1 Jun 1998 16:51:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 16:47:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14616 for ipp-outgoing; Mon, 1 Jun 1998 16:42:17 -0400 (EDT) Message-Id: <3.0.1.32.19980601120222.00afd100@mail2.cp10.es.xerox.com> X-Sender: xriley@mail2.cp10.es.xerox.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 1 Jun 1998 12:02:22 PDT To: ipp@pwg.org From: "Xavier D. Riley" Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I agree with Randy. My preference order would be the following: 1) Leave as currently specified 2) Use new http method(s) instead of POST 3) Use new "ipp:" scheme instead of http (least desirable and major deployment issues in my opinion) --Xavier At 11:02 AM 6/1/98 PDT, you wrote: > > > >If this gets down to a point where we HAVE to modify our specification, >then I agree with Josh, it would be much better to differentiate based >on HTTP method than on URL scheme, (IMHO). (But I think its ok as it >stands now) >Randy > > -----Original Message----- > From: Josh Cohen [SMTP:joshco@MICROSOFT.com] > > Sent: Monday, June 01, 1998 10:54 AM > To: 'http-wg@cuckoo.hpl.hp.com' > Subject: RE: IPP> Re: Implications of introducing new > scheme and port for existing HTTP servers > >I think its fine to have a new default dest port associated with IPP, >but a new URL scheme seems like more trouble than may be apparent. >For one, even though IPP is a different service than HTTP, an IPP client >*is* speaking HTTP, IMHO. HTTP is used as a layer underneath IPP. So, >I think the URL scheme should continue to be http://. . >Using a new URL scheme will certainly break compatibility with existing >proxies. Proxy server's encountering a new scheme will fail unless they >are modified to understand it. >As I've stated before, I think the best way to differentiate the service >and remain compatible with existing proxy servers is to use a new method >on the request line. > > > > > ______________________________________________________________________ Xavier Riley Xerox Corp. Corp. Research & Tech. Voice: 310-333-8329 / 8*823-8329 701 S. Aviation Blvd ESAE-231 Fax: 310-333-6618 / 8*823-6618 El Segundo, California 90245 Email: xriley@cp10.es.xerox.com ______________________________________________________________________ From ipp-owner@pwg.org Mon Jun 1 17:01:15 1998 Delivery-Date: Mon, 01 Jun 1998 17:01:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01861 for ; Mon, 1 Jun 1998 17:01:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05112 for ; Mon, 1 Jun 1998 17:03:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16364 for ; Mon, 1 Jun 1998 17:00:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 16:52:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15161 for ipp-outgoing; Mon, 1 Jun 1998 16:51:08 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 01 Jun 1998 14:50:16 -0600 From: "Scott Isaacson" To: manros@cp10.es.xerox.com, http-wg@hplb.hpl.hp.com, joshco@microsoft.com, hardie@nic.nasa.gov Cc: moore@cs.utk.edu, ipp@pwg.org Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01861 I agree with Josh that the introduction of a new URL scheme (ala "ipp:") would be problematic. The key here is that IPP has a new "default" port, not a new "must-only-use-the-new-port" port. As he points out, IPP really is HTTP. Form processing with HTTP POST does not require a new "form:" URL scheme. As I understand it, an httpd server is always listening on one or more ports. The URL for a resource behind that server advertises what the port is: either the default port (no port is included in the URL) or some other port (the port included in the URL). Therefore, it is up to the client to attempt a connection on the correct port. You may ask: "If there is a default for IPP and a default for HTTP, then how will the client know which to use?" I claim that it will never be ambiguous. The client will always be in the context of making a generic HTTP request or an IPP request and it will be very clear which default to use. For example, take a URL that does not explicitly specify a port: http://my.domain.com/printer1 - If the client is in the act of printing (browser that is printing or a print only client) the the port to use is the new IPP default port. - Any other client will use the HTTP default port Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ >>> Josh Cohen 06/01 11:51 AM >>> I think its fine to have a new default dest port associated with IPP, but a new URL scheme seems like more trouble than may be apparent. For one, even though IPP is a different service than HTTP, an IPP client *is* speaking HTTP, IMHO. HTTP is used as a layer underneath IPP. So, I think the URL scheme should continue to be http://.. Using a new URL scheme will certainly break compatibility with existing proxies. Proxy server's encountering a new scheme will fail unless they are modified to understand it. As I've stated before, I think the best way to differentiate the service and remain compatible with existing proxy servers is to use a new method on the request line. > -----Original Message----- > From: hardie@thornhill.arc.nasa.gov > [mailto:hardie@thornhill.arc.nasa.gov] > Sent: Monday, June 01, 1998 10:31 AM > To: Carl-Uno Manros; http-wg@hplb.hpl.hp.com > Cc: ipp@pwg.org > Subject: IPP> Re: Implications of introducing new scheme and port for > existing HTTP servers > > > Carl-Uno, > By "scheme" in the text below, do you mean a > new HTTP method, parallel to GET and POST, or something > else? > regards, > Ted Hardie > NASA NIC > > > 1) the introduction of a new scheme called "ipp" > > 2) the introduction a new default port number for IPP servers. > > > > Before the IPP WG responds to those suggestions, the IPP WG > would like to > > get some advice from the HTTP WG on the implications of > such a change. > > In particular, we want some feedback on how easy or > difficult it would be > > to configure existing web servers to accomodate the > suggested changes. > From ipp-owner@pwg.org Mon Jun 1 17:01:41 1998 Delivery-Date: Mon, 01 Jun 1998 17:01:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01867 for ; Mon, 1 Jun 1998 17:01:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05121 for ; Mon, 1 Jun 1998 17:04:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16438 for ; Mon, 1 Jun 1998 17:01:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 16:52:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14620 for ipp-outgoing; Mon, 1 Jun 1998 16:42:20 -0400 (EDT) Message-Id: <3.0.5.32.19980601130127.01209680@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 1 Jun 1998 13:01:27 PDT To: ipp@pwg.org From: Jim Whitehead (by way of Carl-Uno Manros ) Subject: IPP> Forward WISEN announcement to IPP WG? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org UC Irvine is organizing a pre-IETF workshop on Internet notifications, for those who might be interested. See details below. Carl-Uno -- Hi Carl-Uno, Would it be possible for you to forward this announcement to the mailing list of the IPP working group? I think many members of the IPP WG would be interested in attending the WISEN workshop. Thank you! - Jim Whitehead Workshop on Internet-Scale Event Notification (WISEN) July 13-14, 1998 McDonnell Douglas Auditorium, UC Irvine Irvine, California USA http://www.ics.uci.edu/IRUS/wisen/ WORKSHOP OBJECTIVES & AGENDA WISEN aims to gather participants from industry and academia who are working on or researching event notification systems or protocols for use on the Internet. Communities interested in notification such as web authoring, instant messaging, buddy lists, workflow, and internet printing should find this workshop highly relevant. The goals of the workshop include developing a better understanding among the different communities of interest, improved definition of requirements for an event notification service, a better appreciation of the application domains that will benefit from an event notification service, and suggestions for fruitful research directions. The first day will feature a single track of presentations from invited speakers. The second day will feature presentations from invited speakers in the morning, and parallel breakout sessions in the afternoon. The workshop will end with participants gathering for a summary of the breakout sessions. Breakout sessions are currently planned on the topics of: * What are the requirements for internet scale event notifications? * What set of technologies can be leveraged to create an internet-scale notification service? * What are the scaling factors for internet event notifications? * What applications most benefit from an internet notification service? * What are the security considerations for notifications? CONFIRMED PRESENTERS To date, we have already confirmed a number of speakers: * Josh Cohen, Microsoft, joshco@microsoft.com * Mark Day, Lotus, mark_day@lotus.com * Surendra Reddy, Oracle, skreddy@us.oracle.com * Scott Isaacson, Novell, sisaacson@novell.com * Matt Jensen, BLIP, mattj@blip.org * John Mathon, TIBCO, mathon@tibco.com * Elisabetta Di Nitto, CEFRIEL-Politecnico di Milano and University of California, Irvine, dinitto@ics.uci.edu * Adam Rifkin, California Institute of Technology, adam@cs.caltech.edu * David Rosenblum, University of California, Irvine, dsr@ics.uci.edu * Michael Gorlick, The Aerospace Corp., gorlick@aero.org * Antonio Carzaniga, University of Colorado, Boulder, carzanig@cs.colorado.edu REGISTRATION DETAILS Participation is strictly limited to 100 participants due to capacity constraints. Advance registrations are $125; on-site registrations will only be accepted on a space-available basis at $175. The fee includes continental breakfast, box lunch, and snacks for both days as well as a welcome reception on Monday the 13th. Discounts are available to IRUS members and full-time students. Please consult the workshop web pages for the latest registration details, hotel information, and the online registration form. ORGANIZING COMMITTEE * Alfonso Fuggetta, Politecnico di Milano, Italy, fuggetta@elet.polimi.it * Michael Gorlick, The Aerospace Corp., gorlick@aero.org * Dennis Heimbigner, University of Colorado, Boulder, dennis@cs.colorado.edu * Rohit Khare, University of California, Irvine, rohit@ics.uci.edu * David S. Rosenblum, University of California, Irvine, dsr@ics.uci.edu * Richard N. Taylor, University of California, Irvine, taylor@ics.uci.edu * E. James Whitehead, University of California, Irvine, ejw@ics.uci.edu * Alexander L. Wolf, University of Colorado, Boulder, alw@cs.colorado.edu From ipp-owner@pwg.org Mon Jun 1 17:07:06 1998 Delivery-Date: Mon, 01 Jun 1998 17:07:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01904 for ; Mon, 1 Jun 1998 17:07:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05156 for ; Mon, 1 Jun 1998 17:09:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17144 for ; Mon, 1 Jun 1998 17:07:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 17:01:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15592 for ipp-outgoing; Mon, 1 Jun 1998 16:54:59 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: RE: IPP> New IPP Model Document Message-ID: <5030100021193448000002L082*@MHS> Date: Mon, 1 Jun 1998 16:53:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01904 Scott - Maybe we need to step back and define the requirements before we nail down the specification. Consider some high-level scenarios: 1) IPP over HTTP: the simplest approach here, I think, would be to let the Request-URI take precedence. In this scenario, the IPP embedded target URI (printer-uri, job-uri, etc.) is essentially meaningless, since any entity in a position to read it has already been identified as the resource designated to receive this request by the HTTP Request-URI. But this scenario (IPP/HTTP) isn't the reason that the target URI was added to the IPP protocol. In fact, we know that IPP/HTTP can work without IPP embedded target URIs. 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario, any entity in a position to read the IPP embedded target URI attributes is presumably an IPP Object. Therefore, the addressing of the request to the appropriate IPP Object is the responsibility of the transport layer (e.g., by email address). The IPP embedded target URI is used to identify a resource relative to the receiving IPP Object (e.g., a Job within the context of a Printer). So it is a Relative URI. 3) IPP Router: Apparently there are other scenarios involving some kind of IPP router capable of parsing an IPP request and retransmitting it to the resource identified by the embedded target URI. I haven't seen any of these re-route scenarios, but I think that only by working through some of them will we come to understand what the real requirements are. Maybe we need a new IPP embedded target URI attribute, of Absolute form, to identifiy the destination IPP Object in a router scenario. Scenario 1) could be modified to fit the general case of 2). Then the HTTP Request-URI would identify a Printer relative to a host, and the IPP embedded target URI would identify a resource relative to that Printer. - Carl SISAACSON@novell.com on 05/29/98 05:35:45 PM Please respond to SISAACSON@novell.com To: Carl Kugler/Boulder/IBM@ibmus, ipp@pwg.org cc: Subject: Re: RE: IPP> New IPP Model Document Carl, You provide good examples of why two URLs might refer to the same IPP object yet might be literally different (this gets back to the classical problems with equality - syntactically, semantically, instance vs class, type vs value, etc). Do we need to put any of them in the document as examples? Can we live with the fairly simple statement that is in the document: " 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they must both reference the same IPP object." or is the statement too simple? I also think that most of the text that I added to the model document on this subject should be moved to the encoding and transport document. The model document should not care about all of the reasons why 2 HTTP URLs might not be identical and yet refer to the "same" resource. What do you think? Scott >>> Carl Kugler 05/29 4:59 PM >>> Speculation: they might also be different: After TLS negotiation? Where the URIs are semantically the same but syntactically different, e.g.: - Absolute vs. Relative - host.domain vs dotted-ip - Default port specified vs. port omitted - UPPERCASE/lowercase in hostname - URI translation using equivalent escape codes After an HTTP redirect handled automatically by an HTTP layer in the client stack that doesn't know about IPP? Maybe an HTTP proxy server handles a redirect invisibly to the client? owner-ipp@pwg.org on 05/29/98 04:13:56 PM Please respond to owner-ipp@pwg.org To: jkm@underscore.com cc: ipp@pwg.org Subject: RE: IPP> New IPP Model Document Absolutely, I see the advantage of having the IPP information take precedence, I'm just not sure of the impact of having the two headers (HTTP and IPP-body) be different, and actually getting this to work in a CGI/NSAPI/ISAPI-based implementation. The generic web server will dispatch to the HTTP header-specified URI (I'm assuming, someone correct me if this is not the case). Once this dispatch occurs, the target in the HTTP header better be able to handle whatever is coming in the application/ipp body part. In this scenario, its too late to apply any precedence. Has someone identified a case where the two headers have to be different? (I may have missed some email...) Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Friday, May 29, 1998 2:51 PM To: Turner, Randy Cc: ipp@pwg.org; Puru Bish Subject: Re: IPP> New IPP Model Document Randy, > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). Are you sure about this? I mean, I can see you point to a certain extent, but wouldn't it be advantageous for an IPP server implemented as a front-end on a generic platform to be used as a multiplexor to several Printers and Jobs? On the other hand, if the HTTP request header takes precedent, then why are we specifying printer-uri/job-uri at all at the IPP protocol level? Aren't we asking for trouble when the HTTP request header and the corresponding IPP attributes don't match (with regard to interoperability)? ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ---------------------------------------------------------------------- From ipp-owner@pwg.org Mon Jun 1 17:20:05 1998 Delivery-Date: Mon, 01 Jun 1998 17:20:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02041 for ; Mon, 1 Jun 1998 17:20:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05248 for ; Mon, 1 Jun 1998 17:22:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA17818 for ; Mon, 1 Jun 1998 17:19:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 17:15:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA17218 for ipp-outgoing; Mon, 1 Jun 1998 17:10:13 -0400 (EDT) Message-ID: From: Paul Moore To: "'Scott Isaacson'" , manros@cp10.es.xerox.com, http-wg@hplb.hpl.hp.com, Josh Cohen , hardie@nic.nasa.gov Cc: moore@cs.utk.edu, ipp@pwg.org Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Date: Mon, 1 Jun 1998 14:12:21 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Doesnt changing scheme from 'HTTP' to 'IPP' mean that we should stop using HTTP wire representation. If we are using HTTP we should say so in the URL - i.e. http:............. What is the point of saying IPP:.... if we are actually sending HTTP. This seems to be neither one thing or another. > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Monday, June 01, 1998 1:50 PM > To: manros@cp10.es.xerox.com; http-wg@hplb.hpl.hp.com; Josh Cohen; > hardie@nic.nasa.gov > Cc: moore@cs.utk.edu; ipp@pwg.org > Subject: RE: IPP> Re: Implications of introducing new scheme and port > for existing HTTP servers > > I agree with Josh that the introduction of a new URL scheme (ala "ipp:") > would be problematic. The key here is that IPP has a new "default" port, > not a new "must-only-use-the-new-port" port. As he points out, IPP really > is HTTP. Form processing with HTTP POST does not require a new "form:" > URL scheme. > > As I understand it, an httpd server is always listening on one or more > ports. The URL for a resource behind that server advertises what the port > is: either the default port (no port is included in the URL) or some other > port (the port included in the URL). Therefore, it is up to the client to > attempt a connection on the correct port. You may ask: "If there is a > default for IPP and a default for HTTP, then how will the client know > which to use?" I claim that it will never be ambiguous. The client will > always be in the context of making a generic HTTP request or an IPP > request and it will be very clear which default to use. > > For example, take a URL that does not explicitly specify a port: > > http://my.domain.com/printer1 > > - If the client is in the act of printing (browser that is printing or a > print only client) the the port to use is the new IPP default port. > > - Any other client will use the HTTP default port > > Scott > > ************************************************************ > Scott A. Isaacson > Corporate Architect > Novell Inc., M/S PRV-C-121 > 122 E 1700 S, Provo, UT 84606 > voice: (801) 861-7366, (800) 453-1267 x17366 > fax: (801) 861-2517 > email: sisaacson@novell.com > web: http://www.novell.com > ************************************************************ > > > >>> Josh Cohen 06/01 11:51 AM >>> > I think its fine to have a new default dest port > associated with IPP, but a new URL scheme seems like more > trouble than may be apparent. > > For one, even though IPP is a different service than HTTP, > an IPP client *is* speaking HTTP, IMHO. HTTP is used as > a layer underneath IPP. So, I think the URL scheme > should continue to be http://.. > > Using a new URL scheme will certainly break compatibility > with existing proxies. Proxy server's encountering a new > scheme will fail unless they are modified to understand it. > > As I've stated before, I think the best way to differentiate > the service and remain compatible with existing proxy servers > is to use a new method on the request line. > > > > -----Original Message----- > > From: hardie@thornhill.arc.nasa.gov > > [mailto:hardie@thornhill.arc.nasa.gov] > > Sent: Monday, June 01, 1998 10:31 AM > > To: Carl-Uno Manros; http-wg@hplb.hpl.hp.com > > Cc: ipp@pwg.org > > Subject: IPP> Re: Implications of introducing new scheme and port for > > existing HTTP servers > > > > > > Carl-Uno, > > By "scheme" in the text below, do you mean a > > new HTTP method, parallel to GET and POST, or something > > else? > > regards, > > Ted Hardie > > NASA NIC > > > > > 1) the introduction of a new scheme called "ipp" > > > 2) the introduction a new default port number for IPP servers. > > > > > > Before the IPP WG responds to those suggestions, the IPP WG > > would like to > > > get some advice from the HTTP WG on the implications of > > such a change. > > > In particular, we want some feedback on how easy or > > difficult it would be > > > to configure existing web servers to accomodate the > > suggested changes. > > From ipp-owner@pwg.org Mon Jun 1 17:25:12 1998 Delivery-Date: Mon, 01 Jun 1998 17:25:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02212 for ; Mon, 1 Jun 1998 17:25:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05271 for ; Mon, 1 Jun 1998 17:27:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA18429 for ; Mon, 1 Jun 1998 17:25:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 17:20:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA16538 for ipp-outgoing; Mon, 1 Jun 1998 17:02:04 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 01 Jun 1998 15:00:56 -0600 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> Fwd: [WISEN] Workshop on Internet-Scale Event Notification, July 13-14 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_87D3CCBF.A1C0D8F7" Sender: owner-ipp@pwg.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_87D3CCBF.A1C0D8F7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is a message about a workshop on internet event notifications. Due = to the discussion I lead on IPP notification requirements at the Los = Angeles IETF, I was asked by the organizing committee to present at this = workshop. It looks like there is a combination of applications that need = some notification support as well as some notification infrastructure = proposals. =20 I expect that this effort will lead to a BOF at the next IEFT and = eventually a working group that can define and endorse a common solution = that can meet the needs of many other services for "internet scale event = notification". Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121=20 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ --=_87D3CCBF.A1C0D8F7 Content-Type: message/rfc822 Received: from PRV1-MX.PROVO.NOVELL.COM by prv-mail25.provo.novell.com; Mon, 01 Jun 1998 12:43:16 -0600 Received: from ietf.org by PRV1-MX.PROVO.NOVELL.COM; Mon, 01 Jun 1998 12:44:49 -0600 Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA28685 for ietf-outbound.04@ietf.org; Mon, 1 Jun 1998 14:20:03 -0400 (EDT) Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA28660 for ; Mon, 1 Jun 1998 14:19:09 -0400 (EDT) Received: from cloud.ics.uci.edu by paris.ics.uci.edu id aa07188; 1 Jun 98 11:09 PDT To: ietf@ietf.org Subject: [WISEN] Workshop on Internet-Scale Event Notification, July 13-14 Date: Mon, 01 Jun 1998 11:08:59 -0700 From: Jim Whitehead Message-ID: <9806011109.aa07188@paris.ics.uci.edu> Workshop on Internet-Scale Event Notification (WISEN) July 13-14, 1998 McDonnell Douglas Auditorium, UC Irvine Irvine, California USA http://www.ics.uci.edu/IRUS/wisen/ WORKSHOP OBJECTIVES & AGENDA WISEN aims to gather participants from industry and academia who are working on or researching event notification systems or protocols for use on the Internet. Communities interested in notification such as web authoring, instant messaging, buddy lists, workflow, and internet printing should find this workshop highly relevant. The goals of the workshop include developing a better understanding among the different communities of interest, improved definition of requirements for an event notification service, a better appreciation of the application domains that will benefit from an event notification service, and suggestions for fruitful research directions. The first day will feature a single track of presentations from invited speakers. The second day will feature presentations from invited speakers in the morning, and parallel breakout sessions in the afternoon. The workshop will end with participants gathering for a summary of the breakout sessions. Breakout sessions are currently planned on the topics of: * What are the requirements for internet scale event notifications? * What set of technologies can be leveraged to create an internet-scale notification service? * What are the scaling factors for internet event notifications? * What applications most benefit from an internet notification service? * What are the security considerations for notifications? CONFIRMED PRESENTERS To date, we have already confirmed a number of speakers: * Josh Cohen, Microsoft, joshco@microsoft.com * Mark Day, Lotus, mark_day@lotus.com * Surendra Reddy, Oracle, skreddy@us.oracle.com * Scott Isaacson, Novell, sisaacson@novell.com * Matt Jensen, BLIP, mattj@blip.org * John Mathon, TIBCO, mathon@tibco.com * Elisabetta Di Nitto, CEFRIEL-Politecnico di Milano and University of California, Irvine, dinitto@ics.uci.edu * Adam Rifkin, California Institute of Technology, adam@cs.caltech.edu * David Rosenblum, University of California, Irvine, dsr@ics.uci.edu * Michael Gorlick, The Aerospace Corp., gorlick@aero.org * Antonio Carzaniga, University of Colorado, Boulder, carzanig@cs.colorado.edu REGISTRATION DETAILS Participation is strictly limited to 100 participants due to capacity constraints. Advance registrations are $125; on-site registrations will only be accepted on a space-available basis at $175. The fee includes continental breakfast, box lunch, and snacks for both days as well as a welcome reception on Monday the 13th. Discounts are available to IRUS members and full-time students. Please consult the workshop web pages for the latest registration details, hotel information, and the online registration form. ORGANIZING COMMITTEE * Alfonso Fuggetta, Politecnico di Milano, Italy, fuggetta@elet.polimi.it * Michael Gorlick, The Aerospace Corp., gorlick@aero.org * Dennis Heimbigner, University of Colorado, Boulder, dennis@cs.colorado.edu * Rohit Khare, University of California, Irvine, rohit@ics.uci.edu * David S. Rosenblum, University of California, Irvine, dsr@ics.uci.edu * Richard N. Taylor, University of California, Irvine, taylor@ics.uci.edu * E. James Whitehead, University of California, Irvine, ejw@ics.uci.edu * Alexander L. Wolf, University of Colorado, Boulder, alw@cs.colorado.edu --=_87D3CCBF.A1C0D8F7-- From ipp-owner@pwg.org Mon Jun 1 17:54:23 1998 Delivery-Date: Mon, 01 Jun 1998 17:54:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02485 for ; Mon, 1 Jun 1998 17:54:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05346 for ; Mon, 1 Jun 1998 17:56:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19326 for ; Mon, 1 Jun 1998 17:54:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 17:48:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18541 for ipp-outgoing; Mon, 1 Jun 1998 17:32:36 -0400 (EDT) Message-ID: <35731DCE.46BD7B76@us.ibm.com> Date: Mon, 01 Jun 1998 15:31:59 -0600 From: Carl Kugler X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Implications of introducing new scheme and port for existing Content-Type: multipart/mixed; boundary="------------7A8176E65D10978C9D9AF6D2" Sender: owner-ipp@pwg.org This is a multi-part message in MIME format. --------------7A8176E65D10978C9D9AF6D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 1) the introduction of a new scheme called "ipp" > Not a problem for the case in which the client talks directly to the origin server. In fact, the scheme isn't part of the HTTP request message in this case; it's more of a hint to the client about how to connect to the server. Big problem for proxy servers, though. An existing proxy server wouldn't know how to proxy a request to an absolute URI with an "ipp" scheme. And not all proxies are firewalls. Sometimes they're used for caching (e.g., to reduce transoceanic traffic in an intranet). > 2) the introduction a new default port number for IPP servers. > No major implications from my point of view. http://pwg.org/hypermail/ipp/0523.html --------------7A8176E65D10978C9D9AF6D2 Content-Type: text/html; charset=us-ascii; name="0523.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0523.html" Content-Base: "http://pwg.org/hypermail/ipp/0523.html" IPP Mail Archive: IPP> Implications of introducing new scheme and port for existing

IPP> Implications of introducing new scheme and port for existing

Carl-Uno Manros (manros@cp10.es.xerox.com)
Mon, 1 Jun 1998 10:20:01 PDT

Hi,

As most of you know already, the Internet Printing Protocol (IPP) WG has
suggested using HTTP as "transport", with the payload in the form of a MIME
object passed with the POST method.

As part of the onging IESG review process, the Application Area Director
Keith Moore has suggested to distinguish IPP traffic from "normal" HTTP
traffic by:

1) the introduction of a new scheme called "ipp"
2) the introduction a new default port number for IPP servers.

Before the IPP WG responds to those suggestions, the IPP WG would like to
get some advice from the HTTP WG on the implications of such a change.
In particular, we want some feedback on how easy or difficult it would be
to configure existing web servers to accomodate the suggested changes.

Please note that many printer vendors are not in the business of developing
web servers or HTTP servers and are dependent on getting those compoments
from other vendors.

Please respond back to the IPP DL at:

ipp@pwg.org

Thanks,

Carl-Uno Manros
Chair of the IETF IPP WG

--------------7A8176E65D10978C9D9AF6D2-- From ipp-owner@pwg.org Mon Jun 1 17:58:05 1998 Delivery-Date: Mon, 01 Jun 1998 17:58:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02502 for ; Mon, 1 Jun 1998 17:58:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05358 for ; Mon, 1 Jun 1998 18:00:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA19820 for ; Mon, 1 Jun 1998 17:58:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 17:52:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18597 for ipp-outgoing; Mon, 1 Jun 1998 17:41:11 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 01 Jun 1998 15:40:42 -0600 From: "Scott Isaacson" To: kugler@us.ibm.com Cc: ipp@pwg.org Subject: IPP> URLs within IPP operations Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA02502 I changed the subject line. We do so seem to be confusing addressing vs payload. Addressing should be independent of payload. With URLs embedded within IPP operations, we are mixing addressing and payload. Since we chose HTTP for IPP we should rely on it for all of our addressing and routing, so we all seem to agree that for High Level Scenario 1 the URLs in the IPP operation are as you say "meaningless" In fact they were never there until late in the game and were added "just in case there is a mapping to some other transport other than HTTP" When that happens, no longer will IPP objects be identified with "http:" URLs, but some other type of addressing/naming scheme. In that case, we ought to make sure that there is enough info in that URL (URI, URN whatever) to get to the IPP printer object and not worry so much about including in the operation itself. I am becoming more and more convinced that it as a bad idea to put the URLs in there at all. We should rely on the addressing in the layer upon which IPP is mapped to solve the problem. I think we all agree that the URLs within IPP operations are not needed for HTTP. Then we try to guess if they are needed for other mappings? You suggest in scenarios 2 and 3 that the embedded info might be needed for identifying a resource "underneath" or "behind" the IPP object. However, I wonder if this is true. The only addressable IPP objects are Printers and Jobs. Once a Printer gets a Printer request it should handle it as if it were supposed to get that request, and not have to check "is this really for me" That should be handled at a different layer. Same for a Job object. The HTTP level URL is all that is needed to route to the correct Job or Printer. So to me, scenarios 2 and 3 either collapse into one called "other" or expand into possibly many unexplored options. Let's not solve that problem now. Consider this example: If I get a postal service letter in my mail box, I open the evenlope and read it assuming it is for me. If I am at home, the address on the envelope is perhaps much simpler than if I am at work. If I am at home, it probably just has my name and street address. If I am at work, it probably has a street address, company name, mail/stop, building number, and my name. NOTE: **** In either case, the letter in the envelope can be exactly the same. **** What if the letter happens to have the address that was used at the top of the page? I usually just ignore it and read the letter, I don't care how it got to me. What if the letter happens to have the wrong address? ( the proxy case), I still ignore it and read the letter - the letter got to me, it must be for me. In the proxy case, who cares what the address printed at the top of the page is? Summary, why do we have a solution waiting for a problem that is causing a different problem? Scott >>> Carl Kugler 06/01 2:53 PM >>> > Scott - > > Maybe we need to step back and define the requirements before we nail down the > specification. > > Consider some high-level scenarios: > > 1) IPP over HTTP: the simplest approach here, I think, would be to let the > Request-URI take precedence. In this scenario, the IPP embedded target URI > (printer-uri, job-uri, etc.) is essentially meaningless, since any entity in a > position to read it has already been identified as the resource designated to > receive this request by the HTTP Request-URI. But this scenario (IPP/HTTP) > isn't the reason that the target URI was added to the IPP protocol. In fact, > we know that IPP/HTTP can work without IPP embedded target URIs. > > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario, any > entity in a position to read the IPP embedded target URI attributes is > presumably an IPP Object. Therefore, the addressing of the request to the > appropriate IPP Object is the responsibility of the transport layer (e.g., by > email address). The IPP embedded target URI is used to identify a resource > relative to the receiving IPP Object (e.g., a Job within the context of a > Printer). So it is a Relative URI. > > 3) IPP Router: Apparently there are other scenarios involving some kind of > IPP router capable of parsing an IPP request and retransmitting it to the > resource identified by the embedded target URI. I haven't seen any of these > re-route scenarios, but I think that only by working through some of them will > we come to understand what the real requirements are. Maybe we need a new IPP > embedded target URI attribute, of Absolute form, to identifiy the destination > IPP Object in a router scenario. > Scenario 1) could be modified to fit the general case of 2). Then the HTTP > Request-URI would identify a Printer relative to a host, and the IPP embedded > target URI would identify a resource relative to that Printer. > > - Carl From ipp-owner@pwg.org Mon Jun 1 18:46:19 1998 Delivery-Date: Mon, 01 Jun 1998 18:46:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02866 for ; Mon, 1 Jun 1998 18:46:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05484 for ; Mon, 1 Jun 1998 18:48:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA20726 for ; Mon, 1 Jun 1998 18:46:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 18:42:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20159 for ipp-outgoing; Mon, 1 Jun 1998 18:39:24 -0400 (EDT) Message-ID: From: Paul Moore To: "'Scott Isaacson'" , kugler@us.ibm.com Cc: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations Date: Mon, 1 Jun 1998 15:41:14 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org You forget one thing, the IPP recipient must generate and give out addresses for new objects (Job-URI). it must therefore know its place in the addressing scheme of he underlying transport. > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Monday, June 01, 1998 2:41 PM > To: kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: IPP> URLs within IPP operations > > I changed the subject line. > > We do so seem to be confusing addressing vs payload. Addressing should > be independent of payload. With URLs embedded within IPP operations, we > are mixing addressing and payload. > > Since we chose HTTP for IPP we should rely on it for all of our addressing > and routing, so we all seem to agree that for High Level Scenario 1 the > URLs in the IPP operation are as you say "meaningless" In fact they were > never there until late in the game and were added "just in case there is a > mapping to some other transport other than HTTP" When that happens, no > longer will IPP objects be identified with "http:" URLs, but some other > type of addressing/naming scheme. In that case, we ought to make sure > that there is enough info in that URL (URI, URN whatever) to get to the > IPP printer object and not worry so much about including in the operation > itself. > > I am becoming more and more convinced that it as a bad idea to put the > URLs in there at all. We should rely on the addressing in the layer upon > which IPP is mapped to solve the problem. I think we all agree that the > URLs within IPP operations are not needed for HTTP. Then we try to guess > if they are needed for other mappings? You suggest in scenarios 2 and 3 > that the embedded info might be needed for identifying a resource > "underneath" or "behind" the IPP object. However, I wonder if this is > true. The only addressable IPP objects are Printers and Jobs. Once a > Printer gets a Printer request it should handle it as if it were supposed > to get that request, and not have to check "is this really for me" That > should be handled at a different layer. Same for a Job object. The HTTP > level URL is all that is needed to route to the correct Job or Printer. > So to me, scenarios 2 and 3 either collapse into one called "other" or > expand into possibly many unexplored options. Let's not solve that > problem now. > > Consider this example: > > If I get a postal service letter in my mail box, I open the evenlope and > read it assuming it is for me. If I am at home, the address on the > envelope is perhaps much simpler than if I am at work. If I am at home, > it probably just has my name and street address. If I am at work, it > probably has a street address, company name, mail/stop, building number, > and my name. NOTE: **** In either case, the letter in the envelope can > be exactly the same. **** > > What if the letter happens to have the address that was used at the top of > the page? I usually just ignore it and read the letter, I don't care how > it got to me. What if the letter happens to have the wrong address? ( > the proxy case), I still ignore it and read the letter - the letter got to > me, it must be for me. In the proxy case, who cares what the address > printed at the top of the page is? > > Summary, why do we have a solution waiting for a problem that is causing a > different problem? > > Scott > > >>> Carl Kugler 06/01 2:53 PM >>> > > Scott - > > > > Maybe we need to step back and define the requirements before we nail > down the > > specification. > > > > Consider some high-level scenarios: > > > > 1) IPP over HTTP: the simplest approach here, I think, would be to > let the > > Request-URI take precedence. In this scenario, the IPP embedded target > URI > > (printer-uri, job-uri, etc.) is essentially meaningless, since any > entity in a > > position to read it has already been identified as the resource > designated to > > receive this request by the HTTP Request-URI. But this scenario > (IPP/HTTP) > > isn't the reason that the target URI was added to the IPP protocol. In > fact, > > we know that IPP/HTTP can work without IPP embedded target URIs. > > > > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario, > any > > entity in a position to read the IPP embedded target URI attributes is > > presumably an IPP Object. Therefore, the addressing of the request to > the > > appropriate IPP Object is the responsibility of the transport layer > (e.g., by > > email address). The IPP embedded target URI is used to identify a > resource > > relative to the receiving IPP Object (e.g., a Job within the context of > a > > Printer). So it is a Relative URI. > > > > 3) IPP Router: Apparently there are other scenarios involving some > kind of > > IPP router capable of parsing an IPP request and retransmitting it to > the > > resource identified by the embedded target URI. I haven't seen any of > these > > re-route scenarios, but I think that only by working through some of > them will > > we come to understand what the real requirements are. Maybe we need a > new IPP > > embedded target URI attribute, of Absolute form, to identifiy the > destination > > IPP Object in a router scenario. > > Scenario 1) could be modified to fit the general case of 2). Then the > HTTP > > Request-URI would identify a Printer relative to a host, and the IPP > embedded > > target URI would identify a resource relative to that Printer. > > > > - Carl > From ipp-owner@pwg.org Mon Jun 1 19:03:28 1998 Delivery-Date: Mon, 01 Jun 1998 19:03:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02960 for ; Mon, 1 Jun 1998 19:03:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05526 for ; Mon, 1 Jun 1998 19:05:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA21519 for ; Mon, 1 Jun 1998 19:03:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 18:58:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20827 for ipp-outgoing; Mon, 1 Jun 1998 18:48:52 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'Paul Moore'" , "'Scott Isaacson'" , kugler@us.ibm.com Cc: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations Date: Mon, 1 Jun 1998 15:49:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org I think its implementation-dependent how it derives "output URIs". I don't think they are "by necessity" tightly coupled. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Monday, June 01, 1998 3:41 PM To: 'Scott Isaacson'; kugler@us.ibm.com Cc: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations You forget one thing, the IPP recipient must generate and give out addresses for new objects (Job-URI). it must therefore know its place in the addressing scheme of he underlying transport. > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Monday, June 01, 1998 2:41 PM > To: kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: IPP> URLs within IPP operations > > I changed the subject line. > > We do so seem to be confusing addressing vs payload. Addressing should > be independent of payload. With URLs embedded within IPP operations, we > are mixing addressing and payload. > > Since we chose HTTP for IPP we should rely on it for all of our addressing > and routing, so we all seem to agree that for High Level Scenario 1 the > URLs in the IPP operation are as you say "meaningless" In fact they were > never there until late in the game and were added "just in case there is a > mapping to some other transport other than HTTP" When that happens, no > longer will IPP objects be identified with "http:" URLs, but some other > type of addressing/naming scheme. In that case, we ought to make sure > that there is enough info in that URL (URI, URN whatever) to get to the > IPP printer object and not worry so much about including in the operation > itself. > > I am becoming more and more convinced that it as a bad idea to put the > URLs in there at all. We should rely on the addressing in the layer upon > which IPP is mapped to solve the problem. I think we all agree that the > URLs within IPP operations are not needed for HTTP. Then we try to guess > if they are needed for other mappings? You suggest in scenarios 2 and 3 > that the embedded info might be needed for identifying a resource > "underneath" or "behind" the IPP object. However, I wonder if this is > true. The only addressable IPP objects are Printers and Jobs. Once a > Printer gets a Printer request it should handle it as if it were supposed > to get that request, and not have to check "is this really for me" That > should be handled at a different layer. Same for a Job object. The HTTP > level URL is all that is needed to route to the correct Job or Printer. > So to me, scenarios 2 and 3 either collapse into one called "other" or > expand into possibly many unexplored options. Let's not solve that > problem now. > > Consider this example: > > If I get a postal service letter in my mail box, I open the evenlope and > read it assuming it is for me. If I am at home, the address on the > envelope is perhaps much simpler than if I am at work. If I am at home, > it probably just has my name and street address. If I am at work, it > probably has a street address, company name, mail/stop, building number, > and my name. NOTE: **** In either case, the letter in the envelope can > be exactly the same. **** > > What if the letter happens to have the address that was used at the top of > the page? I usually just ignore it and read the letter, I don't care how > it got to me. What if the letter happens to have the wrong address? ( > the proxy case), I still ignore it and read the letter - the letter got to > me, it must be for me. In the proxy case, who cares what the address > printed at the top of the page is? > > Summary, why do we have a solution waiting for a problem that is causing a > different problem? > > Scott > > >>> Carl Kugler 06/01 2:53 PM >>> > > Scott - > > > > Maybe we need to step back and define the requirements before we nail > down the > > specification. > > > > Consider some high-level scenarios: > > > > 1) IPP over HTTP: the simplest approach here, I think, would be to > let the > > Request-URI take precedence. In this scenario, the IPP embedded target > URI > > (printer-uri, job-uri, etc.) is essentially meaningless, since any > entity in a > > position to read it has already been identified as the resource > designated to > > receive this request by the HTTP Request-URI. But this scenario > (IPP/HTTP) > > isn't the reason that the target URI was added to the IPP protocol. In > fact, > > we know that IPP/HTTP can work without IPP embedded target URIs. > > > > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario, > any > > entity in a position to read the IPP embedded target URI attributes is > > presumably an IPP Object. Therefore, the addressing of the request to > the > > appropriate IPP Object is the responsibility of the transport layer > (e.g., by > > email address). The IPP embedded target URI is used to identify a > resource > > relative to the receiving IPP Object (e.g., a Job within the context of > a > > Printer). So it is a Relative URI. > > > > 3) IPP Router: Apparently there are other scenarios involving some > kind of > > IPP router capable of parsing an IPP request and retransmitting it to > the > > resource identified by the embedded target URI. I haven't seen any of > these > > re-route scenarios, but I think that only by working through some of > them will > > we come to understand what the real requirements are. Maybe we need a > new IPP > > embedded target URI attribute, of Absolute form, to identifiy the > destination > > IPP Object in a router scenario. > > Scenario 1) could be modified to fit the general case of 2). Then the > HTTP > > Request-URI would identify a Printer relative to a host, and the IPP > embedded > > target URI would identify a resource relative to that Printer. > > > > - Carl > From ipp-owner@pwg.org Mon Jun 1 19:14:01 1998 Delivery-Date: Mon, 01 Jun 1998 19:14:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03000 for ; Mon, 1 Jun 1998 19:14:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05558 for ; Mon, 1 Jun 1998 19:16:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA22439 for ; Mon, 1 Jun 1998 19:13:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 19:09:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20873 for ipp-outgoing; Mon, 1 Jun 1998 18:52:00 -0400 (EDT) Message-ID: From: Paul Moore To: "'Turner, Randy'" , "'Scott Isaacson'" , kugler@us.ibm.com Cc: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations Date: Mon, 1 Jun 1998 15:54:07 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Not so, the person that receives the 'output-URI' expects to be able to give it to the transport layer as a valid endpoint. The receiver may not look at the URI to obtain any meaning but it is assumed that the URI makes sense to the transport. > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Monday, June 01, 1998 3:49 PM > To: Paul Moore; 'Scott Isaacson'; kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: RE: IPP> URLs within IPP operations > > > I think its implementation-dependent how it derives "output URIs". I > don't think they are "by necessity" tightly coupled. > > Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Monday, June 01, 1998 3:41 PM > To: 'Scott Isaacson'; kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: RE: IPP> URLs within IPP operations > > You forget one thing, the IPP recipient must generate and give > out addresses > for new objects (Job-URI). it must therefore know its place in > the > addressing scheme of he underlying transport. > > > -----Original Message----- > > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > > Sent: Monday, June 01, 1998 2:41 PM > > To: kugler@us.ibm.com > > Cc: ipp@pwg.org > > Subject: IPP> URLs within IPP operations > > > > I changed the subject line. > > > > We do so seem to be confusing addressing vs payload. > Addressing should > > be independent of payload. With URLs embedded within IPP > operations, we > > are mixing addressing and payload. > > > > Since we chose HTTP for IPP we should rely on it for all of > our addressing > > and routing, so we all seem to agree that for High Level > Scenario 1 the > > URLs in the IPP operation are as you say "meaningless" In > fact they were > > never there until late in the game and were added "just in > case there is a > > mapping to some other transport other than HTTP" When that > happens, no > > longer will IPP objects be identified with "http:" URLs, but > some other > > type of addressing/naming scheme. In that case, we ought to > make sure > > that there is enough info in that URL (URI, URN whatever) to > get to the > > IPP printer object and not worry so much about including in > the operation > > itself. > > > > I am becoming more and more convinced that it as a bad idea to > put the > > URLs in there at all. We should rely on the addressing in the > layer upon > > which IPP is mapped to solve the problem. I think we all > agree that the > > URLs within IPP operations are not needed for HTTP. Then we > try to guess > > if they are needed for other mappings? You suggest in > scenarios 2 and 3 > > that the embedded info might be needed for identifying a > resource > > "underneath" or "behind" the IPP object. However, I wonder if > this is > > true. The only addressable IPP objects are Printers and Jobs. > Once a > > Printer gets a Printer request it should handle it as if it > were supposed > > to get that request, and not have to check "is this really for > me" That > > should be handled at a different layer. Same for a Job > object. The HTTP > > level URL is all that is needed to route to the correct Job or > Printer. > > So to me, scenarios 2 and 3 either collapse into one called > "other" or > > expand into possibly many unexplored options. Let's not solve > that > > problem now. > > > > Consider this example: > > > > If I get a postal service letter in my mail box, I open the > evenlope and > > read it assuming it is for me. If I am at home, the address > on the > > envelope is perhaps much simpler than if I am at work. If I > am at home, > > it probably just has my name and street address. If I am at > work, it > > probably has a street address, company name, mail/stop, > building number, > > and my name. NOTE: **** In either case, the letter in the > envelope can > > be exactly the same. **** > > > > What if the letter happens to have the address that was used > at the top of > > the page? I usually just ignore it and read the letter, I > don't care how > > it got to me. What if the letter happens to have the wrong > address? ( > > the proxy case), I still ignore it and read the letter - the > letter got to > > me, it must be for me. In the proxy case, who cares what the > address > > printed at the top of the page is? > > > > Summary, why do we have a solution waiting for a problem that > is causing a > > different problem? > > > > Scott > > > > >>> Carl Kugler 06/01 2:53 PM >>> > > > Scott - > > > > > > Maybe we need to step back and define the requirements > before we nail > > down the > > > specification. > > > > > > Consider some high-level scenarios: > > > > > > 1) IPP over HTTP: the simplest approach here, I think, > would be to > > let the > > > Request-URI take precedence. In this scenario, the IPP > embedded target > > URI > > > (printer-uri, job-uri, etc.) is essentially meaningless, > since any > > entity in a > > > position to read it has already been identified as the > resource > > designated to > > > receive this request by the HTTP Request-URI. But this > scenario > > (IPP/HTTP) > > > isn't the reason that the target URI was added to the IPP > protocol. In > > fact, > > > we know that IPP/HTTP can work without IPP embedded target > URIs. > > > > > > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In > this scenario, > > any > > > entity in a position to read the IPP embedded target URI > attributes is > > > presumably an IPP Object. Therefore, the addressing of the > request to > > the > > > appropriate IPP Object is the responsibility of the > transport layer > > (e.g., by > > > email address). The IPP embedded target URI is used to > identify a > > resource > > > relative to the receiving IPP Object (e.g., a Job within the > context of > > a > > > Printer). So it is a Relative URI. > > > > > > 3) IPP Router: Apparently there are other scenarios > involving some > > kind of > > > IPP router capable of parsing an IPP request and > retransmitting it to > > the > > > resource identified by the embedded target URI. I haven't > seen any of > > these > > > re-route scenarios, but I think that only by working through > some of > > them will > > > we come to understand what the real requirements are. Maybe > we need a > > new IPP > > > embedded target URI attribute, of Absolute form, to > identifiy the > > destination > > > IPP Object in a router scenario. > > > Scenario 1) could be modified to fit the general case of 2). > Then the > > HTTP > > > Request-URI would identify a Printer relative to a host, and > the IPP > > embedded > > > target URI would identify a resource relative to that > Printer. > > > > > > - Carl > > From ipp-owner@pwg.org Mon Jun 1 19:31:51 1998 Delivery-Date: Mon, 01 Jun 1998 19:31:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03061 for ; Mon, 1 Jun 1998 19:31:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05587 for ; Mon, 1 Jun 1998 19:34:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA23537 for ; Mon, 1 Jun 1998 19:31:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 19:27:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA22822 for ipp-outgoing; Mon, 1 Jun 1998 19:23:29 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> URLs within IPP operations Date: Mon, 1 Jun 1998 16:23:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org That's true, but I was questioning whether or not it needed to know "its place" in the transport domain. And also, an IPP implementation may "ask" the transport layer to map a new URI to use, or to translate an IPP object name into a suitable transport URI. I agree that there is a linkage, but there are a lot of ways to make this linkage more loosely coupled. Randy -----Original Message----- From: Paul Moore [SMTP:paulmo@microsoft.com] Sent: Monday, June 01, 1998 3:54 PM To: 'Turner, Randy'; 'Scott Isaacson'; kugler@us.ibm.com Cc: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations Not so, the person that receives the 'output-URI' expects to be able to give it to the transport layer as a valid endpoint. The receiver may not look at the URI to obtain any meaning but it is assumed that the URI makes sense to the transport. > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Monday, June 01, 1998 3:49 PM > To: Paul Moore; 'Scott Isaacson'; kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: RE: IPP> URLs within IPP operations > > > I think its implementation-dependent how it derives "output URIs". I > don't think they are "by necessity" tightly coupled. > > Randy > > > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Monday, June 01, 1998 3:41 PM > To: 'Scott Isaacson'; kugler@us.ibm.com > Cc: ipp@pwg.org > Subject: RE: IPP> URLs within IPP operations > > You forget one thing, the IPP recipient must generate and give > out addresses > for new objects (Job-URI). it must therefore know its place in > the > addressing scheme of he underlying transport. > > > -----Original Message----- > > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > > Sent: Monday, June 01, 1998 2:41 PM > > To: kugler@us.ibm.com > > Cc: ipp@pwg.org > > Subject: IPP> URLs within IPP operations > > > > I changed the subject line. > > > > We do so seem to be confusing addressing vs payload. > Addressing should > > be independent of payload. With URLs embedded within IPP > operations, we > > are mixing addressing and payload. > > > > Since we chose HTTP for IPP we should rely on it for all of > our addressing > > and routing, so we all seem to agree that for High Level > Scenario 1 the > > URLs in the IPP operation are as you say "meaningless" In > fact they were > > never there until late in the game and were added "just in > case there is a > > mapping to some other transport other than HTTP" When that > happens, no > > longer will IPP objects be identified with "http:" URLs, but > some other > > type of addressing/naming scheme. In that case, we ought to > make sure > > that there is enough info in that URL (URI, URN whatever) to > get to the > > IPP printer object and not worry so much about including in > the operation > > itself. > > > > I am becoming more and more convinced that it as a bad idea to > put the > > URLs in there at all. We should rely on the addressing in the > layer upon > > which IPP is mapped to solve the problem. I think we all > agree that the > > URLs within IPP operations are not needed for HTTP. Then we > try to guess > > if they are needed for other mappings? You suggest in > scenarios 2 and 3 > > that the embedded info might be needed for identifying a > resource > > "underneath" or "behind" the IPP object. However, I wonder if > this is > > true. The only addressable IPP objects are Printers and Jobs. > Once a > > Printer gets a Printer request it should handle it as if it > were supposed > > to get that request, and not have to check "is this really for > me" That > > should be handled at a different layer. Same for a Job > object. The HTTP > > level URL is all that is needed to route to the correct Job or > Printer. > > So to me, scenarios 2 and 3 either collapse into one called > "other" or > > expand into possibly many unexplored options. Let's not solve > that > > problem now. > > > > Consider this example: > > > > If I get a postal service letter in my mail box, I open the > evenlope and > > read it assuming it is for me. If I am at home, the address > on the > > envelope is perhaps much simpler than if I am at work. If I > am at home, > > it probably just has my name and street address. If I am at > work, it > > probably has a street address, company name, mail/stop, > building number, > > and my name. NOTE: **** In either case, the letter in the > envelope can > > be exactly the same. **** > > > > What if the letter happens to have the address that was used > at the top of > > the page? I usually just ignore it and read the letter, I > don't care how > > it got to me. What if the letter happens to have the wrong > address? ( > > the proxy case), I still ignore it and read the letter - the > letter got to > > me, it must be for me. In the proxy case, who cares what the > address > > printed at the top of the page is? > > > > Summary, why do we have a solution waiting for a problem that > is causing a > > different problem? > > > > Scott > > > > >>> Carl Kugler 06/01 2:53 PM >>> > > > Scott - > > > > > > Maybe we need to step back and define the requirements > before we nail > > down the > > > specification. > > > > > > Consider some high-level scenarios: > > > > > > 1) IPP over HTTP: the simplest approach here, I think, > would be to > > let the > > > Request-URI take precedence. In this scenario, the IPP > embedded target > > URI > > > (printer-uri, job-uri, etc.) is essentially meaningless, > since any > > entity in a > > > position to read it has already been identified as the > resource > > designated to > > > receive this request by the HTTP Request-URI. But this > scenario > > (IPP/HTTP) > > > isn't the reason that the target URI was added to the IPP > protocol. In > > fact, > > > we know that IPP/HTTP can work without IPP embedded target > URIs. > > > > > > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In > this scenario, > > any > > > entity in a position to read the IPP embedded target URI > attributes is > > > presumably an IPP Object. Therefore, the addressing of the > request to > > the > > > appropriate IPP Object is the responsibility of the > transport layer > > (e.g., by > > > email address). The IPP embedded target URI is used to > identify a > > resource > > > relative to the receiving IPP Object (e.g., a Job within the > context of > > a > > > Printer). So it is a Relative URI. > > > > > > 3) IPP Router: Apparently there are other scenarios > involving some > > kind of > > > IPP router capable of parsing an IPP request and > retransmitting it to > > the > > > resource identified by the embedded target URI. I haven't > seen any of > > these > > > re-route scenarios, but I think that only by working through > some of > > them will > > > we come to understand what the real requirements are. Maybe > we need a > > new IPP > > > embedded target URI attribute, of Absolute form, to > identifiy the > > destination > > > IPP Object in a router scenario. > > > Scenario 1) could be modified to fit the general case of 2). > Then the > > HTTP > > > Request-URI would identify a Printer relative to a host, and > the IPP > > embedded > > > target URI would identify a resource relative to that > Printer. > > > > > > - Carl > > From ipp-owner@pwg.org Mon Jun 1 19:56:43 1998 Delivery-Date: Mon, 01 Jun 1998 19:56:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03129 for ; Mon, 1 Jun 1998 19:56:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05637 for ; Mon, 1 Jun 1998 19:59:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA24418 for ; Mon, 1 Jun 1998 19:56:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 19:52:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23775 for ipp-outgoing; Mon, 1 Jun 1998 19:47:08 -0400 (EDT) Message-ID: <35733D5C.73B28AA3@us.ibm.com> Date: Mon, 01 Jun 1998 17:46:36 -0600 From: Carl Kugler X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: RE: IPP> URLs within IPP operations Content-Type: multipart/mixed; boundary="------------9233C429104D40AEF3E2F6F9" Sender: owner-ipp@pwg.org This is a multi-part message in MIME format. --------------9233C429104D40AEF3E2F6F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > You forget one thing, the IPP recipient must generate and give out addresses > for new objects (Job-URI). it must therefore know its place in the > addressing scheme of he underlying transport. > But it doesn't necessarily have to get that knowledge from the request message. http://www.pwg.org/hypermail/ipp/0541.html --------------9233C429104D40AEF3E2F6F9 Content-Type: text/html; charset=us-ascii; name="0541.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0541.html" Content-Base: "http://www.pwg.org/hypermail/ipp/0541. html" IPP Mail Archive: RE: IPP> URLs within IPP operations

RE: IPP> URLs within IPP operations

Paul Moore (paulmo@microsoft.com)
Mon, 1 Jun 1998 15:41:14 -0700

You forget one thing, the IPP recipient must generate and give out addresses
for new objects (Job-URI). it must therefore know its place in the
addressing scheme of he underlying transport.

> -----Original Message-----
> From: Scott Isaacson [SMTP:SISAACSON@novell.com]
> Sent: Monday, June 01, 1998 2:41 PM
> To: kugler@us.ibm.com
> Cc: ipp@pwg.org
> Subject: IPP> URLs within IPP operations
>
> I changed the subject line.
>
> We do so seem to be confusing addressing vs payload. Addressing should
> be independent of payload. With URLs embedded within IPP operations, we
> are mixing addressing and payload.
>
> Since we chose HTTP for IPP we should rely on it for all of our addressing
> and routing, so we all seem to agree that for High Level Scenario 1 the
> URLs in the IPP operation are as you say "meaningless" In fact they were
> never there until late in the game and were added "just in case there is a
> mapping to some other transport other than HTTP" When that happens, no
> longer will IPP objects be identified with "http:" URLs, but some other
> type of addressing/naming scheme. In that case, we ought to make sure
> that there is enough info in that URL (URI, URN whatever) to get to the
> IPP printer object and not worry so much about including in the operation
> itself.
>
> I am becoming more and more convinced that it as a bad idea to put the
> URLs in there at all. We should rely on the addressing in the layer upon
> which IPP is mapped to solve the problem. I think we all agree that the
> URLs within IPP operations are not needed for HTTP. Then we try to guess
> if they are needed for other mappings? You suggest in scenarios 2 and 3
> that the embedded info might be needed for identifying a resource
> "underneath" or "behind" the IPP object. However, I wonder if this is
> true. The only addressable IPP objects are Printers and Jobs. Once a
> Printer gets a Printer request it should handle it as if it were supposed
> to get that request, and not have to check "is this really for me" That
> should be handled at a different layer. Same for a Job object. The HTTP
> level URL is all that is needed to route to the correct Job or Printer.
> So to me, scenarios 2 and 3 either collapse into one called "other" or
> expand into possibly many unexplored options. Let's not solve that
> problem now.
>
> Consider this example:
>
> If I get a postal service letter in my mail box, I open the evenlope and
> read it assuming it is for me. If I am at home, the address on the
> envelope is perhaps much simpler than if I am at work. If I am at home,
> it probably just has my name and street address. If I am at work, it
> probably has a street address, company name, mail/stop, building number,
> and my name. NOTE: **** In either case, the letter in the envelope can
> be exactly the same. ****
>
> What if the letter happens to have the address that was used at the top of
> the page? I usually just ignore it and read the letter, I don't care how
> it got to me. What if the letter happens to have the wrong address? (
> the proxy case), I still ignore it and read the letter - the letter got to
> me, it must be for me. In the proxy case, who cares what the address
> printed at the top of the page is?
>
> Summary, why do we have a solution waiting for a problem that is causing a
> different problem?
>
> Scott
>
> >>> Carl Kugler <kugler@us.ibm.com> 06/01 2:53 PM >>>
> > Scott -
> >
> > Maybe we need to step back and define the requirements before we nail
> down the
> > specification.
> >
> > Consider some high-level scenarios:
> >
> > 1) IPP over HTTP: the simplest approach here, I think, would be to
> let the
> > Request-URI take precedence. In this scenario, the IPP embedded target
> URI
> > (printer-uri, job-uri, etc.) is essentially meaningless, since any
> entity in a
> > position to read it has already been identified as the resource
> designated to
> > receive this request by the HTTP Request-URI. But this scenario
> (IPP/HTTP)
> > isn't the reason that the target URI was added to the IPP protocol. In
> fact,
> > we know that IPP/HTTP can work without IPP embedded target URIs.
> >
> > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario,
> any
> > entity in a position to read the IPP embedded target URI attributes is
> > presumably an IPP Object. Therefore, the addressing of the request to
> the
> > appropriate IPP Object is the responsibility of the transport layer
> (e.g., by
> > email address). The IPP embedded target URI is used to identify a
> resource
> > relative to the receiving IPP Object (e.g., a Job within the context of
> a
> > Printer). So it is a Relative URI.
> >
> > 3) IPP Router: Apparently there are other scenarios involving some
> kind of
> > IPP router capable of parsing an IPP request and retransmitting it to
> the
> > resource identified by the embedded target URI. I haven't seen any of
> these
> > re-route scenarios, but I think that only by working through some of
> them will
> > we come to understand what the real requirements are. Maybe we need a
> new IPP
> > embedded target URI attribute, of Absolute form, to identifiy the
> destination
> > IPP Object in a router scenario.
> > Scenario 1) could be modified to fit the general case of 2). Then the
> HTTP
> > Request-URI would identify a Printer relative to a host, and the IPP
> embedded
> > target URI would identify a resource relative to that Printer.
> >
> > - Carl
>

--------------9233C429104D40AEF3E2F6F9-- From ipp-owner@pwg.org Mon Jun 1 20:02:27 1998 Delivery-Date: Mon, 01 Jun 1998 20:02:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA03154 for ; Mon, 1 Jun 1998 20:02:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05654 for ; Mon, 1 Jun 1998 20:04:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25077 for ; Mon, 1 Jun 1998 20:02:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 19:57:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23932 for ipp-outgoing; Mon, 1 Jun 1998 19:52:59 -0400 (EDT) Message-Id: <3.0.5.32.19980601165036.009ad100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 1 Jun 1998 16:50:36 PDT To: From: Carl-Uno Manros Subject: IPP> Re: Fw: compression Cc: ipp@pwg.org, jis@mit.edu, mleech@nortel.ca In-Reply-To: <00ea01bd897b$b5c85630$91981b81@plipp.iaik.tu-graz.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org For your information, Keith Moore, Applications Area Director, has just finished reviewing the Internet Printing Protocol (IPP) drafts for RFC publication. One of his recommendations is to change the SHOULD statement for use of TLS in IPP to a SHALL. Implementors of IPP are not thrilled. How can we reference a non-existing standard document, and who will provide implementations? This again raises the question - WHAT IS HAPPENING TO TLS! WHERE IS IT? In the IETF DC Meeting in December we were told that TLS is now stable and was becoming an RFC on the IETF Standards Track shortly. We heard the same thing again in April in LA. Now we have June, and I have so far failed to see any RFCs or even any mention on this DL when they might materialize. Is somebody working on this at all? Who has the ball? Is it a secret or what? Regards, Carl-Uno Manros Chair IETF IPP WG Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 1 20:16:41 1998 Delivery-Date: Mon, 01 Jun 1998 20:16:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA03233 for ; Mon, 1 Jun 1998 20:16:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA05686 for ; Mon, 1 Jun 1998 20:19:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA25826 for ; Mon, 1 Jun 1998 20:16:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 20:12:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25186 for ipp-outgoing; Mon, 1 Jun 1998 20:05:55 -0400 (EDT) Message-Id: <199806012356.QAA03234@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 01 Jun 1998 17:01:29 -0700 To: "Scott Isaacson" , manros@cp10.es.xerox.com, http-wg@hplb.hpl.hp.com, joshco@microsoft.com, hardie@nic.nasa.gov From: Robert Herriot Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers Cc: moore@cs.utk.edu, ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_17590854==_.ALT" Sender: owner-ipp@pwg.org --=====================_17590854==_.ALT Content-Type: text/plain; charset="us-ascii" I have done a few tests with the Java WebServer to see how it works with an IPP scheme. The results are mixed. I dicovered that the request line has to be of the form: POST /servlet/printServer?killtree HTTP/1.0 and the POST fails if it of the form: POST http://woden/servlet/printServer?killtree HTTP/1.0 I found that I can change HTTP/1.0 to IPP/1.0 and things continue to work. The method getProtocol returns 'IPP/1.0' instead of 'HTTP/1.0', but the value of getScheme remains 'http' regardless of the protocol. Since there is no way to specify the scheme, except implicitly in the protocol name, the server seems to assume the scheme is http regardless of protocol. This indicates to me that there is some danger in changing to an IPP scheme if we still expect things to work with web servers. This also raises an important question. If we are changing to an "ipp" scheme and a different port, then we have fundamentally changed the protocol and that opens up many issues, such as 1) do we need for HTTP request line and headers or is everything in IPP? 2) do we need MIME syntax for wrapping the application/ipp? 3) should we add separate port for sending data since we are no longer dependent on HTTP? --=====================_17590854==_.ALT Content-Type: text/html; charset="us-ascii"
I have done a few tests with the Java WebServer to see how it works with an
IPP scheme.  The results are mixed.

I dicovered that the request line has to be of the form:
     POST /servlet/printServer?killtree HTTP/1.0

and the POST fails if it of the form:
     POST http://woden/servlet/printServer?killtree HTTP/1.0

I found that I can change HTTP/1.0 to IPP/1.0 and things continue to work. 
The method getProtocol returns 'IPP/1.0' instead of 'HTTP/1.0', but the
value of getScheme remains 'http' regardless of the protocol.  

Since there is no way to specify the scheme, except implicitly in the
protocol name, the server seems to assume the scheme is http  regardless of
protocol.

This indicates to me that there is some danger in changing to an IPP scheme
if we still expect things to work with web servers.

This also raises an important question. If we are changing to an "ipp"
scheme and a different port, then we have fundamentally changed the protocol
and that opens up many issues, such as

    1) do we need for HTTP request line and headers or is everything in IPP?
    2) do we need MIME syntax for wrapping the application/ipp?
    3) should we add separate port for sending data since we are no longer dependent on HTTP?
--=====================_17590854==_.ALT-- From ipp-owner@pwg.org Mon Jun 1 22:51:42 1998 Delivery-Date: Mon, 01 Jun 1998 22:51:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA04667 for ; Mon, 1 Jun 1998 22:51:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA06028 for ; Mon, 1 Jun 1998 22:54:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA27628 for ; Mon, 1 Jun 1998 22:51:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 1 Jun 1998 22:47:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA27026 for ipp-outgoing; Mon, 1 Jun 1998 22:44:28 -0400 (EDT) Date: Mon, 1 Jun 1998 19:34:06 -0700 (PDT) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: Carl-Uno Manros cc: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org, http-wg@hplb.hpl.hp.com Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: <3.0.5.32.19980601102001.00a0b510@garfield> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org I would strongly urge you to NOT introduce a new url scheme. I would assert that any existing proxy which doesn't reject an unknown scheme badly broken. At the very minimum, proxies would have to be configured to accept this new scheme and interpret it as HTTP. A requirement which will be fraught with failure in the implementation. I'm not aware of any proxies which would be this simple to adapt so this is speculation of the lower bound of difficulty generated by using a new scheme. (I'm also not wild about new HTTP methods as I know of existing proxies which will reject unknown methods. Don't know of any which will accept unknown methods. I'm also unaware of any firewall software which examines the HTTP request method as part of its algorithm but then I'm not a firewall expert.) A new default port may be OK but I believe unnecessary. In any case, an installation should be allowed to overload port 80 etc. if desired by over-riding the default if it isn't 80. But then I don't buy the basic premis that its necessary to distinguish between IPP (or any other HTTP-based content protocol) and HTTP. Dave Morris On Mon, 1 Jun 1998, Carl-Uno Manros wrote: > Hi, > > As most of you know already, the Internet Printing Protocol (IPP) WG has > suggested using HTTP as "transport", with the payload in the form of a MIME > object passed with the POST method. > > As part of the onging IESG review process, the Application Area Director > Keith Moore has suggested to distinguish IPP traffic from "normal" HTTP > traffic by: > > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult it would be > to configure existing web servers to accomodate the suggested changes. > > Please note that many printer vendors are not in the business of developing > web servers or HTTP servers and are dependent on getting those compoments > from other vendors. > > Please respond back to the IPP DL at: > > ipp@pwg.org > > Thanks, > > Carl-Uno Manros > Chair of the IETF IPP WG > > From ipp-owner@pwg.org Tue Jun 2 00:21:38 1998 Delivery-Date: Tue, 02 Jun 1998 00:21:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA13613 for ; Tue, 2 Jun 1998 00:21:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA06213 for ; Tue, 2 Jun 1998 00:23:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA28929 for ; Tue, 2 Jun 1998 00:21:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 00:17:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA28334 for ipp-outgoing; Tue, 2 Jun 1998 00:11:53 -0400 (EDT) Content-return: allowed Date: Mon, 1 Jun 1998 12:52:21 PDT From: "Zehler, Peter " Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers To: Scott Lawrence , ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org Scott, Will your product require no change at all if it is the front end for a standard web server and an IPP Printer? It seems this would require your product to listen to 2 ports. An alternative would be to have 2 instantiations, one for regular HTTP and one for IPP over HTTP. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Scott Lawrence [SMTP:lawrence@agranat.com] Sent: Monday, June 01, 1998 3:02 PM To: ipp@pwg.org Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers On Mon, 1 Jun 1998, Carl-Uno Manros wrote: > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult it would be > to configure existing web servers to accomodate the suggested changes. Answering for EmWeb, our embedded web server: The new scheme (1) would require a very minor change from our existing product, which requires that he scheme be 'http' if it is present at all. We'd need to allow 'ipp', and perhaps add a check to ensure that it is being used on the proper port (if that is deemed to be important). If the client does not send the scheme, then there would be no change. The new port (2) would be no change at all, since it can already operate on any port. One might wish to recognize that the default port for an 'ipp:' scheme redirect would be different than for an 'http:' redirect, but that's a very minor matter. From ipp-owner@pwg.org Tue Jun 2 09:17:13 1998 Delivery-Date: Tue, 02 Jun 1998 09:17:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA22081 for ; Tue, 2 Jun 1998 09:17:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07314 for ; Tue, 2 Jun 1998 09:19:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA02802 for ; Tue, 2 Jun 1998 09:17:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 09:07:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02077 for ipp-outgoing; Tue, 2 Jun 1998 09:06:11 -0400 (EDT) From: "Rob Polansky" To: "David W. Morris" Cc: "http-wg" , Subject: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Tue, 2 Jun 1998 09:05:32 -0400 Message-ID: <001501bd8e27$1fe3bf50$cb0115ac@raptor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-ipp@pwg.org I know of at least one :-) firewall that not only rejects unknown methods but also examines the HTTP request method as part of its "algorithm". From a protocol and security perspective, it appears to be the right thing to do. If you don't understand the method, how can you properly proxy it? Take the CONNECT method as an example. In summary, any proxy that is more than a simple packet passer (supports CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of failing to pass IPP if it uses a new scheme and/or a new method. Not that that's a bad thing... :-) -Rob Polansky > -----Original Message----- > From: David W. Morris [mailto:dwm@xpasc.com] > Sent: Monday, June 01, 1998 10:34 PM > To: Carl-Uno Manros > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > Subject: Re: Implications of introducing new scheme and port for > existing HTTP servers > > (I'm also not wild about new HTTP methods as I know of existing proxies > which will reject unknown methods. Don't know of any which will accept > unknown methods. I'm also unaware of any firewall software which examines > the HTTP request method as part of its algorithm but then I'm not a > firewall expert.) > From ipp-owner@pwg.org Tue Jun 2 09:20:40 1998 Delivery-Date: Tue, 02 Jun 1998 09:20:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA22160 for ; Tue, 2 Jun 1998 09:20:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07338 for ; Tue, 2 Jun 1998 09:22:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA03247 for ; Tue, 2 Jun 1998 09:20:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 09:15:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02117 for ipp-outgoing; Tue, 2 Jun 1998 09:07:42 -0400 (EDT) Date: Tue, 2 Jun 1998 09:07:29 -0400 (EDT) From: Scott Lawrence To: "Zehler, Peter " cc: ipp@pwg.org Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org On Mon, 1 Jun 1998, Zehler, Peter wrote: > Scott, > Will your product require no change at all if it is the front end for a > standard web server and an IPP Printer? It seems this would require your > product to listen to 2 ports. It is common for a single server to listen on multiple ports. As Peter Melquist from HP pointed out, there is even a well known port for network management over HTTP (280). Our server will listen on whatever ports the system tells it to. From ipp-owner@pwg.org Tue Jun 2 09:41:19 1998 Delivery-Date: Tue, 02 Jun 1998 09:41:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA22457 for ; Tue, 2 Jun 1998 09:41:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07404 for ; Tue, 2 Jun 1998 09:43:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA03933 for ; Tue, 2 Jun 1998 09:41:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 09:37:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA03363 for ipp-outgoing; Tue, 2 Jun 1998 09:30:00 -0400 (EDT) Message-Id: <3573FD1D.E5BAE73A@dazel.com> Date: Tue, 02 Jun 1998 08:24:45 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Carl-Uno Manros , Keith Moore Cc: ipp@pwg.org Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM PDT References: <3.0.5.32.19980529151138.00927db0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org > PWG IPP Phone Conference on 980603, 10:00 AM PDT > ================================================ > > By now I hope that everybody has seen the feedback information from Keith > Moore. In response to that I want to dedicate the next phone conference to > sort out trivial vs. more complex tasks to resolve the listed issues. > > Please read Keith's message beforehand, so we can get straight into the > discussion. You can obvioiusly express views also beforehand on the DL. I am curious about process at this point. Does Keith's response represent the official IETF response to the IPP submissions? In other words, if we respond to and satisfy all of his objections, do we have RFC's? If so, then, Keith, do you consider all comments that were submitted during the last call in forming your opinion/comments? If not, when do those comments come under consideration? I do not know how many submitted comments during last call (presumably there were some, but they probably went directly to the IESG), but it seems to me that all negative comments out to be considered by someone. I have to be honest and admit that I sent my comments directly to the IESG (without CC:ing the IPP DL), but I guess I had no idea that all of this would go into such a black hole for such a long period of time. If there is interest in discussing comments that were submitted during the last call, I would consider forwarding my comments to the list. curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jun 2 09:51:15 1998 Delivery-Date: Tue, 02 Jun 1998 09:51:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA22644 for ; Tue, 2 Jun 1998 09:51:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA07467 for ; Tue, 2 Jun 1998 09:53:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA04554 for ; Tue, 2 Jun 1998 09:51:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 09:47:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA03547 for ipp-outgoing; Tue, 2 Jun 1998 09:38:19 -0400 (EDT) Message-Id: <3573FF19.E9AA1FB7@dazel.com> Date: Tue, 02 Jun 1998 08:33:13 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Paul Moore , Keith Moore Cc: ipp@pwg.org Subject: Re: IPP> review of IPP documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Paul Moore wrote: > > Excellent point. So why the heck are we using HTTP for IPP? Although one could take this as a facetious response, it always seems to me be an important question worth asking again. If IPP and others are approved as standard application protocols built on top of HTTP, then this is a green flag that HTTP is an acceptable transport for application protocols. And we will see more. So, is the IETF supporting (even encouraging ?) application protocols to be built using HTTP as a transport? Or are these protocols that are currently being developed (IPP, WebDAV, etc) just considered test cases to see if the idea will fly? > > > -----Original Message----- > > From: Ned Freed [SMTP:Ned.Freed@innosoft.com] > > Sent: Friday, May 29, 1998 6:49 PM > > To: Keith Moore > > Cc: Paul Moore; 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu > > Subject: Re: IPP> review of IPP documents > > > > > You miss the point. The fact that people already have port 80 proxies > > > installed doesn't matter. There's no way that we're going to > > standardize > > > IPP on port 80 - HTTP already has that port, and IPP is a different > > > service than HTTP. > > > > > Once upon a time, a lot of people had email only access to the Internet. > > > That wasn't an good reason for forcing every service to run over email. > > > > My favorite example is email over FTP. We'd still be doing email that way > > if we hadn't deployed a new email service on a separate port. > > > > Ned ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jun 2 10:26:43 1998 Delivery-Date: Tue, 02 Jun 1998 10:26:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23209 for ; Tue, 2 Jun 1998 10:26:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07924 for ; Tue, 2 Jun 1998 10:28:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA05312 for ; Tue, 2 Jun 1998 10:26:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 10:22:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA04760 for ipp-outgoing; Tue, 2 Jun 1998 10:17:04 -0400 (EDT) Message-ID: <35740958.BDBEB83E@underscore.com> Date: Tue, 02 Jun 1998 10:16:56 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: walker@dazel.com, Carl-Uno Manros , Keith Moore Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM PDT References: <3.0.5.32.19980529151138.00927db0@garfield> <3573FD1D.E5BAE73A@dazel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org I'd like to see Jim Walker's comments posted to the IPP DL, as well as any others' that have been sent to the IESG and/or Keith Moore. The PWG is continually trying to understand how the IETF works (in terms of process) so that we can better mesh into its process for future protocol standards. When one or more persons submits a counter-argument to a proposed spec, you would think that the governing body (ie, the IESG) would make at least a minimal attempt to publically state why (or why not) the argument prevails in the minds of the governing body. In short, we'd like to see what the IESG thought of the counter-arguments to the IPP submission. ...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 -- ---------------------------------------------------------------------- James Walker wrote: > > > PWG IPP Phone Conference on 980603, 10:00 AM PDT > > ================================================ > > > > By now I hope that everybody has seen the feedback information from Keith > > Moore. In response to that I want to dedicate the next phone conference to > > sort out trivial vs. more complex tasks to resolve the listed issues. > > > > Please read Keith's message beforehand, so we can get straight into the > > discussion. You can obvioiusly express views also beforehand on the DL. > > I am curious about process at this point. Does Keith's response > represent the official IETF response to the IPP submissions? > In other words, if we respond to and satisfy all of his objections, > do we have RFC's? > > If so, then, Keith, do you consider all comments that were submitted > during the last call in forming your opinion/comments? If not, when > do those comments come under consideration? I do not know how many > submitted comments during last call (presumably there were some, but > they probably went directly to the IESG), but it seems to me that all > negative comments out to be considered by someone. > > I have to be honest and admit that I sent my comments directly to > the IESG (without CC:ing the IPP DL), but I guess I had no idea > that all of this would go into such a black hole for such a long > period of time. If there is interest in discussing comments that > were submitted during the last call, I would consider forwarding > my comments to the list. > > curious... > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jun 2 11:22:21 1998 Delivery-Date: Tue, 02 Jun 1998 11:22:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25709 for ; Tue, 2 Jun 1998 11:22:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08361 for ; Tue, 2 Jun 1998 11:24:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06296 for ; Tue, 2 Jun 1998 11:22:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 11:17:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05699 for ipp-outgoing; Tue, 2 Jun 1998 11:13:33 -0400 (EDT) Message-ID: From: "Vinod Valloppillil (Exchange)" To: "'Rob Polansky'" , "David W. Morris" Cc: http-wg , ipp@pwg.org Subject: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Tue, 2 Jun 1998 08:15:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2225.0) Content-Type: text/plain Sender: owner-ipp@pwg.org Rob's argument is broadly correct -- as a long term firewall design issue, method inspection (and occasionally payload inspection) will become the rule. However, as a small carrot to today's protocol designers, the vast majority of the installed base of firewalls do no method / payload inspection on HTTP data being passed through. Purely from the perspective of 'reach' there's no impediment to IPP using it's own method in the short run. > -----Original Message----- > From: Rob Polansky [SMTP:polansky@raptor.com] > Sent: Tuesday, June 02, 1998 6:06 AM > To: David W. Morris > Cc: http-wg; ipp@pwg.org > Subject: RE: Implications of introducing new scheme and port for > existing HTTP servers > > I know of at least one :-) firewall that not only rejects unknown methods > but also examines the HTTP request method as part of its "algorithm". From > a > protocol and security perspective, it appears to be the right thing to do. > If you don't understand the method, how can you properly proxy it? Take > the > CONNECT method as an example. > > In summary, any proxy that is more than a simple packet passer (supports > CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of > failing to pass IPP if it uses a new scheme and/or a new method. Not that > that's a bad thing... :-) > > -Rob Polansky > > > -----Original Message----- > > From: David W. Morris [mailto:dwm@xpasc.com] > > Sent: Monday, June 01, 1998 10:34 PM > > To: Carl-Uno Manros > > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > > Subject: Re: Implications of introducing new scheme and port for > > existing HTTP servers > > > > (I'm also not wild about new HTTP methods as I know of existing proxies > > which will reject unknown methods. Don't know of any which will accept > > unknown methods. I'm also unaware of any firewall software which > examines > > the HTTP request method as part of its algorithm but then I'm not a > > firewall expert.) > > From ipp-owner@pwg.org Tue Jun 2 11:41:49 1998 Delivery-Date: Tue, 02 Jun 1998 11:41:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25987 for ; Tue, 2 Jun 1998 11:41:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08464 for ; Tue, 2 Jun 1998 11:44:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06984 for ; Tue, 2 Jun 1998 11:41:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 11:37:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06412 for ipp-outgoing; Tue, 2 Jun 1998 11:34:02 -0400 (EDT) Message-Id: <199806021525.IAA09754@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 02 Jun 1998 08:33:48 -0700 To: "Vinod Valloppillil (Exchange)" , "'Rob Polansky'" , "David W. Morris" From: Randy Turner Subject: Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Cc: http-wg , ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The past few comments about firewalls do not (IMHO) appear to pose a problem for IPP deployment. If the majority of the installed base of firewall products do not do HTTP method inspection then thats ok. everything would work. When the "next-generation" products that can perform this type of inspection, then during installation of this new infrastructure, the administrator will then enable IPP (or WEBDAV) or whatever at that time. Ultimately, I believe firewall admins will explicitly enable internet printing or faxing or whatever, and I don't think a firewall issue should impose undue design constraints on what we (the WG) want to do. Firewall admins already do this explicitly enabling/disabling of application protocols (POP, FTP, IMAP, etc.) and I think we're just another application. I don't think these protocol designers were too bogged down in firewall issues during the development process. At least with the Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the console and enable or disable a particular application protocol. Just my (possibly more than) $0.02 Randy At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: >Rob's argument is broadly correct -- as a long term firewall design issue, >method inspection (and occasionally payload inspection) will become the >rule. > >However, as a small carrot to today's protocol designers, the vast majority >of the installed base of firewalls do no method / payload inspection on HTTP >data being passed through. Purely from the perspective of 'reach' there's >no impediment to IPP using it's own method in the short run. > >> -----Original Message----- >> From: Rob Polansky [SMTP:polansky@raptor.com] >> Sent: Tuesday, June 02, 1998 6:06 AM >> To: David W. Morris >> Cc: http-wg; ipp@pwg.org >> Subject: RE: Implications of introducing new scheme and port for >> existing HTTP servers >> >> I know of at least one :-) firewall that not only rejects unknown methods >> but also examines the HTTP request method as part of its "algorithm". From >> a >> protocol and security perspective, it appears to be the right thing to do. >> If you don't understand the method, how can you properly proxy it? Take >> the >> CONNECT method as an example. >> >> In summary, any proxy that is more than a simple packet passer (supports >> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of >> failing to pass IPP if it uses a new scheme and/or a new method. Not that >> that's a bad thing... :-) >> >> -Rob Polansky >> >> > -----Original Message----- >> > From: David W. Morris [mailto:dwm@xpasc.com] >> > Sent: Monday, June 01, 1998 10:34 PM >> > To: Carl-Uno Manros >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com >> > Subject: Re: Implications of introducing new scheme and port for >> > existing HTTP servers >> > >> > (I'm also not wild about new HTTP methods as I know of existing proxies >> > which will reject unknown methods. Don't know of any which will accept >> > unknown methods. I'm also unaware of any firewall software which >> examines >> > the HTTP request method as part of its algorithm but then I'm not a >> > firewall expert.) >> > > From ipp-owner@pwg.org Tue Jun 2 11:55:46 1998 Delivery-Date: Tue, 02 Jun 1998 11:55:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26146 for ; Tue, 2 Jun 1998 11:55:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08560 for ; Tue, 2 Jun 1998 11:58:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA07668 for ; Tue, 2 Jun 1998 11:55:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 11:51:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06817 for ipp-outgoing; Tue, 2 Jun 1998 11:40:14 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM Message-ID: <5030100021236103000002L032*@MHS> Date: Tue, 2 Jun 1998 11:39:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26146 Of course, common courtesy would have suggested that comments on the IPP submission be copied to the IPP distribution list. Making private comments to the IESG seems a bit tacky to me!!! Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 06/02/98 08:23:38 AM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: moore@cs.utk.edu, manros@cp10.es.xerox.com, walker@dazel.com Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM I'd like to see Jim Walker's comments posted to the IPP DL, as well as any others' that have been sent to the IESG and/or Keith Moore. The PWG is continually trying to understand how the IETF works (in terms of process) so that we can better mesh into its process for future protocol standards. When one or more persons submits a counter-argument to a proposed spec, you would think that the governing body (ie, the IESG) would make at least a minimal attempt to publically state why (or why not) the argument prevails in the minds of the governing body. In short, we'd like to see what the IESG thought of the counter-arguments to the IPP submission. ...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 -- ---------------------------------------------------------------------- James Walker wrote: > > > PWG IPP Phone Conference on 980603, 10:00 AM PDT > > ================================================ > > > > By now I hope that everybody has seen the feedback information from Keith > > Moore. In response to that I want to dedicate the next phone conference to > > sort out trivial vs. more complex tasks to resolve the listed issues. > > > > Please read Keith's message beforehand, so we can get straight into the > > discussion. You can obvioiusly express views also beforehand on the DL. > > I am curious about process at this point. Does Keith's response > represent the official IETF response to the IPP submissions? > In other words, if we respond to and satisfy all of his objections, > do we have RFC's? > > If so, then, Keith, do you consider all comments that were submitted > during the last call in forming your opinion/comments? If not, when > do those comments come under consideration? I do not know how many > submitted comments during last call (presumably there were some, but > they probably went directly to the IESG), but it seems to me that all > negative comments out to be considered by someone. > > I have to be honest and admit that I sent my comments directly to > the IESG (without CC:ing the IPP DL), but I guess I had no idea > that all of this would go into such a black hole for such a long > period of time. If there is interest in discussing comments that > were submitted during the last call, I would consider forwarding > my comments to the list. > > curious... > ...walker > > -- > Jim Walker > System Architect/DAZEL Wizard > DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jun 2 13:07:01 1998 Delivery-Date: Tue, 02 Jun 1998 13:07:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26901 for ; Tue, 2 Jun 1998 13:07:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08874 for ; Tue, 2 Jun 1998 13:09:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA08715 for ; Tue, 2 Jun 1998 13:06:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 13:02:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08117 for ipp-outgoing; Tue, 2 Jun 1998 12:59:11 -0400 (EDT) Date: 2 Jun 1998 16:58:20 -0000 Message-ID: <19980602165820.22395.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> review of IPP documents In-Reply-To: <01IXM6R8X7328WWC78@INNOSOFT.COM> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > You miss the point. The fact that people already have port 80 proxies > > installed doesn't matter. There's no way that we're going to standardize > > IPP on port 80 - HTTP already has that port, and IPP is a different > > service than HTTP. > > > Once upon a time, a lot of people had email only access to the Internet. > > That wasn't an good reason for forcing every service to run over email. > > My favorite example is email over FTP. We'd still be doing email that way > if we hadn't deployed a new email service on a separate port. > > Ned > > I think an important goal in distributed application design is to MINIMIZE the number of application-specific protocols required. Ideally, the designers of SMTP would have looked beyond the immediate problem of email, and devised a generic, extensible application protocol that not only met the needs of FTP and email, but would have enabled an unlimited number of additional applications. Isn't that what people are trying to do today with XML? TCP does this very successfully at its level in the stack. I think it's a waste to have to modify the infrastructure each time you want to support a new distributed application. That's like having to upgrade your computer's operating system every time you want to install a new application: something that should be minimized. Carl Kugler From ipp-owner@pwg.org Tue Jun 2 13:56:41 1998 Delivery-Date: Tue, 02 Jun 1998 13:56:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27758 for ; Tue, 2 Jun 1998 13:56:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09189 for ; Tue, 2 Jun 1998 13:59:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09671 for ; Tue, 2 Jun 1998 13:56:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 13:52:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA09101 for ipp-outgoing; Tue, 2 Jun 1998 13:48:52 -0400 (EDT) Message-Id: <357439D7.F027A9AC@dazel.com> Date: Tue, 02 Jun 1998 12:43:51 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM References: <5030100021236103000002L032*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Roger K Debry wrote: > > Of course, common courtesy would have suggested that comments > on the IPP submission be copied to the IPP distribution list. Making > private comments to the IESG seems a bit tacky to me!!! > > ... Well, tacky comments aside, I find it interesting that *none* of the comments that were made during last call, positive or negative, were copied to the IPP distribution list. Why do you think that is? Certainly, I am not the only person who was tacky enough to make private comments to the IESG about IPP, just the only one who has admitted to it so far. Also, the IESG has deemed it acceptable for last call comments to be sent to their private mailing list, so they must believe that there is a reason for it. If you have a problem with this policy, it might be more appropriate and productive to discuss it on the official IETF mailing list (which I believe is ietf@ietf.org). being tacky... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jun 2 14:31:44 1998 Delivery-Date: Tue, 02 Jun 1998 14:31:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28266 for ; Tue, 2 Jun 1998 14:31:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09418 for ; Tue, 2 Jun 1998 14:34:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10493 for ; Tue, 2 Jun 1998 14:31:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 14:27:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09933 for ipp-outgoing; Tue, 2 Jun 1998 14:23:32 -0400 (EDT) Message-Id: <3.0.5.32.19980602112050.014a6920@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 2 Jun 1998 11:20:50 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - IETF Process Cc: moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org A couple of comments on the IETF-IESG process as I understand them. 1) The comments sent to the IESG in their Last Call do not get redistributed to the IPP DL (or anybody else outside the IESG), unless the original submitter did choose to copy the IPP DL. 2) Keith Moore has done his review on behalf of the IESG, so we should consider his comments as coming from the IESG. His review included taking IESG Last Call comments into account. 3) I have checked with Keith, and he has confirmed that answering his comments is part of the IESG review process, and does not require new Last Calls in the WG or the IESG, but he would like to see that there is consensus in the WG for the replies we send back on his comments. My suggestion is that people who sent in IESG comments and want to find out why they were not considered (if they were not) do contact Keith directly to find out. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 2 15:42:25 1998 Delivery-Date: Tue, 02 Jun 1998 15:42:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29403 for ; Tue, 2 Jun 1998 15:42:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10223 for ; Tue, 2 Jun 1998 15:44:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11617 for ; Tue, 2 Jun 1998 15:42:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 15:37:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10999 for ipp-outgoing; Tue, 2 Jun 1998 15:33:46 -0400 (EDT) Message-Id: <3.0.5.32.19980602123219.01449760@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 2 Jun 1998 12:32:19 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Keith Moore's IESG Comments Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipp@pwg.org Times New RomanAs preparation for tomorrow's phone conference, I have made a stab at writing down my comments against Keith's list. I have tried to express the views of the WG rather than my personal ones, but I am prepared to stand corrected if I got some things wrong. I already had a phone conference with the editors yesteray and they will start updating the drafts with all the things considered to be "Edititorial" in my comments. Roger deBry will take over the editing of the Rationale document, as I assume that Steve Zilles will not be available to us. My comments start with CM> and follow each issue listed. We will work further on this list in the phone conference tomorrow. My intension is to get the revised drafts back to Keith within the next two weeks. As stated in another message, these fixes are part of the IESG process and can be done quickly, unless we run into disagreements about them. Carl-Uno ---- At long last I've completed my review of the IPP documents. My comments follow. Please note that we're still waiting for the TLS document to clear (sigh)... things that depend on TLS can't go through until TLS is finished. Last I heard they were waiting on resolution of some patent issues and/or an X.509 profile that allowed use of UTF-8 in printable strings. (yeech) CM> I have sent out a question to the TLS WG DL asking about status. They are currently blaming PKIK for the hold-up. I am pursuing that at present. I apologize for this haven taken so long. Keith summary: Basically I think the protocols are mostly sound, though the documents need some editorial cleanup. There are some minor technical tweaks here and there. The biggest change that I think is needed, is that IPP's use of HTTP doesn't allow a firewall to distinguish between IPP traffic and ordinary HTTP traffic. Also, IPP's insistence on using port 80 could conflict with ordinary use of that port, in those cases where the IPP server was not designed to "plug in" to the HTTP server. For these reasons, I suggest that a separate port be allocated for IPP, and an "ipp" URL defined which defaults to the IPP port rather than port 80. An alternative would be to have IPP use the PRINT method rather than POST, but to me the separate port seems cleaner and more likely to be compatible with firewalls. One could still use IPP on port 80, by using the port override notation: ipp://hostname:80/etc. CM> I sent out a question to the HTTP WG DL about the adviceabilty of introducing a new URL scheme and to allocate a new default port number to IPP. Not to my surprise, responses so far from the HTTP experts were that allocating a new port wold not cause too much of a problem, but most everybody strongly adviced against a new URL scheme. CM> The alternative proposal to use PRINT instead of POST seems more acceptable and causes less problems. Note that we now have in effect a policy of not allocating separate ports for with/without TLS. (I've asked the security ADs in IESG to review this policy, but I think it will be upheld.) Someone has an internet-draft which attempts to define a way to negotiate TLS in-band over HTTP; you might want to look at that. CM> I do not think we care about this one. Our latest solution does not dictate one or the other. As for considering a new I-Ds that is far from the standards track - forget it. similarly, using the "s" suffix on the URI type to indicate TLS/ is considered by many to be a Bad Idea; if it's necessary to specify a particular authentication and/or encryption type, it should probably be done using a URI parameter. (and it should probably be more flexible than just ";security=tls") CM> Again, we do not really care, we will do what the security groups decide - if they ever make a decision. detailed comments follow; I apologize for mixing the purely editorial (most of the comments) with the technical issues, and thus making this unnecessarily tedious to read for anyone other than the authors. but this way, I get to cross this off my list today! general: 1. In addition to the keywords defined in RFC 2119, the documents use a number of upper case terms like SHALL, SHALL NOT, NEED NOT, etc. If these terms are in upper case because they have special meanings, those meanings need to be defined somewhere, and each document that uses those terms needs to have a prominent notice (i.e. near the beginning of the document) pointing to those definitions. If the terms have their normal meanings (which from my reading seems to be the case), they should be spelled in lower case, unless there is some reason to emphasize a particular use of a term. CM> It seems doubtful that Keith has actually read RFC 2119, which states that these terms are often capitalized and uses that in RFC2119 itself. On the other hand, it appears that SHALL etc. are sometimes used when one of the words in RFC 2119 would do just as well. It would be better to keep consistent technology unless there's a good reason not to do so. CM> Editorial Note that the keywords in RFC 2119 are generally used to indicate implementation choices that would affect compliance with a standard, or very occasionally, requirements for operation of the service (as in "SMTP servers MUST accept mail addressed to Postmaster") Other uses of "MUST", "SHOULD", etc. should generally use lower case letters. For instance, the IPP design goals "MUST" be satisfied in IPP/1.0...this is not a requirement on implementation, and should be spelled "must". CM> Editorial Finally, if you need to use one of these upper cased keywords with "not", it should be "MUST NOT" or "SHALL NOT", rather than "MUST not" or SHALL not (or even "SHALL also not") to have one word upper cased and the other not, is confusing. CM> Editorial 2. there appear to be a number of artifacts in the plain text versions of the documents, which may have resulted from conversion to text from some other format. For instance, tables are poorly formatted in the text version, I saw at least one instance of overprinting, and there appear to be missing pieces of text here and there. Since the plain text versions are considered authoritative, they need to be carefully proofread. CM> Editorial draft-ietf-ipp-rat-02.txt: 1. the last paragraph (9) of section 4 may need tweaking depending on whether IPP is revised to use a different default port than HTTP<< or if it's revised to use PRINT instead of POST. CM> Editorial, once the HTTP solution is decided. 2. section 7 is actually missing the copyright notice; it only contains the license. CM> Editorial draft-ietf-ipp-req-01.txt: 1. Even though the IPP WG was told to write a requirements document, some IESG folks have pushed back on using the word "requirements" in a document title. My guess is that the title should be changed to something like "Design Goals for an Internet Printing Protocol". Either that, or many of the "requirements" need more justification to convince the reader that they're obviously requirements and not merely goals. CM> Editorial 2. Section 1: It's not clear how or why a web browser is part of a complete Internet Printing system. CM> Editorial 3. Section 2.1.4: it's not clear why a user needs to have the ability to submit a print job by reference. CM> Add text explaining it save the user to first download a large document that sits on a repository in a server. 4. Section 2.2: change "the user may only see his own jobs" to "the user might only be able to see his own jobs". CM> Editorial 5. Section 3, third paragraph, last sentence. Seems like "must properly handle this methodology" should be "must properly handle either methodology". CM> Editorial 6. Section 3.1, first paragraph. "Whenever possible, IPP ought to make use of ..." should perhaps be "Whenever reasonable,..." CM> Editorial 7. 3.1, second paragraph. "printing environments describes"... should be "printing environments described"; "document to be printed may all exist" should be "document to be printed may each exist" ; "protection are much stronger" should be "protection may be much stronger" CM> Editorial 8. 3.3, first paragraph. "shall be extensible by several means that facilitates interoperability and prevents"... should be "facilitate" and "prevent" CM> Editorial 9. section 3.3: the structure of the bulleted list is confusing; some of the bullets should apparently be subordinate to the others. 4th bullet: needs a space between "attributes" and "and" CM> Editorial 10. section 4.2. there are significant security risks associated with driver installation; I don't see any discussion of those risks. CM> Consider adding new text - although driver installation is really outside the scope of IPP v1.0. 11. section 7. there appears to be overprinting in the acknowledgements section (at least, enscript didn't handle it right) CM> Editorial 12. the document seems to assume that users will download a driver to talk to a particular printer; there's no requirement that users be able to talk to printers -- even in reduced functionality mode -- without downloading a driver. this would seem to constrain the cross-platform portability of the standard, as well as introducing security risks. (which is not to say that IPP itself has problems with this ... I think it's okay .. but the assumption that everyone who wants to talk to a printer can download and install a driver is not a valid one...it's too windows centric) CM> Editorial 13. section 9.23. do we have permission to use Kinko's and Sir Speedy's names/trademarks? If not, should probably substitute generic names. CM> Editorial 14. document is missing a security considerations section at the end. it can refer to section 4.1 but should also mention security problems related to downloading drivers. CM> Editorial draft-ietf-ipp-model-09.txt: 1. Section 2.4: should refer to TLS, not SSL3. Also, the "https" URL prefix is nonstandard. CM> Editorial, we should take out all references to SSL3 and https. 2. at the end of section 3.1.3, this is misstated: if the URL type allows a port number and one is specified, that port number must be used. if no port number is specified, the default port must be used. (if the URL type doesn't allow a port number and one is specified anyway, it's arguably a parse error on the URL and the whole operation should fail) CM> Editorial. 3. section 3.1.4.1, last paragraph: "object SHALL NOT change either of these attributes and SHALL except them as if they were valid." it's not clear (to me) what this means: doesn't this put the printer in a position where it cannot report errors in the natural language? I understand not allowing the printer to change the request, but shouldn't this be an error condition, and if so, how should it be reported? CM> Check if this an inconsistency in the document 4. section 3.2.1.2, under "Group 3: Job Object Attributes" "Printer object always uses is" should be "Printer object always uses its" CM> Editorial 5. section 4.1.1 it's not clear to me why, if anything defined as 'text' is also allowed to use 'textWithLanguage' syntax, that there are separate syntaxes for text vs. textWithLanguage. Why not either do: text = textWithLanguage | textUsingImplicitLanguage and just call everything 'text' from then on out? (which would be a purely editorial simplification) or just elimiate the implicit language form altogether? (which would be a protocol simplification) CM> Editorial, as long as we do not make changes that are visable in the protocol. 6. 4.1.2, 5th paragraph "SHALL accept, support, and return both the 'text' and 'textWithLanguage' reads as if objects are requried to *return* both syntaxes for every text attribute...not one or the other. CM> Editorial 7. section 4.1.8. if you must refer to https, please refer to it as non-standard. CM> Editorial, remove reference to https 8. section 4.1.9 what does it mean to restrict the use of utf-8 to iso 10646? why do you want to impose such a restriction? CM> Tom Hastings to check. 9. section 4.1.11 'mimeMediaType' is too short, especially given that it contains the parameters also. 127 octets would be marginal. 255 would be a lot better. (is there a reason to use 2**n-1?) CM> Any objections to increase the length? 10. section 4.2.7 does the page-ranges count page images rather than docuemnt page numbers (say in eps or pdf?) CM> Needs clarification. 11. section 4.3.1 despite widespread use of "https" etc, the URI "access method" shouldn't be used to indicate the presense or lack of "security"; when necessary to specify a particular security technology in a URI, that should be a done with a paramter (e.g. ";auth-type=digest"). CM> This is either a misunderstanding from Keith, or we have expressed things poorly. We do not have that dependency. 12. section 4.3.7 for the case where there is an IPP front-end to some other kind of printer queue, and it's not possible for the front-end to determine whether the job is 'completed' according to the IPP definition, what status should it report when the job is finished as best as can be determined? it seems like 'completed' is the right thing to do here, but this would be inconsistent with the definition. CM> We need to figure out what the right reply is. 13. section 4.4.2 the example makes it appear as if "password-printer" is a magic string in a URL, which indicates that a printer is to use basic or digest authenticaiton CM> Needs some rewording and maybe change example. 14. section 4.4.24 cleartext passwords are no longer allowed in URLs CM> So what? We do not have a problem with that, or? 15. section 5.1, last paragraph "Clients may choose to ignore any parameters that it does not understand" should be "...that they do not understand". CM> Editorial 16. section 5.4 Conforming clients MUST (not SHOULD) support TLS access. CM> Which TLS? See earlier comments. Seems controversial proposal. 17. section 6.1 If I'm not mistaken, it's inappropriate for the IPP RFC to actually name the experts. CM> Editorial Nor do I think it's okay to have PWG "specify a replacement [expert] at any time", because PWG isn't responsible to IETF in any way. Nor do I think it's okay to give PWG control over the keywoard/enum value space. IANA can delegate to PWG, but IANA should have ultimate authority. This section needs to be reviewed by IANA. CM> Tom Hastings to check with IANA. draft-ietf-ipp-protocol-05.txt: 1. Section 3.2. I probably haven't grokked how these are used, but are there enough attribute tags and value tags to have room for future expansion? CM> I hope so. 2. Section 3.9 some text appears to be missing CM> Editorial 3. section 3.11 The table in the text version is illegible. CM> Editorial 4. section 4 IPP needs its own default port and url scheme. Support for port 80 should be optional. CM> If we introduce a new default port for IPP, I think that support for 80 will still be required. 5. section 4.1 table is difficult to read CM> Editorial 6. section 4.2 it looks like there might be missing information in the accept-language row of the table. CM> Editorial 7. section 5 IPP needs its own port; support for port 80 should be optional. CM> If we introduce a new default port for IPP, I think that support for 80 will still be required. draft-ietf-ipp-lpd-ipp-map-03.txt 1. section 4.3 table is difficult to read in the text version CM> Editorial 2. section 7 change title to "Security Considerations". yes, some folks are picky about this. CM> Editorial Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 2 18:21:40 1998 Delivery-Date: Tue, 02 Jun 1998 18:21:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01083 for ; Tue, 2 Jun 1998 18:21:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA10927 for ; Tue, 2 Jun 1998 18:24:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA13873 for ; Tue, 2 Jun 1998 18:21:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 18:17:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA13345 for ipp-outgoing; Tue, 2 Jun 1998 18:15:26 -0400 (EDT) Date: 2 Jun 1998 22:14:27 -0000 Message-ID: <19980602221427.14543.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> ADM - Keith Moore's IESG Comments In-Reply-To: <3.0.5.32.19980602123219.01449760@garfield> To: ipp@pwg.org Sender: owner-ipp@pwg.org > 5. section 4.1.1 > > > it's not clear to me why, if anything defined as 'text' is also > > allowed to use 'textWithLanguage' syntax, that there are separate > > syntaxes for text vs. textWithLanguage. Why not either do: > > > text = textWithLanguage | textUsingImplicitLanguage > > > and just call everything 'text' from then on out? > > (which would be a purely editorial simplification) > > > or just elimiate the implicit language form altogether? > > (which would be a protocol simplification) > > > CM> Editorial, as long as we do not make changes > > that are visable in the protocol. > I think it's worth considering making this protocol simplification. It's pretty complicated as it stands now, with a three-level precedence hierarchy. BTW, does the current spec ALLOW a simpler Printer implementation that always returns textWithLanguage and nameWithLanguage even when the explicit language is the same as the implicit language? Can a Printer return attributes-natural-language for each job in a Get-Jobs response even if it is the same as the implicit language? From ipp-owner@pwg.org Tue Jun 2 19:37:31 1998 Delivery-Date: Tue, 02 Jun 1998 19:37:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01343 for ; Tue, 2 Jun 1998 19:37:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11154 for ; Tue, 2 Jun 1998 19:39:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14669 for ; Tue, 2 Jun 1998 19:37:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 19:32:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA14104 for ipp-outgoing; Tue, 2 Jun 1998 19:27:37 -0400 (EDT) Date: 2 Jun 1998 23:26:47 -0000 Message-ID: <19980602232647.19418.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests To: ipp@pwg.org Sender: owner-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 > I think this is actually a bit of a jump from the original proposal in > > 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 ----- > > > From ipp-owner@pwg.org Tue Jun 2 19:57:16 1998 Delivery-Date: Tue, 02 Jun 1998 19:57:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01432 for ; Tue, 2 Jun 1998 19:57:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11197 for ; Tue, 2 Jun 1998 19:59:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA15317 for ; Tue, 2 Jun 1998 19:57:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 19:52:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA14759 for ipp-outgoing; Tue, 2 Jun 1998 19:50:53 -0400 (EDT) Date: 2 Jun 1998 23:50:00 -0000 Message-ID: <19980602235000.21178.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests To: ipp@pwg.org Sender: owner-ipp@pwg.org I agreee with Scott in "URLs within IPP operations", http://www.findmail.com/list/ipp/3695.html that it as a bad idea to embed "printer-uri" in the ipp message body. I went back through the archives to see why "printer-uri" was added to IPP in the first place. > 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 I think this is actually a bit of a jump from the original proposal in "Identifying jobs in requests", http://www.findmail.com/list/ipp/1700.html which only asked for an embedded Job identifier, not an embedded Printer identifier, with the rationale that in some implementations a Job is not directly addressable and must be accessed through its containing Printer. If we accept that Printers are always directly addressable, then there's no reason to put the target printer-uri in the application/ipp message body. -Carl > > > 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 ----- > > > From ipp-owner@pwg.org Tue Jun 2 20:47:17 1998 Delivery-Date: Tue, 02 Jun 1998 20:47:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01679 for ; Tue, 2 Jun 1998 20:47:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11266 for ; Tue, 2 Jun 1998 20:49:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA16042 for ; Tue, 2 Jun 1998 20:47:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 20:42:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15465 for ipp-outgoing; Tue, 2 Jun 1998 20:37:34 -0400 (EDT) Message-ID: From: Paul Moore To: "'Randy Turner'" , "Vinod Valloppillil (Exchange)" , "'Rob Polansky'" , "David W. Morris" Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Tue, 2 Jun 1998 17:37:19 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org The issue is proxies - enablers - not firewalls - disablers. If you replace my proxy by a passthrough cable I cannot do anything, if you replace my firewall by a cable you can do anything. > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Tuesday, June 02, 1998 8:34 AM > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. Morris > Cc: http-wg; ipp@pwg.org > Subject: Re: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > The past few comments about firewalls do not (IMHO) appear to pose a > problem for IPP deployment. If the majority of the installed base of > firewall products do not do HTTP method inspection then thats ok. > everything would work. When the "next-generation" products that can > perform > this type of inspection, then during installation of this new > infrastructure, the administrator will then enable IPP (or WEBDAV) or > whatever at that time. > > Ultimately, I believe firewall admins will explicitly enable internet > printing or faxing or whatever, and I don't think a firewall issue should > impose undue design constraints on what we (the WG) want to do. > Firewall admins already do this explicitly enabling/disabling of > application protocols (POP, FTP, IMAP, etc.) and I think we're just > another > application. I don't think these protocol designers were too bogged down > in > firewall issues during the development process. At least with the > Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the > console and enable or disable a particular application protocol. > > Just my (possibly more than) $0.02 > > Randy > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > >Rob's argument is broadly correct -- as a long term firewall design > issue, > >method inspection (and occasionally payload inspection) will become the > >rule. > > > >However, as a small carrot to today's protocol designers, the vast > majority > >of the installed base of firewalls do no method / payload inspection on > HTTP > >data being passed through. Purely from the perspective of 'reach' > there's > >no impediment to IPP using it's own method in the short run. > > > >> -----Original Message----- > >> From: Rob Polansky [SMTP:polansky@raptor.com] > >> Sent: Tuesday, June 02, 1998 6:06 AM > >> To: David W. Morris > >> Cc: http-wg; ipp@pwg.org > >> Subject: RE: Implications of introducing new scheme and port for > >> existing HTTP servers > >> > >> I know of at least one :-) firewall that not only rejects unknown > methods > >> but also examines the HTTP request method as part of its "algorithm". > From > >> a > >> protocol and security perspective, it appears to be the right thing to > do. > >> If you don't understand the method, how can you properly proxy it? Take > >> the > >> CONNECT method as an example. > >> > >> In summary, any proxy that is more than a simple packet passer > (supports > >> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk > of > >> failing to pass IPP if it uses a new scheme and/or a new method. Not > that > >> that's a bad thing... :-) > >> > >> -Rob Polansky > >> > >> > -----Original Message----- > >> > From: David W. Morris [mailto:dwm@xpasc.com] > >> > Sent: Monday, June 01, 1998 10:34 PM > >> > To: Carl-Uno Manros > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > >> > Subject: Re: Implications of introducing new scheme and port for > >> > existing HTTP servers > >> > > >> > (I'm also not wild about new HTTP methods as I know of existing > proxies > >> > which will reject unknown methods. Don't know of any which will > accept > >> > unknown methods. I'm also unaware of any firewall software which > >> examines > >> > the HTTP request method as part of its algorithm but then I'm not a > >> > firewall expert.) > >> > > > From VRRP-owner@drcoffsite.com Tue Jun 2 21:07:19 1998 Delivery-Date: Tue, 02 Jun 1998 21:07:20 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01758 for ; Tue, 2 Jun 1998 21:07:19 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11319 for ; Tue, 2 Jun 1998 21:09:40 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AFF731B0388; Tue, 02 Jun 1998 20:59:35 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA20459; Tue, 2 Jun 1998 17:58:08 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA19555; Tue, 2 Jun 1998 17:57:57 -0700 (PDT) Date: Tue, 2 Jun 1998 17:57:57 -0700 (PDT) Message-Id: <199806030057.RAA19555@chimp.juniper.net> From: Tony Li To: dwhipple@microsoft.com CC: abhatt@extremenetworks.com, vrrp@drcoffsite.com In-reply-to: <4D0A23B3F74DD111ACCD00805F31D8100666B25D@red-msg-50.dns.microsoft.com> (message from David Whipple on Tue, 2 Jun 1998 17:51:05 -0700) Subject: Re: Gratuitous ARP Precedence: bulk Sender: VRRP-owner@drcoffsite.com | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about | which Unix versions support it. So how does that help the legacy systems that VRRP/HSRP was trying to fix? Tony From VRRP-owner@drcoffsite.com Tue Jun 2 21:42:30 1998 Delivery-Date: Tue, 02 Jun 1998 21:42:30 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01861 for ; Tue, 2 Jun 1998 21:42:29 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11368 for ; Tue, 2 Jun 1998 21:44:48 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A707115C0394; Tue, 02 Jun 1998 21:29:43 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id SAA21537; Tue, 2 Jun 1998 18:28:16 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id SAA19641; Tue, 2 Jun 1998 18:28:05 -0700 (PDT) Date: Tue, 2 Jun 1998 18:28:05 -0700 (PDT) Message-Id: <199806030128.SAA19641@chimp.juniper.net> From: Tony Li To: dwhipple@microsoft.com CC: abhatt@extremenetworks.com, vrrp@drcoffsite.com In-reply-to: <4D0A23B3F74DD111ACCD00805F31D8100666B25E@red-msg-50.dns.microsoft.com> (message from David Whipple on Tue, 2 Jun 1998 18:12:04 -0700) Subject: Re: Gratuitous ARP Precedence: bulk Sender: VRRP-owner@drcoffsite.com David, I was asking about systems that do not support router discovery. New operating systems that do not support router discovery are clearly simply flawed. BSD certainly now supports router discovery. Does Win98? NT? The ENTIRE point of HSRP was to support these legacy systems. Router discovery is a clearly better solution in every respect. I won't claim to understand the technical design goals for VRRP. The non-technical ones are obvious. Tony | I think that there are actually quite a few systems which do support | Gratuitous ARP which it does fix. Two examples were given (NT, and BSD | 4.3/4.4). I am sure that there are many systems which do not support it, | but I am not sure that VRRP was designed to fix these legacy systems. Maybe | HSRP was... | | Thanks. | David Whipple. | | -----Original Message----- | From: Tony Li [mailto:tli@juniper.net] | Sent: Tuesday, June 02, 1998 5:58 PM | To: David Whipple | Cc: abhatt@extremenetworks.com; vrrp@drcoffsite.com | Subject: Re: Gratuitous ARP | | | | | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure | about | | which Unix versions support it. | | So how does that help the legacy systems that VRRP/HSRP was trying to fix? | | Tony | From VRRP-owner@drcoffsite.com Tue Jun 2 21:54:45 1998 Delivery-Date: Tue, 02 Jun 1998 21:54:46 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01895 for ; Tue, 2 Jun 1998 21:54:45 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11402 for ; Tue, 2 Jun 1998 21:57:02 -0400 (EDT) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A97F11EB0394; Tue, 02 Jun 1998 21:40:15 +03d00 Received: from ucxaxp.ucx.lkg.dec.com (ucxaxp.ucx.lkg.dec.com [16.20.208.53]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id VAA20924 for ; Tue, 2 Jun 1998 21:38:48 -0400 (EDT) Received: by ucxaxp.ucx.lkg.dec.com (UCX V4.2-21A, OpenVMS V7.1 Alpha); Tue, 2 Jun 1998 21:38:37 -0400 From: "M. T. Hollinger" To: "David Whipple" , Subject: Re: Gratuitous ARP Date: Tue, 2 Jun 1998 21:35:58 -0400 Message-ID: <01bd8e8f$f58bf6a0$cf501410@BigBrain.ucx.lkg.dec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Precedence: bulk Sender: VRRP-owner@drcoffsite.com >Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about >which Unix versions support it. Sorry, but I think you are mistaken. It works fine on Windows 95, and all the other legacy systems I have tried. I just did a quick test, using a Windows 95 system and two OpenVMS systems. The OpenVMS systems send out unsolicited ARP broadcasts every time you create a new interface (or add an IP address to an existing interface). I watched the output from "arp -a" in an MS-DOS window on the Windows 95 system as I created interfaces on the two OpenVMS systems, in turn, using the same IP address. The ARP cache on the Windows 95 system was immediately updated as I did this, repeated several times. In fact, the particular software product I work on (UCX) relies on other hosts updating their ARP caches upon receipt of such unsolicited broadcasts in order to support our cluster alias failover feature. Although our product has been on the market 10 years now, and has developed a large installed base, I have heard no complaints about cluster alias not working from any particular vendor's client hosts. For this reason, I have repeatedly opposed the use of a shared MAC address by VRRP. It confuses bridges and hubs, complicates troubleshooting, and makes VRRP harder to implement. I'll say it again, since the topic has arisen: there is no reason to require a shared MAC address. At most, this should be an optional provision in VRRP for those vendors who ill-advisedly wish to implement it. - Mark From ipp-owner@pwg.org Wed Jun 3 01:58:31 1998 Delivery-Date: Wed, 03 Jun 1998 01:58:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA13673 for ; Wed, 3 Jun 1998 01:58:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA11876 for ; Wed, 3 Jun 1998 02:00:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA17383 for ; Wed, 3 Jun 1998 01:58:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 01:52:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA16824 for ipp-outgoing; Wed, 3 Jun 1998 01:49:29 -0400 (EDT) Message-Id: <199806030541.WAA13874@slafw.enet.sharplabs.com> From: "Randy Turner" To: "Carl Kugler" , Subject: Re: IPP> Identifying jobs in requests Date: Tue, 2 Jun 1998 18:55:04 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org The reason we have URIs in the message body is that from very early on we decided to rely on URIs as object identifiers WITHIN the core IPP protocol. The problem we are having at the moment is reconciling this decision with the fact that our lower layer transport protocol also uses the same identifier (in some circumstances), and we wanted our core IPP to be transport independent. By the way, concerning Paul's earlier comment about proxies being the issue, I'm assuming that if we make NO changes to the current specs, that proxies are NOT an issue. Proxies rang the warning bell when it was suggested we mandate other port numbers and/or HTTP methods. Is this not the case? Randy ---------- > From: Carl Kugler > To: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > Date: Tuesday, June 02, 1998 4:50 PM > > I agreee with Scott in "URLs within IPP operations", > http://www.findmail.com/list/ipp/3695.html > that it as a bad idea to embed "printer-uri" in the ipp message body. I went back through the archives to see why "printer-uri" was added to IPP in the first place. > > > 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 > > I think this is actually a bit of a jump from the original proposal in > "Identifying jobs in requests", > http://www.findmail.com/list/ipp/1700.html > which only asked for an embedded Job identifier, not an embedded Printer identifier, with the rationale that in some implementations a Job is not directly addressable and must be accessed through its containing Printer. > > If we accept that Printers are always directly addressable, then there's no reason to put the target printer-uri in the application/ipp message body. > > -Carl > > > > > > 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 ----- > > > > > > From ipp-owner@pwg.org Wed Jun 3 09:08:42 1998 Delivery-Date: Wed, 03 Jun 1998 09:08:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16025 for ; Wed, 3 Jun 1998 09:08:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12683 for ; Wed, 3 Jun 1998 09:11:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA18532 for ; Wed, 3 Jun 1998 09:08:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 08:57:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA17962 for ipp-outgoing; Wed, 3 Jun 1998 08:56:10 -0400 (EDT) From: "Rob Polansky" To: "Paul Moore" Cc: "http-wg" , Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 08:55:27 -0400 Message-ID: <000e01bd8eee$e175db40$cb0115ac@raptor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipp@pwg.org This kind of flamebait is not really helpful to our discussion. Firewalls serve legitimate technical and business needs as our friends from Microsoft know, and those firewalls with application proxies look at protocols from a different point of view than your typical caching proxies. The beauty of it is that protocol compliant implementations from either the firewall or the cache point of view will interoperate. The difference is when they encounter something unexpected. Firewalls by definition must "fail closed" so as not to make their protected resources vulnerable to attacks; most other software makes a best effort to pass data. I don't see anything wrong with that difference. Once again, if IPP uses existing methods and schemes, it should be passable through all proxies without trouble. Add a new method and/or scheme i.e. CHANGE THE STANDARD, and you should expect that existing implemenations will not understand it and some (not many) may not pass it. -Rob Polansky > -----Original Message----- > From: Paul Moore [mailto:paulmo@microsoft.com] > Sent: Tuesday, June 02, 1998 8:37 PM > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob Polansky'; David > W. Morris > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > The issue is proxies - enablers - not firewalls - disablers. If > you replace > my proxy by a passthrough cable I cannot do anything, if you replace my > firewall by a cable you can do anything. > > > -----Original Message----- > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > Sent: Tuesday, June 02, 1998 8:34 AM > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. Morris > > Cc: http-wg; ipp@pwg.org > > Subject: Re: IPP> RE: Implications of introducing new scheme and port > > for existing HTTP servers > > > > > > The past few comments about firewalls do not (IMHO) appear to pose a > > problem for IPP deployment. If the majority of the installed base of > > firewall products do not do HTTP method inspection then thats ok. > > everything would work. When the "next-generation" products that can > > perform > > this type of inspection, then during installation of this new > > infrastructure, the administrator will then enable IPP (or WEBDAV) or > > whatever at that time. > > > > Ultimately, I believe firewall admins will explicitly enable internet > > printing or faxing or whatever, and I don't think a firewall > issue should > > impose undue design constraints on what we (the WG) want to do. > > Firewall admins already do this explicitly enabling/disabling of > > application protocols (POP, FTP, IMAP, etc.) and I think we're just > > another > > application. I don't think these protocol designers were too bogged down > > in > > firewall issues during the development process. At least with the > > Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the > > console and enable or disable a particular application protocol. > > > > Just my (possibly more than) $0.02 > > > > Randy > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > >Rob's argument is broadly correct -- as a long term firewall design > > issue, > > >method inspection (and occasionally payload inspection) will become the > > >rule. > > > > > >However, as a small carrot to today's protocol designers, the vast > > majority > > >of the installed base of firewalls do no method / payload inspection on > > HTTP > > >data being passed through. Purely from the perspective of 'reach' > > there's > > >no impediment to IPP using it's own method in the short run. > > > > > >> -----Original Message----- > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > >> To: David W. Morris > > >> Cc: http-wg; ipp@pwg.org > > >> Subject: RE: Implications of introducing new scheme and port for > > >> existing HTTP servers > > >> > > >> I know of at least one :-) firewall that not only rejects unknown > > methods > > >> but also examines the HTTP request method as part of its "algorithm". > > From > > >> a > > >> protocol and security perspective, it appears to be the > right thing to > > do. > > >> If you don't understand the method, how can you properly > proxy it? Take > > >> the > > >> CONNECT method as an example. > > >> > > >> In summary, any proxy that is more than a simple packet passer > > (supports > > >> CONNECT, protocol conversion, proxy authentication, etc.) > runs the risk > > of > > >> failing to pass IPP if it uses a new scheme and/or a new method. Not > > that > > >> that's a bad thing... :-) > > >> > > >> -Rob Polansky > > >> > > >> > -----Original Message----- > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > >> > Sent: Monday, June 01, 1998 10:34 PM > > >> > To: Carl-Uno Manros > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > > >> > Subject: Re: Implications of introducing new scheme and port for > > >> > existing HTTP servers > > >> > > > >> > (I'm also not wild about new HTTP methods as I know of existing > > proxies > > >> > which will reject unknown methods. Don't know of any which will > > accept > > >> > unknown methods. I'm also unaware of any firewall software which > > >> examines > > >> > the HTTP request method as part of its algorithm but then I'm not a > > >> > firewall expert.) > > >> > > > > > From ipp-owner@pwg.org Wed Jun 3 09:31:58 1998 Delivery-Date: Wed, 03 Jun 1998 09:31:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16410 for ; Wed, 3 Jun 1998 09:31:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12821 for ; Wed, 3 Jun 1998 09:34:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA19143 for ; Wed, 3 Jun 1998 09:31:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 09:27:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA18616 for ipp-outgoing; Wed, 3 Jun 1998 09:25:55 -0400 (EDT) From: "Rob Polansky" To: "Paul Moore" , "http-wg" , Subject: IPP> apologies Date: Wed, 3 Jun 1998 09:25:25 -0400 MIME-Version: 1.0 Message-ID: <001c01bd8ef3$111cf730$cb0115ac@raptor.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0014_01BD8ED1.89A4F440"; protocol="application/x-pkcs7-signature"; micalg=SHA-1 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BD8ED1.89A4F440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perhaps I misread Paul's previous message and replied with redundant and unnecessary verbiage. So I'm sorry for wasting your bandwidth. Now back to our regularly scheduled programs... Hey mister, your shopping cart is rolling down the highway! http://www.ultranet.com/~polansky/ http://nairobi.raptor.com/users/rpolansky/ AIM: polanskyr ------=_NextPart_000_0014_01BD8ED1.89A4F440 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGLzCCAn0w ggHmoAMCAQICFHUTa1jzgGlXdaaiTVkQTZzqdkrxMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NzA2MjQwNzAwMDBaFw05OTA2MjQwNzAw MDBaMGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UE CxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAthSmz03QBQ3YyiPQb6q0KZJjjiz4b5bXLp12SxGxNo1XycP9HMa6 /h4IujPKleq+41vNBqi3eR1EKu1z8rFSg2gQcGSR1z5r+fddnRRDm26XRZiBR9Ety927ctdMP3Gq 4kDyVDm8Fu7PfOy62z9sKrMWsYYSna6TNNW41dD3PqkCAwEAAaMzMDEwEQYJYIZIAYb4QgEBBAQD AgEGMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAJIMS+m6 k83/2uZg/Z5kA2YVL1Y8OExoSkfF86uPJdlmQ3NDFXNEvhRIgVp3DMx66tmxvPKL/xGx3xRQSNxl HQuJ+aFeSFJv7bVr9LgITDjwuYlnKQ/g4Df3puvU9NVCqV39veeefBvnT4UtBKFgLoW46+L67xQF JhUYVW8ToR1xMIIDqjCCAxOgAwIBAgIQVVx6VnindCwSJA2VCPpMBDANBgkqhkiG9w0BAQQFADBi MREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1Zl cmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwHhcNOTcxMTA3MDAwMDAw WhcNOTgxMTA3MjM1OTU5WjCCAR8xETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2Ny aWJlcjFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyBJbmNvcnAuIGJ5 IFJlZi4sTElBQi5MVEQoYyk5NjEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh cGUgRnVsbCBTZXJ2aWNlMRowGAYDVQQDExFSb2JlcnQgTSBQb2xhbnNreTEiMCAGCSqGSIb3DQEJ ARYTcG9sYW5za3lAcmFwdG9yLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC/OtWXCJMJeBO1 f0tsiCwHeCCEOpQvtd5QN+9xR2VZMltTIwW5czhear73HcDqKSQpa7cA7obsbqg7xCUrAPO/AgMB AAGjgeUwgeIwCQYDVR0TBAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMBAGCmCGSAGG+EUB BgMEAhYAMA0GCSqGSIb3DQEBBAUAA4GBAJB2xb+p6uwV5gXqFpK1eZmu2cQowbd0dBCY1SBtlyOh taATewj3XroSABiwgfDvh7C5Q25Gp14J+ZTN8srGNr7ErdKrJEa52X/D+I7NSLU/gF34oUkJM6mt 5fgqwI3qYz2RghJGQvNqxnvVAXfYn0XPD3b7T+I3fNe5anGdrUtMMYICHjCCAhoCAQEwdjBiMREw DwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlT aWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEFVcelZ4p3QsEiQNlQj6TAQw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN OTgwNjAzMTMyNTI0WjAjBgkqhkiG9w0BCQQxFgQUhfGEtpwJzx16MZnqQkwRpkoJxKowWAYJKoZI hvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjERMA8GA1UEBxMI SW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFz cyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyAhBVXHpWeKd0LBIkDZUI+kwEMA0GCSqGSIb3 DQEBAQUABEAZvxDHD+RYkZOPi6P2v1ds6XHzIoHPTUh/WsplfL9svpAO84j1l3FpZxwdPMRDsUj/ nkdAezx4J8e5osZxF4GCAAAAAAAA ------=_NextPart_000_0014_01BD8ED1.89A4F440-- From ipp-owner@pwg.org Wed Jun 3 11:52:38 1998 Delivery-Date: Wed, 03 Jun 1998 11:52:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA19916 for ; Wed, 3 Jun 1998 11:52:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA13935 for ; Wed, 3 Jun 1998 11:55:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA20075 for ; Wed, 3 Jun 1998 11:52:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 11:47:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19493 for ipp-outgoing; Wed, 3 Jun 1998 11:43:00 -0400 (EDT) Date: 3 Jun 1998 15:41:51 -0000 Message-ID: <19980603154151.12474.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <199806030541.WAA13874@slafw.enet.sharplabs.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > The reason we have URIs in the message body is that from very early on we > decided to rely on URIs as object identifiers WITHIN the core IPP protocol. But there is no reason to put a Printer identifier inside a request that is addressed to the Printer that reads the request. At one time, people were proposing some kind of dispatching or routing IPP Object that would receive IPP requests and route them based on the embedded "printer-uri". But the final decision was that the HTTP Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the IPP Object that receives the request must be the target. > The problem we are having at the moment is reconciling this decision with > the fact that our lower layer transport protocol also uses the same > identifier (in some circumstances), and we wanted our core IPP to be > transport independent. > > By the way, concerning Paul's earlier comment about proxies being the > issue, I'm assuming that if we make NO changes to the current specs, that > proxies are NOT an issue. Proxies rang the warning bell when it was > suggested we mandate other port numbers and/or HTTP methods. Is this not > the case? > There could be a problem if a proxy rewrites the Request-URI in any way. Certainly he final proxy in the chain will translate the Request-URI from absolute to relative form. Whether or not these forms are considered the same for purposes of comparison with "printer-uri" is something we haven't worked out yet. Also, doesn't your TLS for IPP proposal require server redirects for server-initiated security? Won't that involve rewriting the Request-URI? > Randy > Carl > > ---------- > > From: Carl Kugler > > To: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > Date: Tuesday, June 02, 1998 4:50 PM > > > > I agreee with Scott in "URLs within IPP operations", > > http://www.findmail.com/list/ipp/3695.html > > that it as a bad idea to embed "printer-uri" in the ipp message body. I > went back through the archives to see why "printer-uri" was added to IPP in > the first place. > > > > > 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 > > > > I think this is actually a bit of a jump from the original proposal in > > "Identifying jobs in requests", > > http://www.findmail.com/list/ipp/1700.html > > which only asked for an embedded Job identifier, not an embedded Printer > identifier, with the rationale that in some implementations a Job is not > directly addressable and must be accessed through its containing Printer. > > > > If we accept that Printers are always directly addressable, then there's > no reason to put the target printer-uri in the application/ipp message > body. > > > > -Carl > > > > > > > > > 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 ----- > > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 12:17:17 1998 Delivery-Date: Wed, 03 Jun 1998 12:17:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20849 for ; Wed, 3 Jun 1998 12:17:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14122 for ; Wed, 3 Jun 1998 12:19:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA20746 for ; Wed, 3 Jun 1998 12:17:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:12:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20160 for ipp-outgoing; Wed, 3 Jun 1998 12:07:32 -0400 (EDT) Message-Id: <199806031559.IAA15622@slafw.enet.sharplabs.com> From: "Randy Turner" To: Subject: Re: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 09:03:32 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org We use URIs to identify IPP objects. If we want IPP to maintain transport-independence, then we will always need to have some type of valid URI denoting the target of an IPP request inside our protocol. Its just in the current case of HTTP, the information is redundant in some cases, and could be misleading for some implementations. What we need is some method or algorithm that recognizes the relationship between transport and IPP URIs, but at the same time provides a transport-independent naming scope (still a URI), that is independent of the HTTP transport's treatment of the HTTP URI. At the moment, it seems like our current specs are the least vulnerable to problems resulting from HTTP intermediaries. Also, my TLS proposal did specify redirects as one way of accomplishing secure IPP. The other way was only publishing the secure form of the URI. Also, there is a third way that has been proposed, using in-band SASL negotiation ( which I think is probably best for a server that supports both secure and non-secure IPP ). Randy ---------- > From: Carl Kugler > To: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > Date: Wednesday, June 03, 1998 8:41 AM > > > > > The reason we have URIs in the message body is that from very early on we > > decided to rely on URIs as object identifiers WITHIN the core IPP protocol. > > But there is no reason to put a Printer identifier inside a request that is addressed to the Printer that reads the request. > > At one time, people were proposing some kind of dispatching or routing IPP Object that would receive IPP requests and route them based on the embedded "printer-uri". But the final decision was that the HTTP Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the IPP Object that receives the request must be the target. > > > The problem we are having at the moment is reconciling this decision with > > the fact that our lower layer transport protocol also uses the same > > identifier (in some circumstances), and we wanted our core IPP to be > > transport independent. > > > > By the way, concerning Paul's earlier comment about proxies being the > > issue, I'm assuming that if we make NO changes to the current specs, that > > proxies are NOT an issue. Proxies rang the warning bell when it was > > suggested we mandate other port numbers and/or HTTP methods. Is this not > > the case? > > > > There could be a problem if a proxy rewrites the Request-URI in any way. Certainly he final proxy in the chain will translate the Request-URI from absolute to relative form. Whether or not these forms are considered the same for purposes of comparison with "printer-uri" is something we haven't worked out yet. > > Also, doesn't your TLS for IPP proposal require server redirects for server-initiated security? Won't that involve rewriting the Request-URI? > > > Randy > > > > Carl > > > > > ---------- > > > From: Carl Kugler > > > To: ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > Date: Tuesday, June 02, 1998 4:50 PM > > > > > > I agreee with Scott in "URLs within IPP operations", > > > http://www.findmail.com/list/ipp/3695.html > > > that it as a bad idea to embed "printer-uri" in the ipp message body. I > > went back through the archives to see why "printer-uri" was added to IPP in > > the first place. > > > > > > > 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 > > > > > > I think this is actually a bit of a jump from the original proposal in > > > "Identifying jobs in requests", > > > http://www.findmail.com/list/ipp/1700.html > > > which only asked for an embedded Job identifier, not an embedded Printer > > identifier, with the rationale that in some implementations a Job is not > > directly addressable and must be accessed through its containing Printer. > > > > > > If we accept that Printers are always directly addressable, then there's > > no reason to put the target printer-uri in the application/ipp message > > body. > > > > > > -Carl > > > > > > > > > > > > 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 ----- > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 12:22:25 1998 Delivery-Date: Wed, 03 Jun 1998 12:22:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20989 for ; Wed, 3 Jun 1998 12:22:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14151 for ; Wed, 3 Jun 1998 12:24:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21356 for ; Wed, 3 Jun 1998 12:22:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:18:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20186 for ipp-outgoing; Wed, 3 Jun 1998 12:12:13 -0400 (EDT) Message-ID: From: Paul Moore To: "'Rob Polansky'" Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 09:12:02 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org I just want to be clear on what I am trying to say:- Firewalls are a completely legitimate and valuable tool in the Internet and I think that issues associtaed with IPP and its penetration or otherwise through them are extremely important. Having said that I think that the proxy issue is the more important one because:- a) This is how most businesses users access the Internet b) They invert the firewall model (a firewall blocks, a proxy enables) If we use a mechanism not carried by the current proxy installed base then the majority of business users will not be able to use IPP to talk to 'printers' on the Internet. This would be a big change. I do not place a value judement on this - I merely point out the enormity of the change that would occur. I should point out that at one of the first IPP meeting attended by MS we pointed out that using HTTP primarily as a means of 'stealthing' through firewalls was totally bogus and this continues to be our position. The PWG came to an uneasy agreement that the 'firewall issue' was no longer open for debate since the group divided in two on it and would not be reconciled. > -----Original Message----- > From: Rob Polansky [SMTP:polansky@raptor.com] > Sent: Wednesday, June 03, 1998 5:55 AM > To: Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > This kind of flamebait is not really helpful to our discussion. Firewalls > serve legitimate technical and business needs as our friends from > Microsoft > know, and those firewalls with application proxies look at protocols from > a > different point of view than your typical caching proxies. The beauty of > it > is that protocol compliant implementations from either the firewall or the > cache point of view will interoperate. The difference is when they > encounter > something unexpected. Firewalls by definition must "fail closed" so as not > to make their protected resources vulnerable to attacks; most other > software > makes a best effort to pass data. I don't see anything wrong with that > difference. > > Once again, if IPP uses existing methods and schemes, it should be > passable > through all proxies without trouble. Add a new method and/or scheme i.e. > CHANGE THE STANDARD, and you should expect that existing implemenations > will > not understand it and some (not many) may not pass it. > > -Rob Polansky > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Tuesday, June 02, 1998 8:37 PM > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob Polansky'; David > > W. Morris > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new scheme and port > > for existing HTTP servers > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > you replace > > my proxy by a passthrough cable I cannot do anything, if you replace my > > firewall by a cable you can do anything. > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. > Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: Re: IPP> RE: Implications of introducing new scheme and port > > > for existing HTTP servers > > > > > > > > > The past few comments about firewalls do not (IMHO) appear to pose a > > > problem for IPP deployment. If the majority of the installed base of > > > firewall products do not do HTTP method inspection then thats ok. > > > everything would work. When the "next-generation" products that can > > > perform > > > this type of inspection, then during installation of this new > > > infrastructure, the administrator will then enable IPP (or WEBDAV) or > > > whatever at that time. > > > > > > Ultimately, I believe firewall admins will explicitly enable internet > > > printing or faxing or whatever, and I don't think a firewall > > issue should > > > impose undue design constraints on what we (the WG) want to do. > > > Firewall admins already do this explicitly enabling/disabling of > > > application protocols (POP, FTP, IMAP, etc.) and I think we're just > > > another > > > application. I don't think these protocol designers were too bogged > down > > > in > > > firewall issues during the development process. At least with the > > > Checkpoint Firewall-1 product, it takes about 45 seconds to bring up > the > > > console and enable or disable a particular application protocol. > > > > > > Just my (possibly more than) $0.02 > > > > > > Randy > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > >Rob's argument is broadly correct -- as a long term firewall design > > > issue, > > > >method inspection (and occasionally payload inspection) will become > the > > > >rule. > > > > > > > >However, as a small carrot to today's protocol designers, the vast > > > majority > > > >of the installed base of firewalls do no method / payload inspection > on > > > HTTP > > > >data being passed through. Purely from the perspective of 'reach' > > > there's > > > >no impediment to IPP using it's own method in the short run. > > > > > > > >> -----Original Message----- > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > >> To: David W. Morris > > > >> Cc: http-wg; ipp@pwg.org > > > >> Subject: RE: Implications of introducing new scheme and port > for > > > >> existing HTTP servers > > > >> > > > >> I know of at least one :-) firewall that not only rejects unknown > > > methods > > > >> but also examines the HTTP request method as part of its > "algorithm". > > > From > > > >> a > > > >> protocol and security perspective, it appears to be the > > right thing to > > > do. > > > >> If you don't understand the method, how can you properly > > proxy it? Take > > > >> the > > > >> CONNECT method as an example. > > > >> > > > >> In summary, any proxy that is more than a simple packet passer > > > (supports > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > runs the risk > > > of > > > >> failing to pass IPP if it uses a new scheme and/or a new method. > Not > > > that > > > >> that's a bad thing... :-) > > > >> > > > >> -Rob Polansky > > > >> > > > >> > -----Original Message----- > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > >> > To: Carl-Uno Manros > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > http-wg@hplb.hpl.hp.com > > > >> > Subject: Re: Implications of introducing new scheme and port for > > > >> > existing HTTP servers > > > >> > > > > >> > (I'm also not wild about new HTTP methods as I know of existing > > > proxies > > > >> > which will reject unknown methods. Don't know of any which will > > > accept > > > >> > unknown methods. I'm also unaware of any firewall software which > > > >> examines > > > >> > the HTTP request method as part of its algorithm but then I'm not > a > > > >> > firewall expert.) > > > >> > > > > > > > From ipp-owner@pwg.org Wed Jun 3 12:35:29 1998 Delivery-Date: Wed, 03 Jun 1998 12:35:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA21428 for ; Wed, 3 Jun 1998 12:35:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14261 for ; Wed, 3 Jun 1998 12:37:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21975 for ; Wed, 3 Jun 1998 12:35:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:31:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21413 for ipp-outgoing; Wed, 3 Jun 1998 12:25:08 -0400 (EDT) Message-ID: <357578D3.F99ABB54@underscore.com> Date: Wed, 03 Jun 1998 12:24:51 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests References: <19980603154151.12474.qmail@m2.findmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Carl Kugler wrote: > At one time, people were proposing some kind of dispatching or routing IPP > Object that would receive IPP requests and route them based on the embedded > "printer-uri". I was one of those people suggesting demultiplexing/dispatching, but only within an HTTP server environment. As such, the server- side component (CGI script, servlet, etc) would use the HTTP header component to discriminate the real target. > But the final decision was that the HTTP Request-URI and the embedded > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives > the request must be the target. Did we actually come to a final decision? I didn't read that we had. (Maybe I'm missing a message or two on this subject?) > There could be a problem if a proxy rewrites the Request-URI in any way. Yeah, this worries me, too. We definitely need some serious implementation experience to better understand the ramifications of this situation. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 12:56:29 1998 Delivery-Date: Wed, 03 Jun 1998 12:56:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA22092 for ; Wed, 3 Jun 1998 12:56:29 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14391 for ; Wed, 3 Jun 1998 12:58:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23498 for ; Wed, 3 Jun 1998 12:56:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:45:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21587 for ipp-outgoing; Wed, 3 Jun 1998 12:32:33 -0400 (EDT) Message-ID: <35757A93.5F115C33@underscore.com> Date: Wed, 03 Jun 1998 12:32:19 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Randy Turner CC: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests References: <199806031559.IAA15622@slafw.enet.sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Randy Turner wrote: > > We use URIs to identify IPP objects. If we want IPP to maintain > transport-independence, then we will always need to have some type of valid > URI denoting the target of an IPP request inside our protocol. Not necessarily. Sure, in the case of a demultiplexing front-end, it would be necessary to have the target embedded in the protocol message, but not necessary for single-Printer implementations. I don't have a problem with embedding the target URI in the PDU, but if we get into a big mess with regard to reconciling a similar target in the outer/lower transport level (eg, HTTP), then we might want to consider pulling out the embedded target URI. It would be nice to hear from others on this topic. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 12:58:58 1998 Delivery-Date: Wed, 03 Jun 1998 12:58:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA22188 for ; Wed, 3 Jun 1998 12:58:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14419 for ; Wed, 3 Jun 1998 13:01:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23883 for ; Wed, 3 Jun 1998 12:58:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:46:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22059 for ipp-outgoing; Wed, 3 Jun 1998 12:40:03 -0400 (EDT) Message-ID: <35757C5A.D0AAF51C@underscore.com> Date: Wed, 03 Jun 1998 12:39:54 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Paul Moore wrote: > I should point out that at one of the first IPP meeting attended by MS we > pointed out that using HTTP primarily as a means of 'stealthing' through > firewalls was totally bogus and this continues to be our position. The PWG > came to an uneasy agreement that the 'firewall issue' was no longer open for > debate since the group divided in two on it and would not be reconciled. For fear of sounding like a broken record, let me once again point out that during the initial IPP BOF (San Jose, Dec '96), Keith Moore stated (in response to stealthing thru firewalls) that if the IPP WG came up with a generally useful and improved printing protocol, then the firewall folks would probably not have any problem in making whatever (reasonable) accomodations for IPP in their products. Yet, some highly vocal IPP participants insisted on ignoring that advice and continued to press for generic stealth capabilities. This is truly unfortunate. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 13:01:04 1998 Delivery-Date: Wed, 03 Jun 1998 13:01:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22260 for ; Wed, 3 Jun 1998 13:01:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14432 for ; Wed, 3 Jun 1998 13:03:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA24121 for ; Wed, 3 Jun 1998 13:01:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:48:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22225 for ipp-outgoing; Wed, 3 Jun 1998 12:46:48 -0400 (EDT) Message-Id: <199806031638.JAA15982@slafw.enet.sharplabs.com> From: "Randy Turner" To: "Jay Martin" Cc: Subject: Re: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 09:42:28 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org The demultiplexing front-end is not IPP, and is therefore some type of "transport-helper". While the IPP protocol document must stand on its own, independent of any such transport, and therefore identifiers within the protocol would still be mandatory ( Of course, my argument is entirely based upon the WG's decision that IPP must be transport independent ). Randy ---------- > From: Jay Martin > To: Randy Turner > Cc: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > Date: Wednesday, June 03, 1998 9:32 AM > > Randy Turner wrote: > > > > We use URIs to identify IPP objects. If we want IPP to maintain > > transport-independence, then we will always need to have some type of valid > > URI denoting the target of an IPP request inside our protocol. > > Not necessarily. Sure, in the case of a demultiplexing front-end, > it would be necessary to have the target embedded in the protocol > message, but not necessary for single-Printer implementations. > > I don't have a problem with embedding the target URI in the PDU, > but if we get into a big mess with regard to reconciling a similar > target in the outer/lower transport level (eg, HTTP), then we might > want to consider pulling out the embedded target URI. > > It would be nice to hear from others on this topic. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 13:06:32 1998 Delivery-Date: Wed, 03 Jun 1998 13:06:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22440 for ; Wed, 3 Jun 1998 13:06:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14456 for ; Wed, 3 Jun 1998 13:08:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA24853 for ; Wed, 3 Jun 1998 13:06:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:55:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22095 for ipp-outgoing; Wed, 3 Jun 1998 12:43:39 -0400 (EDT) Date: 3 Jun 1998 16:42:37 -0000 Message-ID: <19980603164237.17075.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <19980603154151.12474.qmail@m2.findmail.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > > > The reason we have URIs in the message body is that from very early on we > > decided to rely on URIs as object identifiers WITHIN the core IPP protocol. > > But there is no reason to put a Printer identifier inside a request that is addressed to the Printer that reads the request. > > At one time, people were proposing some kind of dispatching or routing IPP Object that would receive IPP requests and route them based on the embedded "printer-uri". But the final decision was that the HTTP Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the IPP Object that receives the request must be the target. I should point out that the same argument applies to "job-uri". The only exceptional case is that of a Job being accessed by "job-id" through its containing Printer. In that case, the target is the Job, identified by "job-id", but the Object receiving the request is the Printer. > > > The problem we are having at the moment is reconciling this decision with > > the fact that our lower layer transport protocol also uses the same > > identifier (in some circumstances), and we wanted our core IPP to be > > transport independent. > > > > By the way, concerning Paul's earlier comment about proxies being the > > issue, I'm assuming that if we make NO changes to the current specs, that > > proxies are NOT an issue. Proxies rang the warning bell when it was > > suggested we mandate other port numbers and/or HTTP methods. Is this not > > the case? > > > > There could be a problem if a proxy rewrites the Request-URI in any way. Certainly he final proxy in the chain will translate the Request-URI from absolute to relative form. Whether or not these forms are considered the same for purposes of comparison with "printer-uri" is something we haven't worked out yet. > > Also, doesn't your TLS for IPP proposal require server redirects for server-initiated security? Won't that involve rewriting the Request-URI? > > > Randy > > > > Carl > > > > > ---------- > > > From: Carl Kugler > > > To: ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > Date: Tuesday, June 02, 1998 4:50 PM > > > > > > I agreee with Scott in "URLs within IPP operations", > > > http://www.findmail.com/list/ipp/3695.html > > > that it as a bad idea to embed "printer-uri" in the ipp message body. I > > went back through the archives to see why "printer-uri" was added to IPP in > > the first place. > > > > > > > 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 > > > > > > I think this is actually a bit of a jump from the original proposal in > > > "Identifying jobs in requests", > > > http://www.findmail.com/list/ipp/1700.html > > > which only asked for an embedded Job identifier, not an embedded Printer > > identifier, with the rationale that in some implementations a Job is not > > directly addressable and must be accessed through its containing Printer. > > > > > > If we accept that Printers are always directly addressable, then there's > > no reason to put the target printer-uri in the application/ipp message > > body. > > > > > > -Carl > > > > > > > > > > > > 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 ----- > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 13:09:25 1998 Delivery-Date: Wed, 03 Jun 1998 13:09:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22512 for ; Wed, 3 Jun 1998 13:09:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14481 for ; Wed, 3 Jun 1998 13:11:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25196 for ; Wed, 3 Jun 1998 13:09:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 13:01:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22069 for ipp-outgoing; Wed, 3 Jun 1998 12:40:33 -0400 (EDT) Date: 3 Jun 1998 16:39:23 -0000 Message-ID: <19980603163923.16708.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <199806031559.IAA15622@slafw.enet.sharplabs.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > We use URIs to identify IPP objects. If we want IPP to maintain > transport-independence, then we will always need to have some type of valid > URI denoting the target of an IPP request inside our protocol. > I don't think it's asking too much of a transport layer to require that it be capable of addressing a request to the target object. Without that capability, we'd have to invent our own IPP routers and multiplexors; IPP Objects that retransmit requests based on embedded addressing information. > Its just in the current case of HTTP, the information is redundant in some > cases, and could be misleading for some implementations. > > What we need is some method or algorithm that recognizes the relationship > between transport and IPP URIs, but at the same time provides a > transport-independent naming scope (still a URI), that is independent of > the HTTP transport's treatment of the HTTP URI. At the moment, it seems > like our current specs are the least vulnerable to problems resulting from > HTTP intermediaries. > > Also, my TLS proposal did specify redirects as one way of accomplishing > secure IPP. The other way was only publishing the secure form of the URI. > Also, there is a third way that has been proposed, using in-band SASL > negotiation ( which I think is probably best for a server that supports > both secure and non-secure IPP ). > > Randy > > > ---------- > > From: Carl Kugler > > To: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > Date: Wednesday, June 03, 1998 8:41 AM > > > > > > > > The reason we have URIs in the message body is that from very early on > we > > > decided to rely on URIs as object identifiers WITHIN the core IPP > protocol. > > > > But there is no reason to put a Printer identifier inside a request that > is addressed to the Printer that reads the request. > > > > At one time, people were proposing some kind of dispatching or routing > IPP Object that would receive IPP requests and route them based on the > embedded "printer-uri". But the final decision was that the HTTP > Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the > IPP Object that receives the request must be the target. > > > > > The problem we are having at the moment is reconciling this decision > with > > > the fact that our lower layer transport protocol also uses the same > > > identifier (in some circumstances), and we wanted our core IPP to be > > > transport independent. > > > > > > By the way, concerning Paul's earlier comment about proxies being the > > > issue, I'm assuming that if we make NO changes to the current specs, > that > > > proxies are NOT an issue. Proxies rang the warning bell when it was > > > suggested we mandate other port numbers and/or HTTP methods. Is this > not > > > the case? > > > > > > > There could be a problem if a proxy rewrites the Request-URI in any way. > Certainly he final proxy in the chain will translate the Request-URI from > absolute to relative form. Whether or not these forms are considered the > same for purposes of comparison with "printer-uri" is something we haven't > worked out yet. > > > > Also, doesn't your TLS for IPP proposal require server redirects for > server-initiated security? Won't that involve rewriting the Request-URI? > > > > > Randy > > > > > > > Carl > > > > > > > > ---------- > > > > From: Carl Kugler > > > > To: ipp@pwg.org > > > > Subject: Re: IPP> Identifying jobs in requests > > > > Date: Tuesday, June 02, 1998 4:50 PM > > > > > > > > I agreee with Scott in "URLs within IPP operations", > > > > http://www.findmail.com/list/ipp/3695.html > > > > that it as a bad idea to embed "printer-uri" in the ipp message body. > I > > > went back through the archives to see why "printer-uri" was added to > IPP in > > > the first place. > > > > > > > > > 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 > > > > > > > > I think this is actually a bit of a jump from the original proposal > in > > > > "Identifying jobs in requests", > > > > http://www.findmail.com/list/ipp/1700.html > > > > which only asked for an embedded Job identifier, not an embedded > Printer > > > identifier, with the rationale that in some implementations a Job is > not > > > directly addressable and must be accessed through its containing > Printer. > > > > > > > > If we accept that Printers are always directly addressable, then > there's > > > no reason to put the target printer-uri in the application/ipp message > > > body. > > > > > > > > -Carl > > > > > > > > > > > > > > > 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 ----- > > > > > > > > > > > > > > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 13:42:11 1998 Delivery-Date: Wed, 03 Jun 1998 13:42:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23335 for ; Wed, 3 Jun 1998 13:42:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14655 for ; Wed, 3 Jun 1998 13:44:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA25891 for ; Wed, 3 Jun 1998 13:42:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 13:37:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA25322 for ipp-outgoing; Wed, 3 Jun 1998 13:35:16 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 10:34:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org It's a question of layering, and not a question of actual transport capability. In our model we have a much more serious case of overlap between transport and application addressing than do most other applications. WEBDAV doesn't have to worry about this since they do not have to be transport-independent. Most of the time, there is a multiplexing/demultiplexing step involved when a transport layer has to demultiplex something and send it to the right endpoint. In our case, there is a one-to-one relationship between transport identifier (HTTP URL) and IPP URL. Not that there has to be, its just that's the scenario that everyone seems to be worried about. If you carved up a URI wherein some portion was transport and some portion was IPP, then it might be a little easier to deal with, in that it is much less likely that a correctly chosen IPP URI-portion would be rewritten or modified in any way from sender to receiver. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, June 03, 1998 9:39 AM To: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests > > We use URIs to identify IPP objects. If we want IPP to maintain > transport-independence, then we will always need to have some type of valid > URI denoting the target of an IPP request inside our protocol. > I don't think it's asking too much of a transport layer to require that it be capable of addressing a request to the target object. Without that capability, we'd have to invent our own IPP routers and multiplexors; IPP Objects that retransmit requests based on embedded addressing information. > Its just in the current case of HTTP, the information is redundant in some > cases, and could be misleading for some implementations. > > What we need is some method or algorithm that recognizes the relationship > between transport and IPP URIs, but at the same time provides a > transport-independent naming scope (still a URI), that is independent of > the HTTP transport's treatment of the HTTP URI. At the moment, it seems > like our current specs are the least vulnerable to problems resulting from > HTTP intermediaries. > > Also, my TLS proposal did specify redirects as one way of accomplishing > secure IPP. The other way was only publishing the secure form of the URI. > Also, there is a third way that has been proposed, using in-band SASL > negotiation ( which I think is probably best for a server that supports > both secure and non-secure IPP ). > > Randy > > > ---------- > > From: Carl Kugler > > To: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > Date: Wednesday, June 03, 1998 8:41 AM > > > > > > > > The reason we have URIs in the message body is that from very early on > we > > > decided to rely on URIs as object identifiers WITHIN the core IPP > protocol. > > > > But there is no reason to put a Printer identifier inside a request that > is addressed to the Printer that reads the request. > > > > At one time, people were proposing some kind of dispatching or routing > IPP Object that would receive IPP requests and route them based on the > embedded "printer-uri". But the final decision was that the HTTP > Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the > IPP Object that receives the request must be the target. > > > > > The problem we are having at the moment is reconciling this decision > with > > > the fact that our lower layer transport protocol also uses the same > > > identifier (in some circumstances), and we wanted our core IPP to be > > > transport independent. > > > > > > By the way, concerning Paul's earlier comment about proxies being the > > > issue, I'm assuming that if we make NO changes to the current specs, > that > > > proxies are NOT an issue. Proxies rang the warning bell when it was > > > suggested we mandate other port numbers and/or HTTP methods. Is this > not > > > the case? > > > > > > > There could be a problem if a proxy rewrites the Request-URI in any way. > Certainly he final proxy in the chain will translate the Request-URI from > absolute to relative form. Whether or not these forms are considered the > same for purposes of comparison with "printer-uri" is something we haven't > worked out yet. > > > > Also, doesn't your TLS for IPP proposal require server redirects for > server-initiated security? Won't that involve rewriting the Request-URI? > > > > > Randy > > > > > > > Carl > > > > > > > > ---------- > > > > From: Carl Kugler > > > > To: ipp@pwg.org > > > > Subject: Re: IPP> Identifying jobs in requests > > > > Date: Tuesday, June 02, 1998 4:50 PM > > > > > > > > I agreee with Scott in "URLs within IPP operations", > > > > http://www.findmail.com/list/ipp/3695.html > > > > that it as a bad idea to embed "printer-uri" in the ipp message body. > I > > > went back through the archives to see why "printer-uri" was added to > IPP in > > > the first place. > > > > > > > > > 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 > > > > > > > > I think this is actually a bit of a jump from the original proposal > in > > > > "Identifying jobs in requests", > > > > http://www.findmail.com/list/ipp/1700.html > > > > which only asked for an embedded Job identifier, not an embedded > Printer > > > identifier, with the rationale that in some implementations a Job is > not > > > directly addressable and must be accessed through its containing > Printer. > > > > > > > > If we accept that Printers are always directly addressable, then > there's > > > no reason to put the target printer-uri in the application/ipp message > > > body. > > > > > > > > -Carl > > > > > > > > > > > > > > > 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 ----- > > > > > > > > > > > > > > > > > > > > > > > From VRRP-owner@drcoffsite.com Wed Jun 3 13:47:55 1998 Delivery-Date: Wed, 03 Jun 1998 13:47:56 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23442 for ; Wed, 3 Jun 1998 13:47:55 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA14684 for ; Wed, 3 Jun 1998 13:50:12 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A86F44603C2; Wed, 03 Jun 1998 13:31:27 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id NAA05062; Wed, 3 Jun 1998 13:29:39 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA27286; Wed, 3 Jun 1998 13:29:41 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18328; Wed, 3 Jun 1998 13:29:29 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <357587F8.D97DA50C@raleigh.ibm.com> Date: Wed, 03 Jun 1998 13:29:28 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Tony Li Cc: dwhipple@microsoft.com, abhatt@extremenetworks.com, vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <199806030128.SAA19641@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony Li wrote: > > David, > > I was asking about systems that do not support router discovery. New > operating systems that do not support router discovery are clearly simply > flawed. BSD certainly now supports router discovery. Does Win98? NT? > > The ENTIRE point of HSRP was to support these legacy systems. Router > discovery is a clearly better solution in every respect. > > I won't claim to understand the technical design goals for VRRP. The > non-technical ones are obvious. VRRP supports systems which do not support gratuitous ARP just as HSRP does. The primary differences are: 1) VRRP does not require the concept of a virtual IP address. A backup router simply takes over forwarding responsibility for hosts having the master's IP address as their default gateway address. RFC 2238 explains (hopefully, clearly) what that entails. This avoids the problems associated with ICMP redirects and the virtual IP address. 2) VRRP runs on link basis rather than an IP subnet basis. Consequently, a single VRID can be used for multiple subnets on the same physical network. 3) VRRP's authentication encoding is more consistent with other protocols (e.g, RIPv2 and OSPF). However, this may be a moot point if one is using IPSEC encapsulation. -- Acee From ipp-owner@pwg.org Wed Jun 3 14:11:54 1998 Delivery-Date: Wed, 03 Jun 1998 14:11:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24210 for ; Wed, 3 Jun 1998 14:11:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14815 for ; Wed, 3 Jun 1998 14:14:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA26511 for ; Wed, 3 Jun 1998 14:11:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:07:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA25980 for ipp-outgoing; Wed, 3 Jun 1998 14:03:10 -0400 (EDT) Message-ID: <3FF8121C9B6DD111812100805F31FC0D0297140C@red-msg-59.dns.microsoft.com> From: Yaron Goland To: "'Rob Polansky'" , Paul Moore Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 11:02:58 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org When you say "change the standard" are you referring to RFC 2068 or the IPP standard? Thanks, Yaron > -----Original Message----- > From: Rob Polansky [mailto:polansky@raptor.com] > Sent: Wednesday, June 03, 1998 5:55 AM > To: Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > This kind of flamebait is not really helpful to our > discussion. Firewalls > serve legitimate technical and business needs as our friends > from Microsoft > know, and those firewalls with application proxies look at > protocols from a > different point of view than your typical caching proxies. > The beauty of it > is that protocol compliant implementations from either the > firewall or the > cache point of view will interoperate. The difference is when > they encounter > something unexpected. Firewalls by definition must "fail > closed" so as not > to make their protected resources vulnerable to attacks; most > other software > makes a best effort to pass data. I don't see anything wrong with that > difference. > > Once again, if IPP uses existing methods and schemes, it > should be passable > through all proxies without trouble. Add a new method and/or > scheme i.e. > CHANGE THE STANDARD, and you should expect that existing > implemenations will > not understand it and some (not many) may not pass it. > > -Rob Polansky > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Tuesday, June 02, 1998 8:37 PM > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob > Polansky'; David > > W. Morris > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new > scheme and port > > for existing HTTP servers > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > you replace > > my proxy by a passthrough cable I cannot do anything, if > you replace my > > firewall by a cable you can do anything. > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; > David W. Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: Re: IPP> RE: Implications of introducing new > scheme and port > > > for existing HTTP servers > > > > > > > > > The past few comments about firewalls do not (IMHO) > appear to pose a > > > problem for IPP deployment. If the majority of the > installed base of > > > firewall products do not do HTTP method inspection then thats ok. > > > everything would work. When the "next-generation" > products that can > > > perform > > > this type of inspection, then during installation of this new > > > infrastructure, the administrator will then enable IPP > (or WEBDAV) or > > > whatever at that time. > > > > > > Ultimately, I believe firewall admins will explicitly > enable internet > > > printing or faxing or whatever, and I don't think a firewall > > issue should > > > impose undue design constraints on what we (the WG) want to do. > > > Firewall admins already do this explicitly enabling/disabling of > > > application protocols (POP, FTP, IMAP, etc.) and I think > we're just > > > another > > > application. I don't think these protocol designers were > too bogged down > > > in > > > firewall issues during the development process. At least with the > > > Checkpoint Firewall-1 product, it takes about 45 seconds > to bring up the > > > console and enable or disable a particular application protocol. > > > > > > Just my (possibly more than) $0.02 > > > > > > Randy > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > >Rob's argument is broadly correct -- as a long term > firewall design > > > issue, > > > >method inspection (and occasionally payload inspection) > will become the > > > >rule. > > > > > > > >However, as a small carrot to today's protocol > designers, the vast > > > majority > > > >of the installed base of firewalls do no method / > payload inspection on > > > HTTP > > > >data being passed through. Purely from the perspective > of 'reach' > > > there's > > > >no impediment to IPP using it's own method in the short run. > > > > > > > >> -----Original Message----- > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > >> To: David W. Morris > > > >> Cc: http-wg; ipp@pwg.org > > > >> Subject: RE: Implications of introducing new > scheme and port for > > > >> existing HTTP servers > > > >> > > > >> I know of at least one :-) firewall that not only > rejects unknown > > > methods > > > >> but also examines the HTTP request method as part of > its "algorithm". > > > From > > > >> a > > > >> protocol and security perspective, it appears to be the > > right thing to > > > do. > > > >> If you don't understand the method, how can you properly > > proxy it? Take > > > >> the > > > >> CONNECT method as an example. > > > >> > > > >> In summary, any proxy that is more than a simple packet passer > > > (supports > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > runs the risk > > > of > > > >> failing to pass IPP if it uses a new scheme and/or a > new method. Not > > > that > > > >> that's a bad thing... :-) > > > >> > > > >> -Rob Polansky > > > >> > > > >> > -----Original Message----- > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > >> > To: Carl-Uno Manros > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > http-wg@hplb.hpl.hp.com > > > >> > Subject: Re: Implications of introducing new scheme > and port for > > > >> > existing HTTP servers > > > >> > > > > >> > (I'm also not wild about new HTTP methods as I know > of existing > > > proxies > > > >> > which will reject unknown methods. Don't know of any > which will > > > accept > > > >> > unknown methods. I'm also unaware of any firewall > software which > > > >> examines > > > >> > the HTTP request method as part of its algorithm but > then I'm not a > > > >> > firewall expert.) > > > >> > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 14:21:39 1998 Delivery-Date: Wed, 03 Jun 1998 14:21:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24419 for ; Wed, 3 Jun 1998 14:21:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14880 for ; Wed, 3 Jun 1998 14:24:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27133 for ; Wed, 3 Jun 1998 14:21:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:17:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA26597 for ipp-outgoing; Wed, 3 Jun 1998 14:15:48 -0400 (EDT) Date: 3 Jun 1998 18:14:43 -0000 Message-ID: <19980603181443.27533.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <357578D3.F99ABB54@underscore.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org JK Martin wrote: > Carl Kugler wrote: > > > At one time, people were proposing some kind of dispatching or routing IPP > > Object that would receive IPP requests and route them based on the embedded > > "printer-uri". > > I was one of those people suggesting demultiplexing/dispatching, > but only within an HTTP server environment. As such, the server- > side component (CGI script, servlet, etc) would use the HTTP > header component to discriminate the real target. > If I understand what you're saying, this works fine today, with the existing model. For example, in our implemenation, these two Request-URIs sent to Host carlk: /servlet/IPPServlet/vega-lp /servlet/IPPServlet/pp4019 both cause the web server on carlk to invoke servlet IPPServlet. IPPServlet uses the path info from the Request-URI to determine if the target output device is "vega-lp" or "pp4019". > > > But the final decision was that the HTTP Request-URI and the embedded > > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives > > the request must be the target. > > Did we actually come to a final decision? I didn't read that we had. > (Maybe I'm missing a message or two on this subject?) > In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote: > 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. Then Randy agreed, and the thread ended. > > > > There could be a problem if a proxy rewrites the Request-URI in any way. > > Yeah, this worries me, too. We definitely need some serious > implementation experience to better understand the ramifications > of this situation. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > From ipp-owner@pwg.org Wed Jun 3 14:35:03 1998 Delivery-Date: Wed, 03 Jun 1998 14:35:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24706 for ; Wed, 3 Jun 1998 14:35:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14927 for ; Wed, 3 Jun 1998 14:37:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27787 for ; Wed, 3 Jun 1998 14:35:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:31:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27222 for ipp-outgoing; Wed, 3 Jun 1998 14:23:39 -0400 (EDT) Date: 3 Jun 1998 18:20:54 -0000 Message-ID: <19980603182054.27969.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <199806031638.JAA15982@slafw.enet.sharplabs.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > The demultiplexing front-end is not IPP, and is therefore some type of > "transport-helper". While the IPP protocol document must stand on its own, > independent of any such transport, and therefore identifiers within the > protocol would still be mandatory ( Of course, my argument is entirely > based upon the WG's decision that IPP must be transport independent ). > > Randy > Randy- If the demultiplexing front-end is not IPP, how is it able to read IPP attributes? - Carl > > ---------- > > From: Jay Martin > > To: Randy Turner > > Cc: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > Date: Wednesday, June 03, 1998 9:32 AM > > > > Randy Turner wrote: > > > > > > We use URIs to identify IPP objects. If we want IPP to maintain > > > transport-independence, then we will always need to have some type of > valid > > > URI denoting the target of an IPP request inside our protocol. > > > > Not necessarily. Sure, in the case of a demultiplexing front-end, > > it would be necessary to have the target embedded in the protocol > > message, but not necessary for single-Printer implementations. > > > > I don't have a problem with embedding the target URI in the PDU, > > but if we get into a big mess with regard to reconciling a similar > > target in the outer/lower transport level (eg, HTTP), then we might > > want to consider pulling out the embedded target URI. > > > > It would be nice to hear from others on this topic. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > > From ipp-owner@pwg.org Wed Jun 3 14:41:41 1998 Delivery-Date: Wed, 03 Jun 1998 14:41:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24835 for ; Wed, 3 Jun 1998 14:41:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14950 for ; Wed, 3 Jun 1998 14:44:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA28394 for ; Wed, 3 Jun 1998 14:41:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:37:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27769 for ipp-outgoing; Wed, 3 Jun 1998 14:34:55 -0400 (EDT) Message-ID: <35759741.19DB086C@underscore.com> Date: Wed, 03 Jun 1998 14:34:41 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Carl Kugler Subject: IPP> When the request-uri differs from the printer/job-uri in the PDU References: <19980603181443.27533.qmail@m2.findmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org I've changed the thread name to improve tracking in the IPP Hypermail archives for this topic. Carl Kugler wrote: > > Jay Martin wrote: > > Carl Kugler wrote: > > > > > But the final decision was that the HTTP Request-URI and the embedded > > > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives > > > the request must be the target. > > > > Did we actually come to a final decision? I didn't read that we had. > > (Maybe I'm missing a message or two on this subject?) > > > In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote: > > > 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. > > Then Randy agreed, and the thread ended. Ok, since no one followed up after that, I guess Herriot's statement stands. No problem. But what happens if the two URIs *do* differ? I think we need some language in the document so developers can do the right thing. All of the recent talk about proxies rewriting the request-uri has me concerned whether we will indeed see quite a few cases in which the two URIs are not the same (and then what?). ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 14:46:48 1998 Delivery-Date: Wed, 03 Jun 1998 14:46:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24920 for ; Wed, 3 Jun 1998 14:46:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14972 for ; Wed, 3 Jun 1998 14:49:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29002 for ; Wed, 3 Jun 1998 14:46:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:42:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28000 for ipp-outgoing; Wed, 3 Jun 1998 14:38:38 -0400 (EDT) Date: 3 Jun 1998 18:37:31 -0000 Message-ID: <19980603183731.28859.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > > It's a question of layering, and not a question of actual transport > capability. In our model we have a much more serious case of overlap > between transport and application addressing than do most other > applications. WEBDAV doesn't have to worry about this since they do not > have to be transport-independent. Most of the time, there is a > multiplexing/demultiplexing step involved when a transport layer has to > demultiplex something and send it to the right endpoint. In our case, > there is a one-to-one relationship between transport identifier (HTTP > URL) and IPP URL. Not that there has to be, its just that's the scenario > that everyone seems to be worried about. If you carved up a URI wherein > some portion was transport and some portion was IPP, then it might be a > little easier to deal with, in that it is much less likely that a > correctly chosen IPP URI-portion would be rewritten or modified in any > way from sender to receiver. > > Randy > Okay, to carve up URIs by layer, we should use Relative identifiers. So the Request-URI identifies a Server within (relative to) a Host, the "printer-uri" identifies a Printer within a Server, the "job-uri" identifies a Job within a Printer. All are Relative URIs defined within the context of the encapsulating entity. There can't be overlap conflicts. From ipp-owner@pwg.org Wed Jun 3 14:56:43 1998 Delivery-Date: Wed, 03 Jun 1998 14:56:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA25225 for ; Wed, 3 Jun 1998 14:56:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA15060 for ; Wed, 3 Jun 1998 14:59:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29651 for ; Wed, 3 Jun 1998 14:56:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:52:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29103 for ipp-outgoing; Wed, 3 Jun 1998 14:51:02 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 11:50:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org I think Jay was talking about a lower-layer demux than what you are talking about. The kind of demux that might be performed by a CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a core IPP processing component. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, June 03, 1998 11:21 AM To: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests > > The demultiplexing front-end is not IPP, and is therefore some type of > "transport-helper". While the IPP protocol document must stand on its own, > independent of any such transport, and therefore identifiers within the > protocol would still be mandatory ( Of course, my argument is entirely > based upon the WG's decision that IPP must be transport independent ). > > Randy > Randy- If the demultiplexing front-end is not IPP, how is it able to read IPP attributes? - Carl > > ---------- > > From: Jay Martin > > To: Randy Turner > > Cc: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > Date: Wednesday, June 03, 1998 9:32 AM > > > > Randy Turner wrote: > > > > > > We use URIs to identify IPP objects. If we want IPP to maintain > > > transport-independence, then we will always need to have some type of > valid > > > URI denoting the target of an IPP request inside our protocol. > > > > Not necessarily. Sure, in the case of a demultiplexing front-end, > > it would be necessary to have the target embedded in the protocol > > message, but not necessary for single-Printer implementations. > > > > I don't have a problem with embedding the target URI in the PDU, > > but if we get into a big mess with regard to reconciling a similar > > target in the outer/lower transport level (eg, HTTP), then we might > > want to consider pulling out the embedded target URI. > > > > It would be nice to hear from others on this topic. > > > > ...jay > > > > ---------------------------------------------------------------------- > > -- JK Martin | Email: jkm@underscore.com -- > > -- Underscore, Inc. | Voice: (603) 889-7000 -- > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > > ---------------------------------------------------------------------- > > From ipp-owner@pwg.org Wed Jun 3 15:02:26 1998 Delivery-Date: Wed, 03 Jun 1998 15:02:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25311 for ; Wed, 3 Jun 1998 15:02:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15093 for ; Wed, 3 Jun 1998 15:04:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00345 for ; Wed, 3 Jun 1998 15:02:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:57:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29624 for ipp-outgoing; Wed, 3 Jun 1998 14:56:29 -0400 (EDT) Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971412@red-msg-59.dns.microsoft.com> From: Yaron Goland To: "'Rob Polansky'" , Paul Moore Cc: "'http-wg'" , "'ipp@pwg.org'" , "Vinod Valloppillil (Exchange)" Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 11:56:10 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org Rob clarified in personal e-mail that he meant the latest rev of the HTTP draft. One of the innovations of HTTP in respect to many other protocols is that you do not need to modify the HTTP standard in order to add new methods for use with HTTP. Rather HTTP defines exactly how one is to act if one receives an unknown method. Thus one can safely add new methods and know that at the worst one will simply receive a method unknown error from servers/firewalls and be tunneled by proxies. Firewall designers understood this simple design goal and thus allowed administrators to specify which methods they did and did not want to allow through their firewall. Thus the issue is not forcing administrators to rev their firewalls to be compliant with some new standard but rather having administrators brought into the loop in order to approve the use of a new method through their firewall. Once they approve they need only change settings on their firewall to permit the new method. It is this very process that firewalls were introduced to enforce. Administrators realized they could not possibly control what every server in their network did. Rather than chasing after every user in order to ensure they were not running "unapproved" or "insecure" software they configured their network such that anyone wishing to do anything external to the network had to run through their firewall. Thus were IPP to use a new method there would be absolutely no need to alter the HTTP standard and IPP would be acting in a manner consistent with the express desires of the administrative community. Yaron > -----Original Message----- > From: Yaron Goland > Sent: Wednesday, June 03, 1998 11:03 AM > To: 'Rob Polansky'; Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > When you say "change the standard" are you referring to RFC > 2068 or the IPP standard? > > Thanks, > Yaron > > > -----Original Message----- > > From: Rob Polansky [mailto:polansky@raptor.com] > > Sent: Wednesday, June 03, 1998 5:55 AM > > To: Paul Moore > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new > scheme and port > > for existing HTTP servers > > > > > > This kind of flamebait is not really helpful to our > > discussion. Firewalls > > serve legitimate technical and business needs as our friends > > from Microsoft > > know, and those firewalls with application proxies look at > > protocols from a > > different point of view than your typical caching proxies. > > The beauty of it > > is that protocol compliant implementations from either the > > firewall or the > > cache point of view will interoperate. The difference is when > > they encounter > > something unexpected. Firewalls by definition must "fail > > closed" so as not > > to make their protected resources vulnerable to attacks; most > > other software > > makes a best effort to pass data. I don't see anything > wrong with that > > difference. > > > > Once again, if IPP uses existing methods and schemes, it > > should be passable > > through all proxies without trouble. Add a new method and/or > > scheme i.e. > > CHANGE THE STANDARD, and you should expect that existing > > implemenations will > > not understand it and some (not many) may not pass it. > > > > -Rob Polansky > > > > > -----Original Message----- > > > From: Paul Moore [mailto:paulmo@microsoft.com] > > > Sent: Tuesday, June 02, 1998 8:37 PM > > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob > > Polansky'; David > > > W. Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: RE: IPP> RE: Implications of introducing new > > scheme and port > > > for existing HTTP servers > > > > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > > you replace > > > my proxy by a passthrough cable I cannot do anything, if > > you replace my > > > firewall by a cable you can do anything. > > > > > > > -----Original Message----- > > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; > > David W. Morris > > > > Cc: http-wg; ipp@pwg.org > > > > Subject: Re: IPP> RE: Implications of introducing new > > scheme and port > > > > for existing HTTP servers > > > > > > > > > > > > The past few comments about firewalls do not (IMHO) > > appear to pose a > > > > problem for IPP deployment. If the majority of the > > installed base of > > > > firewall products do not do HTTP method inspection then > thats ok. > > > > everything would work. When the "next-generation" > > products that can > > > > perform > > > > this type of inspection, then during installation of this new > > > > infrastructure, the administrator will then enable IPP > > (or WEBDAV) or > > > > whatever at that time. > > > > > > > > Ultimately, I believe firewall admins will explicitly > > enable internet > > > > printing or faxing or whatever, and I don't think a firewall > > > issue should > > > > impose undue design constraints on what we (the WG) want to do. > > > > Firewall admins already do this explicitly enabling/disabling of > > > > application protocols (POP, FTP, IMAP, etc.) and I think > > we're just > > > > another > > > > application. I don't think these protocol designers were > > too bogged down > > > > in > > > > firewall issues during the development process. At > least with the > > > > Checkpoint Firewall-1 product, it takes about 45 seconds > > to bring up the > > > > console and enable or disable a particular application protocol. > > > > > > > > Just my (possibly more than) $0.02 > > > > > > > > Randy > > > > > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > > >Rob's argument is broadly correct -- as a long term > > firewall design > > > > issue, > > > > >method inspection (and occasionally payload inspection) > > will become the > > > > >rule. > > > > > > > > > >However, as a small carrot to today's protocol > > designers, the vast > > > > majority > > > > >of the installed base of firewalls do no method / > > payload inspection on > > > > HTTP > > > > >data being passed through. Purely from the perspective > > of 'reach' > > > > there's > > > > >no impediment to IPP using it's own method in the short run. > > > > > > > > > >> -----Original Message----- > > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > > >> To: David W. Morris > > > > >> Cc: http-wg; ipp@pwg.org > > > > >> Subject: RE: Implications of introducing new > > scheme and port for > > > > >> existing HTTP servers > > > > >> > > > > >> I know of at least one :-) firewall that not only > > rejects unknown > > > > methods > > > > >> but also examines the HTTP request method as part of > > its "algorithm". > > > > From > > > > >> a > > > > >> protocol and security perspective, it appears to be the > > > right thing to > > > > do. > > > > >> If you don't understand the method, how can you properly > > > proxy it? Take > > > > >> the > > > > >> CONNECT method as an example. > > > > >> > > > > >> In summary, any proxy that is more than a simple > packet passer > > > > (supports > > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > > runs the risk > > > > of > > > > >> failing to pass IPP if it uses a new scheme and/or a > > new method. Not > > > > that > > > > >> that's a bad thing... :-) > > > > >> > > > > >> -Rob Polansky > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > > >> > To: Carl-Uno Manros > > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > > http-wg@hplb.hpl.hp.com > > > > >> > Subject: Re: Implications of introducing new scheme > > and port for > > > > >> > existing HTTP servers > > > > >> > > > > > >> > (I'm also not wild about new HTTP methods as I know > > of existing > > > > proxies > > > > >> > which will reject unknown methods. Don't know of any > > which will > > > > accept > > > > >> > unknown methods. I'm also unaware of any firewall > > software which > > > > >> examines > > > > >> > the HTTP request method as part of its algorithm but > > then I'm not a > > > > >> > firewall expert.) > > > > >> > > > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 16:28:21 1998 Delivery-Date: Wed, 03 Jun 1998 16:28:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26678 for ; Wed, 3 Jun 1998 16:28:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15626 for ; Wed, 3 Jun 1998 16:30:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01055 for ; Wed, 3 Jun 1998 16:28:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 16:22:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00494 for ipp-outgoing; Wed, 3 Jun 1998 16:18:16 -0400 (EDT) Message-ID: <3575AF24.501A@bell-labs.com> Date: Wed, 03 Jun 1998 16:16:36 -0400 From: Dave Kristol X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.6 sun4m) MIME-Version: 1.0 To: Yaron Goland CC: "'http-wg'" , "'ipp@pwg.org'" Subject: Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers References: <3FF8121C9B6DD111812100805F31FC0D02971412@red-msg-59.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Yaron Goland wrote: > > Rob clarified in personal e-mail that he meant the latest rev of the HTTP > draft. > > One of the innovations of HTTP in respect to many other protocols is that > you do not need to modify the HTTP standard in order to add new methods for > use with HTTP. Rather HTTP defines exactly how one is to act if one receives > an unknown method. Thus one can safely add new methods and know that at the > worst one will simply receive a method unknown error from servers/firewalls > and be tunneled by proxies. How can one "know that at the worst one will ... be tunneled by proxies"? I can't find anything in the HTTP/1.1 spec. that instructs proxies to tunnel unknown methods. I think at worst the request will be rejected. Dave Kristol From ipp-owner@pwg.org Wed Jun 3 17:02:01 1998 Delivery-Date: Wed, 03 Jun 1998 17:02:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27426 for ; Wed, 3 Jun 1998 17:02:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15846 for ; Wed, 3 Jun 1998 17:04:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA01730 for ; Wed, 3 Jun 1998 17:01:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 16:57:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA01166 for ipp-outgoing; Wed, 3 Jun 1998 16:53:35 -0400 (EDT) Message-Id: <199806032049.NAA06290@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 03 Jun 1998 13:54:05 -0700 To: "Carl Kugler" , ipp@pwg.org From: Robert Herriot Subject: Re: IPP> Identifying jobs in requests In-Reply-To: <19980603181443.27533.qmail@m2.findmail.com> References: <357578D3.F99ABB54@underscore.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_2785945==_.ALT" Sender: owner-ipp@pwg.org --=====================_2785945==_.ALT Content-Type: text/plain; charset="us-ascii" I agree with what Carl stated below. One way of implementing IPP is to have requests for all printers go to a single servlet which mulitplexes several printers. The servlet determines the printer by querying the URL. Another way of implementing IPP (which I haven't tried) is to have a separate Servlet for each printer (e.g. /servlet/IPPServletFoo and /servlet/IPPServletBar). I think that the first solution is best. In any case the URL in the HTTP request line is the easiest place for a server to determine the target printer and the printer-uri in the application/ipp is at most checked for consistency. Bob Herriot At 11:14 AM 6/3/98 , Carl Kugler wrote: >JK Martin wrote: >> Carl Kugler wrote: >> >> > At one time, people were proposing some kind of dispatching or routing IPP >> > Object that would receive IPP requests and route them based on the embedded >> > "printer-uri". >> >> I was one of those people suggesting demultiplexing/dispatching, >> but only within an HTTP server environment. As such, the server- >> side component (CGI script, servlet, etc) would use the HTTP >> header component to discriminate the real target. >> >If I understand what you're saying, this works fine today, with the existing model. For example, in our implemenation, these two Request-URIs sent to Host carlk: > > /servlet/IPPServlet/vega-lp > /servlet/IPPServlet/pp4019 > >both cause the web server on carlk to invoke servlet IPPServlet. IPPServlet uses the path info from the Request-URI to determine if the target output device is "vega-lp" or "pp4019". > >> >> > But the final decision was that the HTTP Request-URI and the embedded >> > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives >> > the request must be the target. >> >> Did we actually come to a final decision? I didn't read that we had. >> (Maybe I'm missing a message or two on this subject?) >> >In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote: > >> 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. > >Then Randy agreed, and the thread ended. > >> >> >> > There could be a problem if a proxy rewrites the Request-URI in any way. >> >> Yeah, this worries me, too. We definitely need some serious >> implementation experience to better understand the ramifications >> of this situation. >> >> ...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 -- >> ---------------------------------------------------------------------- >> >> > --=====================_2785945==_.ALT Content-Type: text/html; charset="us-ascii" I agree with what Carl stated below.

One way of implementing IPP is to have requests for all printers go to a
single servlet which mulitplexes several printers. The servlet determines
the printer by querying the URL.

Another way of implementing IPP (which I haven't tried) is to have a
separate Servlet for each printer (e.g. /servlet/IPPServletFoo and
/servlet/IPPServletBar).  I think that the first solution is best.

In any case the URL in the HTTP request line is the easiest place for a
server to determine the target printer and the printer-uri in the
application/ipp is at most checked for consistency.

Bob Herriot

At 11:14 AM 6/3/98 , Carl Kugler wrote:
>JK Martin wrote:            
>> Carl Kugler wrote:
>>
>> > At one time, people were proposing some kind of dispatching or routing IPP
>> > Object that would receive IPP requests and route them based on the embedded
>> > "printer-uri".
>>
>> I was one of those people suggesting demultiplexing/dispatching,
>> but only within an HTTP server environment.  As such, the server-
>> side component (CGI script, servlet, etc) would use the HTTP
>> header component to discriminate the real target.
>>
>If I understand what you're saying, this works fine today, with the existing model.  For example, in our implemenation, these two Request-URIs sent to Host carlk:
>
>    /servlet/IPPServlet/vega-lp
>    /servlet/IPPServlet/pp4019
>
>both cause the web server on carlk to invoke servlet IPPServlet.  IPPServlet uses the path info from the Request-URI to determine if the target output device is "vega-lp" or "pp4019".
>
>>
>> > But the final decision was that the HTTP Request-URI and the embedded
>> > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives
>> > the request must be the target.
>>
>> Did we actually come to a final decision?  I didn't read that we had.
>> (Maybe I'm missing a message or two on this subject?)
>>
>In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote:
>
>> 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.
>
>Then Randy agreed, and the thread ended.
>
>>
>>
>> > There could be a problem if a proxy rewrites the Request-URI in any way.
>>
>> Yeah, this worries me, too.  We definitely need some serious
>> implementation experience to better understand the ramifications
>> of this situation.
>>
>>      ...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   --
>> ----------------------------------------------------------------------
>>
>>
>
--=====================_2785945==_.ALT-- From ipp-owner@pwg.org Wed Jun 3 17:10:54 1998 Delivery-Date: Wed, 03 Jun 1998 17:10:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27501 for ; Wed, 3 Jun 1998 17:10:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15884 for ; Wed, 3 Jun 1998 17:12:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02381 for ; Wed, 3 Jun 1998 17:10:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 17:06:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01559 for ipp-outgoing; Wed, 3 Jun 1998 17:00:31 -0400 (EDT) From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com X-OpenMail-Hops: 1 Date: Wed, 3 Jun 1998 14:00:13 -0700 Message-Id: In-Reply-To: Subject: RE: IPP> Re: Implications of introducing new scheme and po MIME-Version: 1.0 TO: Peter.Zehler@usa.xerox.com CC: lawrence@agranat.com, ipp@pwg.org Content-Type: text/plain Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org If you wish to add security, you may be dealing with up to four ports, two for HTTP and two more for HTTP-S. Embedded web server implementations should be able to deal with this fine. The issue remains reconfiguratoin of Firewalls to allow inbound connections on all ports. Firewalls can be easily configured, IT folks hate to do it though. A beneficial side effect of using special ports for IPP is that of easy IPP service discovery. Web crawler like tools can easily discover IPP servers running on say , port 380, and thereby be able to find all IPP printers within a network. This can allow IPP discovery using standard tools today. The process would look something like... For all IP Valid Addresses... - perform HTTP HEAD request on port 380 - If HEAD response Add URL to Directory Services List as IPP printer This same approach has been used by HP OpenView when discovering Web enabled appliances for management purposes with success on port 280. The same can be done digging for URI's, it takes more work. Someone might pursue grabbing port 380 through IANA... Peter ______________________________ Reply Separator _________________________________ Subject: RE: IPP> Re: Implications of introducing new scheme and po Author: Non-HP-Peter.Zehler (Peter.Zehler@usa.xerox.com) at HP-Roseville,mimegw4 Date: 6/1/98 12:52 PM Scott, Will your product require no change at all if it is the front end for a standard web server and an IPP Printer? It seems this would require your product to listen to 2 ports. An alternative would be to have 2 instantiations, one for regular HTTP and one for IPP over HTTP. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: Scott Lawrence [SMTP:lawrence@agranat.com] Sent: Monday, June 01, 1998 3:02 PM To: ipp@pwg.org Subject: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers On Mon, 1 Jun 1998, Carl-Uno Manros wrote: > 1) the introduction of a new scheme called "ipp" > 2) the introduction a new default port number for IPP servers. > > Before the IPP WG responds to those suggestions, the IPP WG would like to > get some advice from the HTTP WG on the implications of such a change. > In particular, we want some feedback on how easy or difficult it would be > to configure existing web servers to accomodate the suggested changes. Answering for EmWeb, our embedded web server: The new scheme (1) would require a very minor change from our existing product, which requires that he scheme be 'http' if it is present at all. We'd need to allow 'ipp', and perhaps add a check to ensure that it is being used on the proper port (if that is deemed to be important). If the client does not send the scheme, then there would be no change. The new port (2) would be no change at all, since it can already operate on any port. One might wish to recognize that the default port for an 'ipp:' scheme redirect would be different than for an 'http:' redirect, but that's a very minor matter. From ipp-owner@pwg.org Wed Jun 3 17:57:54 1998 Delivery-Date: Wed, 03 Jun 1998 17:57:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28128 for ; Wed, 3 Jun 1998 17:57:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16101 for ; Wed, 3 Jun 1998 18:00:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03113 for ; Wed, 3 Jun 1998 17:57:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 17:52:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02567 for ipp-outgoing; Wed, 3 Jun 1998 17:51:30 -0400 (EDT) Date: 3 Jun 1998 21:50:16 -0000 Message-ID: <19980603215016.14186.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > > I think Jay was talking about a lower-layer demux than what you are > talking about. The kind of demux that might be performed by a > CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a > core IPP processing component. > > Randy > How does placing a URI denoting the target of an IPP request inside our protocol (as an IPP attribute) facilitate this kind of demux? > > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, June 03, 1998 11:21 AM > To: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > > > > > The demultiplexing front-end is not IPP, and is therefore some > type of > > "transport-helper". While the IPP protocol document must stand > on its own, > > independent of any such transport, and therefore identifiers > within the > > protocol would still be mandatory ( Of course, my argument is > entirely > > based upon the WG's decision that IPP must be transport > independent ). > > > > Randy > > > > Randy- > > If the demultiplexing front-end is not IPP, how is it able to > read IPP attributes? > > - Carl > > > > ---------- > > > From: Jay Martin > > > To: Randy Turner > > > Cc: ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > Date: Wednesday, June 03, 1998 9:32 AM > > > > > > Randy Turner wrote: > > > > > > > > We use URIs to identify IPP objects. If we want IPP to > maintain > > > > transport-independence, then we will always need to have > some type of > > valid > > > > URI denoting the target of an IPP request inside our > protocol. > > > > > > Not necessarily. Sure, in the case of a demultiplexing > front-end, > > > it would be necessary to have the target embedded in the > protocol > > > message, but not necessary for single-Printer > implementations. > > > > > > I don't have a problem with embedding the target URI in the > PDU, > > > but if we get into a big mess with regard to reconciling a > similar > > > target in the outer/lower transport level (eg, HTTP), then > we might > > > want to consider pulling out the embedded target URI. > > > > > > It would be nice to hear from others on this topic. > > > > > > ...jay > > > > > > > ---------------------------------------------------------------------- > > > -- JK Martin | Email: jkm@underscore.com > -- > > > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > > > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > > > ---------------------------------------------------------------------- > > > > > > From ipp-owner@pwg.org Wed Jun 3 18:10:30 1998 Delivery-Date: Wed, 03 Jun 1998 18:10:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28342 for ; Wed, 3 Jun 1998 18:10:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16193 for ; Wed, 3 Jun 1998 18:12:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04287 for ; Wed, 3 Jun 1998 18:10:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 18:02:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02582 for ipp-outgoing; Wed, 3 Jun 1998 17:52:37 -0400 (EDT) Message-ID: <00c301bd8f39$9c52ecb0$1e0564d2@tulip> From: "Peter Michalek" To: Subject: Re: RE: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 14:49:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org -----Original Message----- From: Carl Kugler To: ipp@pwg.org Date: Wednesday, June 03, 1998 11:46 AM Subject: Re: RE: IPP> Identifying jobs in requests >> >> It's a question of layering, and not a question of actual transport >> capability. In our model we have a much more serious case of overlap >> between transport and application addressing than do most other >> applications. WEBDAV doesn't have to worry about this since they do not >> have to be transport-independent. Most of the time, there is a >> multiplexing/demultiplexing step involved when a transport layer has to >> demultiplex something and send it to the right endpoint. In our case, >> there is a one-to-one relationship between transport identifier (HTTP >> URL) and IPP URL. Not that there has to be, its just that's the scenario >> that everyone seems to be worried about. If you carved up a URI wherein >> some portion was transport and some portion was IPP, then it might be a >> little easier to deal with, in that it is much less likely that a >> correctly chosen IPP URI-portion would be rewritten or modified in any >> way from sender to receiver. >> >> Randy >> > >Okay, to carve up URIs by layer, we should use Relative identifiers. So the Request-URI identifies a Server within (relative to) a Host, >the "printer-uri" identifies a Printer within a Server, >the "job-uri" identifies a Job within a Printer. > >All are Relative URIs defined within the context of the encapsulating entity. There can't be overlap conflicts. > ** The following operations take job as the target of the operation 3.3.1.1 Send-Document Request 3.3.3.1 Cancel-Job Request 3.3.4.1 Get-Job-Attributes Request Target: Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri" operation attribute(s) which define the target for this operation as described in section 3.1.3. ** The following operations take printer as the target of the operation 3.2.1.1 Print-Job Request 3.2.4 Create-Job Operation 3.2.5.1 Get-Printer-Attributes Request 3.2.6.1 Get-Jobs Request ......................................44 Target: The "printer-uri" operation attribute which is the target for this operation as described in section 3.1.3. ** The protocol document states this about how HTTP is used to address a job target in 3.9: (iii) . "job-uri": When the target is a job and the transport is HTTP or HTTPS (for TLS), the target job-uri of each operation in the IPP model document SHALL be an operation attribute called "job-uri" and it SHALL also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. ** This means that for all jobs, the HTTP server serving IPP will have to generate CGIs or similar entities for each job in the queue or otherwise processed. I think this is not practical and it provides justification for having the target attribute for job-uri in the IPP layer as well. For consistency, it would be good to do the same for printer-uri and modify (iii) above to reflect that. Also, in the line from the spec above: Target: Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri" (1) can't be translated into a HTTP request line which specifies only one target, as (2) provides. Perhaps target of the operations should be only printers and job-id would be considered an argument of the method invoked, or an operation attribute (e.g. cancel job). This would provide practical multiplexing within the module that processes IPP requests, be it CGI, servlet, NSAPI or ISAPI extension, where one printer would typically be served by one module for each security scheme. Peter From ipp-owner@pwg.org Wed Jun 3 18:10:56 1998 Delivery-Date: Wed, 03 Jun 1998 18:10:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28358 for ; Wed, 3 Jun 1998 18:10:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16199 for ; Wed, 3 Jun 1998 18:13:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04361 for ; Wed, 3 Jun 1998 18:10:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 18:03:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03198 for ipp-outgoing; Wed, 3 Jun 1998 17:59:56 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: RE: IPP> Identifying jobs in requests Date: Wed, 3 Jun 1998 14:59:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org The demux wasn't my idea, I was just clarifying what I thought Jay was suggesting...however, the URI itself is self-demux'ing. As you move left to right parsing a URI, you are basically performing a kind of demultiplexing, with one or more layers each handling a portion of the URI string. Its not hard to envision any number of demux'ing techniques using URIs in both HTTP and IPP headers. Sorry I missed the carnage at the teleconference ;)...hope to see the minutes. Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Wednesday, June 03, 1998 2:50 PM To: ipp@pwg.org Subject: Re: RE: IPP> Identifying jobs in requests > > I think Jay was talking about a lower-layer demux than what you are > talking about. The kind of demux that might be performed by a > CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a > core IPP processing component. > > Randy > How does placing a URI denoting the target of an IPP request inside our protocol (as an IPP attribute) facilitate this kind of demux? > > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, June 03, 1998 11:21 AM > To: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > > > > > The demultiplexing front-end is not IPP, and is therefore some > type of > > "transport-helper". While the IPP protocol document must stand > on its own, > > independent of any such transport, and therefore identifiers > within the > > protocol would still be mandatory ( Of course, my argument is > entirely > > based upon the WG's decision that IPP must be transport > independent ). > > > > Randy > > > > Randy- > > If the demultiplexing front-end is not IPP, how is it able to > read IPP attributes? > > - Carl > > > > ---------- > > > From: Jay Martin > > > To: Randy Turner > > > Cc: ipp@pwg.org > > > Subject: Re: IPP> Identifying jobs in requests > > > Date: Wednesday, June 03, 1998 9:32 AM > > > > > > Randy Turner wrote: > > > > > > > > We use URIs to identify IPP objects. If we want IPP to > maintain > > > > transport-independence, then we will always need to have > some type of > > valid > > > > URI denoting the target of an IPP request inside our > protocol. > > > > > > Not necessarily. Sure, in the case of a demultiplexing > front-end, > > > it would be necessary to have the target embedded in the > protocol > > > message, but not necessary for single-Printer > implementations. > > > > > > I don't have a problem with embedding the target URI in the > PDU, > > > but if we get into a big mess with regard to reconciling a > similar > > > target in the outer/lower transport level (eg, HTTP), then > we might > > > want to consider pulling out the embedded target URI. > > > > > > It would be nice to hear from others on this topic. > > > > > > ...jay > > > > > > > ---------------------------------------------------------------------- > > > -- JK Martin | Email: jkm@underscore.com > -- > > > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > > > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > > > ---------------------------------------------------------------------- > > > > > > From ipp-owner@pwg.org Wed Jun 3 18:20:34 1998 Delivery-Date: Wed, 03 Jun 1998 18:20:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28471 for ; Wed, 3 Jun 1998 18:20:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16225 for ; Wed, 3 Jun 1998 18:22:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05024 for ; Wed, 3 Jun 1998 18:20:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 18:16:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04176 for ipp-outgoing; Wed, 3 Jun 1998 18:09:35 -0400 (EDT) Message-Id: <199806032205.PAA06396@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 03 Jun 1998 15:10:06 -0700 To: "Carl Kugler" , ipp@pwg.org From: Robert Herriot Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: <19980603215016.14186.qmail@m2.findmail.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_7346073==_.ALT" Sender: owner-ipp@pwg.org --=====================_7346073==_.ALT Content-Type: text/plain; charset="us-ascii" In my opinion the printer-uri inside application/ipp is of no use for demux in an HTTP context. We knew it was redundant when we put it in. The argument in favor of having it for HTTP was that a gateway would not have to alter the application/ipp data when passing it on. That assumption may be false if the client believed that the gateway is the printer and the gateway has to change the target printer as it passes the operation onward. Furthermore, the application/ipp encoding doesn't handle chunking of document data, so a gateway might still have to do some additional conversion. You may well be correct that the presence of a redundant printer-uri in the application/ipp data causes more problems than it solves. Bob Herriot At 02:50 PM 6/3/98 , Carl Kugler wrote: >> >> I think Jay was talking about a lower-layer demux than what you are >> talking about. The kind of demux that might be performed by a >> CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a >> core IPP processing component. >> >> Randy >> > >How does placing a URI denoting the target of an IPP request inside our protocol (as an IPP attribute) facilitate this kind of demux? > >> >> -----Original Message----- >> From: Carl Kugler [SMTP:kugler@us.ibm.com] >> Sent: Wednesday, June 03, 1998 11:21 AM >> To: ipp@pwg.org >> Subject: Re: IPP> Identifying jobs in requests >> >> > >> > The demultiplexing front-end is not IPP, and is therefore some >> type of >> > "transport-helper". While the IPP protocol document must stand >> on its own, >> > independent of any such transport, and therefore identifiers >> within the >> > protocol would still be mandatory ( Of course, my argument is >> entirely >> > based upon the WG's decision that IPP must be transport >> independent ). >> > >> > Randy >> > >> >> Randy- >> >> If the demultiplexing front-end is not IPP, how is it able to >> read IPP attributes? >> >> - Carl >> > >> > ---------- >> > > From: Jay Martin >> > > To: Randy Turner >> > > Cc: ipp@pwg.org >> > > Subject: Re: IPP> Identifying jobs in requests >> > > Date: Wednesday, June 03, 1998 9:32 AM >> > > >> > > Randy Turner wrote: >> > > > >> > > > We use URIs to identify IPP objects. If we want IPP to >> maintain >> > > > transport-independence, then we will always need to have >> some type of >> > valid >> > > > URI denoting the target of an IPP request inside our >> protocol. >> > > >> > > Not necessarily. Sure, in the case of a demultiplexing >> front-end, >> > > it would be necessary to have the target embedded in the >> protocol >> > > message, but not necessary for single-Printer >> implementations. >> > > >> > > I don't have a problem with embedding the target URI in the >> PDU, >> > > but if we get into a big mess with regard to reconciling a >> similar >> > > target in the outer/lower transport level (eg, HTTP), then >> we might >> > > want to consider pulling out the embedded target URI. >> > > >> > > It would be nice to hear from others on this topic. >> > > >> > > ...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 -- >> > > >> ---------------------------------------------------------------------- >> > >> > >> >> > --=====================_7346073==_.ALT Content-Type: text/html; charset="us-ascii" In my opinion the printer-uri inside application/ipp is of no use for demux
in an HTTP context. We knew it was redundant when we put it in.  The
argument in favor of having it for HTTP was that a gateway would not have to
alter the application/ipp data when passing it on. 

That assumption may be false if the client believed that the gateway is the
printer and the gateway has to change the target printer as it passes the
operation onward.  Furthermore, the application/ipp encoding doesn't handle
chunking of document data, so a gateway might still have to do some
additional conversion.

You may well be correct that the presence of a redundant printer-uri in the
application/ipp data causes more problems than it solves.

Bob Herriot

At 02:50 PM 6/3/98 , Carl Kugler wrote:
>>
>> I think Jay was talking about a lower-layer demux than what you are
>> talking about. The kind of demux that might be performed by a
>> CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a
>> core IPP processing component.
>>
>> Randy
>>
>
>How does placing a URI denoting the target of an IPP request inside our protocol (as an IPP attribute) facilitate this kind of demux?
>
>>
>>      -----Original Message-----
>>      From:   Carl Kugler [SMTP:kugler@us.ibm.com]
>>      Sent:   Wednesday, June 03, 1998 11:21 AM
>>      To:     ipp@pwg.org
>>      Subject:        Re: IPP> Identifying jobs in requests
>>
>>      >
>>      > The demultiplexing front-end is not IPP, and is therefore some
>> type of
>>      > "transport-helper". While the IPP protocol document must stand
>> on its own,
>>      > independent of any such transport, and therefore identifiers
>> within the
>>      > protocol would still be mandatory ( Of course, my argument is
>> entirely
>>      > based upon the WG's decision that IPP must be transport
>> independent ).
>>      >
>>      > Randy
>>      >
>>
>>      Randy-
>>
>>      If the demultiplexing front-end is not IPP, how is it able to
>> read IPP attributes?
>>
>>      - Carl
>>      >
>>      > ----------
>>      > > From: Jay Martin <jkm@underscore.com>
>>      > > To: Randy Turner <rturner@sharplabs.com>
>>      > > Cc: ipp@pwg.org
>>      > > Subject: Re: IPP> Identifying jobs in requests
>>      > > Date: Wednesday, June 03, 1998 9:32 AM
>>      > >
>>      > > Randy Turner wrote:
>>      > > >
>>      > > > We use URIs to identify IPP objects. If we want IPP to
>> maintain
>>      > > > transport-independence, then we will always need to have
>> some type of
>>      > valid
>>      > > > URI denoting the target of an IPP request inside our
>> protocol.
>>      > >
>>      > > Not necessarily.  Sure, in the case of a demultiplexing
>> front-end,
>>      > > it would be necessary to have the target embedded in the
>> protocol
>>      > > message, but not necessary for single-Printer
>> implementations.
>>      > >
>>      > > I don't have a problem with embedding the target URI in the
>> PDU,
>>      > > but if we get into a big mess with regard to reconciling a
>> similar
>>      > > target in the outer/lower transport level (eg, HTTP), then
>> we might
>>      > > want to consider pulling out the embedded target URI.
>>      > >
>>      > > It would be nice to hear from others on this topic.
>>      > >
>>      > >     ...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   --
>>      > >
>> ----------------------------------------------------------------------
>>      >
>>      >
>>
>>
>
--=====================_7346073==_.ALT-- From ipp-owner@pwg.org Wed Jun 3 18:32:11 1998 Delivery-Date: Wed, 03 Jun 1998 18:32:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28540 for ; Wed, 3 Jun 1998 18:32:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16275 for ; Wed, 3 Jun 1998 18:34:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05714 for ; Wed, 3 Jun 1998 18:32:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 18:27:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05120 for ipp-outgoing; Wed, 3 Jun 1998 18:25:14 -0400 (EDT) Message-ID: <3575CD3C.709297CC@underscore.com> Date: Wed, 03 Jun 1998 18:25:00 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Yes, this is what I was envisioning. Thanks, Randy. ...jay Turner, Randy wrote: > > The demux wasn't my idea, I was just clarifying what I thought Jay was > suggesting...however, the URI itself is self-demux'ing. As you move left > to right parsing a URI, you are basically performing a kind of > demultiplexing, with one or more layers each handling a portion of the > URI string. Its not hard to envision any number of demux'ing techniques > using URIs in both HTTP and IPP headers. > > Sorry I missed the carnage at the teleconference ;)...hope to see the > minutes. > > Randy > > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Wednesday, June 03, 1998 2:50 PM > To: ipp@pwg.org > Subject: Re: RE: IPP> Identifying jobs in requests > > > > > I think Jay was talking about a lower-layer demux than what > you are > > talking about. The kind of demux that might be performed by a > > CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the > data to a > > core IPP processing component. > > > > Randy > > > > How does placing a URI denoting the target of an IPP request > inside our protocol (as an IPP attribute) facilitate this kind of demux? > > > > > -----Original Message----- > > From: Carl Kugler [SMTP:kugler@us.ibm.com] > > Sent: Wednesday, June 03, 1998 11:21 AM > > To: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > > > > > > > The demultiplexing front-end is not IPP, and is > therefore some > > type of > > > "transport-helper". While the IPP protocol document > must stand > > on its own, > > > independent of any such transport, and therefore > identifiers > > within the > > > protocol would still be mandatory ( Of course, my > argument is > > entirely > > > based upon the WG's decision that IPP must be > transport > > independent ). > > > > > > Randy > > > > > > > Randy- > > > > If the demultiplexing front-end is not IPP, how is it > able to > > read IPP attributes? > > > > - Carl > > > > > > ---------- > > > > From: Jay Martin > > > > To: Randy Turner > > > > Cc: ipp@pwg.org > > > > Subject: Re: IPP> Identifying jobs in requests > > > > Date: Wednesday, June 03, 1998 9:32 AM > > > > > > > > Randy Turner wrote: > > > > > > > > > > We use URIs to identify IPP objects. If we want > IPP to > > maintain > > > > > transport-independence, then we will always need > to have > > some type of > > > valid > > > > > URI denoting the target of an IPP request inside > our > > protocol. > > > > > > > > Not necessarily. Sure, in the case of a > demultiplexing > > front-end, > > > > it would be necessary to have the target embedded in > the > > protocol > > > > message, but not necessary for single-Printer > > implementations. > > > > > > > > I don't have a problem with embedding the target URI > in the > > PDU, > > > > but if we get into a big mess with regard to > reconciling a > > similar > > > > target in the outer/lower transport level (eg, > HTTP), then > > we might > > > > want to consider pulling out the embedded target > URI. > > > > > > > > It would be nice to hear from others on this topic. > > > > > > > > ...jay > > > > > > > > > > > ---------------------------------------------------------------------- > > > > -- JK Martin | Email: > jkm@underscore.com > > -- > > > > -- Underscore, Inc. | Voice: (603) > 889-7000 > > -- > > > > -- 41C Sagamore Park Road | Fax: (603) > 889-2699 > > -- > > > > -- Hudson, NH 03051-4915 | Web: > > http://www.underscore.com -- > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 18:57:03 1998 Delivery-Date: Wed, 03 Jun 1998 18:57:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28654 for ; Wed, 3 Jun 1998 18:57:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA16370 for ; Wed, 3 Jun 1998 18:59:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA06401 for ; Wed, 3 Jun 1998 18:57:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 18:52:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05831 for ipp-outgoing; Wed, 3 Jun 1998 18:49:03 -0400 (EDT) Date: 3 Jun 1998 22:47:56 -0000 Message-ID: <19980603224756.17362.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: <199806032205.PAA06396@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org Bob Herriot wrote: > > In my opinion the printer-uri inside application/ipp is of no use for demux > in an HTTP context. We knew it was redundant when we put it in. I think the printer-uri inside application/ipp is of no use at all, unless we add another IPP Object to the model, call it a "Server", which demuxes requests by printer-uri IPP attribute. And then, I think printer-uri targets in requests should be Relative URIs, meaningful in the context of the Server. The original proposal just asked for a way to identify Jobs inside requests. That makes sense for implementations that can only address Printers, not Jobs. But any implementation or transport layer should be able to address to the granularity of Printers, or else you have to invent IPP Servers. The "job-id" is effectively a relative identifier, meaningful only in the context of the containing Printer. "job-uri" could be a Relative URI, too, when embedded in an IPP request addressed to a Printer. The > argument in favor of having it for HTTP was that a gateway would not have to > alter the application/ipp data when passing it on. > > That assumption may be false if the client believed that the gateway is the > printer and the gateway has to change the target printer as it passes the > operation onward. Furthermore, the application/ipp encoding doesn't handle > chunking of document data, so a gateway might still have to do some > additional conversion. > > You may well be correct that the presence of a redundant printer-uri in the > application/ipp data causes more problems than it solves. > > Bob Herriot > > At 02:50 PM 6/3/98 , Carl Kugler wrote: > >> > >> I think Jay was talking about a lower-layer demux than what you are > >> talking about. The kind of demux that might be performed by a > >> CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a > >> core IPP processing component. > >> > >> Randy > >> > > > >How does placing a URI denoting the target of an IPP request inside our > protocol (as an IPP attribute) facilitate this kind of demux? > > > >> > >> -----Original Message----- > >> From: Carl Kugler [SMTP:kugler@us.ibm.com] > >> Sent: Wednesday, June 03, 1998 11:21 AM > >> To: ipp@pwg.org > >> Subject: Re: IPP> Identifying jobs in requests > >> > >> > > >> > The demultiplexing front-end is not IPP, and is therefore some > >> type of > >> > "transport-helper". While the IPP protocol document must stand > >> on its own, > >> > independent of any such transport, and therefore identifiers > >> within the > >> > protocol would still be mandatory ( Of course, my argument is > >> entirely > >> > based upon the WG's decision that IPP must be transport > >> independent ). > >> > > >> > Randy > >> > > >> > >> Randy- > >> > >> If the demultiplexing front-end is not IPP, how is it able to > >> read IPP attributes? > >> > >> - Carl > >> > > >> > ---------- > >> > > From: Jay Martin > >> > > To: Randy Turner > >> > > Cc: ipp@pwg.org > >> > > Subject: Re: IPP> Identifying jobs in requests > >> > > Date: Wednesday, June 03, 1998 9:32 AM > >> > > > >> > > Randy Turner wrote: > >> > > > > >> > > > We use URIs to identify IPP objects. If we want IPP to > >> maintain > >> > > > transport-independence, then we will always need to have > >> some type of > >> > valid > >> > > > URI denoting the target of an IPP request inside our > >> protocol. > >> > > > >> > > Not necessarily. Sure, in the case of a demultiplexing > >> front-end, > >> > > it would be necessary to have the target embedded in the > >> protocol > >> > > message, but not necessary for single-Printer > >> implementations. > >> > > > >> > > I don't have a problem with embedding the target URI in the > >> PDU, > >> > > but if we get into a big mess with regard to reconciling a > >> similar > >> > > target in the outer/lower transport level (eg, HTTP), then > >> we might > >> > > want to consider pulling out the embedded target URI. > >> > > > >> > > It would be nice to hear from others on this topic. > >> > > > >> > > ...jay > >> > > > >> > > > >> ---------------------------------------------------------------------- > >> > > -- JK Martin | Email: jkm@underscore.com > >> -- > >> > > -- Underscore, Inc. | Voice: (603) 889-7000 > >> -- > >> > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > >> -- > >> > > -- Hudson, NH 03051-4915 | Web: > >> http://www.underscore.com -- > >> > > > >> ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 19:05:27 1998 Delivery-Date: Wed, 03 Jun 1998 19:05:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28690 for ; Wed, 3 Jun 1998 19:05:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16398 for ; Wed, 3 Jun 1998 19:07:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA07040 for ; Wed, 3 Jun 1998 19:05:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 19:01:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06289 for ipp-outgoing; Wed, 3 Jun 1998 18:56:07 -0400 (EDT) Date: 3 Jun 1998 22:54:56 -0000 Message-ID: <19980603225456.18052.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: <199806032205.PAA06396@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org Bob Herriot wrote: > > In my opinion the printer-uri inside application/ipp is of no use for demux > in an HTTP context. We knew it was redundant when we put it in. I think the printer-uri inside application/ipp is of no use at all, unless we add another IPP Object to the model, call it a "Server", which demuxes requests by printer-uri IPP attribute. And then, I think printer-uri targets in requests should be Relative URIs, meaningful in the context of the Server. The original proposal just asked for a way to identify Jobs inside requests. That makes sense for implementations that can only address Printers, not Jobs. But any implementation or transport layer should be able to address to the granularity of Printers, or else you have to invent IPP Servers. The "job-id" is effectively a relative identifier, meaningful only in the context of the containing Printer. "job-uri" could be a Relative URI, too, when embedded in an IPP request addressed to a Printer. The > argument in favor of having it for HTTP was that a gateway would not have to > alter the application/ipp data when passing it on. > > That assumption may be false if the client believed that the gateway is the > printer and the gateway has to change the target printer as it passes the > operation onward. Furthermore, the application/ipp encoding doesn't handle > chunking of document data, so a gateway might still have to do some > additional conversion. > > You may well be correct that the presence of a redundant printer-uri in the > application/ipp data causes more problems than it solves. > > Bob Herriot > > At 02:50 PM 6/3/98 , Carl Kugler wrote: > >> > >> I think Jay was talking about a lower-layer demux than what you are > >> talking about. The kind of demux that might be performed by a > >> CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a > >> core IPP processing component. > >> > >> Randy > >> > > > >How does placing a URI denoting the target of an IPP request inside our > protocol (as an IPP attribute) facilitate this kind of demux? > > > >> > >> -----Original Message----- > >> From: Carl Kugler [SMTP:kugler@us.ibm.com] > >> Sent: Wednesday, June 03, 1998 11:21 AM > >> To: ipp@pwg.org > >> Subject: Re: IPP> Identifying jobs in requests > >> > >> > > >> > The demultiplexing front-end is not IPP, and is therefore some > >> type of > >> > "transport-helper". While the IPP protocol document must stand > >> on its own, > >> > independent of any such transport, and therefore identifiers > >> within the > >> > protocol would still be mandatory ( Of course, my argument is > >> entirely > >> > based upon the WG's decision that IPP must be transport > >> independent ). > >> > > >> > Randy > >> > > >> > >> Randy- > >> > >> If the demultiplexing front-end is not IPP, how is it able to > >> read IPP attributes? > >> > >> - Carl > >> > > >> > ---------- > >> > > From: Jay Martin > >> > > To: Randy Turner > >> > > Cc: ipp@pwg.org > >> > > Subject: Re: IPP> Identifying jobs in requests > >> > > Date: Wednesday, June 03, 1998 9:32 AM > >> > > > >> > > Randy Turner wrote: > >> > > > > >> > > > We use URIs to identify IPP objects. If we want IPP to > >> maintain > >> > > > transport-independence, then we will always need to have > >> some type of > >> > valid > >> > > > URI denoting the target of an IPP request inside our > >> protocol. > >> > > > >> > > Not necessarily. Sure, in the case of a demultiplexing > >> front-end, > >> > > it would be necessary to have the target embedded in the > >> protocol > >> > > message, but not necessary for single-Printer > >> implementations. > >> > > > >> > > I don't have a problem with embedding the target URI in the > >> PDU, > >> > > but if we get into a big mess with regard to reconciling a > >> similar > >> > > target in the outer/lower transport level (eg, HTTP), then > >> we might > >> > > want to consider pulling out the embedded target URI. > >> > > > >> > > It would be nice to hear from others on this topic. > >> > > > >> > > ...jay > >> > > > >> > > > >> ---------------------------------------------------------------------- > >> > > -- JK Martin | Email: jkm@underscore.com > >> -- > >> > > -- Underscore, Inc. | Voice: (603) 889-7000 > >> -- > >> > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > >> -- > >> > > -- Hudson, NH 03051-4915 | Web: > >> http://www.underscore.com -- > >> > > > >> ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jun 3 19:13:02 1998 Delivery-Date: Wed, 03 Jun 1998 19:13:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28718 for ; Wed, 3 Jun 1998 19:12:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16422 for ; Wed, 3 Jun 1998 19:14:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA07711 for ; Wed, 3 Jun 1998 19:12:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 19:06:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05968 for ipp-outgoing; Wed, 3 Jun 1998 18:53:39 -0400 (EDT) Message-Id: <3.0.5.32.19980603155141.00ce87c0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 3 Jun 1998 15:51:41 PDT To: moore@cs.utk.edu, ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Feedback on IESG comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Keith, Based on two phone conferences and discussions on the IPP and HTTP DLs, here is our first stab at answering your comments. It is abundantly clear that in particular your proposals for the "ipp" scheme and mandating TLS for all IPP clients are NOT finding support in the WG. We will continue the discussion on the DL, but would like to set up a phone conference with you next week to discuss the HTTP and TLS comments with you directly. I have inserted our comments, based on the WG input so far, starting with CM> in your original text below. The editors are already at work to fix all the minor and editorial things. NOTE: I would appreciate if those WG members who feel that their voices have not been heard in these preliminary responses express their views quickly on the IPP DL. I realize that a couple of MS people have expressed strong views on using PRINT instead of POST (no surprise there), but that still seems to be more of a minority view so far. If you are a PRINT method supporter, please speak up now! Carl-Uno ----- At long last I've completed my review of the IPP documents. My comments follow. Please note that we're still waiting for the TLS document to clear (sigh)... things that depend on TLS can't go through until TLS is finished. Last I heard they were waiting on resolution of some patent issues and/or an X.509 profile that allowed use of UTF-8 in printable strings. (yeech) CM> I have sent out a question to the TLS WG DL asking about status. They are currently blaming PKIX for the hold-up. We will keep chasing the responsible.... I apologize for this haven taken so long. CM> Right. Keith summary: Basically I think the protocols are mostly sound, though the documents need some editorial cleanup. There are some minor technical tweaks here and there. The biggest change that I think is needed, is that IPP's use of HTTP doesn't allow a firewall to distinguish between IPP traffic and ordinary HTTP traffic. Also, IPP's insistence on using port 80 could conflict with ordinary use of that port, in those cases where the IPP server was not designed to "plug in" to the HTTP server. For these reasons, I suggest that a separate port be allocated for IPP, and an "ipp" URL defined which defaults to the IPP port rather than port 80. An alternative would be to have IPP use the PRINT method rather than POST, but to me the separate port seems cleaner and more likely to be compatible with firewalls. One could still use IPP on port 80, by using the port override notation: ipp://hostname:80/etc. CM> I sent out a question to the HTTP WG DL about the adviceability of introducing a new URL scheme and to allocate a new default port number to IPP. The responses so far from the HTTP experts were that allocating a new port would not cause too much of a problem, but most everybody strongly adviced against a new URL scheme. CM> A majority in he IPP WG does not see a strong need to change ANYTHING regarding HTTP in the current drafts. You need to give us better arguments for the suggested change - the once you give us have been extensively discussed earlier and rejected. The current IPP solution has now been implemented by several companies and found to work fine. We need very strong reasons to change something that actually works to something that might NOT. Note that we now have in effect a policy of not allocating separate ports for with/without TLS. (I've asked the security ADs in IESG to review this policy, but I think it will be upheld.) Someone has an internet-draft which attempts to define a way to negotiate TLS in-band over HTTP; you might want to look at that. CM> The IPP solution does not assume one or the other. As for considering a new security I-D that is far from the standards track - forget it! similarly, using the "s" suffix on the URI type to indicate TLS/ is considered by many to be a Bad Idea; if it's necessary to specify a particular authentication and/or encryption type, it should probably be done using a URI parameter. (and it should probably be more flexible than just ";security=tls") CM> We do not really care, we will do what the security groups decide - if they ever make a decision. The IPP solution allows either or. We are not in the business of defining new URI parameters for HTTP. detailed comments follow; I apologize for mixing the purely editorial (most of the comments) with the technical issues, and thus making this unnecessarily tedious to read for anyone other than the authors. but this way, I get to cross this off my list today! CM> We are happy to hear SOMETHING from you. general: 1. In addition to the keywords defined in RFC 2119, the documents use a number of upper case terms like SHALL, SHALL NOT, NEED NOT, etc. If these terms are in upper case because they have special meanings, those meanings need to be defined somewhere, and each document that uses those terms needs to have a prominent notice (i.e. near the beginning of the document) pointing to those definitions. If the terms have their normal meanings (which from my reading seems to be the case), they should be spelled in lower case, unless there is some reason to emphasize a particular use of a term. CM> It seems that you have not actually read RFC 2119, which states that these terms are often capitalized and uses that in RFC 2119 itself. On the other hand, it appears that SHALL etc. are sometimes used when one of the words in RFC 2119 would do just as well. It would be better to keep consistent technology unless there's a good reason not to do so. CM> Editorial Note that the keywords in RFC 2119 are generally used to indicate implementation choices that would affect compliance with a standard, or very occasionally, requirements for operation of the service (as in "SMTP servers MUST accept mail addressed to Postmaster") Other uses of "MUST", "SHOULD", etc. should generally use lower case letters. For instance, the IPP design goals "MUST" be satisfied in IPP/1.0...this is not a requirement on implementation, and should be spelled "must". CM> Editorial Finally, if you need to use one of these upper cased keywords with "not", it should be "MUST NOT" or "SHALL NOT", rather than "MUST not" or SHALL not (or even "SHALL also not") to have one word upper cased and the other not, is confusing. CM> Editorial 2. there appear to be a number of artifacts in the plain text versions of the documents, which may have resulted from conversion to text from some other format. For instance, tables are poorly formatted in the text version, I saw at least one instance of overprinting, and there appear to be missing pieces of text here and there. Since the plain text versions are considered authoritative, they need to be carefully proofread. CM> Editorial draft-ietf-ipp-rat-02.txt: 1. the last paragraph (9) of section 4 may need tweaking depending on whether IPP is revised to use a different default port than HTTP< or if it's revised to use PRINT instead of POST. CM> Editorial, only if a new HTTP solution is decided. 2. section 7 is actually missing the copyright notice; it only contains the license. CM> Editorial draft-ietf-ipp-req-01.txt: 1. Even though the IPP WG was told to write a requirements document, some IESG folks have pushed back on using the word "requirements" in a document title. My guess is that the title should be changed to something like "Design Goals for an Internet Printing Protocol". Either that, or many of the "requirements" need more justification to convince the reader that they're obviously requirements and not merely goals. CM> Editorial 2. Section 1: It's not clear how or why a web browser is part of a complete Internet Printing system. CM> Editorial 3. Section 2.1.4: it's not clear why a user needs to have the ability to submit a print job by reference. CM> Add text explaining it saves the user to first download a large document that sits on a repository in a server, including a web server. 4. Section 2.2: change "the user may only see his own jobs" to "the user might only be able to see his own jobs". CM> Editorial 5. Section 3, third paragraph, last sentence. Seems like "must properly handle this methodology" should be "must properly handle either methodology". CM> Editorial 6. Section 3.1, first paragraph. "Whenever possible, IPP ought to make use of ..." should perhaps be "Whenever reasonable,..." CM> Editorial 7. 3.1, second paragraph. "printing environments describes"... should be "printing environments described"; "document to be printed may all exist" should be "document to be printed may each exist" ; "protection are much stronger" should be "protection may be much stronger" CM> Editorial 8. 3.3, first paragraph. "shall be extensible by several means that facilitates interoperability and prevents"... should be "facilitate" and "prevent" CM> Editorial 9. section 3.3: the structure of the bulleted list is confusing; some of the bullets should apparently be subordinate to the others. 4th bullet: needs a space between "attributes" and "and" CM> Editorial 10. section 4.2. there are significant security risks associated with driver installation; I don't see any discussion of those risks. CM> We will consider adding new text - although driver installation is really outside the scope of IPP v1.0. 11. section 7. there appears to be overprinting in the acknowledgements section (at least, enscript didn't handle it right) CM> Editorial 12. the document seems to assume that users will download a driver to talk to a particular printer; there's no requirement that users be able to talk to printers -- even in reduced functionality mode -- without downloading a driver. this would seem to constrain the cross-platform portability of the standard, as well as introducing security risks. (which is not to say that IPP itself has problems with this ... I think it's okay .. but the assumption that everyone who wants to talk to a printer can download and install a driver is not a valid one...it's too windows centric) CM> Editorial. Downloading drivers is common today, but there are other ways. All we need to say is that there must be some way of producing a PDL. The fact that we have an optional URL reference that can point to a page with drivers is a clear user requirement. 13. section 9.23. do we have permission to use Kinko's and Sir Speedy's names/trademarks? If not, should probably substitute generic names. CM> Change to generic names. 14. document is missing a security considerations section at the end. it can refer to section 4.1 but should also mention security problems related to downloading drivers. CM> Editorial draft-ietf-ipp-model-09.txt: 1. Section 2.4: should refer to TLS, not SSL3. Also, the "https" URL prefix is nonstandard. CM> Editorial, we will take out all references to SSL3 and https, except in the security schemes, where SSL3 is still an option. 2. at the end of section 3.1.3, this is misstated: if the URL type allows a port number and one is specified, that port number must be used. if no port number is specified, the default port must be used. (if the URL type doesn't allow a port number and one is specified anyway, it's arguably a parse error on the URL and the whole operation should fail) CM> Editorial. 3. section 3.1.4.1, last paragraph: "object SHALL NOT change either of these attributes and SHALL except them as if they were valid." it's not clear (to me) what this means: doesn't this put the printer in a position where it cannot report errors in the natural language? I understand not allowing the printer to change the request, but shouldn't this be an error condition, and if so, how should it be reported? CM> Will be reworded. 4. section 3.2.1.2, under "Group 3: Job Object Attributes" "Printer object always uses is" should be "Printer object always uses its" CM> Editorial 5. section 4.1.1 it's not clear to me why, if anything defined as 'text' is also allowed to use 'textWithLanguage' syntax, that there are separate syntaxes for text vs. textWithLanguage. Why not either do: text = textWithLanguage | textUsingImplicitLanguage and just call everything 'text' from then on out? (which would be a purely editorial simplification) or just elimiate the implicit language form altogether? (which would be a protocol simplification) CM> Accept first proposal. We do not want to make protocol changes at this stage. 6. 4.1.2, 5th paragraph "SHALL accept, support, and return both the 'text' and 'textWithLanguage' reads as if objects are requried to *return* both syntaxes for every text attribute...not one or the other. CM> Editorial, needs rewording. 7. section 4.1.8. if you must refer to https, please refer to it as non-standard. CM> Editorial, add comment. 8. section 4.1.9 what does it mean to restrict the use of utf-8 to iso 10646? why do you want to impose such a restriction? CM> This restriction is in UTC-8 itself. Reword and change reference to UTF-8 in RFC 2279. 9. section 4.1.11 'mimeMediaType' is too short, especially given that it contains the parameters also. 127 octets would be marginal. 255 would be a lot better. (is there a reason to use 2**n-1?) CM> Increase to 255. 10. section 4.2.7 does the page-ranges count page images rather than docuemnt page numbers (say in eps or pdf?) CM> Needs rewording. Should be page images. 11. section 4.3.1 despite widespread use of "https" etc, the URI "access method" shouldn't be used to indicate the presense or lack of "security"; when necessary to specify a particular security technology in a URI, that should be a done with a paramter (e.g. ";auth-type=digest"). CM> We do not have that dependency. We will improve the text. 12. section 4.3.7 for the case where there is an IPP front-end to some other kind of printer queue, and it's not possible for the front-end to determine whether the job is 'completed' according to the IPP definition, what status should it report when the job is finished as best as can be determined? it seems like 'completed' is the right thing to do here, but this would be inconsistent with the definition. CM> Use "unknown" value. Add note to that effect. 13. section 4.4.2 the example makes it appear as if "password-printer" is a magic string in a URL, which indicates that a printer is to use basic or digest authenticaiton CM> Reword and change example. 14. section 4.4.24 cleartext passwords are no longer allowed in URLs CM> Take out the FTP details, reference RFC 1738 and RFC 2316. 15. section 5.1, last paragraph "Clients may choose to ignore any parameters that it does not understand" should be "...that they do not understand". CM> Editorial 16. section 5.4 Conforming clients MUST (not SHOULD) support TLS access. CM> Controversial proposal, as TLS not yet exists neither as standard nor product. Not even Alphas for TLS yet around, while IPP already in Betas. The security folks did not get their act together. 17. section 6.1 If I'm not mistaken, it's inappropriate for the IPP RFC to actually name the experts. CM> We will check with IANA. Nor do I think it's okay to have PWG "specify a replacement [expert] at any time", because PWG isn't responsible to IETF in any way. CM> It could be responsible to IANA if IANA so decides. Nor do I think it's okay to give PWG control over the keywoard/enum value space. IANA can delegate to PWG, but IANA should have ultimate authority. CM> Check with IANA. This section needs to be reviewed by IANA. draft-ietf-ipp-protocol-05.txt: 1. Section 3.2. I probably haven't grokked how these are used, but are there enough attribute tags and value tags to have room for future expansion? CM> There is lots of room for expansion. We will explain how. 2. Section 3.9 some text appears to be missing CM> Editorial 3. section 3.11 The table in the text version is illegible. CM> Editorial 4. section 4 IPP needs its own default port and url scheme. Support for port 80 should be optional. CM> Not agreed. Strong opposition to define new URL scheme. IPP was designed to run on top of HTTP that has port 80 as default. We could potentially allocate a new alternate port that COULD be used by firewall administrators IF they want to distinguish IPP traffic from other HTTP traffic. 5. section 4.1 table is difficult to read CM> Editorial 6. section 4.2 it looks like there might be missing information in the accept-language row of the table. CM> Editorial 7. section 5 IPP needs its own port; support for port 80 should be optional. CM> IPP was designed to run on top of HTTP that has port 80 as default. We could potentially allocate a new alternate port that COULD be used by firewall administrators IF they want to distinguish IPP traffic from other HTTP traffic. draft-ietf-ipp-lpd-ipp-map-03.txt 1. section 4.3 table is difficult to read in the text version CM> Editorial 2. section 7 change title to "Security Considerations". yes, some folks are picky about this. CM> Editorial Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 3 19:20:27 1998 Delivery-Date: Wed, 03 Jun 1998 19:20:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28755 for ; Wed, 3 Jun 1998 19:20:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16480 for ; Wed, 3 Jun 1998 19:22:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA08329 for ; Wed, 3 Jun 1998 19:20:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 19:16:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07220 for ipp-outgoing; Wed, 3 Jun 1998 19:07:28 -0400 (EDT) Message-ID: <3FF8121C9B6DD111812100805F31FC0D0297141D@red-msg-59.dns.microsoft.com> From: Yaron Goland To: "'Dave Kristol'" Cc: "'http-wg'" , "'ipp@pwg.org'" Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 16:07:14 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org You're right, a non-transparent proxy could reject an unknown method. However the point was that sending methods not specified in the HTTP spec is not a protocol violation. Yaron > -----Original Message----- > From: Dave Kristol [mailto:dmk@bell-labs.com] > Sent: Wednesday, June 03, 1998 1:17 PM > To: Yaron Goland > Cc: 'http-wg'; 'ipp@pwg.org' > Subject: Re: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > Yaron Goland wrote: > > > > Rob clarified in personal e-mail that he meant the latest > rev of the HTTP > > draft. > > > > One of the innovations of HTTP in respect to many other > protocols is that > > you do not need to modify the HTTP standard in order to add > new methods for > > use with HTTP. Rather HTTP defines exactly how one is to > act if one receives > > an unknown method. Thus one can safely add new methods and > know that at the > > worst one will simply receive a method unknown error from > servers/firewalls > > and be tunneled by proxies. > > How can one "know that at the worst one will ... be tunneled by > proxies"? I can't find anything in the HTTP/1.1 spec. that instructs > proxies to tunnel unknown methods. I think at worst the > request will be > rejected. > > Dave Kristol > From ipp-owner@pwg.org Wed Jun 3 19:56:39 1998 Delivery-Date: Wed, 03 Jun 1998 19:56:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28893 for ; Wed, 3 Jun 1998 19:56:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA16577 for ; Wed, 3 Jun 1998 19:59:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA09130 for ; Wed, 3 Jun 1998 19:56:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 19:52:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08566 for ipp-outgoing; Wed, 3 Jun 1998 19:52:02 -0400 (EDT) Message-Id: <3.0.1.32.19980603164732.0129cee0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 3 Jun 1998 16:47:32 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Should enums be 0 to 2**31-1, not -2**31 to 2**31-1? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org In section 4.1.6 'enum' it says that the "integer value is in the range from -2**31 (MIN) to 2**31-1(MAX)." Shouldn't enums be 0 to 2**31-1, not -2**31 to 2**31-1? There shouldn't be negative values, correct? We also don't happen to use 0 values either to align with SNMP MIB enums, but I don't see that we should make the range start at 1. Tom From ipp-owner@pwg.org Thu Jun 4 02:09:25 1998 Delivery-Date: Thu, 04 Jun 1998 02:09:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA11527 for ; Thu, 4 Jun 1998 02:09:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA17250 for ; Thu, 4 Jun 1998 02:11:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA11319 for ; Thu, 4 Jun 1998 02:08:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 02:02:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA10738 for ipp-outgoing; Thu, 4 Jun 1998 01:59:07 -0400 (EDT) From: "Larry Masinter" To: "Scott Isaacson" , , , , Cc: , Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers Date: Wed, 3 Jun 1998 22:58:26 PDT Message-ID: <001e01bd8f7d$ca8a7f00$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org > > For example, take a URL that does not explicitly specify a port: > > http://my.domain.com/printer1 > > - If the client is in the act of printing (browser that is printing > or a print only client) the the port to use is the new IPP default port. > > - Any other client will use the HTTP default port This suggestion is completely unworkable. The default port for the "http" scheme is 80. It isn't "80 when you use it one way and something else when you use it another". I think you can define a new scheme "ipp" and just define it quite simply: ipp://host/path === http://host:ippport/path (used for ipp) E.g., if the IPP port is "187" then ipp://printer.xerox.com/doit would be interpreted _exactly_ as http://printer.xerox.com:187/doit This equivalence can be done in the client, and need not be handled by the proxies at all. Since an ipp client has to know about the rest of the ipp protocol anyway, requiring the ipp client to do the translation is not a burden. From ipp-owner@pwg.org Thu Jun 4 02:53:04 1998 Delivery-Date: Thu, 04 Jun 1998 02:53:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA11696 for ; Thu, 4 Jun 1998 02:53:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA17298 for ; Thu, 4 Jun 1998 02:55:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA12100 for ; Thu, 4 Jun 1998 02:52:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 02:47:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA11535 for ipp-outgoing; Thu, 4 Jun 1998 02:46:15 -0400 (EDT) Date: 4 Jun 1998 06:45:05 -0000 Message-ID: <19980604064505.15713.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD - Should enums be 0 to 2**31-1, not -2** In-Reply-To: <3.0.1.32.19980603164732.0129cee0@garfield> To: ipp@pwg.org Sender: owner-ipp@pwg.org > In section 4.1.6 'enum' it says that the "integer value is in the range > from -2**31 (MIN) to 2**31-1(MAX)." > > Shouldn't enums be 0 to 2**31-1, not -2**31 to 2**31-1? > > There shouldn't be negative values, correct? > > We also don't happen to use 0 values either to align with SNMP MIB > enums, but I don't see that we should make the range start at 1. > I do. I say make them 1 to 2**31-1. They're just arbitrary values anyway, and it's not like we're going to run out. > Tom > > From ipp-owner@pwg.org Thu Jun 4 10:59:51 1998 Delivery-Date: Thu, 04 Jun 1998 10:59:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15067 for ; Thu, 4 Jun 1998 10:59:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA18861 for ; Thu, 4 Jun 1998 11:02:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA14634 for ; Thu, 4 Jun 1998 10:59:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 10:47:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14045 for ipp-outgoing; Thu, 4 Jun 1998 10:43:11 -0400 (EDT) Message-Id: <1.5.4.32.19980604143545.00739078@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, 04 Jun 1998 07:35:45 -0700 To: "Larry Masinter" , "Scott Isaacson" , , , , From: Carl-Uno Manros Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers Cc: , Sender: owner-ipp@pwg.org At 10:58 PM 6/3/98 PDT, Larry Masinter wrote: >> >> For example, take a URL that does not explicitly specify a port: >> >> http://my.domain.com/printer1 >> >> - If the client is in the act of printing (browser that is printing >> or a print only client) the the port to use is the new IPP default port. >> >> - Any other client will use the HTTP default port > >This suggestion is completely unworkable. The default port for >the "http" scheme is 80. It isn't "80 when you use it one way >and something else when you use it another". > >I think you can define a new scheme "ipp" and just define it quite >simply: > ipp://host/path === http://host:ippport/path (used for ipp) > >E.g., if the IPP port is "187" then > ipp://printer.xerox.com/doit > >would be interpreted _exactly_ as > > http://printer.xerox.com:187/doit > >This equivalence can be done in the client, and need not be handled >by the proxies at all. Since an ipp client has to know about the rest >of the ipp protocol anyway, requiring the ipp client to do the translation >is not a burden. > > Larry, This might be a brilliant idea - if I could only understand what it is that you suggest. It seems to me that you are suggesting to introduce "ipp", as a synonym for "http", which you map in both the server and the client? If that is correct, does that not mean that you are running "http" over the wire, and hence through the firewall? The whole discussion as raised in Keith's feedback has to do with firewalls. Also, we are not discussing how easy or not it is to change the specs, but what the consequences are for implementors. My understanding is that Keith is trying to dictate that IPP CANNOT USE "http" - full stop. Considering that he has been the project advisor, I am very disappopinted to see that kind of proposal at this stage in the project. Carl-Uno From VRRP-owner@drcoffsite.com Thu Jun 4 11:17:44 1998 Delivery-Date: Thu, 04 Jun 1998 11:17:44 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15795 for ; Thu, 4 Jun 1998 11:17:37 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA18986 for ; Thu, 4 Jun 1998 11:20:00 -0400 (EDT) Received: from mail12.digital.com [192.208.46.20] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A90E20FA03F2; Thu, 04 Jun 1998 11:11:10 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail12.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id LAA12335; Thu, 4 Jun 1998 11:09:42 -0400 (EDT) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA23004; Thu, 4 Jun 1998 11:09:40 -0400 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA12497; Thu, 4 Jun 1998 11:09:34 -0400 X-Sender: cei@lkg.dec.com Message-Id: <3576B8AD.FF6@cei1.lkg.dec.com> Date: Thu, 04 Jun 1998 11:09:33 -0400 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Tony Li Cc: dwhipple@microsoft.com, abhatt@extremenetworks.com, vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <199806030057.RAA19555@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony: I don't see that the Gratuitous ARP 'fix'es anything with VRRP. In VRRP, when a router dies and is replaced, the new master uses the same IP:MAC binding (same IP address AND same MAC as the failed router). I conclude that the gratuitous ARP does not do any re-mapping of host's ARP entries. Carol Tony Li wrote: > > | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about > | which Unix versions support it. > > So how does that help the legacy systems that VRRP/HSRP was trying to fix? > > Tony From ipp-owner@pwg.org Thu Jun 4 11:28:04 1998 Delivery-Date: Thu, 04 Jun 1998 11:28:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA16018 for ; Thu, 4 Jun 1998 11:28:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA19074 for ; Thu, 4 Jun 1998 11:30:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA15366 for ; Thu, 4 Jun 1998 11:28:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 11:22:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14802 for ipp-outgoing; Thu, 4 Jun 1998 11:19:44 -0400 (EDT) Message-Id: <1.5.4.32.19980604151555.009adce4@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, 04 Jun 1998 08:15:55 -0700 To: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - What is a Firewall? Sender: owner-ipp@pwg.org I have been trying to figure out how we can get the discussion about how to distinguish IPP in firewalls a little more structured and not talk past each other. Let me try to sketch up a simple model of how I think firewalls work, and where the different proposals come in. NOTE, that there is no standard what-so-ever for firewalls, so whatever model you come up with will not fit every firewall implementation. If there was a firewall standard in the IETF, we would not have this discussion. I think a common feature of all firewalls is that they have a hierachy, which sometimes is shallow and sometimes is deep. Here is my try at describing the more important "layers". 1) Host address TCP/IP address 2) Port number Default 80 for HTTP 3) Protocol "http" for HTTP 4) Method POST etc. for HTTP 5) Content HTML etc. Filtering in the firewall can be done on any of these layers. Usually the firewall only let things through that it can identify and refuses the rest. Keith Moore suggests that we need to change both layer 2) and 3) above to give the firewall a chance to distinguish IPP from HTPP traffic. MS experts and a couple of others have suggested that the filtering takes place on layer 4), by allocating a new PRINT method for IPP and we do not need to touch layers 2) and 3). In discussions that I had with firewall experts last year, they indicated that they had no problem to filter on layer 5), e.g. distinguishing IPP from HTML etc. by identifying the content as an "application/ipp" MIME type. So what it all boils down to is how versatile the firewall implementation is. To make a concious decision about filtering in/out IPP from other HTTP traffic, any current firewall will need to be reconfigured or modified in same way. Looking at my hierachy, I suggest that if firewall do all levels, there is NO need to modify anything in the current IPP specs. If we move up (or down) to level 4), then we should go along with the MS approach, etc. My 2 cents, Carl-Uno From ipp-owner@pwg.org Thu Jun 4 11:52:54 1998 Delivery-Date: Thu, 04 Jun 1998 11:52:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA16666 for ; Thu, 4 Jun 1998 11:52:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA19270 for ; Thu, 4 Jun 1998 11:55:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17022 for ; Thu, 4 Jun 1998 11:52:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 11:47:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15905 for ipp-outgoing; Thu, 4 Jun 1998 11:42:09 -0400 (EDT) Date: Thu, 4 Jun 1998 11:42:00 -0400 (EDT) From: Scott Lawrence To: ipp@pwg.org cc: Larry Masinter Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers In-Reply-To: <1.5.4.32.19980604143545.00739078@pop3.holonet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org [I've taken this back to just the IPP list - it really has no effect either way on http that I can see] > The whole discussion as raised > in Keith's feedback has to do with firewalls. Also, we are not discussing > how easy or not it is to change the specs, but what the consequences are > for implementors. > > My understanding is that Keith is trying to dictate that IPP CANNOT USE > "http" - full stop. Considering that he has been the project advisor, I am > very disappopinted to see that kind of proposal at this stage in the > project. I'm not sure that I interpreted Keiths comment that way - I believe that the concern is (and it has been raised by others before this) that a firewall admin has to look too far into the request to determine that it is IPP. It is easy to come up with scenarios in which the admin would want IPP to be able to penetrate where a POST would not (for example, I install an IPP printer I trust _inside_ my firewall and then set the firewall to allow PRINT requests to it from outside, perhaps only from certain business partners). I think that continuing to use http: and by default port 80 is fine, but using a PRINT method gives the admins what they need; they can now allow http PRINT to penetrate (or not) based on the method and the destination server. The IPP spec would only need to specify that the PRINT method is equivalent to POST for the purposes of all http usage rules (cachability, etc - and in any event there are explicit headers available in http [Vary, Connection, Cache-Control] to control these things now anyway). This is trivial change for any server that wants to be used for IPP. The current state of proxies and firewalls on the real net is so widely variable that I think any scheme we can come up with will have problems with some anyway, and those technologies are evolving so rapidly that there is ample opportunity for IPP to create an incentive to support this kind of filtering. From ipp-owner@pwg.org Thu Jun 4 12:06:57 1998 Delivery-Date: Thu, 04 Jun 1998 12:06:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17048 for ; Thu, 4 Jun 1998 12:06:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19405 for ; Thu, 4 Jun 1998 12:09:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA17715 for ; Thu, 4 Jun 1998 12:06:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 12:01:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17093 for ipp-outgoing; Thu, 4 Jun 1998 11:54:28 -0400 (EDT) From: Harry Lewis To: Cc: , , Subject: RE: IPP> Re: Implications of introducing new scheme and port Message-ID: <5030300021589020000002L002*@MHS> Date: Thu, 4 Jun 1998 12:01:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA17048 Carl-Uno said: My understanding is that Keith is trying to dictate that IPP CANNOT USE "http" - full stop. My understand is different, and Larry Masinter expresses my interpretation very well (attached). Are Larry and I the only ones who read it this way? Keith, please clarify. Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 06/04/98 08:53:15 AM Please respond to owner-ipp@pwg.org To: hardie@nic.nasa.gov, joshco@microsoft.com, http-wg@hplb.hpl.hp.com, manros@cp10.es.xerox.com, SISAACSON@novell.com, masinter@parc.xerox.com cc: ipp@pwg.org, moore@cs.utk.edu Subject: RE: IPP> Re: Implications of introducing new scheme and port At 10:58 PM 6/3/98 PDT, Larry Masinter wrote: >> >> For example, take a URL that does not explicitly specify a port: >> >> http://my.domain.com/printer1 >> >> - If the client is in the act of printing (browser that is printing >> or a print only client) the the port to use is the new IPP default port. >> >> - Any other client will use the HTTP default port > >This suggestion is completely unworkable. The default port for >the "http" scheme is 80. It isn't "80 when you use it one way >and something else when you use it another". > >I think you can define a new scheme "ipp" and just define it quite >simply: > ipp://host/path === http://host:ippport/path (used for ipp) > >E.g., if the IPP port is "187" then > ipp://printer.xerox.com/doit > >would be interpreted _exactly_ as > > http://printer.xerox.com:187/doit > >This equivalence can be done in the client, and need not be handled >by the proxies at all. Since an ipp client has to know about the rest >of the ipp protocol anyway, requiring the ipp client to do the translation >is not a burden. > > Larry, This might be a brilliant idea - if I could only understand what it is that you suggest. It seems to me that you are suggesting to introduce "ipp", as a synonym for "http", which you map in both the server and the client? If that is correct, does that not mean that you are running "http" over the wire, and hence through the firewall? The whole discussion as raised in Keith's feedback has to do with firewalls. Also, we are not discussing how easy or not it is to change the specs, but what the consequences are for implementors. My understanding is that Keith is trying to dictate that IPP CANNOT USE "http" - full stop. Considering that he has been the project advisor, I am very disappopinted to see that kind of proposal at this stage in the project. Carl-Uno From ipp-owner@pwg.org Thu Jun 4 12:41:58 1998 Delivery-Date: Thu, 04 Jun 1998 12:41:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA18225 for ; Thu, 4 Jun 1998 12:41:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19679 for ; Thu, 4 Jun 1998 12:44:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18556 for ; Thu, 4 Jun 1998 12:41:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 12:37:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA18011 for ipp-outgoing; Thu, 4 Jun 1998 12:36:58 -0400 (EDT) From: "Larry Masinter" To: "Scott Lawrence" , Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers Date: Thu, 4 Jun 1998 09:00:54 PDT Message-ID: <001001bd8fd1$f43cbd00$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org Actually, I think using a separate PRINT method really is harmful, in that it will interfere with proxies that know how to forward POST but don't know how to forward PRINT. While many 'firewalls' put filtering and forwarding into the same function, really, we should separate them as functions and analyze the cost/benefits independently. There are a number of proxies that forward POST and GET and a few other methods into internal protocols and then forward those internal protocols out the other side of their cloud back into POST and GET. One of the advantages of layering IPP on top of HTTP is the ability to leverage those proxies. Using another method would detract from that, without much advantage, since the filtering function can use the host and port. It's a good idea to have a different port for IPP since port filtering can be accomplished by the simplest of filtering devices -- you can even filter at the router level. It's true that there are some products that combine filtering and forwarding in one application, and can filter on content as easily as filtering on port, but it weakens the protocol to REQUIRE that filtering be accomplished by looking at the data or the method. It makes IPP stronger, thus, to dictate a different default port, and if you're going to change the default port, it's reasonable to change the scheme to "ipp", if only to make ipp://localhost a simple URL to type. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Thu Jun 4 13:12:11 1998 Delivery-Date: Thu, 04 Jun 1998 13:12:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19026 for ; Thu, 4 Jun 1998 13:12:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA19847 for ; Thu, 4 Jun 1998 13:14:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19365 for ; Thu, 4 Jun 1998 13:12:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 13:07:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18815 for ipp-outgoing; Thu, 4 Jun 1998 13:04:22 -0400 (EDT) Date: 4 Jun 1998 17:02:53 -0000 Message-ID: <19980604170253.23035.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: <00c301bd8f39$9c52ecb0$1e0564d2@tulip> To: ipp@pwg.org Sender: owner-ipp@pwg.org Peter Michalek wrote: ... > > ** The following operations take job as the target of the operation > 3.3.1.1 Send-Document Request > 3.3.3.1 Cancel-Job Request > 3.3.4.1 Get-Job-Attributes Request > Target: > Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri" > operation attribute(s) which define the target for this operation > as described in section 3.1.3. > > > ** The following operations take printer as the target of the operation > 3.2.1.1 Print-Job Request > 3.2.4 Create-Job Operation > 3.2.5.1 Get-Printer-Attributes Request > 3.2.6.1 Get-Jobs Request ......................................44 > > Target: > The "printer-uri" operation attribute which is the target for > this operation as described in section 3.1.3. > > > ** The protocol document states this about how HTTP is used to address a job > target in 3.9: > (iii) > . "job-uri": When the target is a job and the transport is HTTP or > HTTPS (for TLS), the target job-uri of each operation in the IPP > model document SHALL be an operation attribute called "job-uri" and > it SHALL also be specified outside of the operation layer as the > request-URI on the Request-Line at the HTTP level. > > ** This means that for all jobs, the HTTP server serving IPP will have to > generate CGIs or similar entities for each job in the queue or otherwise > processed. Is that really true? Suppose your Printer is implemented as a CGI program called /cgi-bin/IPPPrinter. Couldn't your job-uris take the form of http://host.domain/cgi-bin/IPPPrinter/1159 http://host.domain/cgi-bin/IPPPrinter/1042 etc? That way, the web server dispatches the same script regardless of whether the Request-URI addresses a Printer or a Job. The script can get the job-id part of the URI from PATH_INFO. Another possibility would be to generate job-uris that look like http://host.domain/cgi-bin/IPPPrinter?job-id=1159 http://host.domain/cgi-bin/IPPPrinter?job-id=1042 or even http://host.domain/cgi-bin/IPPPrinter#1159 http://host.domain/cgi-bin/IPPPrinter#1042 The HTTP server serving IPP has to generate unique URIs for each job in the queue or otherwise processed, but not necessarily new CGIs. > > I think this is not practical and it provides justification for having > the target attribute for job-uri in the IPP layer as well. > For consistency, it would be good to do the same for printer-uri and > modify (iii) above to reflect that. > > Also, in the line from the spec above: > Target: > Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri" > > (1) can't be translated into a HTTP request line which specifies only > one target, as (2) provides. I agree that in some implementations, "job-id" will need to be specified as an IPP operation attribute. > > Perhaps target of the operations should be only printers and job-id would > be considered an argument of the method invoked, or an operation > attribute (e.g. cancel job). Works for me. You could also use relative job-uris with this approach. > > This would provide practical multiplexing within the module that > processes IPP requests, be > it CGI, servlet, NSAPI or ISAPI extension, where one printer would > typically be served by > one module for each security scheme. > > Peter > > > > Carl From ipp-owner@pwg.org Thu Jun 4 14:07:04 1998 Delivery-Date: Thu, 04 Jun 1998 14:07:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20139 for ; Thu, 4 Jun 1998 14:07:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA20098 for ; Thu, 4 Jun 1998 14:09:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20673 for ; Thu, 4 Jun 1998 14:07:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 14:02:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20108 for ipp-outgoing; Thu, 4 Jun 1998 13:58:39 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: IPP> Identifying jobs in requests Date: Thu, 4 Jun 1998 10:58:28 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org It seem to me that the fundamental question comes down to - should the IPP protocol form, transmit and use information that is specific to the underlying transport. We have chosen to use URI as our way of identifying endpoints. The assumptions we make about these URIs (there actual syntax is irrelevant) are:- a) an agent knows how to form them b) the only thing an agent may do with a URI it receives to it is to pass it to its underlying transport. This means that the creator of the URI MUST use the same URI forming convention as that which will be used by the receivers transport stack (ie. this is not a private issue for a given implementation). It also means that the receiver may not look at the URI to infer any deeper meaning (because that is a private issue for the sending implementation). This last restriction made us invent job-id. We moved to explicitly stating in IPP the way of identifying an endpoint. The real problem is that we end up with leakage from the transport up into the IPP layer. I cannot blindly forward requests from IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change them on the fly. There is another problem that assumpion b causes. It assumes that a printer knows how to form an address (URI) that makes sense in the clients transport stack. This is true for HTTP but not true (or certainly non-trivial) for other transports. I would propose that we use an adressing scheme that corresponds to the transport endpoint only. We then specifiy in IPP the ways of identifying the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Thu Jun 4 14:37:12 1998 Delivery-Date: Thu, 04 Jun 1998 14:37:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20699 for ; Thu, 4 Jun 1998 14:37:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA20235 for ; Thu, 4 Jun 1998 14:39:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21429 for ; Thu, 4 Jun 1998 14:37:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 14:32:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20874 for ipp-outgoing; Thu, 4 Jun 1998 14:28:13 -0400 (EDT) Message-ID: <3576E732.95650826@underscore.com> Date: Thu, 04 Jun 1998 14:28:02 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Why must IPP be transport-independent? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org After reading Paul Moore's posting (below), it appears that we are digger ourselves a deeper and deeper hole to fall into. Must IPP be transport-independent? I say "No". IPP stands for "Internet Printing Protocol", not something like "Generic Printing Protocol", or "Universal Printing Protocol". It was designed for use on the Internet. Sure, there are some in the IPP WG who believe IPP can and *should* become the single, all-encompassing printing protocol for use in almost any environment. I (and others) say "hogwash". Microsoft and Northlake Software have done a good job in delineating areas in which the IPP design falls very short in providing the kind of session- oriented protocol to achieve the kinds of capabilities that already exist in TIP/SI, CPAP and others. If HTTP is going to be the first and primary reference implementation of IPP (damn the nay-sayers...), then why can't we just tie IPP onto HTTP (semantics, syntax et al) and be done with it? Let the SDP project deal with other non-HTTP-oriented requirements. We'll just strive to make the mapping from IPP to SDP as easy and painless 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 -- ---------------------------------------------------------------------- Paul Moore wrote: > > It seem to me that the fundamental question comes down to - should > the IPP protocol form, transmit and use information that is specific to the > underlying transport. > > We have chosen to use URI as our way of identifying endpoints. The > assumptions we make about these URIs (there actual syntax is irrelevant) > are:- > a) an agent knows how to form them > b) the only thing an agent may do with a URI it receives to it is to > pass it to its underlying transport. This means that the creator of the URI > MUST use the same URI forming convention as that which will be used by the > receivers transport stack (ie. this is not a private issue for a given > implementation). It also means that the receiver may not look at the URI to > infer any deeper meaning (because that is a private issue for the sending > implementation). > This last restriction made us invent job-id. We moved to explicitly > stating in IPP the way of identifying an endpoint. > The real problem is that we end up with leakage from the transport > up into the IPP layer. I cannot blindly forward requests from > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change > them on the fly. > There is another problem that assumpion b causes. It assumes that a > printer knows how to form an address (URI) that makes sense in the clients > transport stack. This is true for HTTP but not true (or certainly > non-trivial) for other transports. > > I would propose that we use an adressing scheme that corresponds to > the transport endpoint only. We then specifiy in IPP the ways of identifying > the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Thu Jun 4 14:52:16 1998 Delivery-Date: Thu, 04 Jun 1998 14:52:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20963 for ; Thu, 4 Jun 1998 14:52:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA20297 for ; Thu, 4 Jun 1998 14:54:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22146 for ; Thu, 4 Jun 1998 14:52:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 14:48:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21562 for ipp-outgoing; Thu, 4 Jun 1998 14:43:04 -0400 (EDT) Message-ID: From: Paul Moore To: "'Jay Martin'" , ipp@pwg.org Subject: RE: IPP> Why must IPP be transport-independent? Date: Thu, 4 Jun 1998 11:42:52 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org One point - this is othogonal to much of the 'URI in the protocol' question. As job-id vs job-uri shows there are still areas where this is a problem even if we decide to only do IPP on HTTP. > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Thursday, June 04, 1998 11:28 AM > To: ipp@pwg.org > Subject: IPP> Why must IPP be transport-independent? > > After reading Paul Moore's posting (below), it appears > that we are digger ourselves a deeper and deeper hole > to fall into. > > Must IPP be transport-independent? > > I say "No". IPP stands for "Internet Printing Protocol", > not something like "Generic Printing Protocol", or "Universal > Printing Protocol". It was designed for use on the Internet. > > Sure, there are some in the IPP WG who believe IPP can > and *should* become the single, all-encompassing printing > protocol for use in almost any environment. > > I (and others) say "hogwash". Microsoft and Northlake Software > have done a good job in delineating areas in which the IPP > design falls very short in providing the kind of session- > oriented protocol to achieve the kinds of capabilities that > already exist in TIP/SI, CPAP and others. > > If HTTP is going to be the first and primary reference > implementation of IPP (damn the nay-sayers...), then why > can't we just tie IPP onto HTTP (semantics, syntax et al) > and be done with it? > > Let the SDP project deal with other non-HTTP-oriented > requirements. We'll just strive to make the mapping > from IPP to SDP as easy and painless 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 -- > ---------------------------------------------------------------------- > > > Paul Moore wrote: > > > > It seem to me that the fundamental question comes down to - > should > > the IPP protocol form, transmit and use information that is specific to > the > > underlying transport. > > > > We have chosen to use URI as our way of identifying endpoints. > The > > assumptions we make about these URIs (there actual syntax is irrelevant) > > are:- > > a) an agent knows how to form them > > b) the only thing an agent may do with a URI it receives to it > is to > > pass it to its underlying transport. This means that the creator of the > URI > > MUST use the same URI forming convention as that which will be used by > the > > receivers transport stack (ie. this is not a private issue for a given > > implementation). It also means that the receiver may not look at the URI > to > > infer any deeper meaning (because that is a private issue for the > sending > > implementation). > > This last restriction made us invent job-id. We moved to > explicitly > > stating in IPP the way of identifying an endpoint. > > The real problem is that we end up with leakage from the > transport > > up into the IPP layer. I cannot blindly forward requests from > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and > change > > them on the fly. > > There is another problem that assumpion b causes. It assumes > that a > > printer knows how to form an address (URI) that makes sense in the > clients > > transport stack. This is true for HTTP but not true (or certainly > > non-trivial) for other transports. > > > > I would propose that we use an adressing scheme that corresponds > to > > the transport endpoint only. We then specifiy in IPP the ways of > identifying > > the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Thu Jun 4 15:01:43 1998 Delivery-Date: Thu, 04 Jun 1998 15:01:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21077 for ; Thu, 4 Jun 1998 15:01:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20335 for ; Thu, 4 Jun 1998 15:03:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA22814 for ; Thu, 4 Jun 1998 15:01:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 14:56:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21785 for ipp-outgoing; Thu, 4 Jun 1998 14:49:21 -0400 (EDT) Message-Id: <3.0.5.32.19980604113705.0125d9f0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 11:37:05 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Now we know what is holding up TLS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, Daniel Manchala has been following the thread of blames to its source. FYI, here is a reply to Daniel from the editor of the PKIX document. It looks like things will be moving in the next few weeks, and I sincerely hope that the IESG will process the PKIX spec more quickly than the IPP ones, when they get the text from the security guys. Carl-Uno ---- >Daniel, > >You are absolutely correct - the PKIX profile is holding up the progression >of TLS, which is holding up the progression of IPP. We are acutely aware of >this, and hope to break the logjam shortly. The area director, Jeff >Schiller, is actively working some difficult intellectual property issues. >When they are resolved, the "final" PKIX draft will go to the list. We >expect to forward it to the IESG very quickly after that. > >The group had a choice - strip some encumbered technology from the >specification and go to Last Call, or resolve the patent issues and go to >Last Call. Jeff was directly involved in the decision to pursue the patent >issues and delay Last Call. If the patent issues are not resolved >satisfactorily in the next week, I believe we will go to "Plan B" - strip >encumbered technology and go to Last Call. > >I currently have two versions - with and without the encumbered technology >- of the profile ready to go. When I get the word, we'll hit the ground >running. > >Thanks, > >Tim Polk --- Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 15:17:08 1998 Delivery-Date: Thu, 04 Jun 1998 15:17:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21302 for ; Thu, 4 Jun 1998 15:17:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20415 for ; Thu, 4 Jun 1998 15:19:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23581 for ; Thu, 4 Jun 1998 15:17:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 15:13:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22969 for ipp-outgoing; Thu, 4 Jun 1998 15:07:45 -0400 (EDT) Message-Id: <3.0.5.32.19980604120545.0126e100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 12:05:45 PDT To: Jay Martin , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: <35757C5A.D0AAF51C@underscore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 09:39 AM 6/3/98 PDT, Jay Martin wrote: >For fear of sounding like a broken record, let me once again >point out that during the initial IPP BOF (San Jose, Dec '96), >Keith Moore stated (in response to stealthing thru firewalls) >that if the IPP WG came up with a generally useful and improved >printing protocol, then the firewall folks would probably not >have any problem in making whatever (reasonable) accomodations >for IPP in their products. > >Yet, some highly vocal IPP participants insisted on ignoring >that advice and continued to press for generic stealth capabilities. > >This is truly unfortunate. > > ...jay > Jay, in this case you do sound like a broken record. Independently of what people thought when we started this discussion a long time ago, I do not think that anybody still firmly believes that a strong feature of our current design is to stealth through firewalls. Too many people, myself included, have already warned for such erreneous thinking. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 15:27:28 1998 Delivery-Date: Thu, 04 Jun 1998 15:27:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21400 for ; Thu, 4 Jun 1998 15:27:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20461 for ; Thu, 4 Jun 1998 15:29:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24285 for ; Thu, 4 Jun 1998 15:27:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 15:23:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23680 for ipp-outgoing; Thu, 4 Jun 1998 15:20:04 -0400 (EDT) Message-Id: <3.0.5.32.19980604121810.00ca7bc0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 12:18:10 PDT To: Ned Freed , Keith Moore From: Carl-Uno Manros Subject: Re: IPP> review of IPP documents Cc: Paul Moore , "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <01IXM6R8X7328WWC78@INNOSOFT.COM> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: <"Your message dated Fri, 29 May 1998 20:52:20 -0400"<199805300052.UAA12530@spot.cs.utk.edu> ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 06:49 PM 5/29/98 PDT, Ned Freed wrote: >> You miss the point. The fact that people already have port 80 proxies >> installed doesn't matter. There's no way that we're going to standardize >> IPP on port 80 - HTTP already has that port, and IPP is a different >> service than HTTP. > >> Once upon a time, a lot of people had email only access to the Internet. >> That wasn't an good reason for forcing every service to run over email. > >My favorite example is email over FTP. We'd still be doing email that way >if we hadn't deployed a new email service on a separate port. > > Ned > Ned, If this is your favorite example, why have I not heard you arguing that IFAX cannot be done over SMTP? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 15:37:40 1998 Delivery-Date: Thu, 04 Jun 1998 15:37:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21553 for ; Thu, 4 Jun 1998 15:37:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20492 for ; Thu, 4 Jun 1998 15:40:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24956 for ; Thu, 4 Jun 1998 15:37:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 15:33:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24348 for ipp-outgoing; Thu, 4 Jun 1998 15:28:06 -0400 (EDT) Date: 4 Jun 1998 19:26:44 -0000 Message-ID: <19980604192644.2326.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > It seem to me that the fundamental question comes down to - should > the IPP protocol form, transmit and use information that is specific to the > underlying transport. > > We have chosen to use URI as our way of identifying endpoints. Could you define "endpoint" in this context? Is it equivalent to an IPP "target"? Or are you using the term in the TCP sense? >The > assumptions we make about these URIs (there actual syntax is irrelevant) > are:- > a) an agent knows how to form them > b) the only thing an agent may do with a URI it receives to it is to > pass it to its underlying transport. This means that the creator of the URI > MUST use the same URI forming convention as that which will be used by the > receivers transport stack (ie. this is not a private issue for a given > implementation). It also means that the receiver may not look at the URI to > infer any deeper meaning (because that is a private issue for the sending > implementation). > This last restriction made us invent job-id. We moved to explicitly > stating in IPP the way of identifying an endpoint. > The real problem is that we end up with leakage from the transport > up into the IPP layer. I cannot blindly forward requests from > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change > them on the fly. > There is another problem that assumpion b causes. It assumes that a > printer knows how to form an address (URI) that makes sense in the clients > transport stack. This is true for HTTP but not true (or certainly > non-trivial) for other transports. > > I would propose that we use an adressing scheme that corresponds to > the transport endpoint only. We then specifiy in IPP the ways of identifying > the logical object that we wish to talk to (printer-ID, Job-ID,...). > Or you could invert this, and put the target addressing outside the IPP payload. Then you can forward requests and/or rewrite target addresses without ever opening the "envelop", to use Scott's postal analogy. For this to work, any internal target identifiers would have to be relative (like job-id). It seems to me that your scheme would require the transport endpoint to be some kind of IPP Server that could route requests to Printers based on embedded printer-ID. Then you've added another layer of indirection to the IPP model. From ipp-owner@pwg.org Thu Jun 4 15:50:48 1998 Delivery-Date: Thu, 04 Jun 1998 15:50:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21766 for ; Thu, 4 Jun 1998 15:50:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20555 for ; Thu, 4 Jun 1998 15:53:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA25638 for ; Thu, 4 Jun 1998 15:50:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 15:46:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25047 for ipp-outgoing; Thu, 4 Jun 1998 15:41:23 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> Why must IPP be transport-independent? Message-ID: <5030300021597572000002L022*@MHS> Date: Thu, 4 Jun 1998 15:48:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21766 Unfortunate, I guess, that the charter ever made reference to a Universal Standard for Printing... http://www.ietf.org/html.charters/ipp-charter.html Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 06/04/98 12:34:54 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> Why must IPP be transport-independent? After reading Paul Moore's posting (below), it appears that we are digger ourselves a deeper and deeper hole to fall into. Must IPP be transport-independent? I say "No". IPP stands for "Internet Printing Protocol", not something like "Generic Printing Protocol", or "Universal Printing Protocol". It was designed for use on the Internet. Sure, there are some in the IPP WG who believe IPP can and *should* become the single, all-encompassing printing protocol for use in almost any environment. I (and others) say "hogwash". Microsoft and Northlake Software have done a good job in delineating areas in which the IPP design falls very short in providing the kind of session- oriented protocol to achieve the kinds of capabilities that already exist in TIP/SI, CPAP and others. If HTTP is going to be the first and primary reference implementation of IPP (damn the nay-sayers...), then why can't we just tie IPP onto HTTP (semantics, syntax et al) and be done with it? Let the SDP project deal with other non-HTTP-oriented requirements. We'll just strive to make the mapping from IPP to SDP as easy and painless 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 -- ---------------------------------------------------------------------- Paul Moore wrote: > > It seem to me that the fundamental question comes down to - should > the IPP protocol form, transmit and use information that is specific to the > underlying transport. > > We have chosen to use URI as our way of identifying endpoints. The > assumptions we make about these URIs (there actual syntax is irrelevant) > are:- > a) an agent knows how to form them > b) the only thing an agent may do with a URI it receives to it is to > pass it to its underlying transport. This means that the creator of the URI > MUST use the same URI forming convention as that which will be used by the > receivers transport stack (ie. this is not a private issue for a given > implementation). It also means that the receiver may not look at the URI to > infer any deeper meaning (because that is a private issue for the sending > implementation). > This last restriction made us invent job-id. We moved to explicitly > stating in IPP the way of identifying an endpoint. > The real problem is that we end up with leakage from the transport > up into the IPP layer. I cannot blindly forward requests from > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change > them on the fly. > There is another problem that assumpion b causes. It assumes that a > printer knows how to form an address (URI) that makes sense in the clients > transport stack. This is true for HTTP but not true (or certainly > non-trivial) for other transports. > > I would propose that we use an adressing scheme that corresponds to > the transport endpoint only. We then specifiy in IPP the ways of identifying > the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Thu Jun 4 16:02:41 1998 Delivery-Date: Thu, 04 Jun 1998 16:02:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA21904 for ; Thu, 4 Jun 1998 16:02:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20613 for ; Thu, 4 Jun 1998 16:05:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26363 for ; Thu, 4 Jun 1998 16:02:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 15:58:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25747 for ipp-outgoing; Thu, 4 Jun 1998 15:54:37 -0400 (EDT) Message-Id: <3.0.5.32.19980604125242.009bcc60@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 12:52:42 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - A couple of POSITIVE things about an "ipp" scheme Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Since our phone discussion yesterday in which most of the people attending took a negative attitude to the proposal for the "ipp" scheme, I have been thinking a little about any positive things I could come up with in support of a new scheme. Mind you, this is more to make sure that we have all the facts on the table, rather than an expression of my personal view on what the correct solution is. 1) It seems that even the dumbest of firewalls could distinguish IPP from other HTP traffic, after reconfiguration. See my earlier message on firewalls. 2) The actual URIs for printers might become shorter. See Larry Masinter's propoposal (although I still haven't figured it out). 3) If you want to print your IPP printer address next to the fax address on your business card, it would be crystal clear that it is an IPP address, not your personal web page adress. 4) Software peddlers can more easily label their products as an "IPP Server", rather than as an "HTTP Server with an IPP Printer". 5) It might be a sounder overall architecture for the IETF, but I am still unconvinced about which transports are "transports", and which are "not transports" in the overall "IETF architecture" - if there is one? Can anybody else come up with anything else in favor of scheme "ipp"? If you want the positive arguments for using POST vs. PRINT, please check back on Josh Cohen's I-D at: http://search.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 16:09:19 1998 Delivery-Date: Thu, 04 Jun 1998 16:09:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA21956 for ; Thu, 4 Jun 1998 16:09:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20627 for ; Thu, 4 Jun 1998 16:11:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA27019 for ; Thu, 4 Jun 1998 16:09:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 16:03:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25730 for ipp-outgoing; Thu, 4 Jun 1998 15:53:23 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Thu, 4 Jun 1998 12:52:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org I think for purposes of allowing rewriting of certain URL components by intermediaries, that the URL specified in the IPP message will probably have to be relative. Relative to "what" is the issue. What URL components are typically rewritten by proxies (or other intermediaries)? Randy -----Original Message----- From: Carl Kugler [SMTP:kugler@us.ibm.com] Sent: Thursday, June 04, 1998 12:27 PM To: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests > It seem to me that the fundamental question comes down to - should > the IPP protocol form, transmit and use information that is specific to the > underlying transport. > > We have chosen to use URI as our way of identifying endpoints. Could you define "endpoint" in this context? Is it equivalent to an IPP "target"? Or are you using the term in the TCP sense? >The > assumptions we make about these URIs (there actual syntax is irrelevant) > are:- > a) an agent knows how to form them > b) the only thing an agent may do with a URI it receives to it is to > pass it to its underlying transport. This means that the creator of the URI > MUST use the same URI forming convention as that which will be used by the > receivers transport stack (ie. this is not a private issue for a given > implementation). It also means that the receiver may not look at the URI to > infer any deeper meaning (because that is a private issue for the sending > implementation). > This last restriction made us invent job-id. We moved to explicitly > stating in IPP the way of identifying an endpoint. > The real problem is that we end up with leakage from the transport > up into the IPP layer. I cannot blindly forward requests from > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change > them on the fly. > There is another problem that assumpion b causes. It assumes that a > printer knows how to form an address (URI) that makes sense in the clients > transport stack. This is true for HTTP but not true (or certainly > non-trivial) for other transports. > > I would propose that we use an adressing scheme that corresponds to > the transport endpoint only. We then specifiy in IPP the ways of identifying > the logical object that we wish to talk to (printer-ID, Job-ID,...). > Or you could invert this, and put the target addressing outside the IPP payload. Then you can forward requests and/or rewrite target addresses without ever opening the "envelop", to use Scott's postal analogy. For this to work, any internal target identifiers would have to be relative (like job-id). It seems to me that your scheme would require the transport endpoint to be some kind of IPP Server that could route requests to Printers based on embedded printer-ID. Then you've added another layer of indirection to the IPP model. From ipp-owner@pwg.org Thu Jun 4 16:14:44 1998 Delivery-Date: Thu, 04 Jun 1998 16:14:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22045 for ; Thu, 4 Jun 1998 16:14:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20667 for ; Thu, 4 Jun 1998 16:17:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA27640 for ; Thu, 4 Jun 1998 16:14:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 16:09:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA26427 for ipp-outgoing; Thu, 4 Jun 1998 16:03:58 -0400 (EDT) Message-Id: <199806041959.MAA08056@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 04 Jun 1998 13:04:24 -0700 To: "Larry Masinter" From: Robert Herriot Subject: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers Cc: , In-Reply-To: <001e01bd8f7d$ca8a7f00$15d0000d@copper-208.parc.xerox.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_5345696==_.ALT" Sender: owner-ipp@pwg.org --=====================_5345696==_.ALT Content-Type: text/plain; charset="us-ascii" Larry, I am still confused about your suggestion, even after much discussion on the DL. When you talk about using an ipp scheme, do you still expect the protocol to be HTTP with a request line containing something like "POST /servlet/ippservlet/foo HTTP/1.1"? If I am correct, then the ipp scheme is not seen by the server (as in my example above where it has been stripped). Does the client strip the ipp or does the proxy do it? It would help if you would state the step by step process for a client to send an operation using an ipp scheme to an HTTP server. Bob Herriot At 10:58 PM 6/3/98 , Larry Masinter wrote: >> >> For example, take a URL that does not explicitly specify a port: >> >> http://my.domain.com/printer1 >> >> - If the client is in the act of printing (browser that is printing >> or a print only client) the the port to use is the new IPP default port. >> >> - Any other client will use the HTTP default port > >This suggestion is completely unworkable. The default port for >the "http" scheme is 80. It isn't "80 when you use it one way >and something else when you use it another". > >I think you can define a new scheme "ipp" and just define it quite >simply: > ipp://host/path === http://host:ippport/path (used for ipp) > >E.g., if the IPP port is "187" then > ipp://printer.xerox.com/doit > >would be interpreted _exactly_ as > > http://printer.xerox.com:187/doit > >This equivalence can be done in the client, and need not be handled >by the proxies at all. Since an ipp client has to know about the rest >of the ipp protocol anyway, requiring the ipp client to do the translation >is not a burden. > --=====================_5345696==_.ALT Content-Type: text/html; charset="us-ascii" Larry,

I am still confused about your suggestion, even after much discussion on the
DL.

When you talk about using an ipp scheme, do you still expect the protocol to
be HTTP with a request line containing something like "POST 
/servlet/ippservlet/foo  HTTP/1.1"?

If I am correct, then the ipp scheme is not seen by the server (as in my
example above where it has been stripped).  Does the client strip the ipp or
does the proxy do it?

It would help if you would state the step by step process for a client to
send an operation using an ipp scheme to an HTTP server.

Bob Herriot

At 10:58 PM 6/3/98 , Larry Masinter wrote:
>>
>> For example, take a URL that does not explicitly specify a port:
>>
>>        http://my.domain.com/printer1
>>
>> - If the client is in the act of printing (browser that is printing
>> or a print only client) the the port to use is the new IPP default port.
>>
>> - Any other client will use the HTTP default port
>
>This suggestion is completely unworkable. The default port for
>the "http" scheme is 80. It isn't "80 when you use it one way
>and something else when you use it another".
>
>I think you can define a new scheme "ipp" and just define it quite
>simply:
>       ipp://host/path  ===  http://host:ippport/path (used for ipp)
>
>E.g., if the IPP port is "187" then
>        ipp://printer.xerox.com/doit
>
>would be interpreted _exactly_ as
>
>        http://printer.xerox.com:187/doit
>
>This equivalence can be done in the client, and need not be handled
>by the proxies at all. Since an ipp client has to know about the rest
>of the ipp protocol anyway, requiring the ipp client to do the translation
>is not a burden.
>
--=====================_5345696==_.ALT-- From ipp-owner@pwg.org Thu Jun 4 16:28:13 1998 Delivery-Date: Thu, 04 Jun 1998 16:28:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22227 for ; Thu, 4 Jun 1998 16:28:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20737 for ; Thu, 4 Jun 1998 16:30:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA28340 for ; Thu, 4 Jun 1998 16:28:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 16:23:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27703 for ipp-outgoing; Thu, 4 Jun 1998 16:15:43 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: IPP> Identifying jobs in requests Date: Thu, 4 Jun 1998 13:15:30 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I used the term endpoint loosley (and I think inconsistently). I think we agree in your last but one para (we just prhased it differently). If we took printer-URI and job-URI out of IPP we would arrive at the situation we both want. JOB-ID then identifies jobs. With regards to your last point I think you hit a deeper problem: - the IPP model is over-simple today. We do need a higher level construct in the receiving agent (printer, server, peripheral, what ever you call it). Having 'printer' as the highest level is too restrictive. Even LPR allows for a given transport endpoint to serve multiple named devices. You could say that each printer has a different URL (or TCP port numher maybe). I thing we need to be able to do things like enumerate printers (which you canot do with some high level agent) > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Thursday, June 04, 1998 12:27 PM > To: ipp@pwg.org > Subject: Re: IPP> Identifying jobs in requests > > > It seem to me that the fundamental question comes down to - should > > the IPP protocol form, transmit and use information that is specific to > the > > underlying transport. > > > > We have chosen to use URI as our way of identifying endpoints. > > Could you define "endpoint" in this context? Is it equivalent to an IPP > "target"? Or are you using the term in the TCP sense? > > >The > > assumptions we make about these URIs (there actual syntax is irrelevant) > > are:- > > a) an agent knows how to form them > > b) the only thing an agent may do with a URI it receives to it is to > > pass it to its underlying transport. This means that the creator of the > URI > > MUST use the same URI forming convention as that which will be used by > the > > receivers transport stack (ie. this is not a private issue for a given > > implementation). It also means that the receiver may not look at the URI > to > > infer any deeper meaning (because that is a private issue for the > sending > > implementation). > > This last restriction made us invent job-id. We moved to explicitly > > stating in IPP the way of identifying an endpoint. > > The real problem is that we end up with leakage from the transport > > up into the IPP layer. I cannot blindly forward requests from > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and > change > > them on the fly. > > There is another problem that assumpion b causes. It assumes that a > > printer knows how to form an address (URI) that makes sense in the > clients > > transport stack. This is true for HTTP but not true (or certainly > > non-trivial) for other transports. > > > > I would propose that we use an adressing scheme that corresponds to > > the transport endpoint only. We then specifiy in IPP the ways of > identifying > > the logical object that we wish to talk to (printer-ID, Job-ID,...). > > > > Or you could invert this, and put the target addressing outside the IPP > payload. Then you can forward requests and/or rewrite target addresses > without ever opening the "envelop", to use Scott's postal analogy. For > this to work, any internal target identifiers would have to be relative > (like job-id). > > It seems to me that your scheme would require the transport endpoint to be > some kind of IPP Server that could route requests to Printers based on > embedded printer-ID. Then you've added another layer of indirection to > the IPP model. From ipp-owner@pwg.org Thu Jun 4 16:58:00 1998 Delivery-Date: Thu, 04 Jun 1998 16:58:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22579 for ; Thu, 4 Jun 1998 16:58:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA20911 for ; Thu, 4 Jun 1998 17:00:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA29133 for ; Thu, 4 Jun 1998 16:57:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 16:53:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28528 for ipp-outgoing; Thu, 4 Jun 1998 16:49:09 -0400 (EDT) Message-Id: <3.0.5.32.19980604131944.01294100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 13:19:44 PDT To: Harry Lewis , From: Carl-Uno Manros Subject: Re: IPP> Why must IPP be transport-independent? In-Reply-To: <5030300021597572000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 12:48 PM 6/4/98 PDT, Harry Lewis wrote: >Subject: IPP> Why must IPP be transport-independent? > > >After reading Paul Moore's posting (below), it appears >that we are digger ourselves a deeper and deeper hole >to fall into. > >Must IPP be transport-independent? > >I say "No". IPP stands for "Internet Printing Protocol", >not something like "Generic Printing Protocol", or "Universal >Printing Protocol". It was designed for use on the Internet. Harry, I think I start agreeing with you on this one. My recollection is that we got this as part of our discussion to use a MIME part for the encoding. MIME purists have stated that all MIME types MUST be transport independent. I think that having an object that can be mapped to another transport has its virtues, but I was never convinced that it would ever make sense to actually send the "application/ipp" object over email. Alternative transports that make sense to me are things like the emerging HTTP-NG protocol, and that is most likely able to handle URLs the same way as HTTP does today. If somebody REALLY wants to send "application/ipp" over email, then they would need to have an email address in the place where we are using the HTTP URIs anyway, and I expect that such a mailbox would be dedicated to the IPP printer and know what to do with messages it receives. In short, new transport, new addressing scheme. In summary, I think we should remove any redundant URI information in the "application/ipp", it seems to cause more confusion than what it is worth. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 17:46:02 1998 Delivery-Date: Thu, 04 Jun 1998 17:46:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22961 for ; Thu, 4 Jun 1998 17:46:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21108 for ; Thu, 4 Jun 1998 17:48:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00157 for ; Thu, 4 Jun 1998 17:45:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 17:33:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29439 for ipp-outgoing; Thu, 4 Jun 1998 17:28:57 -0400 (EDT) Date: 4 Jun 1998 21:25:54 -0000 Message-ID: <19980604212554.12477.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > > I think for purposes of allowing rewriting of certain URL components by > intermediaries, that the URL specified in the IPP message will probably > have to be relative. Relative to "what" is the issue. > > What URL components are typically rewritten by proxies (or other > intermediaries)? > Commonly, scheme, host, and port. If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. In requests that they forward, transparent proxies MUST NOT rewrite the “abs_path” part of a Request-URI in any way except to replace a null abs_path with “*”, no matter what the proxy does in its internal implementation. This “no rewrite” rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved URL character for a reserved purpose. Implementers should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI. By itself, the “abs_path” is a Relative URI. > Randy Carl From ipp-owner@pwg.org Thu Jun 4 19:03:51 1998 Delivery-Date: Thu, 04 Jun 1998 19:03:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23434 for ; Thu, 4 Jun 1998 19:03:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21388 for ; Thu, 4 Jun 1998 19:06:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01374 for ; Thu, 4 Jun 1998 19:03:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 18:58:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00746 for ipp-outgoing; Thu, 4 Jun 1998 18:54:10 -0400 (EDT) Date: Thu, 04 Jun 1998 15:07:01 -0700 (PDT) From: Ned Freed Subject: Re: IPP> review of IPP documents In-reply-to: "Your message dated Thu, 04 Jun 1998 12:18:10 -0700 (PDT)" <3.0.5.32.19980604121810.00ca7bc0@garfield> To: Carl-Uno Manros Cc: Ned Freed , Keith Moore , Paul Moore , "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Message-id: <01IXUEBJALAO8WWJU5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01IXM6R8X7328WWC78@INNOSOFT.COM> Sender: owner-ipp@pwg.org > > > Once upon a time, a lot of people had email only access to the Internet. > > > That wasn't an good reason for forcing every service to run over email. > > My favorite example is email over FTP. We'd still be doing email that way > > if we hadn't deployed a new email service on a separate port. > If this is your favorite example, why have I not heard you arguing that > IFAX cannot be done over SMTP? Well, first of all, because one doesn't follow from the other. I never said it is impossible to do email over FTP -- the fact of the matter is that it was possible to do it, and had we continued in that vein I see no overwhelming obstacle to doing it this way today. Similarly, it is possible to do IPP over HTTP. Or SMTP. Or FTP. Or even TELNET. And IFAX can be done over SMTP. Or HTTP. Or FTP. Or even TELNET. So I certainly would not argue that any of these are impossible, since that simply is not the case. Now, I suspect you intended to say was: If this is your favorite example, why have I not heard you arguing that IFAX should not be done over SMTP? And the answer to this is simply that if you have not heard me arguing this you must not have been listening. I have pointed out, not once but many times, that if the service characteristics needed by a new IFAX service are intrinsicly different from those of an email service then the only available option is to build IFAX as a separate and cleanly dilineated service. There is no way to achieve interoperability otherwise, and interoperability is something the IETF requires. However, I have also pointed out that the cost of building a new store and forward service is high, far higher than the cost of simpler point-to-point services, and that this cost has to be weighed against benefits of that new service. I am largely neutral on which way the IFAX work goes on this point. My major concern has been that if IFAX is to be defined as a profile of email and not as a new service, that it approach this layering realistically and carefully, so as not to break existing services or damage the service models already in place. Ned From ipp-owner@pwg.org Thu Jun 4 19:13:03 1998 Delivery-Date: Thu, 04 Jun 1998 19:13:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23467 for ; Thu, 4 Jun 1998 19:13:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA21416 for ; Thu, 4 Jun 1998 19:15:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA02238 for ; Thu, 4 Jun 1998 19:13:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 19:08:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01502 for ipp-outgoing; Thu, 4 Jun 1998 19:07:08 -0400 (EDT) Message-Id: <3.0.5.32.19980604160512.00c32390@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 16:05:12 PDT To: Ned Freed From: Carl-Uno Manros Subject: Re: IPP> review of IPP documents Cc: ipp@pwg.org In-Reply-To: <01IXUEBJALAO8WWJU5@INNOSOFT.COM> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: <"Your message dated Thu, 04 Jun 1998 12:18:10 -0700 (PDT)"<3.0.5.32.19980604121810.00ca7bc0@garfield><01IXM6R8X7328WWC78@INNOSOFT.COM> ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Ned, What I really meant with my comment, is that the IETF is not very consistent and clear in what a tranport layers vs. an application layer is, and keeps on mixing the two in a pragmatic, but architectually unsound and ad hoc way. Is the Internet Architecture Board ever paying any attention to these kind of discussions? Carl-Uno At 03:07 PM 6/4/98 PDT, Ned Freed wrote: >> > > Once upon a time, a lot of people had email only access to the Internet. >> > > That wasn't an good reason for forcing every service to run over email. > >> > My favorite example is email over FTP. We'd still be doing email that way >> > if we hadn't deployed a new email service on a separate port. > >> If this is your favorite example, why have I not heard you arguing that >> IFAX cannot be done over SMTP? > >Well, first of all, because one doesn't follow from the other. I never said it >is impossible to do email over FTP -- the fact of the matter is that it was >possible to do it, and had we continued in that vein I see no overwhelming >obstacle to doing it this way today. > >Similarly, it is possible to do IPP over HTTP. Or SMTP. Or FTP. Or even TELNET. >And IFAX can be done over SMTP. Or HTTP. Or FTP. Or even TELNET. So I certainly >would not argue that any of these are impossible, since that simply is not the >case. > >Now, I suspect you intended to say was: > > If this is your favorite example, why have I not heard you arguing that > IFAX should not be done over SMTP? > >And the answer to this is simply that if you have not heard me arguing this you >must not have been listening. I have pointed out, not once but many times, that >if the service characteristics needed by a new IFAX service are intrinsicly >different from those of an email service then the only available option is to >build IFAX as a separate and cleanly dilineated service. There is no way to >achieve interoperability otherwise, and interoperability is something the IETF >requires. > >However, I have also pointed out that the cost of building a new store and >forward service is high, far higher than the cost of simpler point-to-point >services, and that this cost has to be weighed against benefits of that new >service. > >I am largely neutral on which way the IFAX work goes on this point. My major >concern has been that if IFAX is to be defined as a profile of email and not as >a new service, that it approach this layering realistically and carefully, so >as not to break existing services or damage the service models already in >place. > > Ned > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 20:13:44 1998 Delivery-Date: Thu, 04 Jun 1998 20:13:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA23839 for ; Thu, 4 Jun 1998 20:13:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA21529 for ; Thu, 4 Jun 1998 20:16:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA03363 for ; Thu, 4 Jun 1998 20:13:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 20:08:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA02756 for ipp-outgoing; Thu, 4 Jun 1998 20:06:41 -0400 (EDT) Message-ID: <357735B6.3DE4A001@underscore.com> Date: Thu, 04 Jun 1998 20:03:02 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: Harry Lewis , ipp@pwg.org Subject: Re: IPP> Why must IPP be transport-independent? References: <3.0.5.32.19980604131944.01294100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Carl-Uno, I'm a bit confused about who you're agreeing with here. The text that you've quoted is from me, not Harry. I read Harry's response to my posting as being in mild disagreement, citing that the charter claimed that IPP was supposed to be a generically usable network printing protocol. Are we to read that you've come to the position that maybe IPP should be explicitly relegated for use over HTTP, and not attempt to be transport-independent? Or did I interpret your message incorrectly? ...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 wrote: > > At 12:48 PM 6/4/98 PDT, Harry Lewis wrote: > >Subject: IPP> Why must IPP be transport-independent? > > > > > >After reading Paul Moore's posting (below), it appears > >that we are digger ourselves a deeper and deeper hole > >to fall into. > > > >Must IPP be transport-independent? > > > >I say "No". IPP stands for "Internet Printing Protocol", > >not something like "Generic Printing Protocol", or "Universal > >Printing Protocol". It was designed for use on the Internet. > > Harry, > > I think I start agreeing with you on this one. My recollection is that we > got this as part of our discussion to use a MIME part for the encoding. > MIME purists have stated that all MIME types MUST be transport independent. > > I think that having an object that can be mapped to another transport has > its virtues, but I was never convinced that it would ever make sense to > actually send the "application/ipp" object over email. Alternative > transports that make sense to me are things like the emerging HTTP-NG > protocol, and that is most likely able to handle URLs the same way as HTTP > does today. > > If somebody REALLY wants to send "application/ipp" over email, then they > would need to have an email address in the place where we are using the > HTTP URIs anyway, and I expect that such a mailbox would be dedicated to > the IPP printer and know what to do with messages it receives. In short, > new transport, new addressing scheme. > > In summary, I think we should remove any redundant URI information in the > "application/ipp", it seems to cause more confusion than what it is worth. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 20:47:24 1998 Delivery-Date: Thu, 04 Jun 1998 20:47:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA24036 for ; Thu, 4 Jun 1998 20:47:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA21599 for ; Thu, 4 Jun 1998 20:49:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05155 for ; Thu, 4 Jun 1998 20:47:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 20:43:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04578 for ipp-outgoing; Thu, 4 Jun 1998 20:40:12 -0400 (EDT) Message-Id: <3.0.5.32.19980604173803.012be730@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 4 Jun 1998 17:38:03 PDT To: Jay Martin From: Carl-Uno Manros Subject: Re: IPP> Why must IPP be transport-independent? Cc: Harry Lewis , ipp@pwg.org In-Reply-To: <357735B6.3DE4A001@underscore.com> References: <3.0.5.32.19980604131944.01294100@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Jay, Sorry, it seems that I misread what was written by you and what was written by Harry. If is was you who wrote about the misguided attempt to be fully transport neutral, you are right, I DO agree with you. However, we will need to tackle that problem when we try to do the SDP solution... just now I am grping at straws (maybe another of those European proverbs that not translate well to English) to get IPP V1.0 out the door. Carl-Uno At 05:03 PM 6/4/98 PDT, Jay Martin wrote: >Carl-Uno, > >I'm a bit confused about who you're agreeing with here. > >The text that you've quoted is from me, not Harry. > >I read Harry's response to my posting as being in >mild disagreement, citing that the charter claimed >that IPP was supposed to be a generically usable >network printing protocol. > >Are we to read that you've come to the position that >maybe IPP should be explicitly relegated for use over >HTTP, and not attempt to be transport-independent? >Or did I interpret your message incorrectly? > > ...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 wrote: >> >> At 12:48 PM 6/4/98 PDT, Harry Lewis wrote: >> >Subject: IPP> Why must IPP be transport-independent? >> > >> > >> >After reading Paul Moore's posting (below), it appears >> >that we are digger ourselves a deeper and deeper hole >> >to fall into. >> > >> >Must IPP be transport-independent? >> > >> >I say "No". IPP stands for "Internet Printing Protocol", >> >not something like "Generic Printing Protocol", or "Universal >> >Printing Protocol". It was designed for use on the Internet. >> >> Harry, >> >> I think I start agreeing with you on this one. My recollection is that we >> got this as part of our discussion to use a MIME part for the encoding. >> MIME purists have stated that all MIME types MUST be transport independent. >> >> I think that having an object that can be mapped to another transport has >> its virtues, but I was never convinced that it would ever make sense to >> actually send the "application/ipp" object over email. Alternative >> transports that make sense to me are things like the emerging HTTP-NG >> protocol, and that is most likely able to handle URLs the same way as HTTP >> does today. >> >> If somebody REALLY wants to send "application/ipp" over email, then they >> would need to have an email address in the place where we are using the >> HTTP URIs anyway, and I expect that such a mailbox would be dedicated to >> the IPP printer and know what to do with messages it receives. In short, >> new transport, new addressing scheme. >> >> In summary, I think we should remove any redundant URI information in the >> "application/ipp", it seems to cause more confusion than what it is worth. >> >> 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 > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 21:43:24 1998 Delivery-Date: Thu, 04 Jun 1998 21:43:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA24323 for ; Thu, 4 Jun 1998 21:43:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA21692 for ; Thu, 4 Jun 1998 21:45:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07614 for ; Thu, 4 Jun 1998 21:43:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 21:38:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07023 for ipp-outgoing; Thu, 4 Jun 1998 21:37:17 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE25@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> MOD - A couple of POSITIVE things about an "ipp" scheme Date: Thu, 4 Jun 1998 18:37:04 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Minor correction. this draft is the positive arguments for NOT using POST. > > If you want the positive arguments for using POST vs. PRINT, > please check > back on Josh Cohen's I-D at: > http://search.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 4 23:29:04 1998 Delivery-Date: Thu, 04 Jun 1998 23:29:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA01168 for ; Thu, 4 Jun 1998 23:29:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA21869 for ; Thu, 4 Jun 1998 23:31:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA09548 for ; Thu, 4 Jun 1998 23:29:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 4 Jun 1998 23:23:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08920 for ipp-outgoing; Thu, 4 Jun 1998 23:17:33 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE2C@red-msg-45.dns.microsoft.com> From: Josh Cohen To: Paul Moore , "'Jay Martin'" , ipp@pwg.org Subject: RE: IPP> Why must IPP be transport-independent? Date: Thu, 4 Jun 1998 20:17:21 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I dont see exactly what the issue is. Having a job-uri, or using URIs for naming and identification doesnt link the IPP protocol to HTTP at all. URIs are a fine way to manage a unique namespace, even if your not using HTTP. Technically, if IPP is deployed over any other protocols, you can still use URIs. Lets say, for example, that you deployed IPP over FTP or SMTP. If you did this then your job-uri would be ftp://host/job or mailto:job@host, respectively. If you used IPP over another protocol, you could likely define a new URI scheme to represent it. > -----Original Message----- > From: Paul Moore [mailto:paulmo@microsoft.com] > Sent: Thursday, June 04, 1998 11:43 AM > To: 'Jay Martin'; ipp@pwg.org > Subject: RE: IPP> Why must IPP be transport-independent? > > > One point - this is othogonal to much of the 'URI in the > protocol' question. > As job-id vs job-uri shows there are still areas where this > is a problem > even if we decide to only do IPP on HTTP. > > > > -----Original Message----- > > From: Jay Martin [SMTP:jkm@underscore.com] > > Sent: Thursday, June 04, 1998 11:28 AM > > To: ipp@pwg.org > > Subject: IPP> Why must IPP be transport-independent? > > > > After reading Paul Moore's posting (below), it appears > > that we are digger ourselves a deeper and deeper hole > > to fall into. > > > > Must IPP be transport-independent? > > > > I say "No". IPP stands for "Internet Printing Protocol", > > not something like "Generic Printing Protocol", or "Universal > > Printing Protocol". It was designed for use on the Internet. > > > > Sure, there are some in the IPP WG who believe IPP can > > and *should* become the single, all-encompassing printing > > protocol for use in almost any environment. > > > > I (and others) say "hogwash". Microsoft and Northlake Software > > have done a good job in delineating areas in which the IPP > > design falls very short in providing the kind of session- > > oriented protocol to achieve the kinds of capabilities that > > already exist in TIP/SI, CPAP and others. > > > > If HTTP is going to be the first and primary reference > > implementation of IPP (damn the nay-sayers...), then why > > can't we just tie IPP onto HTTP (semantics, syntax et al) > > and be done with it? > > > > Let the SDP project deal with other non-HTTP-oriented > > requirements. We'll just strive to make the mapping > > from IPP to SDP as easy and painless 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 -- > ---------------------------------------------------------------------- > > > Paul Moore wrote: > > > > It seem to me that the fundamental question comes down to - > should > > the IPP protocol form, transmit and use information that is specific to > the > > underlying transport. > > > > We have chosen to use URI as our way of identifying endpoints. > The > > assumptions we make about these URIs (there actual syntax is irrelevant) > > are:- > > a) an agent knows how to form them > > b) the only thing an agent may do with a URI it receives to it > is to > > pass it to its underlying transport. This means that the creator of the > URI > > MUST use the same URI forming convention as that which will be used by > the > > receivers transport stack (ie. this is not a private issue for a given > > implementation). It also means that the receiver may not look at the URI > to > > infer any deeper meaning (because that is a private issue for the > sending > > implementation). > > This last restriction made us invent job-id. We moved to > explicitly > > stating in IPP the way of identifying an endpoint. > > The real problem is that we end up with leakage from the > transport > > up into the IPP layer. I cannot blindly forward requests from > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and > change > > them on the fly. > > There is another problem that assumpion b causes. It assumes > that a > > printer knows how to form an address (URI) that makes sense in the > clients > > transport stack. This is true for HTTP but not true (or certainly > > non-trivial) for other transports. > > > > I would propose that we use an adressing scheme that corresponds > to > > the transport endpoint only. We then specifiy in IPP the ways of > identifying > > the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Fri Jun 5 00:07:51 1998 Delivery-Date: Fri, 05 Jun 1998 00:07:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01708 for ; Fri, 5 Jun 1998 00:07:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA21954 for ; Fri, 5 Jun 1998 00:10:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA10628 for ; Fri, 5 Jun 1998 00:07:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 00:03:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09972 for ipp-outgoing; Thu, 4 Jun 1998 23:57:28 -0400 (EDT) Message-Id: <1.5.4.32.19980605035129.00737040@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, 04 Jun 1998 20:51:29 -0700 To: ipp@pwg.org From: "Larry Masinter" (by way of Carl-Uno Manros ) Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Sender: owner-ipp@pwg.org All, I just found Larry's answer to my earlier question on my home mnachine. Unfortunately Larry had not copied the IPP DL. Herer it is for the rest of you to enjoy. Carl-Uno --- > This might be a brilliant idea - if I could only understand what it is that > you suggest. It seems to me that you are suggesting to introduce "ipp", as > a synonym for "http", which you map in both the server and the client? I'm suggesting introducing "ipp" as a synonym for "http with a different port, restricted only to accept POST of application/ipp messages". > If that is correct, does that not mean that you are running "http" over > the wire, and hence through the firewall? The whole discussion as raised > in Keith's feedback has to do with firewalls. Also, we are not discussing > how easy or not it is to change the specs, but what the consequences are > for implementors. You are running http over the wire. That was the whole point. There's no value in inventing an HTTP-like protocol; since HTTP is a terrible protocol, the only value you get is from _complete_ compatibility. The consequence of using "ipp" as a synonym for "http with a different port" is that the proxy forwarding remains the same (forwarding is sending ordinary HTTP methods), but proxy filtering is simply controlled (filter on host & port, and, if desired, only allow certain message types). > My understanding is that Keith is trying to dictate that IPP CANNOT USE > "http" - full stop. No, I don't read that in any of his comments at all. He was suggesting not calling it 'http' in the URL scheme, and not using the same port that is reserved for HTTP. > Considering that he has been the project advisor, I am > very disappopinted to see that kind of proposal at this stage in the > project. I think you should look harder his comments. To suggest that IPP _not_ use HTTP at this point would send you back to square one. I don't think the goal was to scuttle IPP at this point, but rather to make some simple changes that would make it clear to clients that a a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing the URL scheme and using a different default port doesn't change your protocol, but rather the 'user' interface to it. I think this is a positive move, can be accomodated easily, and you should do it and get on with it. Don't make this harder than it has to be. Larry From ipp-owner@pwg.org Fri Jun 5 10:39:41 1998 Delivery-Date: Fri, 05 Jun 1998 10:39:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12554 for ; Fri, 5 Jun 1998 10:39:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA23316 for ; Fri, 5 Jun 1998 10:41:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA17548 for ; Fri, 5 Jun 1998 10:39:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 10:28:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16843 for ipp-outgoing; Fri, 5 Jun 1998 10:22:43 -0400 (EDT) Message-Id: <1.5.4.32.19980605141947.009ba6c4@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: Fri, 05 Jun 1998 07:19:47 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Sender: owner-ipp@pwg.org All, I would like your reaction to Larry's proposal. It sounds almost too easy to be true. Can existing http servers and other components, such as firewalls and proxy servers, handle the kind of aliazing that Larry talks about without substantial modification? Is this simpler than to introduce a PRINT method? Is this really what Keith had in mind when he suggested a new scheme and a new port? I will tune out for the next few days to go to Canada and watch Sumo wrestling - keep up your own wrestling on the DL while I am away :-) Carl-Uno >--- > >> This might be a brilliant idea - if I could only understand what it is that >> you suggest. It seems to me that you are suggesting to introduce "ipp", as >> a synonym for "http", which you map in both the server and the client? > >I'm suggesting introducing "ipp" as a synonym for "http with a different >port, restricted only to accept POST of application/ipp messages". > >> If that is correct, does that not mean that you are running "http" over >> the wire, and hence through the firewall? The whole discussion as raised >> in Keith's feedback has to do with firewalls. Also, we are not discussing >> how easy or not it is to change the specs, but what the consequences are >> for implementors. > >You are running http over the wire. That was the whole point. There's >no value in inventing an HTTP-like protocol; since HTTP is a terrible >protocol, the only value you get is from _complete_ compatibility. > >The consequence of using "ipp" as a synonym for "http with a different port" >is that the proxy forwarding remains the same (forwarding is sending ordinary >HTTP methods), but proxy filtering is simply controlled (filter on host >& port, and, if desired, only allow certain message types). > >> My understanding is that Keith is trying to dictate that IPP CANNOT USE >> "http" - full stop. > >No, I don't read that in any of his comments at all. He was suggesting >not calling it 'http' in the URL scheme, and not using the same port >that is reserved for HTTP. > >> Considering that he has been the project advisor, I am >> very disappopinted to see that kind of proposal at this stage in the >> project. > >I think you should look harder his comments. To suggest that IPP _not_ >use HTTP at this point would send you back to square one. > >I don't think the goal was to scuttle IPP at this point, but rather to make >some simple changes that would make it clear to clients that a >a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing >the URL scheme and using a different default port doesn't change your >protocol, but rather the 'user' interface to it. I think this is a positive >move, can be accomodated easily, and you should do it and get on with it. > >Don't make this harder than it has to be. > >Larry From ipp-owner@pwg.org Fri Jun 5 11:45:42 1998 Delivery-Date: Fri, 05 Jun 1998 11:45:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13839 for ; Fri, 5 Jun 1998 11:45:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA23737 for ; Fri, 5 Jun 1998 11:48:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19213 for ; Fri, 5 Jun 1998 11:45:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 11:40:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA18508 for ipp-outgoing; Fri, 5 Jun 1998 11:28:46 -0400 (EDT) Message-ID: <35780E4F.5F4352FF@underscore.com> Date: Fri, 05 Jun 1998 11:27:12 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers References: <1.5.4.32.19980605141947.009ba6c4@pop3.holonet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org I interpreted Larry Masinter's proposal as being one in which clients and servers would talk in terms of ipp://host/printer, but in practice map this (internally) to http://host:nnn/printer when conducting the actual wire protocol. If, on the other hand, he is actually suggesting a new kind of aliasing mechanism (as you've pointed out below), then I, too, have some doubts as to whether firewalls, proxies and web servers would handle that; or, more importantly, whether the vendors would *want* to address that capability in their products. Also, I don't think Keith was suggesting that IPP not use HTTP, although I may have misinterpreted his statements. ...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 wrote: > > All, > > I would like your reaction to Larry's proposal. It sounds almost too easy to > be true. Can existing http servers and other components, such as firewalls > and proxy servers, handle the kind of aliazing that Larry talks about > without substantial modification? Is this simpler than to introduce a PRINT > method? > Is this really what Keith had in mind when he suggested a new scheme and a > new port? > > I will tune out for the next few days to go to Canada and watch Sumo > wrestling - keep up your own wrestling on the DL while I am away :-) > > Carl-Uno > > >--- > > > >> This might be a brilliant idea - if I could only understand what it is that > >> you suggest. It seems to me that you are suggesting to introduce "ipp", as > >> a synonym for "http", which you map in both the server and the client? > > > >I'm suggesting introducing "ipp" as a synonym for "http with a different > >port, restricted only to accept POST of application/ipp messages". > > > >> If that is correct, does that not mean that you are running "http" over > >> the wire, and hence through the firewall? The whole discussion as raised > >> in Keith's feedback has to do with firewalls. Also, we are not discussing > >> how easy or not it is to change the specs, but what the consequences are > >> for implementors. > > > >You are running http over the wire. That was the whole point. There's > >no value in inventing an HTTP-like protocol; since HTTP is a terrible > >protocol, the only value you get is from _complete_ compatibility. > > > >The consequence of using "ipp" as a synonym for "http with a different port" > >is that the proxy forwarding remains the same (forwarding is sending ordinary > >HTTP methods), but proxy filtering is simply controlled (filter on host > >& port, and, if desired, only allow certain message types). > > > >> My understanding is that Keith is trying to dictate that IPP CANNOT USE > >> "http" - full stop. > > > >No, I don't read that in any of his comments at all. He was suggesting > >not calling it 'http' in the URL scheme, and not using the same port > >that is reserved for HTTP. > > > >> Considering that he has been the project advisor, I am > >> very disappopinted to see that kind of proposal at this stage in the > >> project. > > > >I think you should look harder his comments. To suggest that IPP _not_ > >use HTTP at this point would send you back to square one. > > > >I don't think the goal was to scuttle IPP at this point, but rather to make > >some simple changes that would make it clear to clients that a > >a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing > >the URL scheme and using a different default port doesn't change your > >protocol, but rather the 'user' interface to it. I think this is a positive > >move, can be accomodated easily, and you should do it and get on with it. > > > >Don't make this harder than it has to be. > > > >Larry From ipp-owner@pwg.org Fri Jun 5 11:56:19 1998 Delivery-Date: Fri, 05 Jun 1998 11:56:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13986 for ; Fri, 5 Jun 1998 11:56:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA23812 for ; Fri, 5 Jun 1998 11:58:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA19904 for ; Fri, 5 Jun 1998 11:56:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 11:51:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA19162 for ipp-outgoing; Fri, 5 Jun 1998 11:45:03 -0400 (EDT) Message-ID: <35781255.D1229B5B@underscore.com> Date: Fri, 05 Jun 1998 11:44:21 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Josh Cohen CC: Paul Moore , ipp@pwg.org Subject: Re: IPP> Why must IPP be transport-independent? References: <8B57882C41A0D1118F7100805F9F68B502D2CE2C@red-msg-45.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org If you're only talking in abstract or high-level modeling terms, then sure, I can see where you don't see the issue. Exactly what does transport-independent mean, anyway? One school of thought believes that identifiers (such as URIs) should be transport-independent as well. They certainly could be, afterall. However, an IPP implementation that uses mailto:job@host as an indentifier will not be very interoperable with one that uses ftp://host/job. That is the issue, I believe. Comments from others?? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Josh Cohen wrote: > > I dont see exactly what the issue is. > Having a job-uri, or using URIs for naming and identification > doesnt link the IPP protocol to HTTP at all. URIs are > a fine way to manage a unique namespace, even if your > not using HTTP. > Technically, if IPP is deployed over any other protocols, > you can still use URIs. Lets say, for example, that you > deployed IPP over FTP or SMTP. If you did this then > your job-uri would be ftp://host/job or mailto:job@host, > respectively. > If you used IPP over another protocol, you could likely > define a new URI scheme to represent it. > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Thursday, June 04, 1998 11:43 AM > > To: 'Jay Martin'; ipp@pwg.org > > Subject: RE: IPP> Why must IPP be transport-independent? > > > > > > One point - this is othogonal to much of the 'URI in the > > protocol' question. > > As job-id vs job-uri shows there are still areas where this > > is a problem > > even if we decide to only do IPP on HTTP. > > > > > > > -----Original Message----- > > > From: Jay Martin [SMTP:jkm@underscore.com] > > > Sent: Thursday, June 04, 1998 11:28 AM > > > To: ipp@pwg.org > > > Subject: IPP> Why must IPP be transport-independent? > > > > > > After reading Paul Moore's posting (below), it appears > > > that we are digger ourselves a deeper and deeper hole > > > to fall into. > > > > > > Must IPP be transport-independent? > > > > > > I say "No". IPP stands for "Internet Printing Protocol", > > > not something like "Generic Printing Protocol", or "Universal > > > Printing Protocol". It was designed for use on the Internet. > > > > > > Sure, there are some in the IPP WG who believe IPP can > > > and *should* become the single, all-encompassing printing > > > protocol for use in almost any environment. > > > > > > I (and others) say "hogwash". Microsoft and Northlake Software > > > have done a good job in delineating areas in which the IPP > > > design falls very short in providing the kind of session- > > > oriented protocol to achieve the kinds of capabilities that > > > already exist in TIP/SI, CPAP and others. > > > > > > If HTTP is going to be the first and primary reference > > > implementation of IPP (damn the nay-sayers...), then why > > > can't we just tie IPP onto HTTP (semantics, syntax et al) > > > and be done with it? > > > > > > Let the SDP project deal with other non-HTTP-oriented > > > requirements. We'll just strive to make the mapping > > > from IPP to SDP as easy and painless 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 -- > > ---------------------------------------------------------------------- > > > > > > Paul Moore wrote: > > > > > > It seem to me that the fundamental question comes down to - > > should > > > the IPP protocol form, transmit and use information that is specific to > > the > > > underlying transport. > > > > > > We have chosen to use URI as our way of identifying endpoints. > > The > > > assumptions we make about these URIs (there actual syntax is irrelevant) > > > are:- > > > a) an agent knows how to form them > > > b) the only thing an agent may do with a URI it receives to it > > is to > > > pass it to its underlying transport. This means that the creator of the > > URI > > > MUST use the same URI forming convention as that which will be used by > > the > > > receivers transport stack (ie. this is not a private issue for a given > > > implementation). It also means that the receiver may not look at the URI > > to > > > infer any deeper meaning (because that is a private issue for the > > sending > > > implementation). > > > This last restriction made us invent job-id. We moved to > > explicitly > > > stating in IPP the way of identifying an endpoint. > > > The real problem is that we end up with leakage from the > > transport > > > up into the IPP layer. I cannot blindly forward requests from > > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and > > change > > > them on the fly. > > > There is another problem that assumpion b causes. It assumes > > that a > > > printer knows how to form an address (URI) that makes sense in the > > clients > > > transport stack. This is true for HTTP but not true (or certainly > > > non-trivial) for other transports. > > > > > > I would propose that we use an adressing scheme that corresponds > > to > > > the transport endpoint only. We then specifiy in IPP the ways of > > identifying > > > the logical object that we wish to talk to (printer-ID, Job-ID,...). From ipp-owner@pwg.org Fri Jun 5 12:37:57 1998 Delivery-Date: Fri, 05 Jun 1998 12:37:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14663 for ; Fri, 5 Jun 1998 12:37:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA24186 for ; Fri, 5 Jun 1998 12:40:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA20976 for ; Fri, 5 Jun 1998 12:37:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 12:33:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20353 for ipp-outgoing; Fri, 5 Jun 1998 12:32:25 -0400 (EDT) From: don@lexmark.com Message-Id: <199806051632.AA21427@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 5 Jun 1998 12:31:37 -0400 Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org My understanding is that internal to the client and the server, a magic transformation happens that turns ipp://xyz.printer.com/printer1 into http://xyz.printer.com:380/printer1. The "wire" would never see anything but http URLs so the infrastruture would be unaffected. When a client or a server pulled an IPP URL from inside application/ipp, it would also translate it into the HTTP format. In summary: WIRE -- only sees HTTP stuff Humans - see only IPP stuff (i.e. my business card says to print to me at ipp://www.lexmark.com/donsprinter) Clients and Servers -- provide the "magic" to convert back and forth. Am I right, Larry? Interesting idea!! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Jay Martin 06/05/98 11:27 AM To: Carl-Uno Manros cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers I interpreted Larry Masinter's proposal as being one in which clients and servers would talk in terms of ipp://host/printer, but in practice map this (internally) to http://host:nnn/printer when conducting the actual wire protocol. If, on the other hand, he is actually suggesting a new kind of aliasing mechanism (as you've pointed out below), then I, too, have some doubts as to whether firewalls, proxies and web servers would handle that; or, more importantly, whether the vendors would *want* to address that capability in their products. Also, I don't think Keith was suggesting that IPP not use HTTP, although I may have misinterpreted his statements. ...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 wrote: > > All, > > I would like your reaction to Larry's proposal. It sounds almost too easy to > be true. Can existing http servers and other components, such as firewalls > and proxy servers, handle the kind of aliazing that Larry talks about > without substantial modification? Is this simpler than to introduce a PRINT > method? > Is this really what Keith had in mind when he suggested a new scheme and a > new port? > > I will tune out for the next few days to go to Canada and watch Sumo > wrestling - keep up your own wrestling on the DL while I am away :-) > > Carl-Uno > > >--- > > > >> This might be a brilliant idea - if I could only understand what it is that > >> you suggest. It seems to me that you are suggesting to introduce "ipp", as > >> a synonym for "http", which you map in both the server and the client? > > > >I'm suggesting introducing "ipp" as a synonym for "http with a different > >port, restricted only to accept POST of application/ipp messages". > > > >> If that is correct, does that not mean that you are running "http" over > >> the wire, and hence through the firewall? The whole discussion as raised > >> in Keith's feedback has to do with firewalls. Also, we are not discussing > >> how easy or not it is to change the specs, but what the consequences are > >> for implementors. > > > >You are running http over the wire. That was the whole point. There's > >no value in inventing an HTTP-like protocol; since HTTP is a terrible > >protocol, the only value you get is from _complete_ compatibility. > > > >The consequence of using "ipp" as a synonym for "http with a different port" > >is that the proxy forwarding remains the same (forwarding is sending ordinary > >HTTP methods), but proxy filtering is simply controlled (filter on host > >& port, and, if desired, only allow certain message types). > > > >> My understanding is that Keith is trying to dictate that IPP CANNOT USE > >> "http" - full stop. > > > >No, I don't read that in any of his comments at all. He was suggesting > >not calling it 'http' in the URL scheme, and not using the same port > >that is reserved for HTTP. > > > >> Considering that he has been the project advisor, I am > >> very disappopinted to see that kind of proposal at this stage in the > >> project. > > > >I think you should look harder his comments. To suggest that IPP _not_ > >use HTTP at this point would send you back to square one. > > > >I don't think the goal was to scuttle IPP at this point, but rather to make > >some simple changes that would make it clear to clients that a > >a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing > >the URL scheme and using a different default port doesn't change your > >protocol, but rather the 'user' interface to it. I think this is a positive > >move, can be accomodated easily, and you should do it and get on with it. > > > >Don't make this harder than it has to be. > > > >Larry From ipp-owner@pwg.org Fri Jun 5 15:08:43 1998 Delivery-Date: Fri, 05 Jun 1998 15:08:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA16790 for ; Fri, 5 Jun 1998 15:08:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25343 for ; Fri, 5 Jun 1998 15:11:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23213 for ; Fri, 5 Jun 1998 15:08:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 15:03:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22589 for ipp-outgoing; Fri, 5 Jun 1998 15:01:23 -0400 (EDT) Message-Id: <199806051901.PAA23525@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harry Lewis cc: ipp@pwg.org, cmanros@cp10.es.xerox.com, moore@cs.utk.edu, masinter@parc.xerox.com Subject: Re: IPP> Re: Implications of introducing new scheme and port In-reply-to: Your message of "Thu, 04 Jun 1998 12:01:56 EDT." <5030300021589020000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jun 1998 15:01:04 -0400 Sender: owner-ipp@pwg.org > My understanding is that Keith is trying to dictate that IPP CANNOT USE > "http" - full stop. No, that's not quite what I meant. What I am "trying to dictate" is that IPP traffic must be easily distinguishable from HTTP traffic, so that it can be filtered (or not) according to a site's security policy. My suggestion to use a different default port was an attempt to acheive this, with the fewest possible changes to the current IPP protocol. IETF has traditionally used well-known port numbers to distinguish between different services. To follow this pattern, IPP should not use port 80 as a default, because that port is reserved to HTTP. And in my mind this pretty much implies that a new "ipp" URI prefix is needed to refer to printers and print jobs so that the port number doesn't have to be explicitly specified. This doesn't necessarily mean that "http" cannot also be used (and doing this might be useful to tunnel through proxies that understand http: but not ipp:) but sometimes it's a Bad Idea to have two ways to name the same thing. (What happens if you make a request to an ipp: object? Will you get back references to ipp: objects? or might they use the http: scheme?) Note that while some changes might be necessary for IPP protocol elements (using ipp: URLs instead of http: URLs) I would not expect any changes to the HTTP layer itself. Keith From ipp-owner@pwg.org Fri Jun 5 15:16:52 1998 Delivery-Date: Fri, 05 Jun 1998 15:16:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA16921 for ; Fri, 5 Jun 1998 15:16:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25515 for ; Fri, 5 Jun 1998 15:19:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA23884 for ; Fri, 5 Jun 1998 15:16:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 15:11:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22743 for ipp-outgoing; Fri, 5 Jun 1998 15:04:26 -0400 (EDT) Message-Id: <199806051900.MAA11386@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 05 Jun 1998 12:05:36 -0700 To: "Larry Masinter" , don@lexmark.com, ipp@pwg.org From: Robert Herriot Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers In-Reply-To: <199806051632.AA21427@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_2581091==_.ALT" Sender: owner-ipp@pwg.org --=====================_2581091==_.ALT Content-Type: text/plain; charset="us-ascii" Larry, I get the same understanding as Don from your email. I understand you to say that a client translates ipp://foo/killtree to http://foo:380/killtree and sends the operation to the url http://foo:380/killtree. The wire, the proxies and the destination printer/print-server (at http level) see only http://foo:380/killtree. The printer-uri IPP attribute is ipp://foo/killtree, but the request line is "POST /killtree HTTP/1.1" Bob Herriot At 09:31 AM 6/5/98 , don@lexmark.com wrote: >My understanding is that internal to the client and the server, a magic >transformation happens that turns ipp://xyz.printer.com/printer1 into >http://xyz.printer.com:380/printer1. The "wire" would never see anything >but http URLs so the infrastruture would be unaffected. When a client or a >server pulled an IPP URL from inside application/ipp, it would also >translate it into the HTTP format. > >In summary: > > WIRE -- only sees HTTP stuff > Humans - see only IPP stuff (i.e. my business card says to print to me >at ipp://www.lexmark.com/donsprinter) > Clients and Servers -- provide the "magic" to convert back and forth. > >Am I right, Larry? Interesting idea!! > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > >Jay Martin >06/05/98 11:27 AM > > >To: Carl-Uno Manros >cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright) >bcc: Don Wright >Subject: Re: IPP> Re: Implications of introducing new scheme and port > for existing HTTP servers > > > > >I interpreted Larry Masinter's proposal as being one in which >clients and servers would talk in terms of ipp://host/printer, >but in practice map this (internally) to http://host:nnn/printer >when conducting the actual wire protocol. > >If, on the other hand, he is actually suggesting a new kind >of aliasing mechanism (as you've pointed out below), then I, >too, have some doubts as to whether firewalls, proxies and >web servers would handle that; or, more importantly, whether >the vendors would *want* to address that capability in their >products. > >Also, I don't think Keith was suggesting that IPP not use HTTP, >although I may have misinterpreted his statements. > > ...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 wrote: >> >> All, >> >> I would like your reaction to Larry's proposal. It sounds almost too easy >to >> be true. Can existing http servers and other components, such as >firewalls >> and proxy servers, handle the kind of aliazing that Larry talks about >> without substantial modification? Is this simpler than to introduce a >PRINT >> method? >> Is this really what Keith had in mind when he suggested a new scheme and >a >> new port? >> >> I will tune out for the next few days to go to Canada and watch Sumo >> wrestling - keep up your own wrestling on the DL while I am away :-) >> >> Carl-Uno >> >> >--- >> > >> >> This might be a brilliant idea - if I could only understand what it is >that >> >> you suggest. It seems to me that you are suggesting to introduce >"ipp", as >> >> a synonym for "http", which you map in both the server and the client? >> > >> >I'm suggesting introducing "ipp" as a synonym for "http with a different >> >port, restricted only to accept POST of application/ipp messages". >> > >> >> If that is correct, does that not mean that you are running "http" >over >> >> the wire, and hence through the firewall? The whole discussion as >raised >> >> in Keith's feedback has to do with firewalls. Also, we are not >discussing >> >> how easy or not it is to change the specs, but what the consequences >are >> >> for implementors. >> > >> >You are running http over the wire. That was the whole point. There's >> >no value in inventing an HTTP-like protocol; since HTTP is a terrible >> >protocol, the only value you get is from _complete_ compatibility. >> > >> >The consequence of using "ipp" as a synonym for "http with a different >port" >> >is that the proxy forwarding remains the same (forwarding is sending >ordinary >> >HTTP methods), but proxy filtering is simply controlled (filter on host >> >& port, and, if desired, only allow certain message types). >> > >> >> My understanding is that Keith is trying to dictate that IPP CANNOT >USE >> >> "http" - full stop. >> > >> >No, I don't read that in any of his comments at all. He was suggesting >> >not calling it 'http' in the URL scheme, and not using the same port >> >that is reserved for HTTP. >> > >> >> Considering that he has been the project advisor, I am >> >> very disappopinted to see that kind of proposal at this stage in the >> >> project. >> > >> >I think you should look harder his comments. To suggest that IPP _not_ >> >use HTTP at this point would send you back to square one. >> > >> >I don't think the goal was to scuttle IPP at this point, but rather to >make >> >some simple changes that would make it clear to clients that a >> >a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing >> >the URL scheme and using a different default port doesn't change your >> >protocol, but rather the 'user' interface to it. I think this is a >positive >> >move, can be accomodated easily, and you should do it and get on with >it. >> > >> >Don't make this harder than it has to be. >> > >> >Larry > --=====================_2581091==_.ALT Content-Type: text/html; charset="us-ascii" Larry,

I get the same understanding as Don from your email. I understand you to say
that a client translates ipp://foo/killtree to http://foo:380/killtree and
sends the operation to the url http://foo:380/killtree.  The wire, the
proxies and the destination printer/print-server (at http level) see only
http://foo:380/killtree. The printer-uri IPP attribute is
ipp://foo/killtree, but the request line is "POST /killtree HTTP/1.1"


Bob Herriot

At 09:31 AM 6/5/98 , don@lexmark.com wrote:
>My understanding is that internal to the client and the server, a magic
>transformation happens that turns ipp://xyz.printer.com/printer1 into
>http://xyz.printer.com:380/printer1.  The "wire" would never see anything
>but http URLs so the infrastruture would be unaffected.  When a client or a
>server pulled an IPP URL from inside application/ipp, it would also
>translate it into the HTTP format.
>
>In summary:
>
>     WIRE -- only sees HTTP stuff
>     Humans - see only IPP stuff (i.e. my business card says to print to me
>at ipp://www.lexmark.com/donsprinter)
>     Clients and Servers -- provide the "magic" to convert back and forth.
>
>Am I right, Larry?  Interesting idea!!
>
>**********************************************
>* Don Wright                 don@lexmark.com *
>* Product Manager, Strategic Alliances       *
>* Lexmark International                      *
>* 740 New Circle Rd                          *
>* Lexington, Ky 40550                        *
>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>**********************************************
>
>
>
>
>Jay Martin <jkm%underscore.com@interlock.lexmark.com>
>06/05/98 11:27 AM
>
>
>To:   Carl-Uno Manros <carl%manros.com@interlock.lexmark.com>
>cc:   ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright)
>bcc:  Don Wright
>Subject:  Re: IPP> Re: Implications of introducing new scheme and port
>        for existing HTTP servers
>
>
>
>
>I interpreted Larry Masinter's proposal as being one in which
>clients and servers would talk in terms of ipp://host/printer,
>but in practice map this (internally) to http://host:nnn/printer
>when conducting the actual wire protocol.
>
>If, on the other hand, he is actually suggesting a new kind
>of aliasing mechanism (as you've pointed out below), then I,
>too, have some doubts as to whether firewalls, proxies and
>web servers would handle that; or, more importantly, whether
>the vendors would *want* to address that capability in their
>products.
>
>Also, I don't think Keith was suggesting that IPP not use HTTP,
>although I may have misinterpreted his statements.
>
>     ...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 wrote:
>>
>> All,
>>
>> I would like your reaction to Larry's proposal. It sounds almost too easy
>to
>> be true. Can existing http servers and other components, such as
>firewalls
>> and proxy servers, handle the kind of aliazing that Larry talks about
>> without substantial modification? Is this simpler than to introduce a
>PRINT
>> method?
>> Is this really what Keith had in mind when he suggested a new scheme and
>a
>> new port?
>>
>> I will tune out for the next few days to go to Canada and watch Sumo
>> wrestling -  keep up your own wrestling on the DL while I am away :-)
>>
>> Carl-Uno
>>
>> >---
>> >
>> >> This might be a brilliant idea - if I could only understand what it is
>that
>> >> you suggest. It seems to me that you are suggesting to introduce
>"ipp", as
>> >> a synonym for "http", which you map in both the server and the client?
>> >
>> >I'm suggesting introducing "ipp" as a synonym for "http with a different
>> >port, restricted only to accept POST of application/ipp messages".
>> >
>> >> If that is correct, does that not mean that you are running "http"
>over
>> >> the wire, and hence through the firewall? The whole discussion as
>raised
>> >> in Keith's feedback has to do with firewalls. Also, we are not
>discussing
>> >> how easy or not it is to change the specs, but what the consequences
>are
>> >> for implementors.
>> >
>> >You are running http over the wire. That was the whole point. There's
>> >no value in inventing an HTTP-like protocol; since HTTP is a terrible
>> >protocol, the only value you get is from _complete_ compatibility.
>> >
>> >The consequence of using "ipp" as a synonym for "http with a different
>port"
>> >is that the proxy forwarding remains the same (forwarding is sending
>ordinary
>> >HTTP methods), but proxy filtering is simply controlled (filter on host
>> >& port, and, if desired, only allow certain message types).
>> >
>> >> My understanding is that Keith is trying to dictate that IPP CANNOT
>USE
>> >> "http" - full stop.
>> >
>> >No, I don't read that in any of his comments at all. He was suggesting
>> >not calling it 'http' in the URL scheme, and not using the same port
>> >that is reserved for HTTP.
>> >
>> >> Considering that he has been the project advisor, I am
>> >> very disappopinted to see that kind of proposal at this stage in the
>> >> project.
>> >
>> >I think you should look harder his comments. To suggest that IPP _not_
>> >use HTTP at this point would send you back to square one.
>> >
>> >I don't think the goal was to scuttle IPP at this point, but rather to
>make
>> >some simple changes that would make it clear to clients that a
>> >a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing
>> >the URL scheme and using a different default port doesn't change your
>> >protocol, but rather the 'user' interface to it. I think this is a
>positive
>> >move, can be accomodated easily, and you should do it and get on with
>it.
>> >
>> >Don't make this harder than it has to be.
>> >
>> >Larry
>
--=====================_2581091==_.ALT-- From ipp-owner@pwg.org Fri Jun 5 16:08:03 1998 Delivery-Date: Fri, 05 Jun 1998 16:08:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA17568 for ; Fri, 5 Jun 1998 16:08:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA25743 for ; Fri, 5 Jun 1998 16:10:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25397 for ; Fri, 5 Jun 1998 16:07:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 16:03:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA24841 for ipp-outgoing; Fri, 5 Jun 1998 16:02:25 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Implications of a new scheme, etc Message-ID: <5030100021410027000002L072*@MHS> Date: Fri, 5 Jun 1998 16:00:26 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100021410027" Sender: owner-ipp@pwg.org --Boundary=_0.0_=5030100021410027 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable As suggested on Wednesday's teleconference, Harry Lewis, Carl Kugler, and I produced the attached table (in .pdf format) which hopefully summarizes the many views which have been expressed on this subject over the last couple of weeks. Our intent is that this would help support our position with Keith Moore. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 = --Boundary=_0.0_=5030100021410027 Content-Type: application/octet-stream; name=newscheme.pdf Content-Transfer-Encoding: base64 JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAyOTgyDQovRmlsdGVyIC9MWldE ZWNvZGUNCj4+DQpzdHJlYW0NCoAQioDQULyMMRBCCoZoIMISMhALRjEIcMRgMRcORuIBkNByLhsO RAVDbDRAZ4IQiwIBeRynCDOcxARSxJioY5sd4IKCSUChERASTacDYaTGYToaTebpkbzMICcZTuIC gbzkdKgdTaYjKchAYTcZBAUzGaDKbTKKSoaoIRYGCoQaRBBIsMxcMY2NRoMhdFxAMIyNoiMhzfBn EDkZYJDAVAoJBohCsZFcAMBxEYtfcvFRkNpBIhvfBhIpJOyCcznXaTSx1arZBSMM4TI8YNBcMxqN 4RDioRJ2IBAV7MbhAdzKIK4Z7AIDpZqDPuLVjXxeOaDDYjOZTdXTCbK+Z8TZ+1WObSBBS+ObTCaq t5zEajKY6SduPTvOda8d+l0TqbLErjmDeEAyDKMw0u2r4QDgOQ3joN4xje7zyqwMbXIIGq+BoHAb s2kbfAUFA3v6/7jjiOqjDWNg8ws2AaNmhaCBaGrPBwGiPMwu4chgGsPJ3AiiDePIyrFA4QDGOo5w ctA5C4GUnJk8auwWNLUjmFgQSRA4zhAMo8SopI3S3A4zDkMMkjkOr5PwMoXOAKjrKxKkruNAY0rE N0GuKsDyQE6z6Oen8fjZIK0DcrEfu0sQ6jgpcWBqjAZN1Dret+5rjwI+lBjhQqsLAMkWRlSFJRwG MdR5SgFC2FA7zsMo5wWMrrwGMsgDzTjkDy+6vSPJI3yXKzzqeMIQO2qbsu3MrVuI+wrjKMQQNSOT 6DlYEFjfL1XSu9oUhiGgbBRAzEju7o2DmFwUi6KglJMFrDBwhUPhRN7jjNCNB1ZMLmDCMQ2OOpA6 LOOA6JlB1oK09Q5DSPVLypXg5qVZbiObKkAjgozz4k5ye0DL+EjEOtlBAosk3OtaCCoFSCVULgUC DkA0KtJsn2IMo6B04FmyNET/ZENM/1Y5qvjdXL7UsEFwyS5g0PDnQ2K0pk2iGMI5DYFoUokGgbhQ Ks8BA6yZUZJMhwSNytK4rz7bCNL5uOxMzKWmV6q9LN8jDdF1QuwAcrw3cexA4mN2gsrxTaoKnzor iijLP8J1AGu9b5UlTb9VVLNSr7EhBtw2RU6KrjQO40DTfsr0tXMzqWM/OjmOozuzpI0qHftOS1pu nhA2XQqMNAQYoJmpjlXOr27rQmzNA+ASZJwZbBBmwu6FwuBTu91tgyLaIIHAXNzbrBhcGgYQ1ygU CQKgqCgHQcIdliqyT6Wr/AG9v/L87W3T6qDR4yS6LswocGCN4vELCLDIIvMmSAGwNiNwBZUCgED7 A3vuemC0GwMX1E8J8/ZvBsH9PYLgYAHAM4RF/b8CiAbJnrQGRiDUvoOUMOSR3CWB75HzE/KW0o44 Vw0mJffCgGL/XwmXIwqWGKqIMPogIEaDqMC4EZiDCSI0JzXwFf2AoFptnwPiIkjmIq8WWOBhu0aH UPHpwoI+SGGMQ3JxGfo+h9UMwoMJUND016MiHLte2DIGZl4jBDcUoYOcSUXRVBuXcvZIjKx6j4h9 VQTkBOxDgGE+TVwbIYBgCiRzvShySDpJSSwKAmoHdid2TUkZJxXMI8WUR6jvSQk4/CVMoJVykldJ N+5bS3kdI+aMhIMyPmEISC4iEWzEGKAUYyXULZey/JEpBHExTFkEmTLxbpgAbmymdMRzUxpkEemU R0z01JhGYR2XeaEx5pTel4R2QoNZsTjm0YmaICppkiI69oGT+p4TOnlOiek6iRG4NtOKYZFoWGCn 7N2XdAQawsndMGgs46EzpoW7hGcwp9URnPQqZS3jRTNn3OWhE3KKUdBsXah82Z+Ukn/RVbxtp80Q mfNuec9QQG5MrSCgtIqaT+ps9x7c76NU9o5Lw3JfKY0qolSym0CpCg4ozOSFgM6R01oACCBUzKZT xqZVerMwqdUzonPRx9QZl1gISRh+VYqmVlofOAFy760gurWC0wD4qxz5MBQ+gVcSEAxrUYKuz3zL 15rcbKj1fq511rvYWttezZU4sVYCulgrG1EmlYerAN6tWUrrSueZjoUxVMoZqclpiHKRLtLw0Myj SogCmV1acgYUEGkHB6Qq3ZgSJj2+OTMtZOwUk/b+TZ8igBtgjJ2W8H66LdNlFuIip14rRtmkY5bI 2AMSDeixlBOw2n9KSUQ46jCrkyU85gtMKLuogQgG5AwZz8L7X6iwzJugaGypRfa30j7i3BkqDKS8 oQ3Sjlbf2WBGpZYDlZKWTlxwworuWDIjBe3/wwukTtAAc1fQ5WcWO2RXbaGvvWCg9QazjsTJlcgx N3GUogDIGkMyBkjhsPIdZZallqIsLdNIGxfKUy+rRZerlNce1mrhLzIRFjPIzsxPTItb1vWKyFZe vOT78F6mVkkGEhXw5NM7j7K5tq5ZTsJl7KwILE5IzKRLLZfUXZVzBmjIuY815UqZmeyWaotEWy5m /O+cbJZ0i1nbImcanVxR5lpGmZtDWcyDmu0FPqT0YrPMBrNla2ZELtTGuFctL2MzLlXTaPK+6ekL qCvGd9R5yL5qbTFg9U6a0poEhGn7Lah1VpSr+ltT2C0iYy0UVIPWlMtafYpDjDkYrla2XlrwURxW uGlV0goVAKtzIcv5fZFX7wZKe/8l7iSmv9cO/m4pPYABQEJtwa8U3Jd6UwOi5EhvUIIYeQ0wLoRr XitZbC5gQBBKwVxpO/NpYhZPi0FCfsToCQAYm9t701qfh9Na5xHDb1yiNupWO7AQHqaHu9JO8uJG vjvGqLpO+CbThRjsBQM7KVJyBbvSFS558uUgjzI8iNIAwyXVWf3NtKadN3nXXHNeX6kyxnoy+bM+ 5N6BTHUvQ9B9F5/0fVmWed9NrH09HlidBdL0J1Xm9Nwb052znvNuXet9W1p2fsHVDGdcs3U/RPO9 F9r7HrvnWe+adiIyRuH9Wjcav1/vWyhGiOZRrl4PVFjujEY8R1Gi2r+w9x8ORvrxCPGa31j37xHb fNkR8r4byBG+9eTs/33YBb9hRM2J0szOx6LPaofsw0hJUQBGh2VJcnBkW7V2vzIGG24+nL4cUviD mUHIs5LFzC6IF+IPOmgcMSIiwnMTLjEo2LMMJmbHDcnpXwyBkMSaj5j3o9rwJ28ZXKAGurjVz8uF HzbowlNSkdzKIg6fVDr9cOj7LGS+jii+6m4jJDBFz4o4j469wNK+D5S7b+bCyEr6IMb6YNz/j/0A D7a9ThAMT7wsT8An4678hVxYAqz7hED6j6wsS87/UDAMgFkFAFEDw1MEA4i8grBsorYrsAS5sAg2 x+RUqEpqUBQ+L5EBpNZAL87fLk76BQcCrd8F77AML7RCsDj7sGpjA578UEj80CKPD9KEr9g5A479 7B8JUL7kz54FD+8JMF0FcKcKsHq+yyMAwjqErjQMLjjjxXJA7kJzjecNL5yEpcL3hzhc0JZdz9RV JlrgJVwrBbhb8QpccQ5rwMI+jegBT+jfQnZgrhsI0BkBxsb+TEThCSI1EKMOBT0GUN7/osT/8KkA LicHw2T4I0heIJrd0PzeMQDkZdkNUQj3cShcpAZARPBQ8CEUq7xmpmBIgpgOA+JZRkrkj9DjBeMP LjjDQtDkEXhfsX0TUCSI0Sb3rHQt4GbS7xDwLR7vijbesdAjbnLtycjnrp0d7xJGjqTt7zruMeyv rpScjrSlkc6QryLLDr70TuEd0gjzDIsf7pjN0eshbq8g7WDxzn8ezPLvb2DtLPzmsjDsrKTokfch Tv7ubREeTNju8gUez07JL1Udx7QkLSokSELwkl4BS+4vkmUdSYCpUdsnDe0nbmKsLIaf0nIz8e6Z SlTnh7bn0fkmKezxQhEmrxrJso8mSdis0n0q0oKhigcojJQ28n8c8qCizMUqYu0qqscq6hihyoTT Mo0rrq6gkecsUessrzIEEqjzkiw2suRbylEt8osv0nQkUjKrcsIw8u8pDtsvchEkcoEwrsgjClKf cm8tkkyqExEpjYrrZDUpD08x0wYgkzD08rctcuU00y0n4gINCmVuZHN0cmVhbQ0KZW5kb2JqDQoz IDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMSA0IDAgUg0K L0YyIDUgMCBSDQovRjMgNiAwIFINCi9GNCA3IDAgUg0KL0Y1IDggMCBSDQo+Pg0KL0V4dEdTdGF0 ZSA8PA0KL0dTMSA5IDAgUg0KPj4NCj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PA0KL1R5cGUgL0hh bGZ0b25lDQovSGFsZnRvbmVUeXBlIDENCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpDQovRnJlcXVl bmN5IDYwDQovQW5nbGUgNDUNCi9TcG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0KZW5kb2JqDQo5IDAg b2JqDQo8PA0KL1R5cGUgL0V4dEdTdGF0ZQ0KL1NBIGZhbHNlDQovT1AgZmFsc2UNCi9IVCAvRGVm YXVsdA0KPj4NCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlw ZTENCi9OYW1lIC9GMQ0KL0Jhc2VGb250IC9IZWx2ZXRpY2EtQm9sZA0KPj4NCmVuZG9iag0KNSAw IG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMg0KL0Jhc2VG b250IC9UaW1lcy1Cb2xkDQo+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9T dWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YzDQovQmFzZUZvbnQgL1RpbWVzLVJvbWFuDQo+Pg0KZW5k b2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0Y0 DQovRW5jb2RpbmcgMTIgMCBSDQovQmFzZUZvbnQgL1RpbWVzLVJvbWFuDQo+Pg0KZW5kb2JqDQo4 IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0Y1DQovQmFz ZUZvbnQgL1RpbWVzLUJvbGRJdGFsaWMNCj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0KL1R5cGUg L0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWyAwL2dyYXZlL2FjdXRlL2NpcmN1bWZsZXgvdGlsZGUv bWFjcm9uL2JyZXZlL2RvdGFjY2VudC9kaWVyZXNpcw0KL3JpbmcvY2VkaWxsYS9odW5nYXJ1bWxh dXQvb2dvbmVrL2Nhcm9uL2RvdGxlc3NpL2ZpL2ZsDQovTHNsYXNoL2xzbGFzaC9aY2Fyb24vemNh cm9uL21pbnVzIDM5L3F1b3Rlc2luZ2xlIDk2L2dyYXZlIDEzMC9xdW90ZXNpbmdsYmFzZQ0KL2Zs b3Jpbi9xdW90ZWRibGJhc2UvZWxsaXBzaXMvZGFnZ2VyL2RhZ2dlcmRibC9jaXJjdW1mbGV4L3Bl cnRob3VzYW5kL1NjYXJvbg0KL2d1aWxzaW5nbGxlZnQvT0UgMTQ1L3F1b3RlbGVmdC9xdW90ZXJp Z2h0L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0L2J1bGxldC9lbmRhc2gNCi9lbWRhc2gvdGls ZGUvdHJhZGVtYXJrL3NjYXJvbi9ndWlsc2luZ2xyaWdodC9vZSAxNTkvWWRpZXJlc2lzIDE2NC9j dXJyZW5jeQ0KIDE2Ni9icm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodC9vcmRmZW1pbmlu ZSAxNzIvbG9naWNhbG5vdC9oeXBoZW4vcmVnaXN0ZXJlZC9tYWNyb24NCi9kZWdyZWUvcGx1c21p bnVzL3R3b3N1cGVyaW9yL3RocmVlc3VwZXJpb3IvYWN1dGUvbXUgMTgzL3BlcmlvZGNlbnRlcmVk L2NlZGlsbGENCi9vbmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXIvb25laGFs Zi90aHJlZXF1YXJ0ZXJzIDE5Mi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4DQovQXRpbGRlL0Fk aWVyZXNpcy9BcmluZy9BRS9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4DQovRWRp ZXJlc2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0aC9OdGlsZGUvT2dy YXZlDQovT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZS9PZGllcmVzaXMvbXVsdGlwbHkvT3NsYXNo L1VncmF2ZS9VYWN1dGUNCi9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlL1Rob3JuL2dlcm1h bmRibHMvYWdyYXZlL2FhY3V0ZS9hY2lyY3VtZmxleA0KL2F0aWxkZS9hZGllcmVzaXMvYXJpbmcv YWUvY2NlZGlsbGEvZWdyYXZlL2VhY3V0ZS9lY2lyY3VtZmxleA0KL2VkaWVyZXNpcy9pZ3JhdmUv aWFjdXRlL2ljaXJjdW1mbGV4L2lkaWVyZXNpcy9ldGgvbnRpbGRlL29ncmF2ZQ0KL29hY3V0ZS9v Y2lyY3VtZmxleC9vdGlsZGUvb2RpZXJlc2lzL2RpdmlkZS9vc2xhc2gvdWdyYXZlL3VhY3V0ZQ0K L3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJlc2lzDQpdDQo+Pg0KZW5k b2JqDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMTAgMCBSDQovUmVzb3VyY2Vz IDMgMCBSDQovQ29udGVudHMgMiAwIFINCi9Sb3RhdGUgOTANCj4+DQplbmRvYmoNCjEwIDAgb2Jq DQo8PA0KL1R5cGUgL1BhZ2VzDQovS2lkcyBbMSAwIFJdDQovQ291bnQgMQ0KL01lZGlhQm94IFsw IDAgNjEyIDc5Ml0NCj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9Q YWdlcyAxMCAwIFINCj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PA0KL0NyZWF0aW9uRGF0ZSAoRDox OTk4MDYwNTEzNDkwOSkNCi9Qcm9kdWNlciAoXDM3NlwzNzdcMDAwQVwwMDBjXDAwMHJcMDAwb1ww MDBiXDAwMGFcMDAwdFwwMDAgXDAwMERcMDAwaVwwMDBzXDAwMHRcMDAwaVwwMDBsXDAwMGxcMDAw ZVwwMDByXDAwMCBcMDAwM1wwMDAuXDAwMDBcMDAwMVwwMDAgXDAwMGZcMDAwb1wwMDByXDAwMCBc MDAwV1wwMDBpXDAwMG5cMDAwZFwwMDBvXDAwMHdcMDAwcykNCi9DcmVhdG9yIChXaW5kb3dzIE5U IDQuMCkNCi9UaXRsZSAoVW50aXRsZWQgRG9jdW1lbnQpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDE1 DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDUxOTIgMDAwMDAgbg0KMDAwMDAwMDAxNyAwMDAw MCBuDQowMDAwMDAzMDc3IDAwMDAwIG4NCjAwMDAwMDM0MzggMDAwMDAgbg0KMDAwMDAwMzUzMSAw MDAwMCBuDQowMDAwMDAzNjIwIDAwMDAwIG4NCjAwMDAwMDM3MTAgMDAwMDAgbg0KMDAwMDAwMzgx OCAwMDAwMCBuDQowMDAwMDAzMzU5IDAwMDAwIG4NCjAwMDAwMDUyOTMgMDAwMDAgbg0KMDAwMDAw MzIyNiAwMDAwMCBuDQowMDAwMDAzOTEzIDAwMDAwIG4NCjAwMDAwMDUzODMgMDAwMDAgbg0KMDAw MDAwNTQ0MCAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgMTUNCi9Sb290IDEzIDAgUg0KL0lu Zm8gMTQgMCBSDQovSUQgWzxiYjYzN2FmNWUyNDliOTg3Y2FiZjBhZGJmMmE5NTI5ND48YmI2Mzdh ZjVlMjQ5Yjk4N2NhYmYwYWRiZjJhOTUyOTQ+XQ0KPj4NCnN0YXJ0eHJlZg0KNTc0Nw0KJSVFT0YN Cg== --Boundary=_0.0_=5030100021410027-- From ipp-owner@pwg.org Fri Jun 5 17:07:51 1998 Delivery-Date: Fri, 05 Jun 1998 17:07:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA18813 for ; Fri, 5 Jun 1998 17:07:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25981 for ; Fri, 5 Jun 1998 17:10:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26065 for ; Fri, 5 Jun 1998 17:07:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 17:03:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25513 for ipp-outgoing; Fri, 5 Jun 1998 16:59:35 -0400 (EDT) Message-Id: <199806052057.QAA24282@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: walker@dazel.com cc: Carl-Uno Manros , Keith Moore , ipp@pwg.org Subject: Re: IPP> ADM - PWG IPP Phone Conference on 980603, 10:00 AM PDT In-reply-to: Your message of "Tue, 02 Jun 1998 08:24:45 CDT." <3573FD1D.E5BAE73A@dazel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jun 1998 16:57:54 -0400 Sender: owner-ipp@pwg.org > I am curious about process at this point. Does Keith's response > represent the official IETF response to the IPP submissions? > In other words, if we respond to and satisfy all of his objections, > do we have RFC's? This is my review of the document. Documents have to be reviewed by the area director before IESG will ballot them. Based on the review, the area director either recommends that IESG approve the documents to be published as RFCs, or sends the document back to the working group requesting further changes before the document goes to IESG. In this case, I've done the latter. Once these changes are made I'll be in a position to recommend that IESG approve the documents. There's no guarantee that the documents will actually be approved - other IESG folks can still object and request further changes - but most of the IESG people will trust the review written by the area director, and either vote "no objection" or request only editorial changes. (For a list of things that frequently hold up RFC approval by IESG, look at draft-iesg-rfc-checklist-00.txt) > If so, then, Keith, do you consider all comments that were submitted > during the last call in forming your opinion/comments? If not, when > do those comments come under consideration? I do not know how many > submitted comments during last call (presumably there were some, but > they probably went directly to the IESG), but it seems to me that all > negative comments out to be considered by someone. I made an attempt to consider all Last Call comments; however, it's possible that I've missed some of them. (Given that Last Call comments are sometimes sent to any of the IESG, the IETF, the ADs, or the WG list, and they don't always have any identifying string that can be used to search an archive, it's difficult for me to be sure that I've found them all.) > I have to be honest and admit that I sent my comments directly to > the IESG (without CC:ing the IPP DL), but I guess I had no idea > that all of this would go into such a black hole for such a long > period of time. If there is interest in discussing comments that > were submitted during the last call, I would consider forwarding > my comments to the list. As long as you're not proposing drastic changes to the protocol, I recommend that you do so. Keith From ipp-owner@pwg.org Fri Jun 5 17:18:01 1998 Delivery-Date: Fri, 05 Jun 1998 17:18:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA19063 for ; Fri, 5 Jun 1998 17:18:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA26026 for ; Fri, 5 Jun 1998 17:20:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26697 for ; Fri, 5 Jun 1998 17:17:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 17:13:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26129 for ipp-outgoing; Fri, 5 Jun 1998 17:11:06 -0400 (EDT) Message-Id: <35785DA7.E7619049@dazel.com> Date: Fri, 05 Jun 1998 16:05:43 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP> Implications of a new scheme, etc References: <5030100021410027000002L072*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Is it true that there is "no impact" on the Servers for the IPP:X (HTTP on the Wire) scenario? I know that there are URI's that a server has to return to the client, so I am just wondering if there is going to be any server problems (because the URI's will have to be presented as IPP:, right?). curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Fri Jun 5 17:27:35 1998 Delivery-Date: Fri, 05 Jun 1998 17:27:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA19204 for ; Fri, 5 Jun 1998 17:27:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA26068 for ; Fri, 5 Jun 1998 17:29:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27298 for ; Fri, 5 Jun 1998 17:27:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 17:23:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26701 for ipp-outgoing; Fri, 5 Jun 1998 17:18:02 -0400 (EDT) Message-Id: <199806052117.RAA24439@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: walker@dazel.com cc: Paul Moore , Keith Moore , ipp@pwg.org Subject: Re: IPP> review of IPP documents In-reply-to: Your message of "Tue, 02 Jun 1998 08:33:13 CDT." <3573FF19.E9AA1FB7@dazel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jun 1998 17:17:40 -0400 Sender: owner-ipp@pwg.org > > Excellent point. So why the heck are we using HTTP for IPP? > > Although one could take this as a facetious response, it always seems > to me be an important question worth asking again. If IPP and others > are approved as standard application protocols built on top of HTTP, > then this is a green flag that HTTP is an acceptable transport for > application protocols. And we will see more. Yes. There's a lot of interest in layering other things over HTTP, for reasons including: mindshare firewall/proxy/NAT compatibility leveraging SSL/TLS ease of prototyping using CGI and/or client libraries However, several different uses of HTTP tend to pull the protocol in several different directions, and potentially use it in ways that conflict with one another. For example, you don't want a request or response header used slightly differently by X-over-http than by Y-over-http, because this might confuse proxies, or require slight tweaks to client libraries. Similarly for use of HTTP error codes by different protocols. And you want to make sure that firewalls can distinguish X from Y. HTTP is already very complex, and having lots of special cases for different protocols doesn't make it any simpler. > So, is the IETF supporting (even encouraging ?) application protocols > to be built using HTTP as a transport? Or are these protocols that > are currently being developed (IPP, WebDAV, etc) just considered test > cases to see if the idea will fly? I see IPP as breaking new ground in this area. Ideally, IETF should have an RFC with guidelines for how to layer protocols on top of HTTP (and TLS), so that future groups won't have to suffer as much as IPP. WebDAV is a special case...because it's basically manipulating web pages, I see it as an extension to the HTTP service rather than a separate protocol layered on top of HTTP. Keith From ipp-owner@pwg.org Fri Jun 5 19:12:47 1998 Delivery-Date: Fri, 05 Jun 1998 19:12:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA19926 for ; Fri, 5 Jun 1998 19:12:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA26394 for ; Fri, 5 Jun 1998 19:15:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA28105 for ; Fri, 5 Jun 1998 19:12:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 19:08:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27540 for ipp-outgoing; Fri, 5 Jun 1998 19:04:17 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE57@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Roger K Debry'" , ipp@pwg.org Subject: RE: IPP> Implications of a new scheme, etc Date: Fri, 5 Jun 1998 16:04:04 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Hi Roger, I've got some comments on this. (I dont imagine your surprised :) For the IPP: (new scheme proposals) I think putting 'no impact' for proxies is 100% inaccurate. a new IPP scheme will break *every* existing Proxy. I challenge the wg to find a proxy which will pass this exception, if one exists. In the case of the new method, most current proxies will be able to handle it with minimal effort, as you indicated, some will handle it as shipped (MSproxy) and some will need a patch. (squid) If this is a holdup for a new method, I volunteer to submit a patch to the squid group to fix this. To use a new scheme means that proxies must understand the IPP protocol inner workings (which means that it has to know that its really just HTTP on the wire). To use a new method means that IPP is a service on HTTP that is identified by its different method (PRINT). > -----Original Message----- > From: Roger K Debry [mailto:rdebry@us.ibm.com] > Sent: Friday, June 05, 1998 1:00 PM > To: ipp@pwg.org > Subject: IPP> Implications of a new scheme, etc > > > As suggested on Wednesday's teleconference, Harry Lewis, > Carl Kugler, and I produced the attached table (in .pdf format) > which hopefully summarizes the many views which have been > expressed on this subject over the last couple of weeks. Our > intent is that this would help support our position with Keith Moore. > > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > From ipp-owner@pwg.org Fri Jun 5 19:57:18 1998 Delivery-Date: Fri, 05 Jun 1998 19:57:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA20065 for ; Fri, 5 Jun 1998 19:57:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA26457 for ; Fri, 5 Jun 1998 19:59:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA28761 for ; Fri, 5 Jun 1998 19:57:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 19:53:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28236 for ipp-outgoing; Fri, 5 Jun 1998 19:49:48 -0400 (EDT) Date: 5 Jun 1998 23:48:12 -0000 Message-ID: <19980605234812.781.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > I used the term endpoint loosley (and I think inconsistently). > > I think we agree in your last but one para (we just prhased it differently). > If we took printer-URI and job-URI out of IPP we would arrive at the > situation we both want. JOB-ID then identifies jobs. > I think we are approaching group consensus on this. I propose that we remove "printer-uri" and "job-uri" as request Operation attributes, but leave them in their special position in the protocol. > With regards to your last point I think you hit a deeper problem: - the IPP > model is over-simple today. We do need a higher level construct in the > receiving agent (printer, server, peripheral, what ever you call it). Having > 'printer' as the highest level is too restrictive. Even LPR allows for a > given transport endpoint to serve multiple named devices. You could say that > each printer has a different URL (or TCP port numher maybe). I thing we need > to be able to do things like enumerate printers (which you canot do with > some high level agent) IPP originally had a Server object in the model. Looking at the archives from March and May 1997, the group consensus apparently was that the Server itself had no important attributes or operations, so didn't need to be an addressable entity in IPP, and so should be removed from the model. Certainly, in the current model, a single software server might support multiple Printers (distinguished, by, e.g., a segment in the "abs_path" of the printer URIs). I agree that there is no way (in IPP) to invoke an operation like Enumerate-Printers on such a server, but the group considered this and decided it wasn't needed. The discussion was pretty spread out, but some of it appears in ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.txt - Carl > > > -----Original Message----- > > From: Carl Kugler [SMTP:kugler@us.ibm.com] > > Sent: Thursday, June 04, 1998 12:27 PM > > To: ipp@pwg.org > > Subject: Re: IPP> Identifying jobs in requests > > > > > It seem to me that the fundamental question comes down to - should > > > the IPP protocol form, transmit and use information that is specific to > > the > > > underlying transport. > > > > > > We have chosen to use URI as our way of identifying endpoints. > > > > Could you define "endpoint" in this context? Is it equivalent to an IPP > > "target"? Or are you using the term in the TCP sense? > > > > >The > > > assumptions we make about these URIs (there actual syntax is irrelevant) > > > are:- > > > a) an agent knows how to form them > > > b) the only thing an agent may do with a URI it receives to it is to > > > pass it to its underlying transport. This means that the creator of the > > URI > > > MUST use the same URI forming convention as that which will be used by > > the > > > receivers transport stack (ie. this is not a private issue for a given > > > implementation). It also means that the receiver may not look at the URI > > to > > > infer any deeper meaning (because that is a private issue for the > > sending > > > implementation). > > > This last restriction made us invent job-id. We moved to explicitly > > > stating in IPP the way of identifying an endpoint. > > > The real problem is that we end up with leakage from the transport > > > up into the IPP layer. I cannot blindly forward requests from > > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and > > change > > > them on the fly. > > > There is another problem that assumpion b causes. It assumes that a > > > printer knows how to form an address (URI) that makes sense in the > > clients > > > transport stack. This is true for HTTP but not true (or certainly > > > non-trivial) for other transports. > > > > > > I would propose that we use an adressing scheme that corresponds to > > > the transport endpoint only. We then specifiy in IPP the ways of > > identifying > > > the logical object that we wish to talk to (printer-ID, Job-ID,...). > > > > > > > Or you could invert this, and put the target addressing outside the IPP > > payload. Then you can forward requests and/or rewrite target addresses > > without ever opening the "envelop", to use Scott's postal analogy. For > > this to work, any internal target identifiers would have to be relative > > (like job-id). > > > > It seems to me that your scheme would require the transport endpoint to be > > some kind of IPP Server that could route requests to Printers based on > > embedded printer-ID. Then you've added another layer of indirection to > > the IPP model. > > From ipp-owner@pwg.org Fri Jun 5 20:07:14 1998 Delivery-Date: Fri, 05 Jun 1998 20:07:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA20133 for ; Fri, 5 Jun 1998 20:07:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26478 for ; Fri, 5 Jun 1998 20:09:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA29396 for ; Fri, 5 Jun 1998 20:07:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 20:03:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA28848 for ipp-outgoing; Fri, 5 Jun 1998 20:00:19 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: IPP> Identifying jobs in requests Date: Fri, 5 Jun 1998 17:00:08 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think we are approaching group consensus on this. I propose that we remove "printer-uri" and "job-uri" as request Operation attributes, but leave them in their special position in the protocol. [Paul Moore] What 'special position'? From ipp-owner@pwg.org Fri Jun 5 20:18:44 1998 Delivery-Date: Fri, 05 Jun 1998 20:18:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA20225 for ; Fri, 5 Jun 1998 20:18:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26490 for ; Fri, 5 Jun 1998 20:21:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA00481 for ; Fri, 5 Jun 1998 20:18:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 20:11:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29126 for ipp-outgoing; Fri, 5 Jun 1998 20:05:11 -0400 (EDT) Date: 6 Jun 1998 00:03:35 -0000 Message-ID: <19980606000335.1497.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Implications of a new scheme, etc In-Reply-To: <8B57882C41A0D1118F7100805F9F68B502D2CE57@red-msg-45.dns.microsoft.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > Hi Roger, > > I've got some comments on this. (I dont imagine your surprised :) > > For the IPP: (new scheme proposals) > I think putting 'no impact' for proxies is 100% inaccurate. > a new IPP scheme will break *every* existing Proxy. I challenge > the wg to find a proxy which will pass this exception, if one exists. Josh, I think you've misread the chart. For the proposal that puts the "ipp:" scheme ON THE WIRE, we listed "Breaks most installed proxies. At best proxies have to be reconfigured". The column that says "No impact" for Proxies is for the Larry's proposal (http://www.findmail.com/list/ipp/3754.html) which is actually HTTP on the wire. (See http://www.findmail.com/list/ipp/3785.html for more info.) -Carl > > In the case of the new method, most current proxies will be > able to handle it with minimal effort, as you indicated, some will > handle it as shipped (MSproxy) and some will need a patch. (squid) > If this is a holdup for a new method, I volunteer to submit > a patch to the squid group to fix this. > > To use a new scheme means that proxies must understand the > IPP protocol inner workings (which means that it has to know > that its really just HTTP on the wire). To use a new > method means that IPP is a service on HTTP that is identified > by its different method (PRINT). > > > > > -----Original Message----- > > From: Roger K Debry [mailto:rdebry@us.ibm.com] > > Sent: Friday, June 05, 1998 1:00 PM > > To: ipp@pwg.org > > Subject: IPP> Implications of a new scheme, etc > > > > > > As suggested on Wednesday's teleconference, Harry Lewis, > > Carl Kugler, and I produced the attached table (in .pdf format) > > which hopefully summarizes the many views which have been > > expressed on this subject over the last couple of weeks. Our > > intent is that this would help support our position with Keith Moore. > > > > > > > > Roger K deBry > > Senior Technical Staff Member > > Architecture and Technology > > IBM Printing Systems > > email: rdebry@us.ibm.com > > phone: 1-303-924-4080 > > > > From ipp-owner@pwg.org Fri Jun 5 20:20:24 1998 Delivery-Date: Fri, 05 Jun 1998 20:20:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA20236 for ; Fri, 5 Jun 1998 20:20:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26494 for ; Fri, 5 Jun 1998 20:22:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA00684 for ; Fri, 5 Jun 1998 20:20:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 20:13:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29482 for ipp-outgoing; Fri, 5 Jun 1998 20:07:57 -0400 (EDT) Date: 6 Jun 1998 00:06:24 -0000 Message-ID: <19980606000624.1644.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > I think we are approaching group consensus on this. I propose that > we remove "printer-uri" and "job-uri" as request Operation attributes, but > leave them in their special position in the protocol. > > [Paul Moore] What 'special position'? > > Quoting from PRO (Internet Printing Protocol/1.0: Protocol Specification): Some attributes are encoded in a special position. These attribute are:  “printer-uri”: When the target is a printer and the transport is HTTP or HTTP (for TLS), the target printer-uri defined in each operation in the IPP model document SHALL be an operation attribute called “printer-uri” and it SHALL also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. This  “job-uri”: When the target is a job and the transport is HTTP or HTTPS (for TLS), the target job-uri of each operation in the IPP model document SHALL be an operation attribute called “job-uri” and it SHALL also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level.  “version-number”: The attribute named “version-number” in the IPP model document SHALL become the “version-number” field in the operation layer request or response. It SHALL NOT appear as an operation attribute.  “operation-id”: The attribute named “operation-id” in the IPP model document SHALL become the “operation-id” field in the operation layer request. It SHALL NOT appear as an operation attribute.  “status-code”: The attribute named “status-code” in the IPP model document SHALL become the “status-code” field in the operation layer response. It SHALL NOT appear as an operation attribute.  “request-id”: The attribute named “request-id” in the IPP model document SHALL become the “request-id” field in the operation layer request or response. It SHALL NOT appear as an operation attribute. From ipp-owner@pwg.org Fri Jun 5 20:30:46 1998 Delivery-Date: Fri, 05 Jun 1998 20:30:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA20304 for ; Fri, 5 Jun 1998 20:30:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA26535 for ; Fri, 5 Jun 1998 20:33:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA01333 for ; Fri, 5 Jun 1998 20:30:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 20:26:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00739 for ipp-outgoing; Fri, 5 Jun 1998 20:20:51 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE59@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: IPP> Implications of a new scheme, etc Date: Fri, 5 Jun 1998 17:20:40 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org ahh ok.. see below > -----Original Message----- > From: Carl Kugler [mailto:kugler@us.ibm.com] > Sent: Friday, June 05, 1998 5:04 PM > To: ipp@pwg.org > Subject: Re: RE: IPP> Implications of a new scheme, etc > > > > Hi Roger, > > > > I've got some comments on this. (I dont imagine your surprised :) > > > > For the IPP: (new scheme proposals) > > I think putting 'no impact' for proxies is 100% inaccurate. > > a new IPP scheme will break *every* existing Proxy. I challenge > > the wg to find a proxy which will pass this exception, if > one exists. > > Josh, I think you've misread the chart. For the proposal > that puts the "ipp:" scheme ON THE WIRE, we listed "Breaks > most installed proxies. At best proxies have to be > reconfigured". Ok, I would make this stronger. It breaks all proxies. It wont be a matter of reconfiguration. No proxy I know of today can process this without a software change. At best, the ipp: scheme will need to mapped to a scheme that the proxy knows about, which these days is one of : http:// ftp:// gopher:// and maybe wais or mailto: > The column that says "No impact" for Proxies > is for the Larry's proposal > (http://www.findmail.com/list/ipp/3754.html) which is > actually HTTP on the wire. (See > http://www.findmail.com/list/ipp/3785.html for > more info.) > I dont think larry's proposal meets the requirement that keith is asking for. Since the client will just map ipp -> http on the wire and the proxy or firewall will see it just as HTTP. This doesnt allow the proxy to differentiate IPP from HTTP in this case, which was what keith seems to be looking for. > -Carl > > > > > In the case of the new method, most current proxies will be > > able to handle it with minimal effort, as you indicated, some will > > handle it as shipped (MSproxy) and some will need a patch. (squid) > > If this is a holdup for a new method, I volunteer to submit > > a patch to the squid group to fix this. > > > > To use a new scheme means that proxies must understand the > > IPP protocol inner workings (which means that it has to know > > that its really just HTTP on the wire). To use a new > > method means that IPP is a service on HTTP that is identified > > by its different method (PRINT). > > > > > > > > > -----Original Message----- > > > From: Roger K Debry [mailto:rdebry@us.ibm.com] > > > Sent: Friday, June 05, 1998 1:00 PM > > > To: ipp@pwg.org > > > Subject: IPP> Implications of a new scheme, etc > > > > > > > > > As suggested on Wednesday's teleconference, Harry Lewis, > > > Carl Kugler, and I produced the attached table (in .pdf format) > > > which hopefully summarizes the many views which have been > > > expressed on this subject over the last couple of weeks. Our > > > intent is that this would help support our position with > Keith Moore. > > > > > > > > > > > > Roger K deBry > > > Senior Technical Staff Member > > > Architecture and Technology > > > IBM Printing Systems > > > email: rdebry@us.ibm.com > > > phone: 1-303-924-4080 > > > > > > > > From ipp-owner@pwg.org Fri Jun 5 21:17:38 1998 Delivery-Date: Fri, 05 Jun 1998 21:17:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA20701 for ; Fri, 5 Jun 1998 21:17:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA26654 for ; Fri, 5 Jun 1998 21:20:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA02069 for ; Fri, 5 Jun 1998 21:17:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 21:13:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01533 for ipp-outgoing; Fri, 5 Jun 1998 21:11:26 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: IPP> Identifying jobs in requests Date: Fri, 5 Jun 1998 18:08:10 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org The two lines refering to printer-uri and job-uri that you included both say that they (the URIs) are operation attributes. Yet you say that you propose that they are no longer operation attributes BUT should still retain their 'special position'. If the only 'special position' is that they are operation attributes then surely this is a contradictory statement. I guess I'm missing someting here. I want them out too - so I think I agree with you. I just want to be sure about what I'm agreeing with. > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Friday, June 05, 1998 5:06 PM > To: ipp@pwg.org > Subject: Re: RE: RE: IPP> Identifying jobs in requests > > > I think we are approaching group consensus on this. I propose that > > we remove "printer-uri" and "job-uri" as request Operation attributes, > but > > leave them in their special position in the protocol. > > > > [Paul Moore] What 'special position'? > > > > > > Quoting from PRO (Internet Printing Protocol/1.0: Protocol Specification): > > Some attributes are encoded in a special position. These attribute are: >  "printer-uri": When the target is a printer and the transport is > HTTP or HTTP (for TLS), the target printer-uri defined in each operation > in the IPP model document SHALL be an operation attribute called > "printer-uri" and it SHALL also be specified outside of the operation > layer as the request-URI on the Request-Line at the HTTP level. This >  "job-uri": When the target is a job and the transport is HTTP or > HTTPS (for TLS), the target job-uri of each operation in the IPP model > document SHALL be an operation attribute called "job-uri" and it SHALL > also be specified outside of the operation layer as the request-URI on > the Request-Line at the HTTP level. >  "version-number": The attribute named "version-number" in the IPP > model document SHALL become the "version-number" field in the operation > layer request or response. It SHALL NOT appear as an operation attribute. >  "operation-id": The attribute named "operation-id" in the IPP > model document SHALL become the "operation-id" field in the operation > layer request. It SHALL NOT appear as an operation attribute. >  "status-code": The attribute named "status-code" in the IPP model > document SHALL become the "status-code" field in the operation layer > response. It SHALL NOT appear as an operation attribute. >  "request-id": The attribute named "request-id" in the IPP model > document SHALL become the "request-id" field in the operation layer > request or response. It SHALL NOT appear as an operation attribute. From ipp-owner@pwg.org Fri Jun 5 23:53:01 1998 Delivery-Date: Fri, 05 Jun 1998 23:53:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA27985 for ; Fri, 5 Jun 1998 23:53:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA26856 for ; Fri, 5 Jun 1998 23:55:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03200 for ; Fri, 5 Jun 1998 23:52:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 5 Jun 1998 23:48:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA02637 for ipp-outgoing; Fri, 5 Jun 1998 23:45:21 -0400 (EDT) Message-Id: <199806060341.UAA13199@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 05 Jun 1998 20:46:10 -0700 To: Paul Moore , "'Carl Kugler'" , ipp@pwg.org From: Robert Herriot Subject: RE: RE: IPP> Identifying jobs in requests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_33814923==_.ALT" Sender: owner-ipp@pwg.org --=====================_33814923==_.ALT Content-Type: text/plain; charset="us-ascii" We agreed recently that the following operation attributes would be ordered. attributes-charset (always first for requests and responses) attributes-natural-language (always second for requests and response) printer-uri or job-uri (always third for requests, though we are discusses whether it should be present) job-id (always fourth for requests if present ) At 05:00 PM 6/5/98 , Paul Moore wrote: > I think we are approaching group consensus on this. I propose that >we remove "printer-uri" and "job-uri" as request Operation attributes, but >leave them in their special position in the protocol. > > [Paul Moore] What 'special position'? > --=====================_33814923==_.ALT Content-Type: text/html; charset="us-ascii" We agreed recently that the following operation attributes would be ordered.
    attributes-charset (always first for requests and responses)
    attributes-natural-language (always second for requests and response)
    printer-uri or job-uri (always third for requests, though we are discusses whether it should be present)
    job-id (always fourth for requests if present )

At 05:00 PM 6/5/98 , Paul Moore wrote:
>       I think we are approaching group consensus on this.  I propose that
>we remove "printer-uri" and "job-uri" as request Operation attributes, but
>leave them in their special position in the protocol. 
>
>       [Paul Moore]  What 'special position'?
>
--=====================_33814923==_.ALT-- From ipp-owner@pwg.org Sat Jun 6 03:14:22 1998 Delivery-Date: Sat, 06 Jun 1998 03:14:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA03192 for ; Sat, 6 Jun 1998 03:14:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA27083 for ; Sat, 6 Jun 1998 03:16:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA04550 for ; Sat, 6 Jun 1998 03:14:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 6 Jun 1998 03:08:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA03979 for ipp-outgoing; Sat, 6 Jun 1998 03:05:02 -0400 (EDT) From: "Larry Masinter" To: , Subject: RE: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers Date: Sat, 6 Jun 1998 00:04:32 PDT Message-ID: <001301bd9119$5ad59a80$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-to: <199806051632.AA21427@interlock2.lexmark.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org In HTTP/1.1, you don't normally send the URL to the server anyway, you only send the path. So for the most part, the HTTP servers don't need to know anything about the URL but the path component of it. The 'transformation' between ipp://xyz.printer.com/printer1 and http://xyz.printer.com:380/printer1 happens in the client (since the client knows about the rest of IPP too, and a client that doesn't know about ipp has nothing to say to the URL anyway), and possibly in the bowels of the IPP server which is generating real URLs for things like jobs and other printers. But the HTTP infrastructure of proxies, HTTP protocol stacks, etc. need not know anything about the URLs at all, I don't think. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Sat Jun 6 12:24:41 1998 Delivery-Date: Sat, 06 Jun 1998 12:24:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA09484 for ; Sat, 6 Jun 1998 12:24:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA27577 for ; Sat, 6 Jun 1998 12:26:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA07095 for ; Sat, 6 Jun 1998 12:24:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 6 Jun 1998 12:13:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA06495 for ipp-outgoing; Sat, 6 Jun 1998 12:09:18 -0400 (EDT) From: "Larry Masinter" To: "Josh Cohen" Cc: "'Carl Kugler'" , Subject: RE: RE: IPP> Implications of a new scheme, etc Date: Sat, 6 Jun 1998 09:08:51 PDT Message-ID: <000201bd9165$6529bb00$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-to: <8B57882C41A0D1118F7100805F9F68B502D2CE59@red-msg-45.dns.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org I'm sorry that what seems to be a simple proposal has been so hard to understand. The CLIENT (the thing that actually implements IPP) gets "ipp://printer.company.com/prt32" as its target. The CLIENT is wanting to print, so it creates some application/ipp stuff that indicates the print job, and sends it to "http://printer.company.com:380/prt32". If it is sending it through a proxy, the proxy sees "http://printer.company.com:380/prt32". Since the proxy only sees "http://printer.company.com:380/prt32", I'm sorry that I've been less than totally clear on this, but it seems so simple that it wouldn't have to require such a lengthy explanation. SCENARIO for client talking to "ipp://printer.company.com/prt32" Step 1: Client creates "application/ipp" data. Step 2: Client translates "ipp://printer.company.com/prt32" to http URL by Step 2a: changing scheme from "ipp" to "http" Step 2b: adding port 380, if IPP URL doesn't contain a port resulting in "http://printer.company.com:380/prt32" Step 3: Client sends data created in Step 1 to URL created in step 2. Step 3a: Request method: the request method is POST Step 3b: Request URI: if a proxy is in use: Step 3b-proxy: the client's HTTP protocol stack will use the entire "http://printer.company.com:380/prt32" URL as the request-URI to the proxy. if no proxy is in use: Step 3b-noproxy: the client's HTTP protocol stack will use "/prt32" as the request-URI in a connection to "printer.company.com" on port 380 Step 3c: Host The "Host" header should contain "printer.company.com:380" corresponding to the HTTP host. Step 3d: Content-Type The content-type should be application/ipp Step 4-proxy: In the case a proxy is being used, this step occurs at the proxy. The proxy receives a request constructed in Step 3, using the request URI constructed in Step 3b-proxy. Note that this request at the proxy appears as "http://printer.company.com:380/prt32". Note that the string "ipp:" does not occur in the request URI. Note that the "Host" header constructed in step 3c is matches the host in the request-URI. Step 4a: the proxy analyzes "http://printer.company.com:380/prt32" and notes that it is a HTTP request to "printer.company.com" on port 380. Step 4b: scheme dispatching The proxy dispatches the request to the HTTP request handler, since the scheme in the request URI is "http" Step 4c: domain name filtering and forwarding The proxy (potentially) consults its forwarding table to decide whether "printer.company.com" on port 380 is an allowed host name for forwarding, based on the domain name or a domain name pattern. The domain name pattern table may or may not contain port numbers. The forwarding table may contain a rewrite rule, e.g., translate all requests to "printer.company.com" on port 380 to requests to "printer.outsourceagency.com" on port 3724. Such forwarding and translation allows services to be redirected without requiring renaming or reprogramming. The forwarding or filtering rule for a given host or host pattern may contain method rules (GET allowed, POST not), which will be used subsequently in step 4e below. Step 4d: IP address filtering & forwarding The proxy looks up the domain name in the HTTP request "printer.company.com" and gets the IP address for it. The proxy (potentially) consults its forwarding table for entries based on IP address, in the same manner as domain names were looked up in step 4c. As in step 4c, the forwarding or filtering rule for a given address or address range may contain method rules which will be used in step 4e. Step 4e: Method filtering The proxy (potentially) examines the method against the allowed methods from the lookup in steps 4c or 4d, and decides whether the forwarding is allowed. Note that generally implementations do not do different forwarding based on method ("if you're POSTing, go to this URL instead"), even though forwarding based on host or path is common. Step 4f: forwarding If filtering in steps 4c-4e have not disallowed the request and the request is not transformed, a HTTP connection is established to "printer.company.com" on port 380, using the request URI "/prt32". Step 5: Origin server The request arrives at the server either directly from the client (step 3b-noproxy) or from the proxy (step 4f). The server sees a request URI of "/prt32" with a HOST header of "printer.company.com:380". I could elaborate further any of these steps or any subsequent steps if it's still not clear how this is supposed to work. However, I sincerely hope I've made it clear how using an "ipp" scheme can work even when a client is connecting through a proxy, and that this does not "break all existing proxies" since in no case does the string "ipp" appear at a evel that the proxy examines. Regards, Larry From ipp-owner@pwg.org Mon Jun 8 08:50:46 1998 Delivery-Date: Mon, 08 Jun 1998 08:50:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA22745 for ; Mon, 8 Jun 1998 08:50:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02258 for ; Mon, 8 Jun 1998 08:53:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA15727 for ; Mon, 8 Jun 1998 08:50:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 08:38:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA14603 for ipp-outgoing; Mon, 8 Jun 1998 08:35:28 -0400 (EDT) From: Roger K Debry To: Cc: Subject: RE: IPP> Implications of a new scheme, etc Message-ID: <5030100021473672000002L022*@MHS> Date: Mon, 8 Jun 1998 08:34:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22745 Josh, I will make the impact statement for IPP on the wire stronger, as you suggest. I think Carl Kugler has pointed out that the HTTP on the wire column is just Larry Masinter's proposal, which I hope you will agree causes no impact to proxies. Since this column does imply a new port number, isn't this enough to distinguish this for firewall purposes? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 joshco@microsoft.com on 06/05/98 05:04:37 PM Please respond to joshco@microsoft.com To: ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus cc: Subject: RE: IPP> Implications of a new scheme, etc Hi Roger, I've got some comments on this. (I dont imagine your surprised :) For the IPP: (new scheme proposals) I think putting 'no impact' for proxies is 100% inaccurate. a new IPP scheme will break *every* existing Proxy. I challenge the wg to find a proxy which will pass this exception, if one exists. In the case of the new method, most current proxies will be able to handle it with minimal effort, as you indicated, some will handle it as shipped (MSproxy) and some will need a patch. (squid) If this is a holdup for a new method, I volunteer to submit a patch to the squid group to fix this. To use a new scheme means that proxies must understand the IPP protocol inner workings (which means that it has to know that its really just HTTP on the wire). To use a new method means that IPP is a service on HTTP that is identified by its different method (PRINT). > -----Original Message----- > From: Roger K Debry [mailto:rdebry@us.ibm.com] > Sent: Friday, June 05, 1998 1:00 PM > To: ipp@pwg.org > Subject: IPP> Implications of a new scheme, etc > > > As suggested on Wednesday's teleconference, Harry Lewis, > Carl Kugler, and I produced the attached table (in .pdf format) > which hopefully summarizes the many views which have been > expressed on this subject over the last couple of weeks. Our > intent is that this would help support our position with Keith Moore. > > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > From ipp-owner@pwg.org Mon Jun 8 08:50:46 1998 Delivery-Date: Mon, 08 Jun 1998 08:50:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA22747 for ; Mon, 8 Jun 1998 08:50:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02260 for ; Mon, 8 Jun 1998 08:53:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA15730 for ; Mon, 8 Jun 1998 08:50:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 08:43:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA14669 for ipp-outgoing; Mon, 8 Jun 1998 08:39:40 -0400 (EDT) From: Roger K Debry To: Cc: Subject: Re: IPP> Implications of a new scheme, etc Message-ID: <5030100021473780000002L002*@MHS> Date: Mon, 8 Jun 1998 08:38:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22747 The inclusion of URLs in IPP responses seems to be the subject of a lot of debate just now. If the outcome of the debate is that they stay in the response, and include the scheme, then there is some impact, but I'd judge it pretty small. Would you agree? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 06/05/98 03:25:13 PM Please respond to walker@dazel.com To: Roger K Debry/Boulder/IBM@ibmus cc: ipp@pwg.org Subject: Re: IPP> Implications of a new scheme, etc Is it true that there is "no impact" on the Servers for the IPP:X (HTTP on the Wire) scenario? I know that there are URI's that a server has to return to the client, so I am just wondering if there is going to be any server problems (because the URI's will have to be presented as IPP:, right?). curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Mon Jun 8 10:48:41 1998 Delivery-Date: Mon, 08 Jun 1998 10:48:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA25965 for ; Mon, 8 Jun 1998 10:48:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02892 for ; Mon, 8 Jun 1998 10:51:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA16500 for ; Mon, 8 Jun 1998 10:48:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 10:43:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15941 for ipp-outgoing; Mon, 8 Jun 1998 10:39:16 -0400 (EDT) Content-return: allowed Date: Mon, 8 Jun 1998 07:38:05 PDT From: "Zehler, Peter " Subject: RE: IPP> Implications of a new scheme, etc To: walker@dazel.com, Roger K Debry Cc: ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org Jim, As I understand it, there are 3 basic "types" of URLs in IPP. 1) externally configured, such as the printer's "printer-uri-supported" 2) internally generated, such as the job's "job-uri" 3) references to objects outside the IPP model, such as the printer's "printer-more-info" As long as we have consistent naming for items 1 and 2 I see no IPP server problem. I assume that the attribute URLs will contain "ipp" as the method. This put the responsibility on the client to translate. For item 3 IPP would not perform any translation. These URLs refer to objects external to the IPP model and must be left as specified. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 -----Original Message----- From: James Walker [SMTP:walker@dazel.com] Sent: Friday, June 05, 1998 5:06 PM To: Roger K Debry Cc: ipp@pwg.org Subject: Re: IPP> Implications of a new scheme, etc Is it true that there is "no impact" on the Servers for the IPP:X (HTTP on the Wire) scenario? I know that there are URI's that a server has to return to the client, so I am just wondering if there is going to be any server problems (because the URI's will have to be presented as IPP:, right?). curious... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Mon Jun 8 11:58:41 1998 Delivery-Date: Mon, 08 Jun 1998 11:58:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA28221 for ; Mon, 8 Jun 1998 11:58:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03318 for ; Mon, 8 Jun 1998 12:01:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA17451 for ; Mon, 8 Jun 1998 11:58:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 11:54:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA16891 for ipp-outgoing; Mon, 8 Jun 1998 11:52:18 -0400 (EDT) Date: 8 Jun 1998 15:50:04 -0000 Message-ID: <19980608155004.30015.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > The two lines refering to printer-uri and job-uri that you included both say > that they (the URIs) are operation attributes. Yet you say that you propose > that they are no longer operation attributes BUT should still retain their > 'special position'. If the only 'special position' is that they are > operation attributes then surely this is a contradictory statement. > No, the "special position" is "outside of the operation layer as the request-URI on the Request-Line at the HTTP level." Currently, PRO says the target SHALL also be an operation attribute. In my proposal, the target SHALL NOT appear as an operation attribute. It is only specified as the HTTP request-URI. > I guess I'm missing someting here. > > I want them out too - so I think I agree with you. I just want to be sure > about what I'm agreeing with. > > > -----Original Message----- > > From: Carl Kugler [SMTP:kugler@us.ibm.com] > > Sent: Friday, June 05, 1998 5:06 PM > > To: ipp@pwg.org > > Subject: Re: RE: RE: IPP> Identifying jobs in requests > > > > > I think we are approaching group consensus on this. I propose that > > > we remove "printer-uri" and "job-uri" as request Operation attributes, > > but > > > leave them in their special position in the protocol. > > > > > > [Paul Moore] What 'special position'? > > > > > > > > > > Quoting from PRO (Internet Printing Protocol/1.0: Protocol Specification): > > > > Some attributes are encoded in a special position. These attribute are:"printer-uri": When the target is a printer and the transport is > > HTTP or HTTP (for TLS), the target printer-uri defined in each operation > > in the IPP model document SHALL be an operation attribute called > > "printer-uri" and it SHALL also be specified outside of the operation > > layer as the request-URI on the Request-Line at the HTTP level. > >  This > >  "job-uri": When the target is a job and the transport is HTTP or > > HTTPS (for TLS), the target job-uri of each operation in the IPP model > > document SHALL be an operation attribute called "job-uri" and it SHALL > > also be specified outside of the operation layer as the request-URI on > > the Request-Line at the HTTP level. > >  "version-number": The attribute named "version-number" in the IPP > > model document SHALL become the "version-number" field in the operation > > layer request or response. It SHALL NOT appear as an operation attribute. > >  "operation-id": The attribute named "operation-id" in the IPP > > model document SHALL become the "operation-id" field in the operation > > layer request. It SHALL NOT appear as an operation attribute. > >  "status-code": The attribute named "status-code" in the IPP model > > document SHALL become the "status-code" field in the operation layer > > response. It SHALL NOT appear as an operation attribute. > >  "request-id": The attribute named "request-id" in the IPP model > > document SHALL become the "request-id" field in the operation layer > > request or response. It SHALL NOT appear as an operation attribute. > > From ipp-owner@pwg.org Mon Jun 8 12:07:51 1998 Delivery-Date: Mon, 08 Jun 1998 12:07:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA28400 for ; Mon, 8 Jun 1998 12:07:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03377 for ; Mon, 8 Jun 1998 12:10:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18037 for ; Mon, 8 Jun 1998 12:07:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 12:04:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17448 for ipp-outgoing; Mon, 8 Jun 1998 11:58:23 -0400 (EDT) Date: 8 Jun 1998 15:55:59 -0000 Message-ID: <19980608155559.30707.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Identifying jobs in requests In-Reply-To: <199806060341.UAA13199@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > --=====================_33814923==_.ALT > Content-Type: text/plain; charset="us-ascii" > > We agreed recently that the following operation attributes would be ordered. > attributes-charset (always first for requests and responses) > attributes-natural-language (always second for requests and response) > printer-uri or job-uri (always third for requests, though we are discusses > whether it should be present) > job-id (always fourth for requests if present ) Agreed, but I am using "special position" in the sense that it was used earlier, in the PRO document, to describe attributes that are outside the normal attribute groups, placed either in the transport layer or in a fixed position in the application/ipp body. > > At 05:00 PM 6/5/98 , Paul Moore wrote: > > I think we are approaching group consensus on this. I propose that > >we remove "printer-uri" and "job-uri" as request Operation attributes, but > >leave them in their special position in the protocol. > > > > [Paul Moore] What 'special position'? > > > > --=====================_33814923==_.ALT > Content-Type: text/html; charset="us-ascii" > > > We agreed recently that the following operation attributes > would be ordered.
>     attributes-charset (always first for requests and > responses)
>     attributes-natural-language (always second for > requests and response)
>     printer-uri or job-uri (always third for requests, > though we are discusses whether it should be present)
>     job-id (always fourth for requests if present )
>
> At 05:00 PM 6/5/98 , Paul Moore wrote:
> >       I think we > are approaching group consensus on this.  I propose that
> >we remove "printer-uri" and "job-uri" as request > Operation attributes, but
> >leave them in their special position in the protocol. 
> >
> >       [Paul > Moore]  What 'special position'?
> >
> > > --=====================_33814923==_.ALT-- > > > From ipp-owner@pwg.org Mon Jun 8 13:48:42 1998 Delivery-Date: Mon, 08 Jun 1998 13:48:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA00143 for ; Mon, 8 Jun 1998 13:48:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03985 for ; Mon, 8 Jun 1998 13:51:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18738 for ; Mon, 8 Jun 1998 13:48:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 13:44:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18196 for ipp-outgoing; Mon, 8 Jun 1998 13:39:24 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 08 Jun 1998 11:38:31 -0600 From: "Scott Isaacson" To: ipp@pwg.org, kugler@us.ibm.com Subject: Re: RE: RE: RE: IPP> Identifying jobs in requests Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00143 Carl has it right: He is correct when he says: > No, the "special position" is "outside of the operation layer as the request-URI on the Request-Line at > the HTTP level." Currently, PRO says the target SHALL also be an operation attribute. > In my proposal, the target SHALL NOT appear as an operation attribute. It is only specified as the > HTTP request-URI. From ipp-owner@pwg.org Mon Jun 8 14:53:41 1998 Delivery-Date: Mon, 08 Jun 1998 14:53:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01488 for ; Mon, 8 Jun 1998 14:53:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04377 for ; Mon, 8 Jun 1998 14:55:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA19427 for ; Mon, 8 Jun 1998 14:53:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 14:44:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA18855 for ipp-outgoing; Mon, 8 Jun 1998 14:42:23 -0400 (EDT) Message-ID: From: Paul Moore To: "'Robert Herriot'" , "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: IPP> Identifying jobs in requests Date: Mon, 8 Jun 1998 11:42:04 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org I obviously missed this one. So 'special position' means that literally. I thought it mean 'special purpose'. For my interest. Why are we putting things in special positions? > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Friday, June 05, 1998 8:46 PM > To: Paul Moore; 'Carl Kugler'; ipp@pwg.org > Subject: RE: RE: IPP> Identifying jobs in requests > > We agreed recently that the following operation attributes would be > ordered. >     attributes-charset (always first for requests and responses) >     attributes-natural-language (always second for requests and response) >     printer-uri or job-uri (always third for requests, though we are > discusses whether it should be present) >     job-id (always fourth for requests if present ) > > At 05:00 PM 6/5/98 , Paul Moore wrote: > >       I think we are approaching group consensus on this.  I propose > that > >we remove "printer-uri" and "job-uri" as request Operation attributes, > but > >leave them in their special position in the protocol.  > > > >       [Paul Moore]  What 'special position'? > > > From ipp-owner@pwg.org Mon Jun 8 16:08:39 1998 Delivery-Date: Mon, 08 Jun 1998 16:08:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02739 for ; Mon, 8 Jun 1998 16:08:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04916 for ; Mon, 8 Jun 1998 16:11:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20164 for ; Mon, 8 Jun 1998 16:08:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 16:04:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19602 for ipp-outgoing; Mon, 8 Jun 1998 15:59:15 -0400 (EDT) Message-Id: <3.0.1.32.19980608125142.0121d1c8@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 8 Jun 1998 12:51:42 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Keith Moore will join telecon, Wed, 6/10, 10-12 PDT (1-3 EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I talked with Keith today and he will call into the telecon to help us understand his comments on the IPP documents and for us to exchange the feedback we've had on the alternatives. PWG IPP Phone Conference on 980610, 10:00 AM PDT ================================================ The purpose will be to discuss the alternatives that we have considered to Keith comments and the feedback that we have received on each. Dial-in Information: Time: June 10, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Tom Hastings, for Carl-Uno (who will be back Tuesday) From ipp-owner@pwg.org Mon Jun 8 16:29:32 1998 Delivery-Date: Mon, 08 Jun 1998 16:29:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03050 for ; Mon, 8 Jun 1998 16:29:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05049 for ; Mon, 8 Jun 1998 16:31:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20822 for ; Mon, 8 Jun 1998 16:29:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 16:22:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20237 for ipp-outgoing; Mon, 8 Jun 1998 16:16:23 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE7E@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Roger K Debry'" Cc: ipp@pwg.org Subject: RE: IPP> Implications of a new scheme, etc Date: Mon, 8 Jun 1998 13:16:13 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Correct me if Im wrong, this is my understanding of that proposal: (from the proxy/firewall perspective) IPP URLS are always to port 380 (or whatever we choose) Proxies and firewalls can filter IPP by enabling or disabling URLS to port 380. ? > -----Original Message----- > From: Roger K Debry [mailto:rdebry@us.ibm.com] > Sent: Monday, June 08, 1998 5:34 AM > To: Josh Cohen > Cc: ipp@pwg.org > Subject: RE: IPP> Implications of a new scheme, etc > > > Josh, > > I will make the impact statement for IPP on the wire stronger, as > you suggest. I think Carl Kugler has pointed out that the HTTP > on the wire column is just Larry Masinter's proposal, which I > hope you will agree causes no impact to proxies. Since this > column does imply a new port number, isn't this enough to > distinguish this for firewall purposes? > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 > > > > joshco@microsoft.com on 06/05/98 05:04:37 PM > Please respond to joshco@microsoft.com > To: ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus > cc: > Subject: RE: IPP> Implications of a new scheme, etc > > > Hi Roger, > > I've got some comments on this. (I dont imagine your surprised :) > > For the IPP: (new scheme proposals) > I think putting 'no impact' for proxies is 100% inaccurate. > a new IPP scheme will break *every* existing Proxy. I challenge > the wg to find a proxy which will pass this exception, if one exists. > > In the case of the new method, most current proxies will be > able to handle it with minimal effort, as you indicated, some will > handle it as shipped (MSproxy) and some will need a patch. (squid) > If this is a holdup for a new method, I volunteer to submit > a patch to the squid group to fix this. > > To use a new scheme means that proxies must understand the > IPP protocol inner workings (which means that it has to know > that its really just HTTP on the wire). To use a new > method means that IPP is a service on HTTP that is identified > by its different method (PRINT). > > > > > -----Original Message----- > > From: Roger K Debry [mailto:rdebry@us.ibm.com] > > Sent: Friday, June 05, 1998 1:00 PM > > To: ipp@pwg.org > > Subject: IPP> Implications of a new scheme, etc > > > > > > As suggested on Wednesday's teleconference, Harry Lewis, > > Carl Kugler, and I produced the attached table (in .pdf format) > > which hopefully summarizes the many views which have been > > expressed on this subject over the last couple of weeks. Our > > intent is that this would help support our position with > Keith Moore. > > > > > > > > Roger K deBry > > Senior Technical Staff Member > > Architecture and Technology > > IBM Printing Systems > > email: rdebry@us.ibm.com > > phone: 1-303-924-4080 > > > > > > From ipp-owner@pwg.org Mon Jun 8 16:48:20 1998 Delivery-Date: Mon, 08 Jun 1998 16:48:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03381 for ; Mon, 8 Jun 1998 16:48:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05174 for ; Mon, 8 Jun 1998 16:50:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21997 for ; Mon, 8 Jun 1998 16:48:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 16:37:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20798 for ipp-outgoing; Mon, 8 Jun 1998 16:29:01 -0400 (EDT) Message-ID: From: Paul Moore To: "'Robert Herriot'" , "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: IPP> Identifying jobs in requests Date: Mon, 8 Jun 1998 13:28:18 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think that there is a difference between meta-level things like charset and language and real attributes like job-id. I think we should pull all URIs from the IPP model. The only place they should appear in in the (non-existant) 'IPP on HTTP implementation rules'. This is the only way we can make transport independance work > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Monday, June 08, 1998 1:24 PM > To: Paul Moore; 'Robert Herriot'; 'Carl Kugler'; ipp@pwg.org > Subject: RE: RE: IPP> Identifying jobs in requests > > Charset clearly needs to be at the beginning so that a receiving process > knows how to decode string fields before it encounters any of them.  The > charset field is a string field, but the names are all ASCII so the > decoding > need not be known for the class of encodings that IPP support. BTW, XML > puts > charset at the beginning for the same reason. > > Natural language is the next most important value because it specifies the > > language of any text or name field.  Processing is easier if the implicit > language is known at the time a text or name field is encountered. XML has > > similar rules for language. > > The printer-uri/job-uri/job-id should be easy to find if it not in the > enclosing layer.  For HTTP, the position of the target isn't important > because the target is redundant. The position would be important for a > transport where the target is specified only in IPP layer. > > So that's the reasoning. Do you agree? > > Bob Herriot > > At 11:42 AM 6/8/98 , Paul Moore wrote: > >I obviously missed this one. So 'special position' means that literally. > I > >thought it mean 'special purpose'. > > > >For my interest. Why are we putting things in special positions? > > > >> -----Original Message----- > >> From:        Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > >> Sent:        Friday, June 05, 1998 8:46 PM > >> To:  Paul Moore; 'Carl Kugler'; ipp@pwg.org > >> Subject:     RE: RE: IPP> Identifying jobs in requests > >> > >> We agreed recently that the following operation attributes would be > >> ordered. > >>     attributes-charset (always first for requests and responses) > >>     attributes-natural-language (always second for requests and > response) > >>     printer-uri or job-uri (always third for requests, though we are > >> discusses whether it should be present) > >>     job-id (always fourth for requests if present ) > >> > >> At 05:00 PM 6/5/98 , Paul Moore wrote: > >> >       I think we are approaching group consensus on this.  I propose > >> that > >> >we remove "printer-uri" and "job-uri" as request Operation attributes, > >> but > >> >leave them in their special position in the protocol.  > >> > > >> >       [Paul Moore]  What 'special position'? > >> > > >> > > > From ipp-owner@pwg.org Mon Jun 8 16:48:23 1998 Delivery-Date: Mon, 08 Jun 1998 16:48:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03389 for ; Mon, 8 Jun 1998 16:48:23 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05177 for ; Mon, 8 Jun 1998 16:50:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21994 for ; Mon, 8 Jun 1998 16:48:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 16:32:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA20442 for ipp-outgoing; Mon, 8 Jun 1998 16:23:47 -0400 (EDT) Message-Id: <199806082019.NAA15354@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 08 Jun 1998 13:24:08 -0700 To: Paul Moore , "'Robert Herriot'" , "'Carl Kugler'" , ipp@pwg.org From: Robert Herriot Subject: RE: RE: IPP> Identifying jobs in requests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_6796152==_.ALT" Sender: owner-ipp@pwg.org --=====================_6796152==_.ALT Content-Type: text/plain; charset="us-ascii" Charset clearly needs to be at the beginning so that a receiving process knows how to decode string fields before it encounters any of them. The charset field is a string field, but the names are all ASCII so the decoding need not be known for the class of encodings that IPP support. BTW, XML puts charset at the beginning for the same reason. Natural language is the next most important value because it specifies the language of any text or name field. Processing is easier if the implicit language is known at the time a text or name field is encountered. XML has similar rules for language. The printer-uri/job-uri/job-id should be easy to find if it not in the enclosing layer. For HTTP, the position of the target isn't important because the target is redundant. The position would be important for a transport where the target is specified only in IPP layer. So that's the reasoning. Do you agree? Bob Herriot At 11:42 AM 6/8/98 , Paul Moore wrote: >I obviously missed this one. So 'special position' means that literally. I >thought it mean 'special purpose'. > >For my interest. Why are we putting things in special positions? > >> -----Original Message----- >> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] >> Sent: Friday, June 05, 1998 8:46 PM >> To: Paul Moore; 'Carl Kugler'; ipp@pwg.org >> Subject: RE: RE: IPP> Identifying jobs in requests >> >> We agreed recently that the following operation attributes would be >> ordered. >> attributes-charset (always first for requests and responses) >> attributes-natural-language (always second for requests and response) >> printer-uri or job-uri (always third for requests, though we are >> discusses whether it should be present) >> job-id (always fourth for requests if present ) >> >> At 05:00 PM 6/5/98 , Paul Moore wrote: >> > I think we are approaching group consensus on this. I propose >> that >> >we remove "printer-uri" and "job-uri" as request Operation attributes, >> but >> >leave them in their special position in the protocol. >> > >> > [Paul Moore] What 'special position'? >> > >> > --=====================_6796152==_.ALT Content-Type: text/html; charset="us-ascii" Charset clearly needs to be at the beginning so that a receiving process
knows how to decode string fields before it encounters any of them.  The
charset field is a string field, but the names are all ASCII so the decoding
need not be known for the class of encodings that IPP support. BTW, XML puts
charset at the beginning for the same reason.

Natural language is the next most important value because it specifies the
language of any text or name field.  Processing is easier if the implicit
language is known at the time a text or name field is encountered. XML has
similar rules for language.

The printer-uri/job-uri/job-id should be easy to find if it not in the
enclosing layer.  For HTTP, the position of the target isn't important
because the target is redundant. The position would be important for a
transport where the target is specified only in IPP layer.

So that's the reasoning. Do you agree?

Bob Herriot

At 11:42 AM 6/8/98 , Paul Moore wrote:
>I obviously missed this one. So 'special position' means that literally. I
>thought it mean 'special purpose'.
>
>For my interest. Why are we putting things in special positions?
>
>> -----Original Message-----
>> From:        Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
>> Sent:        Friday, June 05, 1998 8:46 PM
>> To:  Paul Moore; 'Carl Kugler'; ipp@pwg.org
>> Subject:     RE: RE: IPP> Identifying jobs in requests
>>
>> We agreed recently that the following operation attributes would be
>> ordered.
>>     attributes-charset (always first for requests and responses)
>>     attributes-natural-language (always second for requests and response)
>>     printer-uri or job-uri (always third for requests, though we are
>> discusses whether it should be present)
>>     job-id (always fourth for requests if present )
>>
>> At 05:00 PM 6/5/98 , Paul Moore wrote:
>> >       I think we are approaching group consensus on this.  I propose
>> that
>> >we remove "printer-uri" and "job-uri" as request Operation attributes,
>> but
>> >leave them in their special position in the protocol. 
>> >
>> >       [Paul Moore]  What 'special position'?
>> >
>>
>
--=====================_6796152==_.ALT-- From ipp-owner@pwg.org Mon Jun 8 17:46:27 1998 Delivery-Date: Mon, 08 Jun 1998 17:46:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04083 for ; Mon, 8 Jun 1998 17:46:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05582 for ; Mon, 8 Jun 1998 17:48:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22852 for ; Mon, 8 Jun 1998 17:46:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 17:39:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22294 for ipp-outgoing; Mon, 8 Jun 1998 17:38:04 -0400 (EDT) Date: 8 Jun 1998 21:35:39 -0000 Message-ID: <19980608213539.7910.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Identifying jobs in requests In-Reply-To: <199806082019.NAA15354@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > --=====================_6796152==_.ALT > Content-Type: text/plain; charset="us-ascii" > > Charset clearly needs to be at the beginning so that a receiving process > knows how to decode string fields before it encounters any of them. That depends on your implementation. But I don't object to putting charset up front. > The > charset field is a string field, but the names are all ASCII so the decoding > need not be known for the class of encodings that IPP support. BTW, XML puts > charset at the beginning for the same reason. > > Natural language is the next most important value because it specifies the > language of any text or name field. Processing is easier if the implicit > language is known at the time a text or name field is encountered. XML has > similar rules for language. I'm curious about what kind of processing is easier. On the Printer side, natural language seems irrelevant except for deciding what language to respond in (for Printer-generated text). On the client side I guess it's used to decide whether text runs right-to-left or top-to-bottom? Are we expecting to see clients supporting multiple languages simultaneously; mixing up various text flows to present, say, the results of a Get-Jobs operation? > > The printer-uri/job-uri/job-id should be easy to find if it not in the > enclosing layer. For HTTP, the position of the target isn't important > because the target is redundant. The position would be important for a > transport where the target is specified only in IPP layer. Do we really need to provide for a future IPP-specific transport? Is it likely that one will be created? If so, since it would be IPP-specific anyway, couldn't we still put the target in the transport layer? > > So that's the reasoning. Do you agree? > > Bob Herriot > > At 11:42 AM 6/8/98 , Paul Moore wrote: > >I obviously missed this one. So 'special position' means that literally. I > >thought it mean 'special purpose'. > > > >For my interest. Why are we putting things in special positions? > > > >> -----Original Message----- > >> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > >> Sent: Friday, June 05, 1998 8:46 PM > >> To: Paul Moore; 'Carl Kugler'; ipp@pwg.org > >> Subject: RE: RE: IPP> Identifying jobs in requests > >> > >> We agreed recently that the following operation attributes would be > >> ordered. > >> attributes-charset (always first for requests and responses) > >> attributes-natural-language (always second for requests and response) > >> printer-uri or job-uri (always third for requests, though we are > >> discusses whether it should be present) > >> job-id (always fourth for requests if present ) > >> > >> At 05:00 PM 6/5/98 , Paul Moore wrote: > >> > I think we are approaching group consensus on this. I propose > >> that > >> >we remove "printer-uri" and "job-uri" as request Operation attributes, > >> but > >> >leave them in their special position in the protocol. > >> > > >> > [Paul Moore] What 'special position'? > >> > > >> > > > > --=====================_6796152==_.ALT > Content-Type: text/html; charset="us-ascii" > > > Charset clearly needs to be at the beginning so that a > receiving process
> knows how to decode string fields before it encounters any of them.  > The
> charset field is a string field, but the names are all ASCII so the > decoding
> need not be known for the class of encodings that IPP support. BTW, XML > puts
> charset at the beginning for the same reason.
>
> Natural language is the next most important value because it specifies > the
> language of any text or name field.  Processing is easier if the > implicit
> language is known at the time a text or name field is encountered. XML > has
> similar rules for language.
>
> The printer-uri/job-uri/job-id should be easy to find if it not in the >
> enclosing layer.  For HTTP, the position of the target isn't > important
> because the target is redundant. The position would be important for a >
> transport where the target is specified only in IPP layer.
>
> So that's the reasoning. Do you agree?
>
> Bob Herriot
>
> At 11:42 AM 6/8/98 , Paul Moore wrote:
> >I obviously missed this one. So 'special position' means that > literally. I
> >thought it mean 'special purpose'.
> >
> >For my interest. Why are we putting things in special > positions?
> >
> >> -----Original Message-----
> >> > From:        Robert > Herriot [SMTP:robert.herriot@Eng.Sun.COM]
> >> > Sent:        Friday, > June 05, 1998 8:46 PM
> >> To:  Paul Moore; 'Carl Kugler'; > ipp@pwg.org
> >> Subject:     RE: RE: > IPP> Identifying jobs in requests
> >>
> >> We agreed recently that the following operation attributes would > be
> >> ordered.
> >>     attributes-charset (always first for > requests and responses)
> >>     attributes-natural-language (always > second for requests and response)
> >>     printer-uri or job-uri (always third for > requests, though we are
> >> discusses whether it should be present)
> >>     job-id (always fourth for requests if > present )
> >>
> >> At 05:00 PM 6/5/98 , Paul Moore wrote:
> >> >       I think we are > approaching group consensus on this.  I propose
> >> that
> >> >we remove "printer-uri" and "job-uri" as > request Operation attributes,
> >> but
> >> >leave them in their special position in the protocol.  >
> >> >
> >> >       [Paul Moore]  What > 'special position'?
> >> >
> >>
> >
> > > --=====================_6796152==_.ALT-- > > > From ipp-owner@pwg.org Mon Jun 8 19:19:59 1998 Delivery-Date: Mon, 08 Jun 1998 19:20:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA04607 for ; Mon, 8 Jun 1998 19:19:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06049 for ; Mon, 8 Jun 1998 19:22:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA23769 for ; Mon, 8 Jun 1998 19:19:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 8 Jun 1998 19:14:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23223 for ipp-outgoing; Mon, 8 Jun 1998 19:11:48 -0400 (EDT) Date: 8 Jun 1998 23:09:33 -0000 Message-ID: <19980608230933.16073.qmail@m2.findmail.com> From: "Carl Kugler" Subject: IPP> MOD> "document-format-supported" To: ipp@pwg.org Sender: owner-ipp@pwg.org A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me to the conclusion that the value of "document-format-supported" in a Get-Printer-Attributes Response will always be either: a) a parroting back of the "document-format" supplied in the Request or b) the Printer's "document-format-default" depending on whether or not the client supplied "document-format" in the Request. Am I reading this correctly? -Carl From ipp-owner@pwg.org Tue Jun 9 12:39:02 1998 Delivery-Date: Tue, 09 Jun 1998 12:39:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA26663 for ; Tue, 9 Jun 1998 12:39:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08978 for ; Tue, 9 Jun 1998 12:41:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA00661 for ; Tue, 9 Jun 1998 12:38:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 12:34:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA00076 for ipp-outgoing; Tue, 9 Jun 1998 12:33:05 -0400 (EDT) Message-Id: <3.0.1.32.19980609092835.01123990@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Jun 1998 09:28:35 PDT To: Carl Kugler From: Tom Hastings Subject: Re: IPP> MOD> 'naturalLanguage' Cc: In-Reply-To: <5030100020678059000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 13:10 05/19/1998 PDT, Carl Kugler wrote: >MOD says: >'naturalLanguage' >The 'naturalLanguage' attribute syntax is a standard identifier for a natural >language and optionally a country. The values for this syntax type are taken >from RFC 1766 [RFC1766]... Examples include: >'en': for English >'en-us': for US English >'fr': for French >'de': for German > >but RFC1766 doesn't give values; it only describes a language tag. Are the >values actually given by ISO 639? Yes. RFC 1766 refers to ISO 639. > > -Carl Kugler > > From ipp-owner@pwg.org Tue Jun 9 12:44:36 1998 Delivery-Date: Tue, 09 Jun 1998 12:44:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA26767 for ; Tue, 9 Jun 1998 12:44:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA09037 for ; Tue, 9 Jun 1998 12:46:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA01328 for ; Tue, 9 Jun 1998 12:44:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 12:40:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA00066 for ipp-outgoing; Tue, 9 Jun 1998 12:28:55 -0400 (EDT) Message-Id: <3.0.5.32.19980609092651.00cfbeb0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 9 Jun 1998 09:26:51 PDT To: Keith Moore From: Carl-Uno Manros Subject: Re: IPP> Re: Implications of introducing new scheme and port Cc: ipp@pwg.org, masinter@parc.xerox.com In-Reply-To: <199806051901.PAA23525@spot.cs.utk.edu> 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: owner-ipp@pwg.org Keith, Thanks for your clarification. Sorry that I have muddied the waters by interpreting your comment differently. Carl-Uno At 12:01 PM 6/5/98 PDT, Keith Moore wrote: >> My understanding is that Keith is trying to dictate that IPP CANNOT USE >> "http" - full stop. > >No, that's not quite what I meant. > >What I am "trying to dictate" is that IPP traffic must be easily >distinguishable from HTTP traffic, so that it can be filtered (or not) >according to a site's security policy. My suggestion to use a >different default port was an attempt to acheive this, with the fewest >possible changes to the current IPP protocol. > > >IETF has traditionally used well-known port numbers to distinguish >between different services. To follow this pattern, IPP should not >use port 80 as a default, because that port is reserved to HTTP. > >And in my mind this pretty much implies that a new "ipp" URI prefix is >needed to refer to printers and print jobs so that the port number >doesn't have to be explicitly specified. This doesn't necessarily >mean that "http" cannot also be used (and doing this might be useful >to tunnel through proxies that understand http: but not ipp:) but >sometimes it's a Bad Idea to have two ways to name the same thing. >(What happens if you make a request to an ipp: object? Will you get >back references to ipp: objects? or might they use the http: scheme?) > >Note that while some changes might be necessary for IPP protocol >elements (using ipp: URLs instead of http: URLs) I would not expect >any changes to the HTTP layer itself. > > > >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 From ipp-owner@pwg.org Tue Jun 9 13:03:18 1998 Delivery-Date: Tue, 09 Jun 1998 13:03:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27239 for ; Tue, 9 Jun 1998 13:03:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09178 for ; Tue, 9 Jun 1998 13:05:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA02036 for ; Tue, 9 Jun 1998 13:03:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 12:59:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01486 for ipp-outgoing; Tue, 9 Jun 1998 12:54:22 -0400 (EDT) Message-Id: <3.0.5.32.19980609095145.0128d500@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 9 Jun 1998 09:51:45 PDT To: Josh Cohen , Carl-Uno Manros , ipp@pwg.org From: Carl-Uno Manros Subject: IPP> RE: MOD - What is a Firewall? In-Reply-To: <8B57882C41A0D1118F7100805F9F68B503E2BA35@red-msg-45.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 09:38 PM 6/5/98 PDT, Josh Cohen wrote: > > >> -----Original Message----- >> From: Carl-Uno Manros [mailto:carl@manros.com] >> Sent: Friday, June 05, 1998 11:51 AM >> To: http-wg@cuckoo.hpl.hp.com >> Subject: MOD - What is a Firewall? >> >> >> 1) Host address TCP/IP address >> 2) Port number Default 80 for HTTP >> 3) Protocol "http" for HTTP >> 4) Method POST etc. for HTTP >> 5) Content HTML etc. >> >Lets add a level, so its: > > 1) Host address TCP/IP address > 2) Port number Default 80 for HTTP > 3) Protocol "http" for HTTP > 4) Method POST etc. for HTTP > 5) Content-type text/HTML etc. > 6) content body filtering (Firewall/proxy attempts to parse the IPP body) > >I wasnt sure if you meant for 5 to be my 5 or 6. >Its much easier to filter by the http header content-type: than >to parse the body and try to filter that way, although both can >technically be done. > >Some proxies can filter the body content, it can, for example, >strip unwanted HTML tags like embedded scripts or Java references. >Though it is possible in these products, the task of parsing >the bodies is such a performance hit, virtually no one uses it >and proxy implementors tend to stick to the guideline that proxies >do not parse the entity-body in HTTP. >(At least the implementors I worked with) > What I intended at 5), was that the first few bytes of the content is read, which in most cases is enough to determine the kind of content that follows. It would be a really bad idea to try to read the WHOLE content. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 9 15:20:39 1998 Delivery-Date: Tue, 09 Jun 1998 15:20:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29226 for ; Tue, 9 Jun 1998 15:20:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10142 for ; Tue, 9 Jun 1998 15:22:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA03079 for ; Tue, 9 Jun 1998 15:20:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 15:09:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA02494 for ipp-outgoing; Tue, 9 Jun 1998 15:08:07 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CE9B@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Carl-Uno Manros'" , Carl-Uno Manros , ipp@pwg.org Subject: RE: IPP> RE: MOD - What is a Firewall? Date: Tue, 9 Jun 1998 12:07:19 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org > > What I intended at 5), was that the first few bytes of the content > is read, which in most cases is enough to determine the kind of > content that follows. It would be a really bad idea to try to read the > WHOLE content. > I agree, reading the whole content is 'bad', but it is being done today. (tag filtering) So, I think its important to distinguish filtering by content-type (the header) and entity body based filtering (like tag filtering). Content-type filtering doesnt necessarily imply parsing the body, but could include the sniffing of the first few bytes. Sounds like the way unix does things with /etc/magic. The final part, tag filtering, is when the proxy parses and presumably understands the content type. So, a proxy might see text/html, then invoke an html parser to complete the filtering. This very expensive and likely to be resisted by admins, however it is being used today in certain cases where it is justified. From ipp-owner@pwg.org Tue Jun 9 15:40:49 1998 Delivery-Date: Tue, 09 Jun 1998 15:40:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29772 for ; Tue, 9 Jun 1998 15:40:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10397 for ; Tue, 9 Jun 1998 15:43:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04000 for ; Tue, 9 Jun 1998 15:40:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 15:34:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03161 for ipp-outgoing; Tue, 9 Jun 1998 15:30:37 -0400 (EDT) Message-Id: <199806091928.PAA23882@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , ipp@pwg.org, masinter@parc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: Implications of introducing new scheme and port In-reply-to: Your message of "Tue, 09 Jun 1998 09:26:51 PDT." <3.0.5.32.19980609092651.00cfbeb0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jun 1998 15:28:26 -0400 Sender: owner-ipp@pwg.org I've been thinking about the interaction of an ipp: URL and the installed base of proxies that support http: but will not understand ipp: Whenever an IPP client is configured to use a proxy, it would probably make sense to have the client send "POST http://foo.bar:XXX/zot HTTP/1.1" to the proxy when attempting to talk to the ipp object "ipp://foo.bar/zot". As far as I can tell from a very casual analysis, this is the only place where it would be necessary to actually send the string "http:" to refer to a ipp object. Every other URI that refers to a ipp object could use "ipp:" instead. I don't see a problem with doing things this way, as long as it's clearly documented. Perhaps it would be wise to add a section called something like "Tunneling of IPP requests over HTTP proxies" to the protocol document that specified such details. Keith From ipp-owner@pwg.org Tue Jun 9 15:43:20 1998 Delivery-Date: Tue, 09 Jun 1998 15:43:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29819 for ; Tue, 9 Jun 1998 15:43:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10418 for ; Tue, 9 Jun 1998 15:45:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04303 for ; Tue, 9 Jun 1998 15:43:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 15:36:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03145 for ipp-outgoing; Tue, 9 Jun 1998 15:25:44 -0400 (EDT) Message-Id: <199806091921.MAA17269@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 09 Jun 1998 12:26:36 -0700 To: "Carl Kugler" , ipp@pwg.org From: Robert Herriot Subject: Re: IPP> MOD> "document-format-supported" In-Reply-To: <19980608230933.16073.qmail@m2.findmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_3129239==_.ALT" Sender: owner-ipp@pwg.org --=====================_3129239==_.ALT Content-Type: text/plain; charset="us-ascii" The value of document-format-supported should be all document-formats supported and its value should not be affected by the document-format operation attribute. Otherwise, how does a client determine what document-formats the printer supports. The document-format attribute should affect other printer attributes returned. Perhaps the model document needs some clarification in this area. Bob Herriot At 04:09 PM 6/8/98 , Carl Kugler wrote: >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me to the conclusion that the value of "document-format-supported" in a Get-Printer-Attributes Response will always be either: > >a) a parroting back of the "document-format" supplied in the Request > >or > >b) the Printer's "document-format-default" > >depending on whether or not the client supplied "document-format" in the Request. Am I reading this correctly? > > -Carl > --=====================_3129239==_.ALT Content-Type: text/html; charset="us-ascii" The value of document-format-supported should be all document-formats
supported and its value should not be affected by the document-format
operation attribute. Otherwise, how does a client determine what
document-formats the printer supports. The document-format attribute should
affect other printer attributes returned. Perhaps the model document needs
some clarification in this area.


Bob Herriot



At 04:09 PM 6/8/98 , Carl Kugler wrote:
>A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me to the conclusion that the value of "document-format-supported" in a Get-Printer-Attributes Response will always be either:
>
>a)  a parroting back of the "document-format" supplied in the Request
>
>or
>
>b) the Printer's "document-format-default"
>
>depending on whether or not the client supplied "document-format" in the Request.  Am I reading this correctly?
>
>    -Carl
>
--=====================_3129239==_.ALT-- From ipp-owner@pwg.org Tue Jun 9 15:48:53 1998 Delivery-Date: Tue, 09 Jun 1998 15:48:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29858 for ; Tue, 9 Jun 1998 15:48:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10436 for ; Tue, 9 Jun 1998 15:51:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04951 for ; Tue, 9 Jun 1998 15:48:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 15:44:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04085 for ipp-outgoing; Tue, 9 Jun 1998 15:41:26 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CEA7@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Keith Moore'" , Carl-Uno Manros Cc: ipp@pwg.org, masinter@parc.xerox.com Subject: RE: IPP> Re: Implications of introducing new scheme and port Date: Tue, 9 Jun 1998 12:40:46 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org so then would the advice that we give to proxy admins to filter/allow IPP to watch for URLs on port XXX ? > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, June 09, 1998 12:28 PM > To: Carl-Uno Manros > Cc: Keith Moore; ipp@pwg.org; masinter@parc.xerox.com; > moore@cs.utk.edu > Subject: Re: IPP> Re: Implications of introducing new scheme and port > > > I've been thinking about the interaction of an ipp: URL and > the installed base of proxies that support http: but will not > understand ipp: > > Whenever an IPP client is configured to use a proxy, it would probably > make sense to have the client send > "POST http://foo.bar:XXX/zot HTTP/1.1" to the proxy when attempting > to talk to the ipp object "ipp://foo.bar/zot". > > As far as I can tell from a very casual analysis, this is the only > place where it would be necessary to actually send the string "http:" > to refer to a ipp object. Every other URI that refers to a ipp object > could use "ipp:" instead. > > I don't see a problem with doing things this way, as long as it's > clearly documented. Perhaps it would be wise to add a section called > something like "Tunneling of IPP requests over HTTP proxies" to the > protocol document that specified such details. > > Keith > > > From ipp-owner@pwg.org Tue Jun 9 15:59:02 1998 Delivery-Date: Tue, 09 Jun 1998 15:59:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29963 for ; Tue, 9 Jun 1998 15:59:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10486 for ; Tue, 9 Jun 1998 16:01:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05593 for ; Tue, 9 Jun 1998 15:58:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 15:54:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05012 for ipp-outgoing; Tue, 9 Jun 1998 15:50:21 -0400 (EDT) Message-Id: <199806091948.PAA24021@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Josh Cohen cc: "'Keith Moore'" , Carl-Uno Manros , ipp@pwg.org, masinter@parc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: Implications of introducing new scheme and port In-reply-to: Your message of "Tue, 09 Jun 1998 12:40:46 PDT." <8B57882C41A0D1118F7100805F9F68B502D2CEA7@red-msg-45.dns.microsoft.com> Date: Tue, 09 Jun 1998 15:48:44 -0400 Sender: owner-ipp@pwg.org > so then would the advice that we give > to proxy admins to filter/allow IPP to > watch for URLs on port XXX ? In my example, XXX is the reserved IPP port. So if the admins want to block outgoing IPP traffic, they tell their routers or firewalls to not transmit requests to anything on port XXX. Of course, anyone with an HTTP server on port XXX will be unreachable from behind such a firewall, and the filter won't block access to IPP servers on other ports. But that's an inherent limitation of firewalls - they can't really filter out all unwanted traffic, they can only filter out most of it. As long as IPP is run on a separate port, I'm pretty ambivalent about PRINT vs. POST. Keith From ipp-owner@pwg.org Tue Jun 9 16:14:20 1998 Delivery-Date: Tue, 09 Jun 1998 16:14:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00231 for ; Tue, 9 Jun 1998 16:14:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10566 for ; Tue, 9 Jun 1998 16:16:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06231 for ; Tue, 9 Jun 1998 16:14:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 16:09:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05663 for ipp-outgoing; Tue, 9 Jun 1998 16:05:52 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CEAC@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Keith Moore'" Cc: Carl-Uno Manros , ipp@pwg.org, masinter@parc.xerox.com Subject: RE: IPP> Re: Implications of introducing new scheme and port Date: Tue, 9 Jun 1998 13:05:41 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > Of course, anyone with an HTTP server on port XXX will be unreachable > from behind such a firewall, and the filter won't block access to IPP > servers on other ports. But that's an inherent limitation of > firewalls - > they can't really filter out all unwanted traffic, they can > only filter > out most of it. > Its only an inherent limitation of firewalls/proxies if you limit them to filtering based on TCP port. Todays proxies and firewalls can do so much more if we just let them. IPP is a service, protocol, or whatever we call it that "runs on top of " HTTP as a transport, substrate,layer or whatever we call that. Instead of setting up IPP to be filtered at the HTTP level, we're asking it to be filtered at the TCP level, which is two levels down. Its like we're creating a new instance of HTTP on port XXX which is underneath IPP called HTTPI.. We're claiming that its a different HTTP than the HTTP that runs on port 80. I'll mention again my RPC analogy. New RPC protocols allow themselves to be filtered by using the semantics (program no) of RPC. An intelligent RPC proxy or firewall knows to recognize the different RPC protocols (NFS,NIS) by looking at the RPC information such as program no. To move this analogy into what we're saying, its like we're saying that for NXS (a new RPC based file share protocol), you run a new portmapper on a port other than 111, lets say on port YYY. Now firewalls filter based on this port instead of the perfectly reasonable program no. (I think we're going to create a mess that will make firewall/proxies lives harder instead of easier) Basic HTTP provides GET a uri PUT a uri (and others) A proxy can filter different actions effectively without ever needing to look beyond the HTTP layer by looking at the method. Why cant PRINT a uri fit right into this simple model with a PRINT method? > As long as IPP is run on a separate port, I'm pretty ambivalent > about PRINT vs. POST. > > Keith > From ipp-owner@pwg.org Tue Jun 9 16:20:06 1998 Delivery-Date: Tue, 09 Jun 1998 16:20:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00319 for ; Tue, 9 Jun 1998 16:20:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10593 for ; Tue, 9 Jun 1998 16:22:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06844 for ; Tue, 9 Jun 1998 16:20:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 16:15:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05980 for ipp-outgoing; Tue, 9 Jun 1998 16:11:57 -0400 (EDT) Message-Id: <3.0.5.32.19980609131008.00bd0cc0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 9 Jun 1998 13:10:08 PDT To: Keith Moore , Josh Cohen From: Carl-Uno Manros Subject: Re: IPP> Re: Implications of introducing new scheme and port Cc: ipp@pwg.org, masinter@parc.xerox.com In-Reply-To: <199806091948.PAA24021@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 12:48 PM 6/9/98 PDT, Keith Moore wrote: >> so then would the advice that we give >> to proxy admins to filter/allow IPP to >> watch for URLs on port XXX ? > >In my example, XXX is the reserved IPP port. So if the admins want to >block outgoing IPP traffic, they tell their routers or firewalls to >not transmit requests to anything on port XXX. > >Of course, anyone with an HTTP server on port XXX will be unreachable >from behind such a firewall, and the filter won't block access to IPP >servers on other ports. But that's an inherent limitation of firewalls - >they can't really filter out all unwanted traffic, they can only filter >out most of it. > >As long as IPP is run on a separate port, I'm pretty ambivalent >about PRINT vs. POST. > >Keith > Keith, I assume in this discussion that port XXX is the DEFAULT port for IPP, but as in other schemes, you can override it by specifying an explicit port number in the URL, including port 80. Is this understanding correct, and if so does it open a way for people to still go around the new IPP port number definition? The administrator could always set up the IPP Printer to ignore anything that does not come in over port XXX. If we go down the IPP port lane, I think we need to specify that new IPP Printers should come out of the box pre-configured to the IPP default port. The biggest problem security admins have is that people just take new equipment out of the box, plug them in, and if it works, never try to reconfigure them. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 9 16:24:59 1998 Delivery-Date: Tue, 09 Jun 1998 16:24:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00359 for ; Tue, 9 Jun 1998 16:24:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10613 for ; Tue, 9 Jun 1998 16:27:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07462 for ; Tue, 9 Jun 1998 16:24:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 16:20:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06250 for ipp-outgoing; Tue, 9 Jun 1998 16:14:35 -0400 (EDT) Message-Id: <199806092012.QAA24292@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Josh Cohen cc: "'Keith Moore'" , Carl-Uno Manros , ipp@pwg.org, masinter@parc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: Implications of introducing new scheme and port In-reply-to: Your message of "Tue, 09 Jun 1998 13:05:41 PDT." <8B57882C41A0D1118F7100805F9F68B502D2CEAC@red-msg-45.dns.microsoft.com> Date: Tue, 09 Jun 1998 16:12:56 -0400 Sender: owner-ipp@pwg.org > > Of course, anyone with an HTTP server on port XXX will be unreachable > > from behind such a firewall, and the filter won't block access to IPP > > servers on other ports. But that's an inherent limitation of > > firewalls - > > they can't really filter out all unwanted traffic, they can > > only filter > > out most of it. > > > Its only an inherent limitation of firewalls/proxies if you > limit them to filtering based on TCP port. I see your point, but I'm not going to insist that IPP use PRINT instead of POST. My position is that this is for the working group to decide; and I'm prepared to defend the WG's decision to IESG. Keith From ipp-owner@pwg.org Tue Jun 9 16:33:32 1998 Delivery-Date: Tue, 09 Jun 1998 16:33:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00489 for ; Tue, 9 Jun 1998 16:33:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10637 for ; Tue, 9 Jun 1998 16:35:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08061 for ; Tue, 9 Jun 1998 16:33:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 16:29:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07390 for ipp-outgoing; Tue, 9 Jun 1998 16:24:23 -0400 (EDT) Message-Id: <199806092022.QAA24336@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , Josh Cohen , ipp@pwg.org, masinter@parc.xerox.com, moore@cs.utk.edu Subject: Re: IPP> Re: Implications of introducing new scheme and port In-reply-to: Your message of "Tue, 09 Jun 1998 13:10:08 PDT." <3.0.5.32.19980609131008.00bd0cc0@garfield> Date: Tue, 09 Jun 1998 16:22:45 -0400 Sender: owner-ipp@pwg.org > If we go down the IPP port lane, I think we need to specify that new > IPP Printers should come out of the box pre-configured to the IPP > default port. I agree. Keith From ipp-owner@pwg.org Tue Jun 9 16:43:19 1998 Delivery-Date: Tue, 09 Jun 1998 16:43:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA00544 for ; Tue, 9 Jun 1998 16:43:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA10684 for ; Tue, 9 Jun 1998 16:45:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08686 for ; Tue, 9 Jun 1998 16:43:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 16:39:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07547 for ipp-outgoing; Tue, 9 Jun 1998 16:29:23 -0400 (EDT) Message-Id: <3.0.5.32.19980609132718.009b5bb0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 9 Jun 1998 13:27:18 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Implication table in TEXT format Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id NAA05113 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00544 All, To make sure we are not leaving anybody out, here is a text version of the Table that Roger deBry et al. produced and earlier sent to the DL as an PDF attachment. Thanks to Roger for this additional version. Carl-Uno -- IPP - Implications of New Port Number and Scheme Assertion: When we began the IPP work we had general agreement that one major objective of our work would be to define a protocol that could be quickly deployed in customer’s enterprises, using existing infrastructure. That is, we did not want to have IPP deployment depend upon the development and widespread deployment by our customers, of a new generation of Web servers, proxies, or firewalls. The following table attempts to summarize discussion on this topic on the IPP distribution list. Key: HTTP:80(Post) means HTTP on port 80, using Post HTTP:X(Post) means a new port for IPP, using Post IPP:X-HTTP means a new port for IPP, using IPP as the scheme name, but still using HTTP on the wire IPP:X-IPP means a new port number and scheme, and using the IPP scheme on the wire. HTTP:80(Print) means defining a new HTTP Print method on port 80 Clients: HTTP:80(Post) - no impact HTTP:X(Post) - no impact IPP:X-HTTP - Minimal impact IPP:X-IPP - Minimal impact HTTP:80(Print) - Minimal impact Servers: HTTP:80(Post)- no impact HTTP:X(Post) - no impact, most servers can listen to multiple ports. HTTP:X-HTTP - no impact HTTP:X-IPP - minimal imapct HTTP:80(Post) - Minimal impact - may be some Web servers make this more difficult than others Proxies: HTTP:80(Post) - no impact HTTP:X(Post) - no impact IPP:X-HTTP - no impact IPP:X-IPP - breaks existing proxies HTTP:80(Print) - breaks some installed proxies Firewalls: HTTP:80(Post) - Can reconfigure to block inbound traffic, based on IP address. May be now way to block outbound traffic. HTTP:X(Post) - Can reconfigure to block inbound traffic based on IP address, or inbound and outbound based on port number IPP:X-HTTP - Can reconfigure to block inbound traffic, based on IP address. May be now way to block outbound traffic IPP:X-IPP - breaks many installed firewalls. At best, firewalls have to be reconfigured. HTTP:80(Print)- Most firewalls do not do method inspection. Breaks some existing firewalls. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 9 17:56:13 1998 Delivery-Date: Tue, 09 Jun 1998 17:56:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01199 for ; Tue, 9 Jun 1998 17:56:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11100 for ; Tue, 9 Jun 1998 17:58:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09589 for ; Tue, 9 Jun 1998 17:56:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 17:51:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08853 for ipp-outgoing; Tue, 9 Jun 1998 17:47:39 -0400 (EDT) Date: 9 Jun 1998 21:47:23 -0000 Message-ID: <19980609214723.7252.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD> "document-format-supported" In-Reply-To: <199806091921.MAA17269@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > --=====================_3129239==_.ALT > Content-Type: text/plain; charset="us-ascii" > > The value of document-format-supported should be all document-formats > supported and its value should not be affected by the document-format > operation attribute. Otherwise, how does a client determine what > document-formats the printer supports. The document-format attribute should > affect other printer attributes returned. Perhaps the model document needs > some clarification in this area. > Okay, that's reasonable. But your reading is a little like saying "application/vnd.hp-PCL" is a supported document-format value for "text/plain" Jobs. So what we have here is a Printer Description Attribute (PDA) which is invariant with respect to document-format. Are there other PDAs that should be considered invariant? printer-name? printer-state? printer-is-accepting-jobs? pdl-override-supported? color-supported? Or can these be considered attributes of a particular interpreter in a Printer? Maybe only Printer Job Template attributes are a function of document-format? > > Bob Herriot > -Carl > > > At 04:09 PM 6/8/98 , Carl Kugler wrote: > >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me to the > conclusion that the value of "document-format-supported" in a > Get-Printer-Attributes Response will always be either: > > > >a) a parroting back of the "document-format" supplied in the Request > > > >or > > > >b) the Printer's "document-format-default" > > > >depending on whether or not the client supplied "document-format" in the > Request. Am I reading this correctly? > > > > -Carl > > > > --=====================_3129239==_.ALT > Content-Type: text/html; charset="us-ascii" > > > The value of document-format-supported should be all > document-formats
> supported and its value should not be affected by the document-format >
> operation attribute. Otherwise, how does a client determine what
> document-formats the printer supports. The document-format attribute > should
> affect other printer attributes returned. Perhaps the model document > needs
> some clarification in this area.
>
>
> Bob Herriot
>
>
>
> At 04:09 PM 6/8/98 , Carl Kugler wrote:
> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads > me to the conclusion that the value of > "document-format-supported" in a Get-Printer-Attributes > Response will always be either:
> >
> >a)  a parroting back of the "document-format" supplied > in the Request
> >
> >or
> >
> >b) the Printer's "document-format-default"
> >
> >depending on whether or not the client supplied > "document-format" in the Request.  Am I reading this > correctly?
> >
> >    -Carl
> >
> > > --=====================_3129239==_.ALT-- > > > From ipp-owner@pwg.org Tue Jun 9 18:18:29 1998 Delivery-Date: Tue, 09 Jun 1998 18:18:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01512 for ; Tue, 9 Jun 1998 18:18:29 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA11187 for ; Tue, 9 Jun 1998 18:20:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10221 for ; Tue, 9 Jun 1998 18:18:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 18:14:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA09690 for ipp-outgoing; Tue, 9 Jun 1998 18:13:03 -0400 (EDT) Date: 9 Jun 1998 22:12:51 -0000 Message-ID: <19980609221251.9567.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org > I think that there is a difference between meta-level things like charset > and language and real attributes like job-id. > > I think we should pull all URIs from the IPP model. The only place they > should appear in in the (non-existant) 'IPP on HTTP implementation rules'. That's a bigger change that what I'm proposing. I'm for leaving them in responses, to indicate printer-uri-supported, uri-security-supported, job-uri, job-printer-uri, and for print by reference. In a response you're supplying a reference to be used as a target in future operations. That's different than telling the target what the target is, which is what happens when we embed targets in requests. > > This is the only way we can make transport independance work Uniform Resource Identifiers (URI) can be used on many different transports (though not all transports). But IPP is the Internet Printing Protocol, so I think identifying resources by network location (URL) is reasonable. > > > > -----Original Message----- > > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > > Sent: Monday, June 08, 1998 1:24 PM > > To: Paul Moore; 'Robert Herriot'; 'Carl Kugler'; ipp@pwg.org > > Subject: RE: RE: IPP> Identifying jobs in requests > > > > Charset clearly needs to be at the beginning so that a receiving process > > knows how to decode string fields before it encounters any of them.  The > > charset field is a string field, but the names are all ASCII so the > > decoding > > need not be known for the class of encodings that IPP support. BTW, XML > > puts > > charset at the beginning for the same reason. > > > > Natural language is the next most important value because it specifies the > > > > language of any text or name field.  Processing is easier if the implicit > > language is known at the time a text or name field is encountered. XML has > > > > similar rules for language. > > > > The printer-uri/job-uri/job-id should be easy to find if it not in the > > enclosing layer.  For HTTP, the position of the target isn't important > > because the target is redundant. The position would be important for a > > transport where the target is specified only in IPP layer. > > > > So that's the reasoning. Do you agree? > > > > Bob Herriot > > > > At 11:42 AM 6/8/98 , Paul Moore wrote: > > >I obviously missed this one. So 'special position' means that literally. > > I > > >thought it mean 'special purpose'. > > > > > >For my interest. Why are we putting things in special positions? > > > > > >> -----Original Message----- > > >> From:        Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > > >> Sent:        Friday, June 05, 1998 8:46 PM > > >> To:  Paul Moore; 'Carl Kugler'; ipp@pwg.org > > >> Subject:     RE: RE: IPP> Identifying jobs in requests > > >> > > >> We agreed recently that the following operation attributes would be > > >> ordered. > > >>     attributes-charset (always first for requests and responses) > > >>     attributes-natural-language (always second for requests and > > response) > > >>     printer-uri or job-uri (always third for requests, though we are > > >> discusses whether it should be present) > > >>     job-id (always fourth for requests if present ) > > >> > > >> At 05:00 PM 6/5/98 , Paul Moore wrote: > > >> >       I think we are approaching group consensus on this.  I propose > > >> that > > >> >we remove "printer-uri" and "job-uri" as request Operation attributes, > > >> but > > >> >leave them in their special position in the protocol.  > > >> > > > >> >       [Paul Moore]  What 'special position'? > > >> > > > >> > > > > > > > From ipp-owner@pwg.org Tue Jun 9 18:48:37 1998 Delivery-Date: Tue, 09 Jun 1998 18:48:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01816 for ; Tue, 9 Jun 1998 18:48:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA11326 for ; Tue, 9 Jun 1998 18:50:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA11103 for ; Tue, 9 Jun 1998 18:48:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 18:44:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10568 for ipp-outgoing; Tue, 9 Jun 1998 18:40:28 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: IPP> Identifying jobs in requests Date: Tue, 9 Jun 1998 15:40:12 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > -----Original Message----- > From: Carl Kugler [SMTP:kugler@us.ibm.com] > Sent: Tuesday, June 09, 1998 3:13 PM > To: ipp@pwg.org > Subject: Re: RE: RE: IPP> Identifying jobs in requests > > > I think that there is a difference between meta-level things like > charset > > and language and real attributes like job-id. > > > > I think we should pull all URIs from the IPP model. The only place they > > should appear in in the (non-existant) 'IPP on HTTP implementation > rules'. > > That's a bigger change that what I'm proposing. I'm for leaving them in > responses, to indicate printer-uri-supported, uri-security-supported, > job-uri, job-printer-uri, and for print by reference. In a response > you're supplying a reference to be used as a target in future operations. > That's different than telling the target what the target is, which is what > happens when we embed targets in requests. [Paul Moore] Actually telling the target what the target is not the main issue (it is , I agree, redundant). In fact my understanding is that the printer-URI is not sent as an attribute in , say, a createjob request. Rather the URI is implicit in the request (since the command arrives at the right place). The real issue is that the reference generated by the printer (job-URI) must make sense in the address space of the client (so that it can use it). This works well for some adressing schemes but not for others. > > > > This is the only way we can make transport independance work > > Uniform Resource Identifiers (URI) can be used on many different > transports (though not all transports). But IPP is the Internet Printing > Protocol, so I think identifying resources by network location (URL) is > reasonable. [Paul Moore] Aha - so you are in the 'let there be IPP for Internet and something else for other scenarios' camp. There is also, I am sure you are aware, the 'IPP is just a convenient name, lets use it on all transports' camp. > > From ipp-owner@pwg.org Tue Jun 9 19:54:16 1998 Delivery-Date: Tue, 09 Jun 1998 19:54:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02065 for ; Tue, 9 Jun 1998 19:54:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11525 for ; Tue, 9 Jun 1998 19:56:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA11991 for ; Tue, 9 Jun 1998 19:54:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 19:49:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11439 for ipp-outgoing; Tue, 9 Jun 1998 19:44:43 -0400 (EDT) Date: 9 Jun 1998 23:44:31 -0000 Message-ID: <19980609234431.18415.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org Paul Moore wrote: > > > > > > I think that there is a difference between meta-level things like > > charset > > > and language and real attributes like job-id. > > > > > > I think we should pull all URIs from the IPP model. The only place they > > > should appear in in the (non-existant) 'IPP on HTTP implementation > > rules'. > > > > That's a bigger change that what I'm proposing. I'm for leaving them in > > responses, to indicate printer-uri-supported, uri-security-supported, > > job-uri, job-printer-uri, and for print by reference. In a response > > you're supplying a reference to be used as a target in future operations. > > That's different than telling the target what the target is, which is what > > happens when we embed targets in requests. > [Paul Moore] Actually telling the target what the target is not the > main issue (it is , I agree, redundant). In fact my understanding is that > the printer-URI is not sent as an attribute in , say, a createjob request. Currently, "printer-uri" is a MANDATORY Operation Attribute of the Create-Job operation (see section 15.3.4.3 Validate the presence of a single occurrence of required Operation attributes). > Rather the URI is implicit in the request (since the command arrives at the > right place). The real issue is that the reference generated by the printer > (job-URI) must make sense in the address space of the client (so that it can > use it). This works well for some adressing schemes but not for others. > > > > > > This is the only way we can make transport independance work > > > > Uniform Resource Identifiers (URI) can be used on many different > > transports (though not all transports). But IPP is the Internet Printing > > Protocol, so I think identifying resources by network location (URL) is > > reasonable. > [Paul Moore] Aha - so you are in the 'let there be IPP for Internet > and something else for other scenarios' camp. There is also, I am sure you > are aware, the 'IPP is just a convenient name, lets use it on all > transports' camp. Well, there's also the PWG's Server to Device Protocol (SDP) to cover another class of transports. > > > > > From ipp-owner@pwg.org Tue Jun 9 20:23:52 1998 Delivery-Date: Tue, 09 Jun 1998 20:23:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02186 for ; Tue, 9 Jun 1998 20:23:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11578 for ; Tue, 9 Jun 1998 20:26:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA12627 for ; Tue, 9 Jun 1998 20:23:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 20:19:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA12071 for ipp-outgoing; Tue, 9 Jun 1998 20:17:48 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Date: Tue, 9 Jun 1998 17:17:39 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Currently, "printer-uri" is a MANDATORY Operation Attribute of the Create-Job operation (see section 15.3.4.3 Validate the presence of a single occurrence of required Operation attributes). [Paul Moore] My reading of this was that it was a 'virtual' attribute. You were not expected to encode it in the IPP packet. This is the same way that the creatjob request does not encode the user name (it can choose to do) rather the user is inferred from the transport. From ipp-owner@pwg.org Tue Jun 9 21:13:55 1998 Delivery-Date: Tue, 09 Jun 1998 21:13:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02637 for ; Tue, 9 Jun 1998 21:13:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA11676 for ; Tue, 9 Jun 1998 21:16:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA13282 for ; Tue, 9 Jun 1998 21:13:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 21:09:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA12729 for ipp-outgoing; Tue, 9 Jun 1998 21:03:53 -0400 (EDT) Message-Id: <3.0.1.32.19980609175923.0111fc08@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 9 Jun 1998 17:59:23 PDT To: Paul Moore From: Tom Hastings Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Cc: "'Carl Kugler'" , ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 17:17 06/09/1998 PDT, Paul Moore wrote: > Currently, "printer-uri" is a MANDATORY Operation Attribute of the >Create-Job operation (see section 15.3.4.3 Validate the presence of a single >occurrence of required Operation attributes). > > [Paul Moore] My reading of this was that it was a 'virtual' >attribute. You were not expected to encode it in the IPP packet. This is the >same way that the creatjob request does not encode the user name (it can >choose to do) rather the user is inferred from the transport. I think that originally "printer-uri" was going to be a "virtual" attribute, as you thought. But later (last Fall?) we changed the Model and Protocol document so that the "printer-uri" attribute was required to be supplied by the client and include in the operation attribute group in the IPP packet (which is defined by the application/ipp MIME type). The thinking was that we wanted the IPP packet and MIME type to be independent of the transport. So that we could send IPP over any transport, such as SMTP or FTP, for examples. (BTW, the Protocol examples forgot to make the change to include the "printer-uri", so maybe that is part of the reason you think that "printer-uri" is not needed in the Operation Attributes group in the IPP packet.) See Section 3.1.3 Operation Targets in the Model: The operation target is a MANDATORY operation attribute that MUST by included in every operation request. (The updated Model in 3.1.4 Operation Targets goes further so require that the Operation Targets come right after the char-set and natural-language in the Operation attributes group). See also Section 15.3.4.3, which does not have an "*" next to "printer-uri" meaning that the client MUST supply it in the operation request. So if we change our minds back to not putting the "printer-uri" target in the IPP layer packet, we need to change the Model and the Protocol documents. Tom From ipp-owner@pwg.org Tue Jun 9 21:23:27 1998 Delivery-Date: Tue, 09 Jun 1998 21:23:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02672 for ; Tue, 9 Jun 1998 21:23:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA11695 for ; Tue, 9 Jun 1998 21:25:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA13863 for ; Tue, 9 Jun 1998 21:23:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 21:19:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA13325 for ipp-outgoing; Tue, 9 Jun 1998 21:14:15 -0400 (EDT) Message-ID: From: Paul Moore To: "'Tom Hastings'" Cc: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Date: Tue, 9 Jun 1998 18:13:55 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think that originally "printer-uri" was going to be a "virtual" attribute, as you thought. But later (last Fall?) we changed the Model and Protocol document so that the "printer-uri" attribute was required to be supplied by the client and include in the operation attribute group in the IPP packet (which is defined by the application/ipp MIME type). The thinking was that we wanted the IPP packet and MIME type to be independent of the transport. So that we could send IPP over any transport, such as SMTP or FTP, for examples. OK. So we are saying that the URIs IN the protocol are NOT to be used as transport adresses. They are in effect opaque cookies that the client must do nothing with except send them back to the printer. They are really job-name and printer-name. Either that or we explicitly state that these fields only make sense in an HTTP-enabled environment (they cannot therefore be mandatory for a universal protocol). From ipp-owner@pwg.org Tue Jun 9 23:28:38 1998 Delivery-Date: Tue, 09 Jun 1998 23:28:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA09552 for ; Tue, 9 Jun 1998 23:28:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA11960 for ; Tue, 9 Jun 1998 23:30:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA14681 for ; Tue, 9 Jun 1998 23:28:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 23:24:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA14163 for ipp-outgoing; Tue, 9 Jun 1998 23:22:37 -0400 (EDT) Message-Id: <199806100309.UAA24470@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 09 Jun 1998 20:13:26 -0700 To: Paul Moore , "'Tom Hastings'" From: Randy Turner Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Cc: "'Carl Kugler'" , ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 06:13 PM 6/9/98 -0700, Paul Moore wrote: > I think that originally "printer-uri" was going to be a "virtual" >attribute, > as you thought. But later (last Fall?) we changed the Model and >Protocol > document so that the "printer-uri" attribute was required to be >supplied > by the client and include in the operation attribute group in the >IPP packet > (which is defined by the application/ipp MIME type). The thinking > was that we wanted the IPP packet and MIME type to be independent > of the transport. So that we could send IPP over any transport, >such > as SMTP or FTP, for examples. > >OK. So we are saying that the URIs IN the protocol are NOT to be used as >transport adresses. They are in effect opaque cookies that the client must >do nothing with except send them back to the printer. They are really >job-name and printer-name. Either that or we explicitly state that these >fields only make sense in an HTTP-enabled environment (they cannot therefore >be mandatory for a universal protocol). > No, the URI is actually a URL that is to be interpreted according to "standard" rules for interpreting URLs (not sure if there is a "formal" standard for this). These resource identifiers are not opaque to clients. This does not mean that we are NOT transport independent, it only means we are identifying resources that must be accessed via the transport (scheme) that is specified in the URL. Since we have "modeled" IPP using URI/URL resource identifiers, all transports used by IPP should have a URL scheme defined. I don't think this is a negative constraint BTW. I consider our selection of URL strings as resource identifiers one of the more compact and powerful capabilities of the model (and protocol). The only problem we have identified so far is what happens when "http" is used as the scheme for IPP resources, and between the client and the resource, there is one or more proxies involved. Note, that this is a problem only in the case of HTTP as the transport. For reference purposes, can someone restate the problem (actually the scenario) with proxies that we are trying to address. I think some solutions that have recently hit the list are bordering on "throwing the baby out with the bath water". Any concrete scenario examples would be much appreciated, as I am still on the learning curve with HTTP proxy behavior. Thanks Randy From ipp-owner@pwg.org Tue Jun 9 23:49:28 1998 Delivery-Date: Tue, 09 Jun 1998 23:49:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA10083 for ; Tue, 9 Jun 1998 23:49:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA12006 for ; Tue, 9 Jun 1998 23:51:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA15409 for ; Tue, 9 Jun 1998 23:49:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 9 Jun 1998 23:44:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA14803 for ipp-outgoing; Tue, 9 Jun 1998 23:42:28 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CED0@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Randy Turner'" , Paul Moore , "'Tom Hastings'" Cc: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Date: Tue, 9 Jun 1998 20:42:12 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > -----Original Message----- > From: Randy Turner [mailto:rturner@sharplabs.com] > Sent: Tuesday, June 09, 1998 8:13 PM > To: Paul Moore; 'Tom Hastings' > Cc: 'Carl Kugler'; ipp@pwg.org > Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests > > For reference purposes, can someone restate the problem (actually the > scenario) with proxies that we are trying to address. I think some > solutions that have recently hit the list are bordering on > "throwing the > baby out with the bath water". Any concrete scenario examples > would be much > appreciated, as I am still on the learning curve with HTTP > proxy behavior. > When a proxy is deployed as part of a gateway, firewall or other security system, one of its responsibilities is to filter and allow or reject certain transactions across a network or organizational boundary in either direction. The issue is that the proxy should be able to understand enough information to decide wether to allow or reject that request's passage. When given an IPP URL such as http://server/printer/queue, it has no way of differentiating this from a typical web browser's form submission. Since form submission and print job submission and or printer control are different in terms of the anticipated functionality that the firewall admin allowed (by allowing POST http requests ), the admin should be able to allow one and not the other. The real world case is a firewall/proxy administrator who sets a policy which allows POST because his intent is to allow "simple web access", which form submission is a part of. Lets say in this case that he is willing to allow simple web access, but he is not interested in allowing IPP functionality, ie print job submission and printer control. At the time IPP went to last call, the specification was to use POST with an http URL. This did not meet the goal of allowing a proxy server administrator to recognize the request as an IPP request instead of a form submission. Keith has come back with the request to somehow make IPP requests identifiable as different from simple http POST form submissions. Numerous suggestions have been made, as referenced by carl-uno's recent posts of the table. From ipp-owner@pwg.org Wed Jun 10 00:18:35 1998 Delivery-Date: Wed, 10 Jun 1998 00:18:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA10195 for ; Wed, 10 Jun 1998 00:18:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12096 for ; Wed, 10 Jun 1998 00:20:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA16007 for ; Wed, 10 Jun 1998 00:18:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 00:14:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA15485 for ipp-outgoing; Wed, 10 Jun 1998 00:10:20 -0400 (EDT) Date: 10 Jun 1998 04:10:01 -0000 Message-ID: <19980610041001.15171.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: <199806100309.UAA24470@slafw.enet.sharplabs.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > At 06:13 PM 6/9/98 -0700, Paul Moore wrote: > > I think that originally "printer-uri" was going to be a "virtual" > >attribute, > > as you thought. But later (last Fall?) we changed the Model and > >Protocol > > document so that the "printer-uri" attribute was required to be > >supplied > > by the client and include in the operation attribute group in the > >IPP packet > > (which is defined by the application/ipp MIME type). The thinking > > was that we wanted the IPP packet and MIME type to be independent > > of the transport. So that we could send IPP over any transport, > >such > > as SMTP or FTP, for examples. > > > >OK. So we are saying that the URIs IN the protocol are NOT to be used as > >transport adresses. They are in effect opaque cookies that the client must > >do nothing with except send them back to the printer. They are really > >job-name and printer-name. Either that or we explicitly state that these > >fields only make sense in an HTTP-enabled environment (they cannot therefore > >be mandatory for a universal protocol). > > > > No, the URI is actually a URL that is to be interpreted according to > "standard" rules for interpreting URLs (not sure if there is a "formal" > standard for this). These resource identifiers are not opaque to clients. > This does not mean that we are NOT transport independent, it only means we > are identifying resources that must be accessed via the transport (scheme) > that is specified in the URL. Since we have "modeled" IPP using URI/URL > resource identifiers, all transports used by IPP should have a URL scheme > defined. I don't think this is a negative constraint BTW. I consider our > selection of URL strings as resource identifiers one of the more compact > and powerful capabilities of the model (and protocol). > > The only problem we have identified so far is what happens when "http" is > used as the scheme for IPP resources, and between the client and the > resource, there is one or more proxies involved. Note, that this is a > problem only in the case of HTTP as the transport. > Another problem is that PRO requires the HTTP Request-URI and the target URI (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're talking to a proxy. And proxies rewrite the Request-URI. > For reference purposes, can someone restate the problem (actually the > scenario) with proxies that we are trying to address. I think some > solutions that have recently hit the list are bordering on "throwing the > baby out with the bath water". Any concrete scenario examples would be much > appreciated, as I am still on the learning curve with HTTP proxy behavior. > > Thanks > > Randy > > > > From ipp-owner@pwg.org Wed Jun 10 01:39:28 1998 Delivery-Date: Wed, 10 Jun 1998 01:39:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA16164 for ; Wed, 10 Jun 1998 01:39:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA12221 for ; Wed, 10 Jun 1998 01:41:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA16809 for ; Wed, 10 Jun 1998 01:39:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 01:34:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA16247 for ipp-outgoing; Wed, 10 Jun 1998 01:31:00 -0400 (EDT) Message-Id: <199806100522.WAA24766@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 09 Jun 1998 22:27:03 -0700 To: "Carl Kugler" From: Randy Turner Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requests Cc: ipp@pwg.org In-Reply-To: <19980610041001.15171.qmail@m2.findmail.com> References: <199806100309.UAA24470@slafw.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Carl, Concerning your earlier message about relative URIs... I noticed in RFC 2068 the following text: To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. Is there any way we could use this to our advantage? Randy At 04:10 AM 6/10/98 +0000, Carl Kugler wrote: >> At 06:13 PM 6/9/98 -0700, Paul Moore wrote: >> > I think that originally "printer-uri" was going to be a "virtual" >> >attribute, >> > as you thought. But later (last Fall?) we changed the Model and >> >Protocol >> > document so that the "printer-uri" attribute was required to be >> >supplied >> > by the client and include in the operation attribute group in the >> >IPP packet >> > (which is defined by the application/ipp MIME type). The thinking >> > was that we wanted the IPP packet and MIME type to be independent >> > of the transport. So that we could send IPP over any transport, >> >such >> > as SMTP or FTP, for examples. >> > >> >OK. So we are saying that the URIs IN the protocol are NOT to be used as >> >transport adresses. They are in effect opaque cookies that the client must >> >do nothing with except send them back to the printer. They are really >> >job-name and printer-name. Either that or we explicitly state that these >> >fields only make sense in an HTTP-enabled environment (they cannot therefore >> >be mandatory for a universal protocol). >> > >> >> No, the URI is actually a URL that is to be interpreted according to >> "standard" rules for interpreting URLs (not sure if there is a "formal" >> standard for this). These resource identifiers are not opaque to clients. >> This does not mean that we are NOT transport independent, it only means we >> are identifying resources that must be accessed via the transport (scheme) >> that is specified in the URL. Since we have "modeled" IPP using URI/URL >> resource identifiers, all transports used by IPP should have a URL scheme >> defined. I don't think this is a negative constraint BTW. I consider our >> selection of URL strings as resource identifiers one of the more compact >> and powerful capabilities of the model (and protocol). >> >> The only problem we have identified so far is what happens when "http" is >> used as the scheme for IPP resources, and between the client and the >> resource, there is one or more proxies involved. Note, that this is a >> problem only in the case of HTTP as the transport. >> >Another problem is that PRO requires the HTTP Request-URI and the target URI (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're talking to a proxy. And proxies rewrite the Request-URI. > >> For reference purposes, can someone restate the problem (actually the >> scenario) with proxies that we are trying to address. I think some >> solutions that have recently hit the list are bordering on "throwing the >> baby out with the bath water". Any concrete scenario examples would be much >> appreciated, as I am still on the learning curve with HTTP proxy behavior. >> >> Thanks >> >> Randy >> >> >> >> > From ipp-owner@pwg.org Wed Jun 10 02:08:36 1998 Delivery-Date: Wed, 10 Jun 1998 02:08:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA16458 for ; Wed, 10 Jun 1998 02:08:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA12272 for ; Wed, 10 Jun 1998 02:10:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA17445 for ; Wed, 10 Jun 1998 02:08:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 02:04:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA16926 for ipp-outgoing; Wed, 10 Jun 1998 02:00:30 -0400 (EDT) Message-Id: <199806100552.WAA24865@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 09 Jun 1998 22:56:36 -0700 To: ipp@pwg.org From: Randy Turner Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: <8B57882C41A0D1118F7100805F9F68B502D2CED0@red-msg-45.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Thanks for the synopsis. It appears that the administrative capability to filter IPP traffic via proxies is a feature that Keith thinks should be provided by IPP. If this is the only key issue holding up our spec, then I would like to suggest that we look into a new method (such as PRINT), and avoid (for now) the issue of new schemes and/or port numbers for IPP. It's the "short path" in my opinion to getting us going again. As far as proxy-rewriting of request URIs, I'm still not clear this is an issue; the "abs-path" (per RFC2068) of the URI is really describing the "IPP" resource in question, and this part cannot be modified by proxies. I really don't care if the other fields are modified, just as long as it reaches the intended origin server. If we have to remove the MUST in the PRO document that talks about the IPP-URI MUST match the requestURI, then so be it. It's a cheap change (IMHO) and I think we can live without it. Randy At 08:42 PM 6/9/98 -0700, Josh Cohen wrote: > > >> -----Original Message----- >> From: Randy Turner [mailto:rturner@sharplabs.com] >> Sent: Tuesday, June 09, 1998 8:13 PM >> To: Paul Moore; 'Tom Hastings' >> Cc: 'Carl Kugler'; ipp@pwg.org >> Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests >> >> For reference purposes, can someone restate the problem (actually the >> scenario) with proxies that we are trying to address. I think some >> solutions that have recently hit the list are bordering on >> "throwing the >> baby out with the bath water". Any concrete scenario examples >> would be much >> appreciated, as I am still on the learning curve with HTTP >> proxy behavior. >> > >When a proxy is deployed as part of a gateway, firewall or other >security system, one of its responsibilities is to filter and allow >or reject certain transactions across a network or organizational boundary >in either direction. >The issue is that the proxy should be able to understand enough information >to decide wether to allow or reject that request's passage. When given >an IPP URL such as http://server/printer/queue, it has no way of >differentiating >this from a typical web browser's form submission. Since form submission >and print job submission and or printer control are different in terms >of the anticipated functionality that the firewall admin allowed >(by allowing POST http requests ), the admin should be able >to allow one and not the other. >The real world case is a firewall/proxy administrator who >sets a policy which allows POST because his intent is to allow >"simple web access", which form submission is a part of. Lets >say in this case that he is willing to allow simple web access, >but he is not interested in allowing IPP functionality, ie >print job submission and printer control. > >At the time IPP went to last call, the specification was to use >POST with an http URL. This did not meet the goal of allowing >a proxy server administrator to recognize the request as an IPP >request instead of a form submission. > >Keith has come back with the request to somehow make IPP requests >identifiable as different from simple http POST form submissions. > >Numerous suggestions have been made, as referenced by carl-uno's >recent posts of the table. > From ipp-owner@pwg.org Wed Jun 10 09:04:57 1998 Delivery-Date: Wed, 10 Jun 1998 09:04:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20191 for ; Wed, 10 Jun 1998 09:04:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12857 for ; Wed, 10 Jun 1998 09:07:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA18939 for ; Wed, 10 Jun 1998 09:04:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 08:54:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA17898 for ipp-outgoing; Wed, 10 Jun 1998 08:50:38 -0400 (EDT) Message-Id: <357E7FFC.DD1C86CA@dazel.com> Date: Wed, 10 Jun 1998 07:45:48 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Randy Turner Cc: ipp@pwg.org Subject: Re: IPP> Identifying jobs in requests References: <199806100552.WAA24865@slafw.enet.sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Randy Turner wrote: > > Thanks for the synopsis. It appears that the administrative capability to > filter IPP traffic via proxies is a feature that Keith thinks should be > provided by IPP. If this is the only key issue holding up our spec, then I > would like to suggest that we look into a new method (such as PRINT), and > avoid (for now) the issue of new schemes and/or port numbers for IPP. It's > the "short path" in my opinion to getting us going again. > > ... I also got the impression from comments made in this discussion that there was some advantage for a user to be able to look at an URL and somehow "know" that it was an IPP thing rather than just some web page. Thus, Larry's ipp: scheme idea (which gets translated at the client side to http://:/) seems attractive. Personally, I think that both of these ideas provide useful functionality, and we should consider both of them. That is, use the ipp: scheme (which the client translates to http:), and use a new PRINT method. one man's thoughts... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Jun 10 09:05:50 1998 Delivery-Date: Wed, 10 Jun 1998 09:05:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20211 for ; Wed, 10 Jun 1998 09:05:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA12863 for ; Wed, 10 Jun 1998 09:08:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA19052 for ; Wed, 10 Jun 1998 09:05:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 08:59:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA18135 for ipp-outgoing; Wed, 10 Jun 1998 08:58:18 -0400 (EDT) From: Roger K Debry To: Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Message-ID: <5030100021578849000002L092*@MHS> Date: Wed, 10 Jun 1998 08:57:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20211 Thanks for the synopsis. It appears that the administrative capability to filter IPP traffic via proxies is a feature that Keith thinks should be provided by IPP. If this is the only key issue holding up our spec, then I would like to suggest that we look into a new method (such as PRINT), and avoid (for now) the issue of new schemes and/or port numbers for IPP. It's the "short path" in my opinion to getting us going again. Why is defining a new method less of an issue than getting a new port number? If the table I created summarizes the situation accurately, a new port number results in the least breakage. From ipp-owner@pwg.org Wed Jun 10 10:20:16 1998 Delivery-Date: Wed, 10 Jun 1998 10:20:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21539 for ; Wed, 10 Jun 1998 10:20:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA13198 for ; Wed, 10 Jun 1998 10:22:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA19730 for ; Wed, 10 Jun 1998 10:20:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 10:14:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19190 for ipp-outgoing; Wed, 10 Jun 1998 10:12:27 -0400 (EDT) Message-ID: <357E940E.B2B6AEAE@adn.alcatel.com> Date: Wed, 10 Jun 1998 10:11:26 -0400 From: "Rajesh Chawla (cont)" X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> ADM - Implication table in TEXT format References: <3.0.5.32.19980609132718.009b5bb0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org > Hi folks, If the ipp:// format is adopted, does this imply there will be an ipps:// format for secure transmissions? Regards, Rajesh From ipp-owner@pwg.org Wed Jun 10 10:53:32 1998 Delivery-Date: Wed, 10 Jun 1998 10:53:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21987 for ; Wed, 10 Jun 1998 10:53:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA13396 for ; Wed, 10 Jun 1998 10:55:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA20327 for ; Wed, 10 Jun 1998 10:53:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 10:49:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19807 for ipp-outgoing; Wed, 10 Jun 1998 10:46:28 -0400 (EDT) Message-Id: <1.5.4.32.19980610144335.009c80e4@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: Wed, 10 Jun 1998 07:43:35 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Phone Conference with Area Director today Sender: owner-ipp@pwg.org All, Please remember our weekly phone conference which is coming up in a couple of hours. Keith Moore and possibly also Patrik Faltstrom (sorry no dots) will be discussing Keith's comments with us. The two major discussion points are: 1) How do we help firewall administrators to distinguish IPP from normal web traffic. Check Roger's table for the alternatives. It seems that we have supporters for two of the alternatives, namely: - the "Larry" proposal, which uses a new default IPP port in combination with an ipp: naming scheme, but with HHTP on the wire. - the "Josh" proposal, which replaces the POST method with a PRINT method. I think that we can ignore the other cases, and discuss whether to introduce ONE or BOTH of these two remaining proposals. 2) What do we do about Keith's proposal to mandate TLS for all IPP CLIENTS? In our earlier phone conference this was considered unreasonable. There has been no discussion of this on the DL, since then. Has anybody changed their views on this? This is probably as important as the HTTP discussion. We will also ask Keith if he was happy with the remaining preliminary answers we sent him last week. If we end up with time on our hands, we can always devote it to debate if we keep URLs in application/ipp :-) Here is the dial-in information again: Time: June 10, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno From ipp-owner@pwg.org Wed Jun 10 11:35:01 1998 Delivery-Date: Wed, 10 Jun 1998 11:35:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22497 for ; Wed, 10 Jun 1998 11:35:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA13607 for ; Wed, 10 Jun 1998 11:37:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21017 for ; Wed, 10 Jun 1998 11:34:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 11:29:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20445 for ipp-outgoing; Wed, 10 Jun 1998 11:27:47 -0400 (EDT) Message-Id: <199806101519.IAA26319@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 10 Jun 1998 08:23:49 -0700 To: ipp@pwg.org From: Randy Turner Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: <5030100021578849000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 08:57 AM 6/10/98 -0400, Roger K Debry wrote: >Thanks for the synopsis. It appears that the administrative capability to >filter IPP traffic via proxies is a feature that Keith thinks should be >provided by IPP. If this is the only key issue holding up our spec, then I >would like to suggest that we look into a new method (such as PRINT), and >avoid (for now) the issue of new schemes and/or port numbers for IPP. It's >the "short path" in my opinion to getting us going again. > > > Why is defining a new method less of an issue than getting a new port >number? If the table > I created summarizes the situation accurately, a new port number results >in the least > breakage. > I think a PRINT method would be less breakage when you consider both the true "internet" printing scenarios, as well as the "intranet" printing scenarios. I think we're forgetting the simple case (direct client to origin server) lately in our discussion. If I'm operating in an intranet, running something like the Apache web server,then I don't care about filtering issues (necessarily), so I would like to just work up a server-side extension (CGI, NSAPI, servlet,etc.) that works with my existing server. If I use a default port number for IPP that is different than port 80, then some web servers (take your pick, either host-based or embedded) would require that separate instances of the server be running, which requires at least one extra configuration file,and possibly another set of server log files. If a single instance of a web service can "listen" on more than one port number, then its not as bad, but I just thought a PRINT method would be more straightforward. Playing devil's advocate for a moment against my own proposal, I am aware that some pure firewall products do not have the ability to filter on HTTP methods, rather they usually filter on port number, and source/destination IP addresses/networks. Basically, choosing a new default port number causes "everyone" to reconfigure, even those that are not worried about filtering. Randy From ipp-owner@pwg.org Wed Jun 10 11:39:38 1998 Delivery-Date: Wed, 10 Jun 1998 11:39:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22597 for ; Wed, 10 Jun 1998 11:39:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA13630 for ; Wed, 10 Jun 1998 11:42:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA21622 for ; Wed, 10 Jun 1998 11:39:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 11:35:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20816 for ipp-outgoing; Wed, 10 Jun 1998 11:32:33 -0400 (EDT) From: "Larry Masinter" To: , "Randy Turner" Cc: Subject: RE: IPP> Identifying jobs in requests Date: Wed, 10 Jun 1998 08:26:20 PDT Message-ID: <000e01bd9484$1e532000$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <357E7FFC.DD1C86CA@dazel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org Actually, I realize that if TLS is mandatory for IPP, then "ipp://host.dom/path" gets turned into "https://host.dom:432/path", i.e., assuming a secure transmission. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Jun 10 12:03:36 1998 Delivery-Date: Wed, 10 Jun 1998 12:03:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23070 for ; Wed, 10 Jun 1998 12:03:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13752 for ; Wed, 10 Jun 1998 12:05:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22258 for ; Wed, 10 Jun 1998 12:03:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 11:59:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21715 for ipp-outgoing; Wed, 10 Jun 1998 11:53:02 -0400 (EDT) From: "Larry Masinter" To: "Josh Cohen" Cc: , Subject: IPP> On the harm of adding new methods Date: Wed, 10 Jun 1998 08:46:39 PDT Message-ID: <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <8B57882C41A0D1118F7100805F9F68B502D2CEAC@red-msg-45.dns.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org There are two functions of a proxy: filtering and forwarding. A filter decides whether or not to accept a request, and a forwarder actually forwards the request and processes the result; forwarding implements caching, protocol translation, tunneling, while filtering is generally a binary "allowed" or "not allowed". There are some forwarders that do rewriting in lieu of filtering (allow but modify). Forwarders MUST actually understand methods, because -- unfortunately -- the meaning of HTTP headers and responses differ based on the method of the request (e.g., Content-Length for HEAD vs GET). Many forwarding systems will not accept new methods gracefully. "Forwarding" includes a wide variety of mechanisms of tunneling, proxying, caching, distributed caching, and is a large industry. Many of the forwarding proxies do NO filtering at all: they're there for improving performance and reliability. Any new METHOD in HTTP is a serious modification to the protocol, because the forwarding function must be aware of it. A new content-type, however, can be as easily recognized in the filter layer as a new method, but requires NO changes to the forwarding function. Many filters already filter on content-type anyway. In the case of IPP, it is perfectly adequate to filter on content-type, since all IPP content is carried in application/IPP. The arguments for adding a new method (that it is somehow 'easier' to filter on the first few bytes of the protocol) are specious because most filters that are looking at the protocol at all are looking at content-type. So the "firewall filtering" rationale just doesn't hold as a reason for adding new methods. Larry -- http://www.parc.xerox.com/masinter From ipp-owner@pwg.org Wed Jun 10 12:09:36 1998 Delivery-Date: Wed, 10 Jun 1998 12:09:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23179 for ; Wed, 10 Jun 1998 12:09:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13798 for ; Wed, 10 Jun 1998 12:11:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA22906 for ; Wed, 10 Jun 1998 12:09:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:04:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21725 for ipp-outgoing; Wed, 10 Jun 1998 11:53:43 -0400 (EDT) Message-Id: <3.0.1.32.19980610084912.01136c38@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Jun 1998 08:49:12 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org In case we do get time to: At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: >If we end up with time on our hands, we can always devote it to debate >if we keep URLs in application/ipp :-) There seems to be a growing consensus that we should remove the (redundant) printer-uri and job-uri operation attribute targets from the operation attributes group in IPP requests. This would be a change to sections 3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version) and section 15.3.4.3. Then we would be depending on the transport to get the request to the right place. There would be no other changes to the application/ipp part of requests and no changes to responses at all. For operations on jobs, the only form would be the "job-id" (integer) in the Operation attribute group in the request, so this change would be eliminating one of the two repsentations for operations on jobs (a good simplification). Recall that the reason that we added the printer-uri and job-uri targets to the operation attribute group in requests was in the "name of transport independence" (a good thing). But what do we really mean by making application/ipp "transport independent"? One could argue that by removing the "printer-uri" and "job-uri" targets operation attributes that we are making the application/ipp MIME media type more transport independent and we are depending on the transport to get the request to the intended target. To understand better what transport-independence really means, imagine that we are trying to sent IPP requests over other transports, such as SMTP, FTP, and TCP/IP. We would depend on those transports to get the request to some destination that knows what to do with the request. For requests on jobs (Send-Document, Send-URI, Cancel-Job, Get-Job-Attributes), the "job-id" in the application/ipp tells the recipient which job the operations is upon. We don't have a similar operation attribute for operations on printers (Print-Job, Print-URI, Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs). We could add the existing "printer-name" Printer attribute as an Operation attribute for operations on Printers. Then the transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any IPP request knows which Printer or Job object the operation is intended by simply looking at the "printer-name" or "job-id" operation attribute and can ignore any transport request URI. Extending Scott's home mail delivery analogy, the U.S. Postal service is a transport that delivers to your house any mail addressed to your house without looking at the name of the addressee. The recipient (familiy) then looks at the name and knows for whom the mail is really for (including someone who no longer lives there - return to sender). I'm not sure how/whether removing these "printer-uri" and "job-uri" operation attribute targets from the application/ipp MIME type requests affects client communication with proxies in which the http URIs get changed from absolute to relative in the HTTP header. But it seems like there might be no problem, since HTTP request headers are the province of the transport, which includes proxies and they can do what ever they like, including changing absolute URIs to relative URIs. Such changes only affect getting the message to the recipient. The recipient only looks at the application/ipp operation attributes to know which printer or job is really the intended object instance. Tom From ipp-owner@pwg.org Wed Jun 10 12:14:43 1998 Delivery-Date: Wed, 10 Jun 1998 12:14:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23243 for ; Wed, 10 Jun 1998 12:14:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13813 for ; Wed, 10 Jun 1998 12:17:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23528 for ; Wed, 10 Jun 1998 12:14:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:10:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22621 for ipp-outgoing; Wed, 10 Jun 1998 12:07:06 -0400 (EDT) Message-ID: From: Paul Moore To: "'Randy Turner'" , "'Tom Hastings'" Cc: "'Carl Kugler'" , ipp@pwg.org Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests Date: Wed, 10 Jun 1998 09:06:41 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > No, the URI is actually a URL that is to be interpreted according to > "standard" rules for interpreting URLs (not sure if there is a "formal" > standard for this). These resource identifiers are not opaque to clients. > This does not mean that we are NOT transport independent, it only means we > are identifying resources that must be accessed via the transport (scheme) > that is specified in the URL. [Paul Moore] not so - for at least 2 reasons. 1. In some transports the server cannot know the adressing scheme of the client and so cannot form an adress that makes sense for the client. A URI is meant to be Universal (hence the name) - even if a server can form a URI that makes sense in the addressing scheme of the original client, what happens if this is forwarded to another client? Example - in a 1284 connected environment what should the URI look like (ipp:/lpt1/jobx ?), how does the server know which lpt port number to use. 2. I cannot forward an IPP packet containing a URI to another system that is not part of the same homogeneous address space as the original client and server. I have to crack every packet , find all the URIs and change them. However I do not know HOW to change them because we have avoided making rules about the formation of URI (they are supposed to be implementation specific), without the knowledge of which bits mean what in the URI I cannot know how to change them from one transport to another From ipp-owner@pwg.org Wed Jun 10 12:24:01 1998 Delivery-Date: Wed, 10 Jun 1998 12:24:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23382 for ; Wed, 10 Jun 1998 12:24:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13865 for ; Wed, 10 Jun 1998 12:26:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24141 for ; Wed, 10 Jun 1998 12:23:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:19:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23590 for ipp-outgoing; Wed, 10 Jun 1998 12:15:23 -0400 (EDT) Date: Wed, 10 Jun 1998 12:15:11 -0400 (EDT) From: Scott Lawrence To: Larry Masinter cc: Josh Cohen , ipp@pwg.org, ietf-http-ext@w3.org Subject: IPP> Re: On the harm of adding new methods In-Reply-To: <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org On Wed, 10 Jun 1998, Larry Masinter wrote: > Any new METHOD in HTTP is a serious modification to the protocol, because > the forwarding function must be aware of it. A new content-type, however, > can be as easily recognized in the filter layer as a new method, but > requires NO changes to the forwarding function. Many filters already filter > on content-type anyway. But will the content-type be ok in both directions? What is the content-type of an ipp response? If it is not also application/ipp, then you could easily create a situation in which the request can be sent and pass through the filter, but the response cannot... From ipp-owner@pwg.org Wed Jun 10 12:34:10 1998 Delivery-Date: Wed, 10 Jun 1998 12:34:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23464 for ; Wed, 10 Jun 1998 12:34:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13904 for ; Wed, 10 Jun 1998 12:36:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA24823 for ; Wed, 10 Jun 1998 12:34:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:29:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23907 for ipp-outgoing; Wed, 10 Jun 1998 12:21:53 -0400 (EDT) Message-ID: <005701bd948b$8fb60e40$1e0564d2@tulip> From: "Peter Michalek" To: Subject: RE: IPP> Identifying jobs in requests Date: Wed, 10 Jun 1998 09:18:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org >From Carl Kugler's response to my message from last week, I realized that having urls denoting jobs without requiring an extra cgi to serve them is trivial: http://ipp.cgi?jobId=2 (as opposed to http://ipp.cgi/2). It brings a question whether job is not an "artificial" target, since usually, a request to cancel a job or get job attributes will be served by a cgi representing the printer where the job was created. Whether the target (job-uri or printer-uri or printer-uri + job-id) is taken out of IPP layer or not, it would be more simple to have just one possible kind of target: printer-uri, where job-id would be considered an operation attribute. If the target is taken out of IPP layer and will be used only in the transport layer, not having job-uri as a possible target would probably make addressing possible for other transports, e.g. mailto:ipp@printingorg.com, where specification of arguments is not allowed (according to rfc1738). Regarding the message below, I don't understand: >Another problem is that PRO requires the HTTP Request-URI and the target URI (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're talking to a proxy. And proxies rewrite the Request-URI. In what respect are HTTP/1.1 clients not allowed to send absolute Request-URIs? I didn't see a mention of that in RFC2068. Peter -----Original Message----- From: Carl Kugler To: ipp@pwg.org Date: Tuesday, June 09, 1998 9:18 PM Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requests >> At 06:13 PM 6/9/98 -0700, Paul Moore wrote: >> > I think that originally "printer-uri" was going to be a "virtual" >> >attribute, >> > as you thought. But later (last Fall?) we changed the Model and >> >Protocol >> > document so that the "printer-uri" attribute was required to be >> >supplied >> > by the client and include in the operation attribute group in the >> >IPP packet >> > (which is defined by the application/ipp MIME type). The thinking >> > was that we wanted the IPP packet and MIME type to be independent >> > of the transport. So that we could send IPP over any transport, >> >such >> > as SMTP or FTP, for examples. >> > >> >OK. So we are saying that the URIs IN the protocol are NOT to be used as >> >transport adresses. They are in effect opaque cookies that the client must >> >do nothing with except send them back to the printer. They are really >> >job-name and printer-name. Either that or we explicitly state that these >> >fields only make sense in an HTTP-enabled environment (they cannot therefore >> >be mandatory for a universal protocol). >> > >> >> No, the URI is actually a URL that is to be interpreted according to >> "standard" rules for interpreting URLs (not sure if there is a "formal" >> standard for this). These resource identifiers are not opaque to clients. >> This does not mean that we are NOT transport independent, it only means we >> are identifying resources that must be accessed via the transport (scheme) >> that is specified in the URL. Since we have "modeled" IPP using URI/URL >> resource identifiers, all transports used by IPP should have a URL scheme >> defined. I don't think this is a negative constraint BTW. I consider our >> selection of URL strings as resource identifiers one of the more compact >> and powerful capabilities of the model (and protocol). >> >> The only problem we have identified so far is what happens when "http" is >> used as the scheme for IPP resources, and between the client and the >> resource, there is one or more proxies involved. Note, that this is a >> problem only in the case of HTTP as the transport. >> >Another problem is that PRO requires the HTTP Request-URI and the target URI (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're talking to a proxy. And proxies rewrite the Request-URI. > >> For reference purposes, can someone restate the problem (actually the >> scenario) with proxies that we are trying to address. I think some >> solutions that have recently hit the list are bordering on "throwing the >> baby out with the bath water". Any concrete scenario examples would be much >> appreciated, as I am still on the learning curve with HTTP proxy behavior. >> >> Thanks >> >> Randy >> >> >> >> > > From ipp-owner@pwg.org Wed Jun 10 12:44:13 1998 Delivery-Date: Wed, 10 Jun 1998 12:44:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23560 for ; Wed, 10 Jun 1998 12:44:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13956 for ; Wed, 10 Jun 1998 12:46:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25443 for ; Wed, 10 Jun 1998 12:43:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:39:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24893 for ipp-outgoing; Wed, 10 Jun 1998 12:35:31 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Re: On the harm of adding new methods Message-ID: <5030100021589495000002L052*@MHS> Date: Wed, 10 Jun 1998 12:34:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23560 But will the content-type be ok in both directions? What is the content-type of an ipp response? If it is not also application/ipp, then you could easily create a situation in which the request can be sent and pass through the filter, but the response cannot... What would prevent the response from passing? What is the Alternative? If we use the PRINT method on a request, what is the response? From ipp-owner@pwg.org Wed Jun 10 12:49:47 1998 Delivery-Date: Wed, 10 Jun 1998 12:49:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23616 for ; Wed, 10 Jun 1998 12:49:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13980 for ; Wed, 10 Jun 1998 12:52:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26095 for ; Wed, 10 Jun 1998 12:49:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:45:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24892 for ipp-outgoing; Wed, 10 Jun 1998 12:35:29 -0400 (EDT) Message-Id: <3.0.5.32.19980610093318.0136e290@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Jun 1998 09:33:18 PDT To: Scott Lawrence , Larry Masinter From: Carl-Uno Manros Subject: Re: IPP> Re: On the harm of adding new methods Cc: Josh Cohen , ipp@pwg.org, ietf-http-ext@w3.org In-Reply-To: References: <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 09:15 AM 6/10/98 PDT, Scott Lawrence wrote: > >On Wed, 10 Jun 1998, Larry Masinter wrote: > >> Any new METHOD in HTTP is a serious modification to the protocol, because >> the forwarding function must be aware of it. A new content-type, however, >> can be as easily recognized in the filter layer as a new method, but >> requires NO changes to the forwarding function. Many filters already filter >> on content-type anyway. > > But will the content-type be ok in both directions? What is the >content-type of an ipp response? If it is not also application/ipp, >then you could easily create a situation in which the request can be >sent and pass through the filter, but the response cannot... > Scott, FYI, ALL requests and responses in IPP are in application/ipp format. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 10 12:54:47 1998 Delivery-Date: Wed, 10 Jun 1998 12:54:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23648 for ; Wed, 10 Jun 1998 12:54:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA13996 for ; Wed, 10 Jun 1998 12:57:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26698 for ; Wed, 10 Jun 1998 12:54:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:50:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25355 for ipp-outgoing; Wed, 10 Jun 1998 12:43:04 -0400 (EDT) Message-ID: <007101bd948e$b0cfb0b0$1e0564d2@tulip> From: "Peter Michalek" To: Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets Date: Wed, 10 Jun 1998 09:41:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org -----Original Message----- From: Tom Hastings To: ipp@pwg.org Date: Wednesday, June 10, 1998 9:09 AM Subject: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets >In case we do get time to: > >At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: >>If we end up with time on our hands, we can always devote it to debate >>if we keep URLs in application/ipp :-) I'm not sure how/whether removing these "printer-uri" and "job-uri" >operation attribute targets from the application/ipp MIME type requests >affects client communication with proxies in which the http URIs get >changed from absolute to relative in the HTTP header. But it seems like >there might be no problem, since HTTP request headers are the province >of the transport, which includes proxies and they can do what ever they >like, including changing absolute URIs to relative URIs. Such changes >only affect getting the message to the recipient. The recipient only >looks at the application/ipp operation attributes to know which printer >or job is really the intended object instance. I was addressing this scenario in my previous e-mail today, The job-id will be an operation attribute, so job addressing within a printer should be taken care of. To address the printer, we would have to decide on one of two rules : 1) * the entity processing the request is representing only one printer and no additional attribute is necessary 2) * or as Tom mentions above, printer-name should assist in addressing the target 2) seems more flexible. Peter From ipp-owner@pwg.org Wed Jun 10 13:12:50 1998 Delivery-Date: Wed, 10 Jun 1998 13:12:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23808 for ; Wed, 10 Jun 1998 13:12:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14072 for ; Wed, 10 Jun 1998 13:15:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27358 for ; Wed, 10 Jun 1998 13:12:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 13:08:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26807 for ipp-outgoing; Wed, 10 Jun 1998 13:03:21 -0400 (EDT) Message-Id: <199806101655.JAA26911@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 10 Jun 1998 09:59:22 -0700 To: ipp@pwg.org From: Randy Turner Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 09:06 AM 6/10/98 -0700, Paul Moore wrote: >> No, the URI is actually a URL that is to be interpreted according to >> "standard" rules for interpreting URLs (not sure if there is a "formal" >> standard for this). These resource identifiers are not opaque to clients. >> This does not mean that we are NOT transport independent, it only means we >> are identifying resources that must be accessed via the transport (scheme) >> that is specified in the URL. > [Paul Moore] not so - for at least 2 reasons. > > 1. In some transports the server cannot know the adressing scheme of >the client and so cannot form an adress that makes sense for the client. A >URI is meant to be Universal (hence the name) - even if a server can form a >URI that makes sense in the addressing scheme of the original client, what >happens if this is forwarded to another client? Example - in a 1284 >connected environment what should the URI look like (ipp:/lpt1/jobx ?), how >does the server know which lpt port number to use. In practical application, the server would never return a resource identifier that specified a transport to which the client had not already used to contact the server. And the forwarding scenario isn't realistic, and also outside the scope of IPP. > > 2. I cannot forward an IPP packet containing a URI to another system >that is not part of the same homogeneous address space as the original >client and server. I have to crack every packet , find all the URIs and >change them. However I do not know HOW to change them because we have >avoided making rules about the formation of URI (they are supposed to be >implementation specific), without the knowledge of which bits mean what in >the URI I cannot know how to change them from one transport to another This isn't supported by IPP either; this functionality would be some type of gateway application that would have to administratively configured. The way we have it defined now carves out middle 80% functionality we wanted to achieve. Randy > From ipp-owner@pwg.org Wed Jun 10 13:39:22 1998 Delivery-Date: Wed, 10 Jun 1998 13:39:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA24170 for ; Wed, 10 Jun 1998 13:39:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14204 for ; Wed, 10 Jun 1998 13:41:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28032 for ; Wed, 10 Jun 1998 13:39:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 13:34:47 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27467 for ipp-outgoing; Wed, 10 Jun 1998 13:32:38 -0400 (EDT) Date: Wed, 10 Jun 1998 09:36:41 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9806101636.AA08091@snorkel.eso.mc.xerox.com> To: lawrence@agranat.com, masinter@parc.xerox.com Subject: Re: IPP> Re: On the harm of adding new methods Cc: ietf-http-ext@w3.org, ipp@pwg.org, joshco@microsoft.com Sender: owner-ipp@pwg.org Hi folks, Yes, the content-type of IPP requests AND responses is ALWAYS 'application/ipp'. That was decided a long time ago. This isn't a legitimate concern Cheers, - Ira McDonald (High North) ------------------------------------------------------- [the thread] >From ipp-owner@pwg.org Wed Jun 10 12:32:55 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA08083; Wed, 10 Jun 98 12:32:54 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA22993; Wed, 10 Jun 98 12:25:21 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52413(1)>; Wed, 10 Jun 1998 09:25:54 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA23982 for ; Wed, 10 Jun 1998 12:22:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 12:19:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA23590 for ipp-outgoing; Wed, 10 Jun 1998 12:15:23 -0400 (EDT) Date: Wed, 10 Jun 1998 09:15:11 PDT From: Scott Lawrence To: Larry Masinter Cc: Josh Cohen , ipp@pwg.org, ietf-http-ext@w3.org Subject: IPP> Re: On the harm of adding new methods In-Reply-To: <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org Status: R On Wed, 10 Jun 1998, Larry Masinter wrote: > Any new METHOD in HTTP is a serious modification to the protocol, because > the forwarding function must be aware of it. A new content-type, however, > can be as easily recognized in the filter layer as a new method, but > requires NO changes to the forwarding function. Many filters already filter > on content-type anyway. But will the content-type be ok in both directions? What is the content-type of an ipp response? If it is not also application/ipp, then you could easily create a situation in which the request can be sent and pass through the filter, but the response cannot... From ipp-owner@pwg.org Wed Jun 10 13:58:55 1998 Delivery-Date: Wed, 10 Jun 1998 13:59:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA24446 for ; Wed, 10 Jun 1998 13:58:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14295 for ; Wed, 10 Jun 1998 14:01:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28675 for ; Wed, 10 Jun 1998 13:58:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 13:54:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28130 for ipp-outgoing; Wed, 10 Jun 1998 13:51:40 -0400 (EDT) Message-Id: <3.0.1.32.19980610095021.011340b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Jun 1998 09:50:21 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets Cc: ipp@pwg.org In-Reply-To: <3.0.1.32.19980610084912.01136c38@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org A simpler way of understanding this proposal is: 1. We remove the choice of supplying a "job-uri" operation attribute target in application/ipp requests in operations on jobs (Send-Document, Send-URI, Cancel-Job, Get-Job-Attributes). 2. We replace the "printer-uri" operation attribute target in application/ipp requests in operations on jobs and printers with the "printer-name" Printer attribute. So operation requests for printers would have: "printer-name" and operations for jobs would have both: "printer-name" "job-id" in that order (after "attributes-charset" and "attribute-natural-language". Now that we have made "printer-name" MANDATORY in a directory entry, the client knows what "printer-name" to put into every request. Tom At 08:49 06/10/1998 PDT, Tom Hastings wrote: >In case we do get time to: > >At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: >>If we end up with time on our hands, we can always devote it to debate >>if we keep URLs in application/ipp :-) > >There seems to be a growing consensus that we should remove the (redundant) >printer-uri and job-uri operation attribute targets from the operation >attributes group in IPP requests. This would be a change to sections >3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version) >and section 15.3.4.3. Then we would be depending on the transport >to get the request to the right place. There would be no other changes >to the application/ipp part of requests and no changes to responses at all. >For operations on jobs, the only form would be the "job-id" (integer) in the >Operation attribute group in the request, so this change would be eliminating >one of the two repsentations for operations on jobs (a good simplification). > >Recall that the reason that we added the printer-uri and job-uri targets >to the operation attribute group in requests was in the "name of >transport independence" (a good thing). But what do we really mean by making >application/ipp "transport independent"? One could argue that by removing >the "printer-uri" and "job-uri" targets operation attributes that we are >making the application/ipp MIME media type more transport independent >and we are depending on the transport to get the request to the intended >target. > >To understand better what transport-independence really means, imagine >that we are trying to sent IPP requests over other transports, such as >SMTP, FTP, and TCP/IP. We would depend on those transports to get the >request to some destination that knows what to do with the request. >For requests on jobs (Send-Document, Send-URI, Cancel-Job, >Get-Job-Attributes), the "job-id" in the application/ipp tells the >recipient which job the operations is upon. We don't have a similar >operation attribute for operations on printers (Print-Job, Print-URI, >Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs). >We could add the existing "printer-name" Printer attribute as an >Operation attribute for operations on Printers. Then the >transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any >IPP request knows which Printer or Job object the operation is intended >by simply looking at the "printer-name" or "job-id" operation attribute >and can ignore any transport request URI. > >Extending Scott's home mail delivery analogy, the U.S. Postal service >is a transport that delivers to your house any mail addressed to your house >without looking at the name of the addressee. The recipient (familiy) then >looks at the name and knows for whom the mail is really for (including >someone who no longer lives there - return to sender). > >I'm not sure how/whether removing these "printer-uri" and "job-uri" >operation attribute targets from the application/ipp MIME type requests >affects client communication with proxies in which the http URIs get >changed from absolute to relative in the HTTP header. But it seems like >there might be no problem, since HTTP request headers are the province >of the transport, which includes proxies and they can do what ever they >like, including changing absolute URIs to relative URIs. Such changes >only affect getting the message to the recipient. The recipient only >looks at the application/ipp operation attributes to know which printer >or job is really the intended object instance. > >Tom > > > From ipp-owner@pwg.org Wed Jun 10 13:58:55 1998 Delivery-Date: Wed, 10 Jun 1998 13:59:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA24446 for ; Wed, 10 Jun 1998 13:58:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14295 for ; Wed, 10 Jun 1998 14:01:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28675 for ; Wed, 10 Jun 1998 13:58:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 13:54:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28130 for ipp-outgoing; Wed, 10 Jun 1998 13:51:40 -0400 (EDT) Message-Id: <3.0.1.32.19980610095021.011340b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Jun 1998 09:50:21 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets Cc: ipp@pwg.org In-Reply-To: <3.0.1.32.19980610084912.01136c38@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org A simpler way of understanding this proposal is: 1. We remove the choice of supplying a "job-uri" operation attribute target in application/ipp requests in operations on jobs (Send-Document, Send-URI, Cancel-Job, Get-Job-Attributes). 2. We replace the "printer-uri" operation attribute target in application/ipp requests in operations on jobs and printers with the "printer-name" Printer attribute. So operation requests for printers would have: "printer-name" and operations for jobs would have both: "printer-name" "job-id" in that order (after "attributes-charset" and "attribute-natural-language". Now that we have made "printer-name" MANDATORY in a directory entry, the client knows what "printer-name" to put into every request. Tom At 08:49 06/10/1998 PDT, Tom Hastings wrote: >In case we do get time to: > >At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: >>If we end up with time on our hands, we can always devote it to debate >>if we keep URLs in application/ipp :-) > >There seems to be a growing consensus that we should remove the (redundant) >printer-uri and job-uri operation attribute targets from the operation >attributes group in IPP requests. This would be a change to sections >3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version) >and section 15.3.4.3. Then we would be depending on the transport >to get the request to the right place. There would be no other changes >to the application/ipp part of requests and no changes to responses at all. >For operations on jobs, the only form would be the "job-id" (integer) in the >Operation attribute group in the request, so this change would be eliminating >one of the two repsentations for operations on jobs (a good simplification). > >Recall that the reason that we added the printer-uri and job-uri targets >to the operation attribute group in requests was in the "name of >transport independence" (a good thing). But what do we really mean by making >application/ipp "transport independent"? One could argue that by removing >the "printer-uri" and "job-uri" targets operation attributes that we are >making the application/ipp MIME media type more transport independent >and we are depending on the transport to get the request to the intended >target. > >To understand better what transport-independence really means, imagine >that we are trying to sent IPP requests over other transports, such as >SMTP, FTP, and TCP/IP. We would depend on those transports to get the >request to some destination that knows what to do with the request. >For requests on jobs (Send-Document, Send-URI, Cancel-Job, >Get-Job-Attributes), the "job-id" in the application/ipp tells the >recipient which job the operations is upon. We don't have a similar >operation attribute for operations on printers (Print-Job, Print-URI, >Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs). >We could add the existing "printer-name" Printer attribute as an >Operation attribute for operations on Printers. Then the >transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any >IPP request knows which Printer or Job object the operation is intended >by simply looking at the "printer-name" or "job-id" operation attribute >and can ignore any transport request URI. > >Extending Scott's home mail delivery analogy, the U.S. Postal service >is a transport that delivers to your house any mail addressed to your house >without looking at the name of the addressee. The recipient (familiy) then >looks at the name and knows for whom the mail is really for (including >someone who no longer lives there - return to sender). > >I'm not sure how/whether removing these "printer-uri" and "job-uri" >operation attribute targets from the application/ipp MIME type requests >affects client communication with proxies in which the http URIs get >changed from absolute to relative in the HTTP header. But it seems like >there might be no problem, since HTTP request headers are the province >of the transport, which includes proxies and they can do what ever they >like, including changing absolute URIs to relative URIs. Such changes >only affect getting the message to the recipient. The recipient only >looks at the application/ipp operation attributes to know which printer >or job is really the intended object instance. > >Tom > > > From ipp-owner@pwg.org Wed Jun 10 14:04:28 1998 Delivery-Date: Wed, 10 Jun 1998 14:04:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24553 for ; Wed, 10 Jun 1998 14:04:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14328 for ; Wed, 10 Jun 1998 14:06:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29316 for ; Wed, 10 Jun 1998 14:04:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 14:00:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28150 for ipp-outgoing; Wed, 10 Jun 1998 13:53:55 -0400 (EDT) Message-Id: <3.0.5.32.19980610090926.013f9100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Jun 1998 09:09:26 PDT To: "Rajesh Chawla (cont)" From: Carl-Uno Manros Subject: Re: IPP> ADM - Implication table in TEXT format Cc: ipp@pwg.org In-Reply-To: <357E940E.B2B6AEAE@adn.alcatel.com> References: <3.0.5.32.19980609132718.009b5bb0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 07:11 AM 6/10/98 PDT, Rajesh Chawla (cont) wrote: >> > >Hi folks, > >If the ipp:// format is adopted, does this imply there >will be an ipps:// format for secure transmissions? > >Regards, >Rajesh > Not according to Keith Moore, who believes that the security folks will solve the problem of using the same port and same scheme... Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 10 14:09:40 1998 Delivery-Date: Wed, 10 Jun 1998 14:09:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24689 for ; Wed, 10 Jun 1998 14:09:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14358 for ; Wed, 10 Jun 1998 14:11:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29933 for ; Wed, 10 Jun 1998 14:09:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 14:05:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28160 for ipp-outgoing; Wed, 10 Jun 1998 13:54:07 -0400 (EDT) Message-Id: <3.0.5.32.19980610091149.0135f620@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Jun 1998 09:11:49 PDT To: "Larry Masinter" , , "Randy Turner" From: Carl-Uno Manros Subject: RE: IPP> Identifying jobs in requests Cc: In-Reply-To: <000e01bd9484$1e532000$aa66010d@copper.parc.xerox.com> References: <357E7FFC.DD1C86CA@dazel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 08:26 AM 6/10/98 PDT, Larry Masinter wrote: >Actually, I realize that if TLS is mandatory for IPP, then >"ipp://host.dom/path" gets turned into "https://host.dom:432/path", >i.e., assuming a secure transmission. > >Larry >-- >http://www.parc.xerox.com/masinter > > > Larry, We will discuss this with Keith. He thinks otherwise. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 10 16:30:59 1998 Delivery-Date: Wed, 10 Jun 1998 16:31:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26238 for ; Wed, 10 Jun 1998 16:30:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15032 for ; Wed, 10 Jun 1998 16:33:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00747 for ; Wed, 10 Jun 1998 16:30:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 16:24:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00182 for ipp-outgoing; Wed, 10 Jun 1998 16:21:55 -0400 (EDT) Message-Id: <3.0.1.32.19980610131705.01139738@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Jun 1998 13:17:05 PDT To: "Carl Kugler" From: Tom Hastings Subject: Re: IPP> MOD> "document-format-supported" [MOD needs clarification] Cc: ipp@pwg.org In-Reply-To: <19980609214723.7252.qmail@m2.findmail.com> References: <199806091921.MAA17269@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I agree with Bob that "document-formats-supported" must be invariant with respect to the "document-format" input parmeter that a client might supply in a Get-Printer-Attributes request. I agree with both Bob and Carl that the Model document needs clarification on which attributes returned in Get-Printer-Attributes MAY depend on the value of the "document-format" supplied as an input parameter and which SHALL NOT depend on the "document-format" supplied, i.e., MUST be invariant. I agree with Carl that all Printer attributes that are Job Template attributes in the Printer object (xxx-default and xxx-supported in the Table in Section 4.2) MAY depend on the value of the document-format. Here is an analysis of the remaining Printer Description attributes: create operation attribute corresponding Printer attributes vary? -------------------------- -------------------------------- ---- attributes-charset charset-configured shall not charset-supported shall not attributes-natural-language natural-language-configured shall not generated-natural-language-supported shall not printer-uri printer-uri-supported shall not uri-security-supported shall not requesting-user-name - job-name - ipp-attribute-fidelity pdl-override-supported MAY document-name - document-format document-format-default shall not document-format-supported shall not document-natural-language - compression compression-supported MAY job-k-octets job-k-octets-supported MAY job-impressions job-impressions-supported MAY job-media-sheets job-media-sheets-supported MAY - printer-driver-installer MAY - operations-suported shall not - printer-is-accepting-jobs shall not - queued-job-count shall not - color-supported MAY - reference-uri-schemes-supported MAY? An IPP Printer object SHALL NOT return different values for all other Printer Description attribute depending on the "document-format" supplied as an input parameter to the Get-Printer-Attributes operation: printer-name, printer-location, printer-info, printer-more-info, printer-make-and-model, printer-more-info-manufacturer, printer-state, printer-state-reasons, printer-message-from-operator, printer-up-time, printer-current-time, and multiple-operation-time-out. Suggested text to be the clarification We could add the following to the Get-Printer-Attribute request under the "document-format" operation attribute description: All Printer attributes that are Job Template attributes in the Printer object (xxx-default and xxx-supported in the Table in Section 4.2) MAY depend on the value of the "document-format" supplied in the request. In addition, the following Printer attributes MAY depend on the value of the "document-format" supplied: pdl-override-supported, compression-supported, job-k-octets-supported, job-impressions-supported, job-media-sheets-supported, printer-driver-installer, color-supported, reference-uri-schemes-supported(?). An IPP Printer object SHALL NOT return different values for all other Printer Description attributes depending on the "document-format" supplied as an input parameter in the Get-Printer-Attributes request. When a new Printer attribute is registered (see section 6), part of its specification needs to contain the following sentence: The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" attribute supplied (see Section 3.2.5.1). If the specification does not, then its value SHALL NOT depend on the "document-format" supplied in the request. When a new Job Template attribute is registered, the value of the Printer attributes MAY vary with "document-format" supplied in the request without the specification having to indicate so. For the 7 or 8 Printer attributes indicated with MAY above, we might want to add a sentence to each description something like: The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" attribute supplied (see Section 3.2.5.1). Comments? Tom At 14:47 06/09/1998 PDT, Carl Kugler wrote: >> --=====================_3129239==_.ALT >> Content-Type: text/plain; charset="us-ascii" >> >> The value of document-format-supported should be all document-formats >> supported and its value should not be affected by the document-format >> operation attribute. Otherwise, how does a client determine what >> document-formats the printer supports. The document-format attribute should >> affect other printer attributes returned. Perhaps the model document needs >> some clarification in this area. >> >Okay, that's reasonable. But your reading is a little like saying "application/vnd.hp-PCL" is a supported document-format value for "text/plain" Jobs. > >So what we have here is a Printer Description Attribute (PDA) which is invariant with respect to document-format. Are there other PDAs that should be considered invariant? printer-name? printer-state? printer-is-accepting-jobs? pdl-override-supported? color-supported? Or can these be considered attributes of a particular interpreter in a Printer? Maybe only Printer Job Template attributes are a function of document-format? > >> >> Bob Herriot >> > > -Carl > >> >> >> At 04:09 PM 6/8/98 , Carl Kugler wrote: >> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me to the >> conclusion that the value of "document-format-supported" in a >> Get-Printer-Attributes Response will always be either: >> > >> >a) a parroting back of the "document-format" supplied in the Request >> > >> >or >> > >> >b) the Printer's "document-format-default" >> > >> >depending on whether or not the client supplied "document-format" in the >> Request. Am I reading this correctly? >> > >> > -Carl >> > >> >> --=====================_3129239==_.ALT >> Content-Type: text/html; charset="us-ascii" >> >> >> The value of document-format-supported should be all >> document-formats
>> supported and its value should not be affected by the document-format >>
>> operation attribute. Otherwise, how does a client determine what
>> document-formats the printer supports. The document-format attribute >> should
>> affect other printer attributes returned. Perhaps the model document >> needs
>> some clarification in this area.
>>
>>
>> Bob Herriot
>>
>>
>>
>> At 04:09 PM 6/8/98 , Carl Kugler wrote:
>> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads >> me to the conclusion that the value of >> "document-format-supported" in a Get-Printer-Attributes >> Response will always be either:
>> >
>> >a)  a parroting back of the "document-format" supplied >> in the Request
>> >
>> >or
>> >
>> >b) the Printer's "document-format-default"
>> >
>> >depending on whether or not the client supplied >> "document-format" in the Request.  Am I reading this >> correctly?
>> >
>> >    -Carl
>> >
>> >> >> --=====================_3129239==_.ALT-- >> >> >> > > > From ipp-owner@pwg.org Wed Jun 10 16:48:59 1998 Delivery-Date: Wed, 10 Jun 1998 16:49:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26487 for ; Wed, 10 Jun 1998 16:48:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15094 for ; Wed, 10 Jun 1998 16:51:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01350 for ; Wed, 10 Jun 1998 16:48:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 16:44:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00822 for ipp-outgoing; Wed, 10 Jun 1998 16:39:19 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CED8@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Larry Masinter'" Cc: ipp@pwg.org, ietf-http-ext@w3.org Subject: RE: IPP> On the harm of adding new methods Date: Wed, 10 Jun 1998 13:39:03 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > Larry Said: > > In the case of IPP, it is perfectly adequate to filter on > content-type, > since all IPP content is carried in application/IPP. The > arguments for > adding a new method (that it is somehow 'easier' to filter on > the first > few bytes of the protocol) are specious because most filters that are > looking at the protocol at all are looking at content-type. So the > "firewall filtering" rationale just doesn't hold as a reason > for adding > new methods. > That isnt how I see things. Today, more delpoyed proxies look at the method than the content-type. Content-Type may offer a way of filtering, Ill agree with that, but to say that proxies commonly filter based on content type and not method isn't right. From ipp-owner@pwg.org Wed Jun 10 17:19:00 1998 Delivery-Date: Wed, 10 Jun 1998 17:19:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26808 for ; Wed, 10 Jun 1998 17:19:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15247 for ; Wed, 10 Jun 1998 17:21:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02025 for ; Wed, 10 Jun 1998 17:18:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 17:14:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01472 for ipp-outgoing; Wed, 10 Jun 1998 17:10:10 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP> Minutes of 6/10 IPP conference call Message-ID: <5030100021603541000002L012*@MHS> Date: Wed, 10 Jun 1998 17:08:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA26808 When I agreed to take minutes, I did not agree to spell peoples names corrrectly, remember everything that transpired during the discussion, or get it 1100% correct when transposing to paper. Please accept my apologies in advance for such errors. With those caveats, here are the minutes of the 6/10 call. I won't feel bad if you have to correct me. Thanks ... Participating in the call ( mostly in the order joining the call): Shevan Albright Daniel Manchella Keith Moore (area director) Patrick ?? (area director) Kris Schaff Tom Hastings Jim Walker Ron Bergman Harry Lewis Larry Masinter Don Wright Xavier Riley Ira MacDonald Carl Kugler Peter ??? Steve Gebert Randy Turner Paul Moore Scott Issacson The call began at approximately 11:00am (Mountain Daylight Time) with Carl-Uno reviewing the agenda. It was agreed that the two major issues to be discussed were the issue of how to differentiate IPP for filtering purposes, and what to do about TLS. Carl-Uno asked Keith Moore to being the discussion by giving his thoughts on the first issue. In response, Keith Moore said that the goal was to be able to differentiate IPP from normal HTTP traffic going through firewalls. By tradition new services run on different port numbers. Keith's poll of the IESG found general agreement that IPP should run on a new port number. Larry Masinter reviewed his proposal for providing a new scheme name for IPP at the client. In this proposal, IPP as a scheme never appears on the wire. Randy Turner argued that requiring a new port number for IPP would be a hardship on some implementations, specifically where a server is not capabale of listening to multiple ports, ports other than 80. Paul Moore agreed with the idea of a default IPP Port number (as long as could still use port 80), but thought that using IPP as a shorthand notation was nothing more than an end user convenience, and really had nothing to do with the protocol. Keith Moore expressed the opinion that there was benefit to using IPP. Carl-Uno then asked for comments on the proposal to define a new HTTP method, PRINT. Larry Masinter reviewed his recent communication on differences between filtering proxies and forwarding proxies. His claim is that forwarding proxies would all break with definition of a new method. Paul Moore disagreed, indicating that Microsoft's polling of proxy vendors indicated that most proxies would handle a new method without any problem. Larry said he does not believe this is the case. There was some debate about what the out-of box condition of IPP should be, and what impact our direction would have on this. Keith Moore too a very strong position that it was up to the System Adminsitrator to configure things so they worked, our responsibility was to be sure the System Administrator was not surprised. The resulting agreement from this debate was that we would focus on the details of using a new port number and using IPP as a naming scheme, per Larry Masinter's proposal. We would not pursue the definition of a new method. Randy Turner agreed to write up a draft of how this would work. Carl-Uno agreed to take a work item to contact IANA about an IPP port number. We then turned to the TLS discussion. Keith Moore indicated that TLS is currenly hung up wating for documents from the PCIKS group, which are currently in last call. Keith expects the TLS issue to be resolved soon and to have TLS progress down the standards track. Keith said that there is weak agreement in the IETF on doing security negotiation in-band. The idea of having a reserved port for TLS is still under discussion. Keith proposed that IPP use a parameter in the URL to indicate TLS use. After quite a bit of discussion, Keith agreed that he would support the use of SHOULD for IPP client support of TLS. However, he warned that others on the IESG may not approve with that wording. He suggested that we articulate client instances where TLS may not be appropriate, e.g. on a Palm Pilot. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Wed Jun 10 17:39:06 1998 Delivery-Date: Wed, 10 Jun 1998 17:39:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26987 for ; Wed, 10 Jun 1998 17:39:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15359 for ; Wed, 10 Jun 1998 17:41:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02652 for ; Wed, 10 Jun 1998 17:39:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 17:34:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02101 for ipp-outgoing; Wed, 10 Jun 1998 17:29:10 -0400 (EDT) Date: 10 Jun 1998 21:28:11 -0000 Message-ID: <19980610212811.15889.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD> "document-format-supported" [MOD ne In-Reply-To: <3.0.1.32.19980610131705.01139738@garfield> To: ipp@pwg.org Sender: owner-ipp@pwg.org > I agree with Bob that "document-formats-supported" must be invariant with > respect to the "document-format" input parmeter that a client might supply > in a Get-Printer-Attributes request. > > I agree with both Bob and Carl that the Model document needs clarification on > which attributes returned in Get-Printer-Attributes MAY depend on > the value of the "document-format" supplied as an input parameter and > which SHALL NOT depend on the "document-format" supplied, i.e., MUST > be invariant. > > I agree with Carl that all Printer attributes that are Job Template > attributes in the Printer object (xxx-default and xxx-supported in the > Table in Section 4.2) MAY depend on the value of the document-format. Glad we agree on all this. > > Here is an analysis of the remaining Printer Description attributes: > > create operation attribute corresponding Printer attributes vary? > -------------------------- -------------------------------- ---- > attributes-charset charset-configured shall not > charset-supported shall not > attributes-natural-language natural-language-configured shall not > generated-natural-language-supported shall not > printer-uri printer-uri-supported shall not > uri-security-supported shall not > requesting-user-name - > job-name - > ipp-attribute-fidelity pdl-override-supported MAY > document-name - > document-format document-format-default shall not > document-format-supported shall not > document-natural-language - > compression compression-supported MAY > job-k-octets job-k-octets-supported MAY > job-impressions job-impressions-supported MAY > job-media-sheets job-media-sheets-supported MAY > > - printer-driver-installer MAY > - operations-suported shall not > - printer-is-accepting-jobs shall not > - queued-job-count shall not > - color-supported MAY > - reference-uri-schemes-supported MAY? > > > An IPP Printer object SHALL NOT return different values for all other > Printer Description attribute depending on the "document-format" supplied > as an input parameter to the Get-Printer-Attributes operation: > printer-name, printer-location, printer-info, printer-more-info, > printer-make-and-model, printer-more-info-manufacturer, printer-state, > printer-state-reasons, printer-message-from-operator, printer-up-time, > printer-current-time, and multiple-operation-time-out. > Some of these could be debatable. For example, suppose the Postscript interpreter is down but the printer is still capable of printing text/plain jobs. Giving "printer-is-accepting-jobs" Printer scope wouldn't allow a client to discover that text/plain could still be accepted. I doubt this is significant, but I wanted to point it out. > > > Suggested text to be the clarification > I have an alternative wording, which follows. ------------------------------------------------------------------ The following are Printer attributes (and are independent of "document-format"): charset-configured charset-supported natural-language-configured generated-natural-language-supported printer-uri-supported uri-security-supported document-format-default document-format-supported operations-suported printer-is-accepting-jobs queued-job-count printer-name printer-location printer-info printer-more-info printer-make-and-model printer-more-info-manufacturer printer-state printer-state-reasons printer-message-from-operator printer-up-time printer-current-time multiple-operation-time-out A Printer contains one or more Interpreters, selected by the "docment-format" Operation attribute. Multiple document-formats may be associated with one Interpreter. The following are Interpreter attributes: pdl-override-supported compression-supported job-k-octets-supported job-impressions-supported job-media-sheets-supported printer-driver-installer color-supported reference-uri-schemes-supported Also, all Job Template xxx-default and xxx-supported attributes are Interpreter attributes. ------------------------------------------------------------------ > We could add the following to the Get-Printer-Attribute request > under the "document-format" operation attribute description: > > All Printer attributes that are Job Template attributes in the Printer > object (xxx-default and xxx-supported in the Table in Section 4.2) MAY > depend on the value of the "document-format" supplied in the request. > > In addition, the following Printer attributes MAY depend on the value of > the "document-format" supplied: pdl-override-supported, > compression-supported, job-k-octets-supported, job-impressions-supported, > job-media-sheets-supported, printer-driver-installer, color-supported, > reference-uri-schemes-supported(?). An IPP Printer object SHALL NOT return > different values for all other Printer Description attributes depending on > the "document-format" supplied as an input parameter in the > Get-Printer-Attributes request. > > When a new Printer attribute is registered (see section 6), part of its > specification needs to contain the following sentence: > > The value of this attribute returned in a Get-Printer-Attributes > response MAY depend on the "document-format" attribute supplied (see > Section 3.2.5.1). > > If the specification does not, then its value SHALL NOT depend on the > "document-format" supplied in the request. > > When a new Job Template attribute is registered, the value of the Printer > attributes MAY vary with "document-format" supplied in the request > without the specification having to indicate so. > > > > For the 7 or 8 Printer attributes indicated with MAY above, we might want to > add a sentence to each description something like: > > The value of this attribute returned in a Get-Printer-Attributes > response MAY depend on the "document-format" attribute supplied (see > Section 3.2.5.1). > > Comments? > > Tom > > > At 14:47 06/09/1998 PDT, Carl Kugler wrote: > >> --=====================_3129239==_.ALT > >> Content-Type: text/plain; charset="us-ascii" > >> > >> The value of document-format-supported should be all document-formats > >> supported and its value should not be affected by the document-format > >> operation attribute. Otherwise, how does a client determine what > >> document-formats the printer supports. The document-format attribute > should > >> affect other printer attributes returned. Perhaps the model document needs > >> some clarification in this area. > >> > >Okay, that's reasonable. But your reading is a little like saying > "application/vnd.hp-PCL" is a supported document-format value for > "text/plain" Jobs. > > > >So what we have here is a Printer Description Attribute (PDA) which is > invariant with respect to document-format. Are there other PDAs that > should be considered invariant? printer-name? printer-state? > printer-is-accepting-jobs? pdl-override-supported? color-supported? Or can > these be considered attributes of a particular interpreter in a Printer? > Maybe only Printer Job Template attributes are a function of document-format? > > > >> > >> Bob Herriot > >> > > > > -Carl > > > >> > >> > >> At 04:09 PM 6/8/98 , Carl Kugler wrote: > >> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me > to the > >> conclusion that the value of "document-format-supported" in a > >> Get-Printer-Attributes Response will always be either: > >> > > >> >a) a parroting back of the "document-format" supplied in the Request > >> > > >> >or > >> > > >> >b) the Printer's "document-format-default" > >> > > >> >depending on whether or not the client supplied "document-format" in the > >> Request. Am I reading this correctly? > >> > > >> > -Carl > >> > > >> > >> --=====================_3129239==_.ALT > >> Content-Type: text/html; charset="us-ascii" > >> > >> > >> The value of document-format-supported should be all > >> document-formats
> >> supported and its value should not be affected by the document-format > >>
> >> operation attribute. Otherwise, how does a client determine what
> >> document-formats the printer supports. The document-format attribute > >> should
> >> affect other printer attributes returned. Perhaps the model document > >> needs
> >> some clarification in this area.
> >>
> >>
> >> Bob Herriot
> >>
> >>
> >>
> >> At 04:09 PM 6/8/98 , Carl Kugler wrote:
> >> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads > >> me to the conclusion that the value of > >> "document-format-supported" in a Get-Printer-Attributes > >> Response will always be either:
> >> >
> >> >a)  a parroting back of the "document-format" supplied > >> in the Request
> >> >
> >> >or
> >> >
> >> >b) the Printer's "document-format-default"
> >> >
> >> >depending on whether or not the client supplied > >> "document-format" in the Request.  Am I reading this > >> correctly?
> >> >
> >> >    -Carl
> >> >
> >> > >> > >> --=====================_3129239==_.ALT-- > >> > >> > >> > > > > > > > > From ipp-owner@pwg.org Wed Jun 10 17:53:39 1998 Delivery-Date: Wed, 10 Jun 1998 17:53:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27066 for ; Wed, 10 Jun 1998 17:53:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA15462 for ; Wed, 10 Jun 1998 17:56:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03244 for ; Wed, 10 Jun 1998 17:53:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 17:49:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02722 for ipp-outgoing; Wed, 10 Jun 1998 17:43:58 -0400 (EDT) Date: 10 Jun 1998 21:43:32 -0000 Message-ID: <19980610214332.17303.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requ In-Reply-To: <199806100522.WAA24766@slafw.enet.sharplabs.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > Carl, > > Concerning your earlier message about relative URIs... > > I noticed in RFC 2068 the following text: > > To allow for transition to absoluteURIs in all requests in future > versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI > form in requests, even though HTTP/1.1 clients will only generate > them in requests to proxies. > > Is there any way we could use this to our advantage? > No, I don't think so. Even though servers MUST accept absoluteURI form Request-URIs, HTTP/1.1 clients MUST transmit abs_path Request-URIs when talking to an origin server: "The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI... I think you'll find that existing web servers will ACCEPT an absoluteURI Request-URI in an HTTP/1.1 request, but they will try to proxy that request to themselves. > Randy > > > At 04:10 AM 6/10/98 +0000, Carl Kugler wrote: > >> At 06:13 PM 6/9/98 -0700, Paul Moore wrote: > >> > I think that originally "printer-uri" was going to be a "virtual" > >> >attribute, > >> > as you thought. But later (last Fall?) we changed the Model and > >> >Protocol > >> > document so that the "printer-uri" attribute was required to be > >> >supplied > >> > by the client and include in the operation attribute group in the > >> >IPP packet > >> > (which is defined by the application/ipp MIME type). The thinking > >> > was that we wanted the IPP packet and MIME type to be independent > >> > of the transport. So that we could send IPP over any transport, > >> >such > >> > as SMTP or FTP, for examples. > >> > > >> >OK. So we are saying that the URIs IN the protocol are NOT to be used as > >> >transport adresses. They are in effect opaque cookies that the client must > >> >do nothing with except send them back to the printer. They are really > >> >job-name and printer-name. Either that or we explicitly state that these > >> >fields only make sense in an HTTP-enabled environment (they cannot > therefore > >> >be mandatory for a universal protocol). > >> > > >> > >> No, the URI is actually a URL that is to be interpreted according to > >> "standard" rules for interpreting URLs (not sure if there is a "formal" > >> standard for this). These resource identifiers are not opaque to clients. > >> This does not mean that we are NOT transport independent, it only means we > >> are identifying resources that must be accessed via the transport (scheme) > >> that is specified in the URL. Since we have "modeled" IPP using URI/URL > >> resource identifiers, all transports used by IPP should have a URL scheme > >> defined. I don't think this is a negative constraint BTW. I consider our > >> selection of URL strings as resource identifiers one of the more compact > >> and powerful capabilities of the model (and protocol). > >> > >> The only problem we have identified so far is what happens when "http" is > >> used as the scheme for IPP resources, and between the client and the > >> resource, there is one or more proxies involved. Note, that this is a > >> problem only in the case of HTTP as the transport. > >> > >Another problem is that PRO requires the HTTP Request-URI and the target URI > (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 > clients aren't allowed to send absolute Request-URIs unless they're talking to > a proxy. And proxies rewrite the Request-URI. > > > >> For reference purposes, can someone restate the problem (actually the > >> scenario) with proxies that we are trying to address. I think some > >> solutions that have recently hit the list are bordering on "throwing the > >> baby out with the bath water". Any concrete scenario examples would be much > >> appreciated, as I am still on the learning curve with HTTP proxy behavior. > >> > >> Thanks > >> > >> Randy > >> > >> > >> > >> > > > > > From ipp-owner@pwg.org Wed Jun 10 18:08:38 1998 Delivery-Date: Wed, 10 Jun 1998 18:08:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27144 for ; Wed, 10 Jun 1998 18:08:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15559 for ; Wed, 10 Jun 1998 18:11:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03871 for ; Wed, 10 Jun 1998 18:08:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 18:04:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03345 for ipp-outgoing; Wed, 10 Jun 1998 18:01:31 -0400 (EDT) To: ipp@pwg.org In-reply-to: <5030100021603541000002L012*@MHS> (message from Roger K Debry on Wed, 10 Jun 1998 14:08:31 PDT) Subject: IPP> PRINT => "Cache Detected Error" or "Method not supported" From: Larry Masinter Message-Id: <98Jun10.150050pdt."1585114"@skaskatch.parc.xerox.com> Date: Wed, 10 Jun 1998 15:00:50 PDT Sender: owner-ipp@pwg.org I checked out three different proxies installed in Xerox, two of them different implementations of squid and one implementation of Netscape-Proxy. In each case, I attempted to make a connection to a host which supported the 'PRINT' method, namely: http://sandbox.parc.xerox.com/cgi-bin/null (this web server supports the PRINT method in a particularly stupid way, but that's besides the point). With the Netscape server, I got 405 "Method not allowed", but with the squid servers, I got "400 Cache Detected Error". Of course, 'POST' works fine for outbound HTTP traffic through both of these services. ================================================================ PRINT http://sandbox.parc.xerox.com/cgi-bin/null HTTP/1.1 Host: sandbox.parc.xerox.com Connection: close HTTP/1.0 405 Method not allowed Mime-version: 1.0 Proxy-agent: Netscape-Proxy/2.53 Content-type: text/html Method not supported

Method PRINT unknown or not supported

Proxy server at mc0300ux01.mc.xerox.com on port 8000
Connection closed by foreign host. Process telnet-www.mc.xerox.com 8000 exited abnormally with code 1 ================================================================ PRINT http://sandbox.xerox.com/cgi-bin/null HTTP/1.1 HTTP/1.0 400 Cache Detected Error Content-type: text/html ERROR: Invalid HTTP Request

ERROR

Invalid HTTP Request

PRINT http://sandbox.xerox.com/cgi-bin/null HTTP/1.1

Generated by squid/1.1.15@wwwproxy0.parc.xerox.com
Connection closed by foreign host. Process telnet-wwwproxy0 8000 exited abnormally with code 1 ================================================================ From ipp-owner@pwg.org Wed Jun 10 18:18:41 1998 Delivery-Date: Wed, 10 Jun 1998 18:18:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27179 for ; Wed, 10 Jun 1998 18:18:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15601 for ; Wed, 10 Jun 1998 18:21:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04487 for ; Wed, 10 Jun 1998 18:18:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 18:14:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03962 for ipp-outgoing; Wed, 10 Jun 1998 18:12:39 -0400 (EDT) Date: 10 Jun 1998 22:12:12 -0000 Message-ID: <19980610221212.20547.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Identifying jobs in requests In-Reply-To: <005701bd948b$8fb60e40$1e0564d2@tulip> To: ipp@pwg.org Sender: owner-ipp@pwg.org > From Carl Kugler's response to my message from last week, I realized that > having > urls denoting jobs without requiring an extra cgi to serve them is trivial: > http://ipp.cgi?jobId=2 (as opposed to http://ipp.cgi/2). > > It brings a question whether job is not an "artificial" target, since > usually, a request > to cancel a job or get job attributes will be served by a cgi representing > the printer where > the job was created. > > Whether the target (job-uri or printer-uri or printer-uri + job-id) is taken > out of IPP layer or not, > it would be more simple to have just one possible kind of target: > printer-uri, where job-id would > be considered an operation attribute. I agree. But, having job-uri does permit more flexibility in the implementation, for load-balancing, etc. For example, a Printer could hand off a Job to a different Printer and return a job-uri that actually addresses the new Printer. > > If the target is taken out of IPP layer and will be used only in the > transport layer, not having job-uri > as a possible target would probably make addressing possible for other > transports, e.g. > mailto:ipp@printingorg.com, where specification of arguments is not allowed > (according to rfc1738). The current model lets you do this with job-id. > > > Regarding the message below, I don't understand: > >Another problem is that PRO requires the HTTP Request-URI and the target > URI (embedded in the application/ipp) to be the same (absolute) URIs, but > HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're > talking to a proxy. And proxies rewrite the Request-URI. > > In what respect are HTTP/1.1 clients not allowed to send absolute > Request-URIs? I didn't see a mention of that in RFC2068. > Here's the quote: "The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI... abs_path is a form of Relative URI (as opposed to Absoluter URI). If you send an absolute Request-URI to a web server it will probably try to proxy the request, which is not what you want if you're talking to the "origin" server. > > Peter > > > -----Original Message----- > From: Carl Kugler > To: ipp@pwg.org > Date: Tuesday, June 09, 1998 9:18 PM > Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requests > > > >> At 06:13 PM 6/9/98 -0700, Paul Moore wrote: > >> > I think that originally "printer-uri" was going to be a "virtual" > >> >attribute, > >> > as you thought. But later (last Fall?) we changed the Model and > >> >Protocol > >> > document so that the "printer-uri" attribute was required to be > >> >supplied > >> > by the client and include in the operation attribute group in the > >> >IPP packet > >> > (which is defined by the application/ipp MIME type). The thinking > >> > was that we wanted the IPP packet and MIME type to be independent > >> > of the transport. So that we could send IPP over any transport, > >> >such > >> > as SMTP or FTP, for examples. > >> > > >> >OK. So we are saying that the URIs IN the protocol are NOT to be used as > >> >transport adresses. They are in effect opaque cookies that the client > must > >> >do nothing with except send them back to the printer. They are really > >> >job-name and printer-name. Either that or we explicitly state that these > >> >fields only make sense in an HTTP-enabled environment (they cannot > therefore > >> >be mandatory for a universal protocol). > >> > > >> > >> No, the URI is actually a URL that is to be interpreted according to > >> "standard" rules for interpreting URLs (not sure if there is a "formal" > >> standard for this). These resource identifiers are not opaque to clients. > >> This does not mean that we are NOT transport independent, it only means > we > >> are identifying resources that must be accessed via the transport > (scheme) > >> that is specified in the URL. Since we have "modeled" IPP using URI/URL > >> resource identifiers, all transports used by IPP should have a URL scheme > >> defined. I don't think this is a negative constraint BTW. I consider our > >> selection of URL strings as resource identifiers one of the more compact > >> and powerful capabilities of the model (and protocol). > >> > >> The only problem we have identified so far is what happens when "http" is > >> used as the scheme for IPP resources, and between the client and the > >> resource, there is one or more proxies involved. Note, that this is a > >> problem only in the case of HTTP as the transport. > >> > >Another problem is that PRO requires the HTTP Request-URI and the target > URI (embedded in the application/ipp) to be the same (absolute) URIs, but > HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're > talking to a proxy. And proxies rewrite the Request-URI. > > > >> For reference purposes, can someone restate the problem (actually the > >> scenario) with proxies that we are trying to address. I think some > >> solutions that have recently hit the list are bordering on "throwing the > >> baby out with the bath water". Any concrete scenario examples would be > much > >> appreciated, as I am still on the learning curve with HTTP proxy > behavior. > >> > >> Thanks > >> > >> Randy > >> > >> > >> > >> > > > > > > > From ipp-owner@pwg.org Wed Jun 10 18:49:00 1998 Delivery-Date: Wed, 10 Jun 1998 18:49:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27305 for ; Wed, 10 Jun 1998 18:49:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15749 for ; Wed, 10 Jun 1998 18:51:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05127 for ; Wed, 10 Jun 1998 18:48:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 18:44:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04609 for ipp-outgoing; Wed, 10 Jun 1998 18:43:07 -0400 (EDT) To: ipp@pwg.org Subject: IPP> "breaks all known proxies" From: Larry Masinter Message-Id: <98Jun10.154242pdt."1585114"@skaskatch.parc.xerox.com> Date: Wed, 10 Jun 1998 15:42:42 PDT Sender: owner-ipp@pwg.org The claims that a new scheme 'breaks all known proxies' seems to be disingenous. The squid server (http://squid.nlanr.net/Squid/1.1/Release-Notes-1.1.txt) contains a URL redirector capability that would easily allow a squid proxy to be reconfigured to redirect "ipp" requests to "http" requests, for example, using a simple rewrite rule. On the other hand, squid doesn't seem to have any way to rewrite methods. The W3C httpd server, implemented as a proxy, similarly has a configuration file which will allow it to map new URL schemes (http://www.w3.org/Daemon/User/Config/Rules.html). While there is also support for enabling other methods (http://www.w3.org/Daemon/User/Config/General.html#Enable), it says By default GET, HEAD and POST are enabled, and the rest are disabled. so a PRINT method would be disabled through all those proxy servers if installed with the default (as most are). The commercial products listed in http://www.w3.org/Protocols/HTTP/Forum/Reports/ as proxies supporting HTTP/1.1 don't have their configuration documentation online for me to determine whether they work with PRINT; it would seem from looking at the CL-HTTP documentation that it doesn't, for example, in proxy mode. I'm investigating http://lpwa.com:8000 to see if it will pass a PRINT method vs. a POST method. Larry From ipp-owner@pwg.org Wed Jun 10 18:54:22 1998 Delivery-Date: Wed, 10 Jun 1998 18:54:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27332 for ; Wed, 10 Jun 1998 18:54:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA15793 for ; Wed, 10 Jun 1998 18:56:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05762 for ; Wed, 10 Jun 1998 18:54:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 18:50:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04599 for ipp-outgoing; Wed, 10 Jun 1998 18:41:21 -0400 (EDT) Date: 10 Jun 1998 22:40:51 -0000 Message-ID: <19980610224051.22745.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri ope In-Reply-To: <3.0.1.32.19980610084912.01136c38@garfield> To: ipp@pwg.org Sender: owner-ipp@pwg.org Can't we depend on the transport to get the request all the way to the appropriate Printer? For example, couldn't each Printer on a host have a unique email address, e.g. prt015@myhost.com, prt030@myhost.com, etc.? For FTP, couldn't each printer have a unique directory? TCP/IP a unique port? HTTP a unique abs_path segment? Why do we need the extra level of indirection provided by "printer-name"? Tom Hastings wrote: > In case we do get time to: > > At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: > >If we end up with time on our hands, we can always devote it to debate > >if we keep URLs in application/ipp :-) > > There seems to be a growing consensus that we should remove the (redundant) > printer-uri and job-uri operation attribute targets from the operation > attributes group in IPP requests. This would be a change to sections > 3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version) > and section 15.3.4.3. Then we would be depending on the transport > to get the request to the right place. There would be no other changes > to the application/ipp part of requests and no changes to responses at all. > For operations on jobs, the only form would be the "job-id" (integer) in the > Operation attribute group in the request, so this change would be eliminating > one of the two repsentations for operations on jobs (a good simplification). > > Recall that the reason that we added the printer-uri and job-uri targets > to the operation attribute group in requests was in the "name of > transport independence" (a good thing). But what do we really mean by making > application/ipp "transport independent"? One could argue that by removing > the "printer-uri" and "job-uri" targets operation attributes that we are > making the application/ipp MIME media type more transport independent > and we are depending on the transport to get the request to the intended > target. > > To understand better what transport-independence really means, imagine > that we are trying to sent IPP requests over other transports, such as > SMTP, FTP, and TCP/IP. We would depend on those transports to get the > request to some destination that knows what to do with the request. > For requests on jobs (Send-Document, Send-URI, Cancel-Job, > Get-Job-Attributes), the "job-id" in the application/ipp tells the > recipient which job the operations is upon. We don't have a similar > operation attribute for operations on printers (Print-Job, Print-URI, > Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs). > We could add the existing "printer-name" Printer attribute as an > Operation attribute for operations on Printers. Then the > transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any > IPP request knows which Printer or Job object the operation is intended > by simply looking at the "printer-name" or "job-id" operation attribute > and can ignore any transport request URI. > > Extending Scott's home mail delivery analogy, the U.S. Postal service > is a transport that delivers to your house any mail addressed to your house > without looking at the name of the addressee. The recipient (familiy) then > looks at the name and knows for whom the mail is really for (including > someone who no longer lives there - return to sender). > > I'm not sure how/whether removing these "printer-uri" and "job-uri" > operation attribute targets from the application/ipp MIME type requests > affects client communication with proxies in which the http URIs get > changed from absolute to relative in the HTTP header. But it seems like > there might be no problem, since HTTP request headers are the province > of the transport, which includes proxies and they can do what ever they > like, including changing absolute URIs to relative URIs. Such changes > only affect getting the message to the recipient. The recipient only > looks at the application/ipp operation attributes to know which printer > or job is really the intended object instance. > > Tom > > > From ipp-owner@pwg.org Wed Jun 10 19:03:50 1998 Delivery-Date: Wed, 10 Jun 1998 19:03:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27373 for ; Wed, 10 Jun 1998 19:03:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15825 for ; Wed, 10 Jun 1998 19:06:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06355 for ; Wed, 10 Jun 1998 19:03:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 18:59:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05821 for ipp-outgoing; Wed, 10 Jun 1998 18:55:42 -0400 (EDT) Date: 10 Jun 1998 22:55:16 -0000 Message-ID: <19980610225516.23918.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri In-Reply-To: <007101bd948e$b0cfb0b0$1e0564d2@tulip> To: ipp@pwg.org Sender: owner-ipp@pwg.org > > -----Original Message----- > From: Tom Hastings > To: ipp@pwg.org > Date: Wednesday, June 10, 1998 9:09 AM > Subject: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute > targets > > > >In case we do get time to: > > > >At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: > >>If we end up with time on our hands, we can always devote it to debate > >>if we keep URLs in application/ipp :-) > I'm not sure how/whether removing these "printer-uri" and "job-uri" > >operation attribute targets from the application/ipp MIME type requests > >affects client communication with proxies in which the http URIs get > >changed from absolute to relative in the HTTP header. But it seems like > >there might be no problem, since HTTP request headers are the province > >of the transport, which includes proxies and they can do what ever they > >like, including changing absolute URIs to relative URIs. Such changes > >only affect getting the message to the recipient. The recipient only > >looks at the application/ipp operation attributes to know which printer > >or job is really the intended object instance. > > > I was addressing this scenario in my previous e-mail today, > The job-id will be an operation attribute, so job addressing within a > printer should be > taken care of. > To address the printer, we would have to decide on one of two rules : > 1) * the entity processing the request is representing only one printer and > no additional attribute is necessary > 2) * or as Tom mentions above, printer-name should assist in addressing the > target > > 2) seems more flexible. > > Peter > With 2, were're back to having an IPP Server in the model. This Server receives a request, reads the application/ipp content, and forwards the request to the Printer specified by the "printer-name" IPP attribute. I'm not saying this is a bad thing, but I thought this decision was already made back in March of 1997. > > > > From ipp-owner@pwg.org Wed Jun 10 19:23:54 1998 Delivery-Date: Wed, 10 Jun 1998 19:23:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27438 for ; Wed, 10 Jun 1998 19:23:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA15923 for ; Wed, 10 Jun 1998 19:26:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06986 for ; Wed, 10 Jun 1998 19:23:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 19:19:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA06468 for ipp-outgoing; Wed, 10 Jun 1998 19:14:46 -0400 (EDT) Message-Id: <3.0.5.32.19980610161244.01412b10@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Jun 1998 16:12:44 PDT To: "Carl Kugler" , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri ope In-Reply-To: <19980610224051.22745.qmail@m2.findmail.com> References: <3.0.1.32.19980610084912.01136c38@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 03:40 PM 6/10/98 PDT, Carl Kugler wrote: > >Can't we depend on the transport to get the request all the way to the appropriate Printer? For example, couldn't each Printer on a host have a unique email address, e.g. prt015@myhost.com, prt030@myhost.com, etc.? For FTP, couldn't each printer have a unique directory? TCP/IP a unique port? HTTP a unique abs_path segment? Why do we need the extra level of indirection provided by "printer-name"? Carl, I agree with you. I do not think that we need another level of addressing; the URI can be extended to any level within a print server to address individual printers, if needed. Carl-Uno > >Tom Hastings wrote: >> In case we do get time to: >> >> At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote: >> >If we end up with time on our hands, we can always devote it to debate >> >if we keep URLs in application/ipp :-) >> >> There seems to be a growing consensus that we should remove the (redundant) >> printer-uri and job-uri operation attribute targets from the operation >> attributes group in IPP requests. This would be a change to sections >> 3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version) >> and section 15.3.4.3. Then we would be depending on the transport >> to get the request to the right place. There would be no other changes >> to the application/ipp part of requests and no changes to responses at all. >> For operations on jobs, the only form would be the "job-id" (integer) in the >> Operation attribute group in the request, so this change would be eliminating >> one of the two repsentations for operations on jobs (a good simplification). >> >> Recall that the reason that we added the printer-uri and job-uri targets >> to the operation attribute group in requests was in the "name of >> transport independence" (a good thing). But what do we really mean by making >> application/ipp "transport independent"? One could argue that by removing >> the "printer-uri" and "job-uri" targets operation attributes that we are >> making the application/ipp MIME media type more transport independent >> and we are depending on the transport to get the request to the intended >> target. >> >> To understand better what transport-independence really means, imagine >> that we are trying to sent IPP requests over other transports, such as >> SMTP, FTP, and TCP/IP. We would depend on those transports to get the >> request to some destination that knows what to do with the request. >> For requests on jobs (Send-Document, Send-URI, Cancel-Job, >> Get-Job-Attributes), the "job-id" in the application/ipp tells the >> recipient which job the operations is upon. We don't have a similar >> operation attribute for operations on printers (Print-Job, Print-URI, >> Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs). >> We could add the existing "printer-name" Printer attribute as an >> Operation attribute for operations on Printers. Then the >> transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any >> IPP request knows which Printer or Job object the operation is intended >> by simply looking at the "printer-name" or "job-id" operation attribute >> and can ignore any transport request URI. >> >> Extending Scott's home mail delivery analogy, the U.S. Postal service >> is a transport that delivers to your house any mail addressed to your house >> without looking at the name of the addressee. The recipient (familiy) then >> looks at the name and knows for whom the mail is really for (including >> someone who no longer lives there - return to sender). >> >> I'm not sure how/whether removing these "printer-uri" and "job-uri" >> operation attribute targets from the application/ipp MIME type requests >> affects client communication with proxies in which the http URIs get >> changed from absolute to relative in the HTTP header. But it seems like >> there might be no problem, since HTTP request headers are the province >> of the transport, which includes proxies and they can do what ever they >> like, including changing absolute URIs to relative URIs. Such changes >> only affect getting the message to the recipient. The recipient only >> looks at the application/ipp operation attributes to know which printer >> or job is really the intended object instance. >> >> Tom >> >> >> > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 10 21:45:25 1998 Delivery-Date: Wed, 10 Jun 1998 21:45:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28012 for ; Wed, 10 Jun 1998 21:45:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA16320 for ; Wed, 10 Jun 1998 21:47:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07692 for ; Wed, 10 Jun 1998 21:45:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 10 Jun 1998 21:39:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA07141 for ipp-outgoing; Wed, 10 Jun 1998 21:37:17 -0400 (EDT) To: Larry Masinter cc: ipp@pwg.org, ietf-http-ext@w3.org Subject: IPP> Re: On the harm of adding new methods In-reply-to: Your message of "Wed, 10 Jun 1998 08:46:39 PDT." <000f01bd9486$f504c160$aa66010d@copper.parc.xerox.com> Date: Wed, 10 Jun 1998 18:29:05 -0700 From: "Roy T. Fielding" Message-ID: <9806101829.aa17430@paris.ics.uci.edu> Sender: owner-ipp@pwg.org I disagree with some of Larry's points. The design of HTTP was intended for method extension whenever there is a standardizable semantics that can be shared between client and server (and, most importantly, between those agents and any intermediaries that may be between them). >There are two functions of a proxy: filtering and forwarding. >A filter decides whether or not to accept a request, and a forwarder >actually forwards the request and processes the result; forwarding >implements caching, protocol translation, tunneling, while filtering >is generally a binary "allowed" or "not allowed". There are some >forwarders that do rewriting in lieu of filtering (allow but modify). And also those that do transformation and forwarding, though that's not an issue here. Basically, there exist active and passive intermediaries. >Forwarders MUST actually understand methods, because -- unfortunately -- >the meaning of HTTP headers and responses differ based on the method >of the request (e.g., Content-Length for HEAD vs GET). Many forwarding >systems will not accept new methods gracefully. Actually, that is only true for HEAD and GET -- all header fields have the same meaning for all other methods. HEAD is the only method for which Content-Length has a different meaning, and no new method can change the message length calculation. GET/HEAD is the only method for which conditional request header fields have the 304 meaning, whereas for all other methods they have the 412 meaning. I can't think of any other exceptions at the moment -- if any have been added in the past year or so, they need to be removed. HTTP/1.1 is designed to enable forwarding without understanding the method semantics, provided that such forwarding fits within the security policy set at the intermediary. >Any new METHOD in HTTP is a serious modification to the protocol, because >the forwarding function must be aware of it. A new content-type, however, >can be as easily recognized in the filter layer as a new method, but >requires NO changes to the forwarding function. Many filters already filter >on content-type anyway. On the contrary, the forwarding function is based on the URI, not on the method or media type. The filtering function (or, more accurately, the routing function) is based on everything in the request. What you are saying is that it is better for filtering to eliminate one of the criteria by which an intermediary can do filtering, in this case the one that is easiest to find and interpret quickly in an HTTP request. I think that is a bad design when there are semantics that can be easily distinguished via the method. >In the case of IPP, it is perfectly adequate to filter on content-type, >since all IPP content is carried in application/IPP. The arguments for >adding a new method (that it is somehow 'easier' to filter on the first >few bytes of the protocol) are specious because most filters that are >looking at the protocol at all are looking at content-type. So the >"firewall filtering" rationale just doesn't hold as a reason for adding >new methods. Well, it seems I disagree with everyone on this part. There is nothing special about Internet printing that requires independent firewall semantics. Nothing. A printer is a network resource that must be protected like all other network resources -- as a resource. There is no difference between sending a POST full of data to an HTTP server acting as a printer gateway and sending a POST full of data to the printer directly. Treating the two as being different violates one of the basic principles of the Web architecture. That does not mean we should add a PRINT method to the protocol. PRINT does not say anything semantically interesting. Why should the client care what mechanism is being used behind the curtains? Should the semantics need to change if the server is actually a pipeline like client ---- proxy ----- fax ----- fax ---- printer If you look at any modern operating system design, you will find such differences abstracted away so that every application does not need separate interface protocols for every device type. Why should the Internet be any different? RENDER would be a more semantically meaningful choice, since what the client is saying is that it wants the service to render the data as specified and then discard it. However, the reason for defining this new method has nothing to do with firewall filtering. The IPP design is poor because it conflates an intended action with the transfer syntax of the data, thus reducing the normal mechanisms of allowing selective access to a printer's resources using any of the independently defined security mechanisms of HTTP. While it may be nice to think of Internet printing as a layered protocol on top of HTTP, the result is something that is neither efficient nor capable of reusing many of the advantages of HTTP. Instead, printing should have been designed as a service with a defined resource model; standard Web agents could then manipulate that resource model using the same protocols as everyone else's resources. For those cases where data and control information is to be sent in one action, an application-independent transfer syntax should be used to group them (a la multipart/related). Of course, there is nothing to prevent such an implementation from coexisting with IPP, so I am not suggesting that IPP be changed at this time. Attempting to isolate printer services from other services using any of the options suggested (new URI scheme, separate port, new method, obscure media type) is ultimately futile. None of these provide anything useful in the way of securing access to resources; the first two in particular are a total waste of time since the "http" URI scheme is port-independent. The only thing you accomplish is making the implementations more complicated. Control of network resource access is already provided at the URI level and in the underlying protocol layers upon which the HTTP communication takes place. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(949)824-1715 http://www.ics.uci.edu/~fielding/ From ipp-owner@pwg.org Thu Jun 11 12:14:47 1998 Delivery-Date: Thu, 11 Jun 1998 12:14:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA21348 for ; Thu, 11 Jun 1998 12:14:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA19080 for ; Thu, 11 Jun 1998 12:17:05 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA09228 for ; Thu, 11 Jun 1998 12:14:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 12:05:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA08658 for ipp-outgoing; Thu, 11 Jun 1998 12:02:29 -0400 (EDT) From: Harry Lewis To: , Cc: , Subject: Re: IPP> Re: On the harm of adding new methods Message-ID: <5030100021650031000002L012*@MHS> Date: Thu, 11 Jun 1998 12:00:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21348 Roy, thanks for commenting on some of the last remaining issues with IPP and the current recommendation of our area director to specify a default port and a new name for the URI scheme. I am most likely not as knowledgeable as you regarding HTTP, it's design and various uses, so I would like to ask for some clarifications and share some observations. You said >On the contrary, the forwarding function is based on the URI, >not on the method or media type. The filtering function >(or, more accurately, the routing function) is based on >everything in the request. I should interpret this as "anything in the request might be useful for filtering", right? I don't think I should read this as "all (filtering) routers always use everything in the request as a filter", right? Larry said >In the case of IPP, it is perfectly adequate to filter on >content-type, since all IPP content is carried in application/IPP. To which you replied >There is nothing special about Internet printing that requires >independent firewall semantics. Since media-type is part of "everything in the request"... why do you refer to this recommendation as "independent firewall semantics"? It seems valid for Larry to point out that mime-type is consistent for IPP and, therefore, can be considered a reliable filter. I don't think anyone is recommending the treatment of POST to an HTTP server (acting as a print server) any differently than POST directly to a printer or differently from any POST to any HTTP server, for that matter. Just, if you want to filter on mime-type, you can. You wrap up with two additional points (paraphrased): 1. Because IPP is mapped to HTTP, it does not allow selective access to the printer's resources. IPP allows access to resources such as configuration or job information, regardless of the protocol mapping. Is this what you are referring to? What other resources of the printer do you want to access independently? Are you thinking of things like firmware refresh or font libraries? 2. Control of network resource access is already provided at the URI level and in the underlying protocol layers upon which HTTP takes place. Right... doesn't this confirm or choice of HTTP as the initial mapping? Harry Lewis owner-ipp@pwg.org on 06/10/98 07:46:14 PM Please respond to owner-ipp@pwg.org To: masinter@parc.xerox.com cc: ietf-http-ext@w3.org, ipp@pwg.org Subject: IPP> Re: On the harm of adding new methods I disagree with some of Larry's points. The design of HTTP was intended for method extension whenever there is a standardizable semantics that can be shared between client and server (and, most importantly, between those agents and any intermediaries that may be between them). >There are two functions of a proxy: filtering and forwarding. >A filter decides whether or not to accept a request, and a forwarder >actually forwards the request and processes the result; forwarding >implements caching, protocol translation, tunneling, while filtering >is generally a binary "allowed" or "not allowed". There are some >forwarders that do rewriting in lieu of filtering (allow but modify). And also those that do transformation and forwarding, though that's not an issue here. Basically, there exist active and passive intermediaries. >Forwarders MUST actually understand methods, because -- unfortunately -- >the meaning of HTTP headers and responses differ based on the method >of the request (e.g., Content-Length for HEAD vs GET). Many forwarding >systems will not accept new methods gracefully. Actually, that is only true for HEAD and GET -- all header fields have the same meaning for all other methods. HEAD is the only method for which Content-Length has a different meaning, and no new method can change the message length calculation. GET/HEAD is the only method for which conditional request header fields have the 304 meaning, whereas for all other methods they have the 412 meaning. I can't think of any other exceptions at the moment -- if any have been added in the past year or so, they need to be removed. HTTP/1.1 is designed to enable forwarding without understanding the method semantics, provided that such forwarding fits within the security policy set at the intermediary. >Any new METHOD in HTTP is a serious modification to the protocol, because >the forwarding function must be aware of it. A new content-type, however, >can be as easily recognized in the filter layer as a new method, but >requires NO changes to the forwarding function. Many filters already filter >on content-type anyway. On the contrary, the forwarding function is based on the URI, not on the method or media type. The filtering function (or, more accurately, the routing function) is based on everything in the request. What you are saying is that it is better for filtering to eliminate one of the criteria by which an intermediary can do filtering, in this case the one that is easiest to find and interpret quickly in an HTTP request. I think that is a bad design when there are semantics that can be easily distinguished via the method. >In the case of IPP, it is perfectly adequate to filter on content-type, >since all IPP content is carried in application/IPP. The arguments for >adding a new method (that it is somehow 'easier' to filter on the first >few bytes of the protocol) are specious because most filters that are >looking at the protocol at all are looking at content-type. So the >"firewall filtering" rationale just doesn't hold as a reason for adding >new methods. Well, it seems I disagree with everyone on this part. There is nothing special about Internet printing that requires independent firewall semantics. Nothing. A printer is a network resource that must be protected like all other network resources -- as a resource. There is no difference between sending a POST full of data to an HTTP server acting as a printer gateway and sending a POST full of data to the printer directly. Treating the two as being different violates one of the basic principles of the Web architecture. That does not mean we should add a PRINT method to the protocol. PRINT does not say anything semantically interesting. Why should the client care what mechanism is being used behind the curtains? Should the semantics need to change if the server is actually a pipeline like client ---- proxy ----- fax ----- fax ---- printer If you look at any modern operating system design, you will find such differences abstracted away so that every application does not need separate interface protocols for every device type. Why should the Internet be any different? RENDER would be a more semantically meaningful choice, since what the client is saying is that it wants the service to render the data as specified and then discard it. However, the reason for defining this new method has nothing to do with firewall filtering. The IPP design is poor because it conflates an intended action with the transfer syntax of the data, thus reducing the normal mechanisms of allowing selective access to a printer's resources using any of the independently defined security mechanisms of HTTP. While it may be nice to think of Internet printing as a layered protocol on top of HTTP, the result is something that is neither efficient nor capable of reusing many of the advantages of HTTP. Instead, printing should have been designed as a service with a defined resource model; standard Web agents could then manipulate that resource model using the same protocols as everyone else's resources. For those cases where data and control information is to be sent in one action, an application-independent transfer syntax should be used to group them (a la multipart/related). Of course, there is nothing to prevent such an implementation from coexisting with IPP, so I am not suggesting that IPP be changed at this time. Attempting to isolate printer services from other services using any of the options suggested (new URI scheme, separate port, new method, obscure media type) is ultimately futile. None of these provide anything useful in the way of securing access to resources; the first two in particular are a total waste of time since the "http" URI scheme is port-independent. The only thing you accomplish is making the implementations more complicated. Control of network resource access is already provided at the URI level and in the underlying protocol layers upon which the HTTP communication takes place. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(949)824-1715 http://www.ics.uci.edu/~fielding/ From ipp-owner@pwg.org Thu Jun 11 14:30:14 1998 Delivery-Date: Thu, 11 Jun 1998 14:30:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23022 for ; Thu, 11 Jun 1998 14:30:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19900 for ; Thu, 11 Jun 1998 14:32:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09953 for ; Thu, 11 Jun 1998 14:30:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 14:25:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09393 for ipp-outgoing; Thu, 11 Jun 1998 14:19:37 -0400 (EDT) From: koen@win.tue.nl (Koen Holtman) Message-Id: <199806111819.UAA22553@wsooti08.win.tue.nl> Subject: IPP> Re: On the harm of adding new methods To: fielding@kiwi.ics.uci.edu (Roy T. Fielding) Date: Thu, 11 Jun 1998 20:19:11 +0200 (MET DST) Cc: masinter@parc.xerox.com, ipp@pwg.org, ietf-http-ext@w3.org In-Reply-To: <9806101829.aa17430@paris.ics.uci.edu> from "Roy T. Fielding" at Jun 10, 98 06:29:05 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ipp@pwg.org Roy T. Fielding: > [Larry Masinter:] >>Forwarders MUST actually understand methods, because -- unfortunately -- >>the meaning of HTTP headers and responses differ based on the method >>of the request (e.g., Content-Length for HEAD vs GET). Many forwarding >>systems will not accept new methods gracefully. > >Actually, that is only true for HEAD and GET -- all header fields have >the same meaning for all other methods. [...] > I can't think of any other >exceptions at the moment -- if any have been added in the past year >or so, they need to be removed. I just checked the latest revision of the spec and no other exceptions have been added. Also, reviewing the material in sections 4.3 and 4.4, I conclude that it is possible to make an HTTP/1.1 forwarder which will correctly forward any 1.1 message even if it has an unknown new method. This is of course as it should be: the spec would be broken otherwise. Koen. From ipp-owner@pwg.org Thu Jun 11 14:49:05 1998 Delivery-Date: Thu, 11 Jun 1998 14:49:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23229 for ; Thu, 11 Jun 1998 14:49:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA19988 for ; Thu, 11 Jun 1998 14:51:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA10553 for ; Thu, 11 Jun 1998 14:48:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 14:45:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA10029 for ipp-outgoing; Thu, 11 Jun 1998 14:39:11 -0400 (EDT) Message-Id: <3.0.5.32.19980611113623.01110100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Jun 1998 11:36:23 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Protocol Action: Guide for Internet Standards Writers to BCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Editors and other text contributors, This guide document is now official. We should make sure that we do not violate any of the rules to ensure that we get our documents smoothly through the RFC editor. Carl-Uno >To: IETF-Announce:; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: stdguide@midnight.com >From: The IESG >Subject: Protocol Action: Guide for Internet Standards Writers to BCP >Date: Thu, 11 Jun 1998 05:24:09 PDT >Sender: scoya@CNRI.Reston.VA.US > > > >The IESG has approved the Internet-Draft Guide for Internet Standards >Writers as a BCP. This document is >the product of the Guide for Internet Standards Writers Working Group. >The IESG contact person is Fred Baker. > > >Technical Summary > > This document is a guide for Internet standard writers. It defines > those characteristics that make standards coherent, unambiguous, and > easy to interpret. Also, it singles out usage believed to have led > to unclear specifications, resulting in non-interoperable > interpretations in the past. These guidelines are to be used with > RFC 1543, Instructions to RFC Authors, and with other documents, such > as the > >Working Group Summary > > The working group was chartered to "...provide a forum for implementers, > testers, and users of current Internet standard protocols to provide > feedback on the standards themselves; i.e., on what aspects of the > documents defining the standards have assisted or hindered the > implementation, test, and use of those protocols." > > It in fact provided that forum, and came to consensus on this set of > recommendations. > >Protocol Quality > > The specification was reviewed by Mike O'Dell. Specifications written > October 1995 have been affected by developments in this draft, and the > sense of the IESG is that to the extent that they have, they have been > improved. > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 11 15:44:52 1998 Delivery-Date: Thu, 11 Jun 1998 15:44:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24078 for ; Thu, 11 Jun 1998 15:44:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA20386 for ; Thu, 11 Jun 1998 15:47:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA11259 for ; Thu, 11 Jun 1998 15:44:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 15:40:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA10707 for ipp-outgoing; Thu, 11 Jun 1998 15:36:24 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Firewalls etc. Date: Thu, 11 Jun 1998 12:36:14 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org It became clear to me during the last tele conf that we need to clearly distinguish two cases in this discussion. 1. A user inside a corporation sending print commands out into the internet. This is the one I was always talking about 2. A printer inside a corporation being accessed from outside. It was clear to me that this is what some others were talking about I think that these are two very different things and we have not be clear about what is desirable, acceptable, etc. in each case. Also I think that some people have been discussing #1 with people who think that they are discussing #2 (I certainly discovered that I was) ---------------------------------------------------------------------------- --------------------------- Now my views on the two cases. #1 must work by default. I.e. if somebody on a web site or whatever has an ipp URL then (provided I have the right client s/w installed) I should be able to print to it, in the same way I can send email or browse a web site. #2 Must not work by default. I.e. if I install an IPP printer (whether s/w on an NT server or embedded in the device) then somebody outside my company should not be able to print to it. . This is the solution we have today. #1 works provided that the user can post onto the internet (usually true). #2 works because most networks dont allow arbitrary inbound posts. This is true in routed cases and in proxy cases. The main problem that we seem to have is 'how can an admin allow #2?'. For example PrintShopsRUs want to make their printer(s) available. Second example is: I want to set up an IPP printer in my office as an 'internet fax'. How can their admin configure their router/firewall/proxy to only allow IPP traffic in? Well today's proxies dont allow inbound HTTP traffic which rules this scenario out in the vast majority of corporate cases anyway. For routed/firewall cases it seems that you either allow any POST to a given IP address (OK for a real printer but not ok for a server), or we need someway of distinguishing the traffic. If we dont do this then this will disable this class of usage scenarios. My view is that this is of secondary importance - given that #2 will never work for proxied environments we should focus on #1 scenarios, which do work. For #2 people will have to either a)trust and cross their fingers b) place the printers outside the firewall (like their web servers often are). I can never see the Internet Fax one working in a corporation. I mean allowing me to setup up a printer in my office and just having it work without any SA work. Most network admins are fanatical (rightly so) about not allowing inbound connections, each one has has to be approved and hand configured. They dont even allow ping in, so there is no way an admin would allow inbound IPP traffic to all IP adresses. The only issue I see left then is 'how can an admin prevent #1'? My immediate response is 'why would they want to?' From ipp-owner@pwg.org Thu Jun 11 16:09:02 1998 Delivery-Date: Thu, 11 Jun 1998 16:09:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24388 for ; Thu, 11 Jun 1998 16:09:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20701 for ; Thu, 11 Jun 1998 16:11:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA11854 for ; Thu, 11 Jun 1998 16:08:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 16:05:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11337 for ipp-outgoing; Thu, 11 Jun 1998 16:00:39 -0400 (EDT) Date: Thu, 11 Jun 1998 16:00:32 -0400 (EDT) From: Scott Lawrence To: Paul Moore cc: "'ipp@pwg.org'" Subject: Re: IPP> Firewalls etc. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org On Thu, 11 Jun 1998, Paul Moore wrote: > 1. A user inside a corporation sending print commands out into the internet. > This is the one I was always talking about > > 2. A printer inside a corporation being accessed from outside. It was clear > to me that this is what some others were talking about > ---------------------------------------------------------------------------- > > #1 must work by default. I.e. if somebody on a web site or whatever has an > ipp URL then (provided I have the right client s/w installed) I should be > able to print to it, in the same way I can send email or browse a web site. I think that you'll find that many corporate IT managers would strenuously disagree. Your sending a print job from your desk could: - print company confidential documents in an unsecure place - incur print charges on behalf of the company (if you are sending it to a commercial print shop) Many firewalls I've used will allow ftp GET but disallow PUT for similar reasons. > This is the solution we have today. #1 works provided that the user can post > onto the internet (usually true). IPP in its current form is (in my view) likely to make some people wonder about the wisdom of this. > #2 works because most networks dont allow > arbitrary inbound posts. This is true in routed cases and in proxy cases. From ipp-owner@pwg.org Thu Jun 11 16:29:31 1998 Delivery-Date: Thu, 11 Jun 1998 16:29:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24623 for ; Thu, 11 Jun 1998 16:29:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA20869 for ; Thu, 11 Jun 1998 16:31:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12524 for ; Thu, 11 Jun 1998 16:29:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 16:25:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11968 for ipp-outgoing; Thu, 11 Jun 1998 16:21:09 -0400 (EDT) Message-ID: From: Paul Moore To: "'Scott Lawrence'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Firewalls etc. Date: Thu, 11 Jun 1998 13:20:57 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I think that you'll find that many corporate IT managers would strenuously disagree. Your sending a print job from your desk could: - print company confidential documents in an unsecure place - incur print charges on behalf of the company (if you are sending it to a commercial print shop) The security agrument is not valid (I can copy a file to diskette and take it home, I can remeber it and retryp it when I get home, I can print it locally and put the paper in my pocket, I can email it, I can do a web based file upload to a web site, I can display it on the screen and take photos of it, I can phone my answering machine at home and dictate it). If I am trusted to have access to the document then I am assumed to be trustable. The only place where this is not the case is in ultra secure enviroments (DOD Orange book Class b or greater). This will have no external connectivity at all. Actually I dont see how they can incur print charges for their company. I use all sorts of online services from my desk - I cant see how I could incur charges to my company (I pay for them myself with my credit card). Still if a company has that degree of paranoia they wont allow any web access at all. In this case they will disallow outbound POST as you point out later. > From ipp-owner@pwg.org Thu Jun 11 16:44:32 1998 Delivery-Date: Thu, 11 Jun 1998 16:44:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24831 for ; Thu, 11 Jun 1998 16:44:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA21098 for ; Thu, 11 Jun 1998 16:46:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA13150 for ; Thu, 11 Jun 1998 16:44:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 16:40:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12598 for ipp-outgoing; Thu, 11 Jun 1998 16:36:35 -0400 (EDT) Message-Id: <3.0.5.32.19980611133433.011349f0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Jun 1998 13:34:33 PDT To: Scott Lawrence , Paul Moore From: Carl-Uno Manros Subject: Re: IPP> Firewalls etc. Cc: "'ipp@pwg.org'" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Scott, A couple of comments on your comments. Carl-Uno At 01:00 PM 6/11/98 PDT, Scott Lawrence wrote: > >On Thu, 11 Jun 1998, Paul Moore wrote: > >> 1. A user inside a corporation sending print commands out into the internet. >> This is the one I was always talking about >> >> 2. A printer inside a corporation being accessed from outside. It was clear >> to me that this is what some others were talking about >> ---------------------------------------------------------------------------- >> >> #1 must work by default. I.e. if somebody on a web site or whatever has an >> ipp URL then (provided I have the right client s/w installed) I should be >> able to print to it, in the same way I can send email or browse a web site. > >I think that you'll find that many corporate IT managers would >strenuously disagree. Your sending a print job from your desk could: > >- print company confidential documents in an unsecure place How does this differ from sending the same document as an email attachment? >- incur print charges on behalf of the company (if you are sending it to > a commercial print shop) This may be a desirable feature. You can be certain that the print shop will require enough security to make sure that they will get paid for the work by an authorized customer. Print shops see printing over the Internet as a new business opportunity. > >Many firewalls I've used will allow ftp GET but disallow PUT for similar >reasons. > >> This is the solution we have today. #1 works provided that the user can post >> onto the internet (usually true). > >IPP in its current form is (in my view) likely to make some people >wonder about the wisdom of this. > >> #2 works because most networks dont allow >> arbitrary inbound posts. This is true in routed cases and in proxy cases. > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 11 17:09:05 1998 Delivery-Date: Thu, 11 Jun 1998 17:09:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA25167 for ; Thu, 11 Jun 1998 17:09:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA21276 for ; Thu, 11 Jun 1998 17:11:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13771 for ; Thu, 11 Jun 1998 17:09:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 17:05:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13252 for ipp-outgoing; Thu, 11 Jun 1998 17:01:36 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> Firewalls etc. Message-ID: <5030100021664680000002L002*@MHS> Date: Thu, 11 Jun 1998 16:59:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25167 I agree with Paul. Outbound should work, by default. There are many ways to shuffle confidential information outside a company's firewall, or spend their money foolishly, if someone is into risking their job for excitement. Allowing print jobs by default does not add significantly to this capability. I think the "Internet PRINT to my office" scenario (analogous to FAX) is a compelling feature of IPP. Paul is probably right that this will not happen without some SA involvement, but, in my opinion, we need to be sure we all understand how this will be facilitated. Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 06/11/98 02:09:26 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> Firewalls etc. It became clear to me during the last tele conf that we need to clearly distinguish two cases in this discussion. 1. A user inside a corporation sending print commands out into the internet. This is the one I was always talking about 2. A printer inside a corporation being accessed from outside. It was clear to me that this is what some others were talking about I think that these are two very different things and we have not be clear about what is desirable, acceptable, etc. in each case. Also I think that some people have been discussing #1 with people who think that they are discussing #2 (I certainly discovered that I was) ---------------------------------------------------------------------------- --------------------------- Now my views on the two cases. #1 must work by default. I.e. if somebody on a web site or whatever has an ipp URL then (provided I have the right client s/w installed) I should be able to print to it, in the same way I can send email or browse a web site. #2 Must not work by default. I.e. if I install an IPP printer (whether s/w on an NT server or embedded in the device) then somebody outside my company should not be able to print to it. . This is the solution we have today. #1 works provided that the user can post onto the internet (usually true). #2 works because most networks dont allow arbitrary inbound posts. This is true in routed cases and in proxy cases. The main problem that we seem to have is 'how can an admin allow #2?'. For example PrintShopsRUs want to make their printer(s) available. Second example is: I want to set up an IPP printer in my office as an 'internet fax'. How can their admin configure their router/firewall/proxy to only allow IPP traffic in? Well today's proxies dont allow inbound HTTP traffic which rules this scenario out in the vast majority of corporate cases anyway. For routed/firewall cases it seems that you either allow any POST to a given IP address (OK for a real printer but not ok for a server), or we need someway of distinguishing the traffic. If we dont do this then this will disable this class of usage scenarios. My view is that this is of secondary importance - given that #2 will never work for proxied environments we should focus on #1 scenarios, which do work. For #2 people will have to either a)trust and cross their fingers b) place the printers outside the firewall (like their web servers often are). I can never see the Internet Fax one working in a corporation. I mean allowing me to setup up a printer in my office and just having it work without any SA work. Most network admins are fanatical (rightly so) about not allowing inbound connections, each one has has to be approved and hand configured. They dont even allow ping in, so there is no way an admin would allow inbound IPP traffic to all IP adresses. The only issue I see left then is 'how can an admin prevent #1'? My immediate response is 'why would they want to?' From ipp-owner@pwg.org Thu Jun 11 18:44:12 1998 Delivery-Date: Thu, 11 Jun 1998 18:44:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26425 for ; Thu, 11 Jun 1998 18:44:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA21818 for ; Thu, 11 Jun 1998 18:46:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14730 for ; Thu, 11 Jun 1998 18:44:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 18:40:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA14208 for ipp-outgoing; Thu, 11 Jun 1998 18:38:45 -0400 (EDT) Message-ID: From: Paul Moore To: "'Harry Lewis'" , ipp@pwg.org Subject: RE: IPP> Firewalls etc. Date: Thu, 11 Jun 1998 15:38:34 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Let me add 1 qualification to my '#1 must work by default' If I already have 'normal' (GET, PUT & POST) web access to the Internet from my desktop then #1 should work by default. > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Thursday, June 11, 1998 2:00 PM > To: ipp@pwg.org > Subject: Re: IPP> Firewalls etc. > > I agree with Paul. Outbound should work, by default. There are many ways > to > shuffle confidential information outside a company's firewall, or spend > their > money foolishly, if someone is into risking their job for excitement. > Allowing > print jobs by default does not add significantly to this capability. > > I think the "Internet PRINT to my office" scenario (analogous to FAX) is a > compelling feature of IPP. Paul is probably right that this will not > happen > without some SA involvement, but, in my opinion, we need to be sure we all > understand how this will be facilitated. > > Harry Lewis - IBM Printing Systems > > > > owner-ipp@pwg.org on 06/11/98 02:09:26 PM > Please respond to owner-ipp@pwg.org > To: ipp@pwg.org > cc: > Subject: IPP> Firewalls etc. > > > It became clear to me during the last tele conf that we need to clearly > distinguish two cases in this discussion. > > 1. A user inside a corporation sending print commands out into the > internet. > This is the one I was always talking about > > 2. A printer inside a corporation being accessed from outside. It was > clear > to me that this is what some others were talking about > > I think that these are two very different things and we have not be clear > about what is desirable, acceptable, etc. in each case. Also I think that > some people have been discussing #1 with people who think that they are > discussing #2 (I certainly discovered that I was) > -------------------------------------------------------------------------- > -- > --------------------------- > Now my views on the two cases. > > #1 must work by default. I.e. if somebody on a web site or whatever has an > ipp URL then (provided I have the right client s/w installed) I should be > able to print to it, in the same way I can send email or browse a web > site. > > #2 Must not work by default. I.e. if I install an IPP printer (whether s/w > on an NT server or embedded in the device) then somebody outside my > company > should not be able to print to it. . > > This is the solution we have today. #1 works provided that the user can > post > onto the internet (usually true). #2 works because most networks dont > allow > arbitrary inbound posts. This is true in routed cases and in proxy cases. > > The main problem that we seem to have is 'how can an admin allow #2?'. For > example PrintShopsRUs want to make their printer(s) available. Second > example is: I want to set up an IPP printer in my office as an 'internet > fax'. How can their admin configure their router/firewall/proxy to only > allow IPP traffic in? Well today's proxies dont allow inbound HTTP traffic > which rules this scenario out in the vast majority of corporate cases > anyway. For routed/firewall cases it seems that you either allow any POST > to > a given IP address (OK for a real printer but not ok for a server), or we > need someway of distinguishing the traffic. If we dont do this then this > will disable this class of usage scenarios. My view is that this is of > secondary importance - given that #2 will never work for proxied > environments we should focus on #1 scenarios, which do work. For #2 people > will have to either a)trust and cross their fingers b) place the printers > outside the firewall (like their web servers often are). > > I can never see the Internet Fax one working in a corporation. I mean > allowing me to setup up a printer in my office and just having it work > without any SA work. Most network admins are fanatical (rightly so) about > not allowing inbound connections, each one has has to be approved and hand > configured. They dont even allow ping in, so there is no way an admin > would > allow inbound IPP traffic to all IP adresses. > > The only issue I see left then is 'how can an admin prevent #1'? My > immediate response is 'why would they want to?' > > > From ipp-owner@pwg.org Thu Jun 11 22:36:18 1998 Delivery-Date: Thu, 11 Jun 1998 22:36:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA28227 for ; Thu, 11 Jun 1998 22:36:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA22381 for ; Thu, 11 Jun 1998 22:38:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA15540 for ; Thu, 11 Jun 1998 22:36:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 11 Jun 1998 22:30:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA14992 for ipp-outgoing; Thu, 11 Jun 1998 22:28:38 -0400 (EDT) To: Harry Lewis cc: ipp@pwg.org, ietf-http-ext@w3.org Subject: Re: IPP> Re: On the harm of adding new methods In-reply-to: Your message of "Thu, 11 Jun 1998 12:00:49 EDT." <5030100021650031000002L012*@MHS> Date: Thu, 11 Jun 1998 19:23:41 -0700 From: "Roy T. Fielding" Message-ID: <9806111923.ab28026@paris.ics.uci.edu> Sender: owner-ipp@pwg.org >>On the contrary, the forwarding function is based on the URI, >>not on the method or media type. The filtering function >>(or, more accurately, the routing function) is based on >>everything in the request. > >I should interpret this as "anything in the request might be useful for >filtering", right? Right. Proxies will use whatever is easiest first, depending on the level of security enforced by the site. A true firewall will look at everything, even though this will considerably slow processing. >>In the case of IPP, it is perfectly adequate to filter on >>content-type, since all IPP content is carried in application/IPP. > >To which you replied > >>There is nothing special about Internet printing that requires >>independent firewall semantics. > >Since media-type is part of "everything in the request"... why do you refer to >this recommendation as "independent firewall semantics"? It seems valid for >Larry to point out that mime-type is consistent for IPP and, therefore, can be >considered a reliable filter. I was saying that there is no need to block IPP requests via the protocol. For incoming requests, a firewall is going to be blocking first according to the resource (the URI or IP address) and, if selective access is enabled, the method. For outgoing requests, blocking via the resource is not really feasible unless you want to restrict access to only named portions of the Internet, so the request will be blocked by method or header field or content (in order of increasing performance cost). But why would a firewall want to block an outgoing IPP request? The only security policy that applies here is that the site doesn't want the INFORMATION to go outside the firewall, and it just doesn't matter what data format is being used to contain that information. That is why application/ipp is useless as a "reliable filter". So, from a security standpoint this whole discussion is pointless. >From an implementation standpoint, you want to make it easy for applications to understand the request quickly so that the process of filtering doesn't overwhelm usability. Extracting and comparing the method from an HTTP request can be done in two instructions once the message beginning is found. Extracting and comparing the media type requires parsing all of the header fields, finding the one named Content-Type (being aware that an attacker might provide several such fields in the hope that the firewall would look at the first while the application would look at the last), parsing that field to extract the major and minor type, and then comparing it against "application/ipp". I'm not sure exactly how many instructions that costs, but I do know from experience that it is significant. That is why using RENDER as a method is a better engineering choice from the standpoint of a firewall implementer, since it expresses the semantics that the outgoing firewall wants to block in a way that is easiest to process. >You wrap up with two additional points (paraphrased): > >1. Because IPP is mapped to HTTP, it does not allow > selective access to the printer's resources. No, I said the opposite. Because IPP is hidden within a media type, it is not using HTTP for anything but transport. HTTP is not a transport protocol; it is an application protocol. The reason HTTP is allowed through firewalls is because it expresses enough of the application's intent that intelligent filtering is possible. Selective access means that you may not have access to POST, but you do have access to OPTIONS, printer status, job queue, MTBF statistics, toner levels, etc. There are many service queries that you might want an off-site person to investigate which do not result in printing cost, and you don't want those things to be blocked at the firewall implementation. >IPP allows access to resources such as configuration or job information, >regardless of the protocol mapping. Is this what you are referring to? >What other resources of the printer do you want to access independently? Are >you thinking of things like firmware refresh or font libraries? I am thinking of everything that has identity on the server within the printer. A server based on a printer is no different from a server based on a hard disk -- it controls access to a namespace consisting of identified resources on that server (the Web's notion of a resource is defined in the URI syntax draft). Each of those resources can be represented by some media type, and therefore can be GET-able by any HTTP application. If desired, you can even define a standard namespace for typical printer resources, just like SNMP has a MIB. >2. Control of network resource access is already > provided at the URI level and in the underlying > protocol layers upon which HTTP takes place. > >Right... doesn't this confirm or choice of HTTP as the initial mapping? No. You'd get the same from binary messages on TCP. IPP is just an incredibly inefficient implementation of RPC that runs on port 80. A true mapping to HTTP maps the protocol user's actions to something that can be expressed using HTTP semantics, thus creating a network-based API to printer services which can be understood by agents and intermediaries without any knowledge of printing as an application. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(949)824-1715 http://www.ics.uci.edu/~fielding/ From ipp-owner@pwg.org Fri Jun 12 20:03:40 1998 Delivery-Date: Fri, 12 Jun 1998 20:03:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA27253 for ; Fri, 12 Jun 1998 20:03:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA27105 for ; Fri, 12 Jun 1998 20:05:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18951 for ; Fri, 12 Jun 1998 20:03:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Jun 1998 19:55:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18380 for ipp-outgoing; Fri, 12 Jun 1998 19:53:37 -0400 (EDT) Message-Id: <3.0.5.32.19980612165125.009bd630@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Jun 1998 16:51:25 PDT To: ipp@pwg.org, , From: Carl-Uno Manros Subject: IPP> Application for port-number Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, Carl-Uno -- >Date: Fri, 12 Jun 1998 16:41:47 PDT >From: Carl-Uno Manros - As Chair of IETF IPP WG >To: iana@iana.org, manros@cp10.es.xerox.com >Reply-To: manros@cp10.es.xerox.com >Sender: manros@cp10.es.xerox.com >Subject: Application for port-number >X-Real-Host-From: okydoky.xerox.com > >Name : >Carl-Uno Manros - As Chair of IETF IPP WG > >E-mail : >manros@cp10.es.xerox.com > >Protocol Number : >6 > >Message Formats : >Same as HTTP 1.1 > >Message Types : >HTTP 1.1 POST method requests with responses. > >Data transported are of type MIME media "application/ipp" (a new type, which also needs registration) > >Message opcodes : >Same as HTTP 1.1 POST method > >Message Sequences : >Requests & responses, synchronised. > >Protocol functions : >Sending document data to be printed, >Inquires about job status, >Cancellation of jobs, >Inquieries about printer capabilities and printer status. > > > >Broadcast or Multicast used ? >no > >How and what for Broadcast or Multicast is used (if used): > > >Range for port number : >system port > >Description : >The Internet Prrinting Protocol (IPP) is curently under review by the IESG as a >new Proposed Internet Standard. The Application Area Directors have strongly >recommended allocating a new default port for IPP over HTTP traffic to >distinguish it from "normal" web traffic over HTTP. >This is a similar case to port 280, which is used for System Management >over HTTP. >As a number of vendors are already implementing IPP and interoperability >testing is ongoing, it would be beneficial to allocate the port now, >rather than wait until the RFC editor has finished all the details. > >Name of the port : >IPP > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jun 12 20:14:27 1998 Delivery-Date: Fri, 12 Jun 1998 20:14:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA27307 for ; Fri, 12 Jun 1998 20:14:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA27123 for ; Fri, 12 Jun 1998 20:16:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19583 for ; Fri, 12 Jun 1998 20:14:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 12 Jun 1998 20:10:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA19042 for ipp-outgoing; Fri, 12 Jun 1998 20:08:52 -0400 (EDT) Message-ID: From: Paul Moore To: "'Roger K Debry'" , ipp@pwg.org Cc: cmanros@cp10.es.xerox.com Subject: RE: IPP> Minutes of 6/10 IPP conference call Date: Fri, 12 Jun 1998 17:08:37 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org Well i dont recall the agreement that we should abandon the new method path. As far as I could see we were arguing over facts (would it break proxies or not). Until the answer to this is known I dont see how we can decide. > -----Original Message----- > From: Roger K Debry [SMTP:rdebry@us.ibm.com] > Sent: Wednesday, June 10, 1998 2:09 PM > To: ipp@pwg.org > Cc: cmanros@cp10.es.xerox.com > Subject: IPP> Minutes of 6/10 IPP conference call > > When I agreed to take minutes, I did not agree to spell peoples names > corrrectly, remember everything that transpired during the discussion, or > get > it 1100% correct when transposing to paper. Please accept my apologies in > advance for such errors. With those caveats, here are the minutes of the > 6/10 > call. I won't feel bad if you have to correct me. Thanks ... > > Participating in the call ( mostly in the order joining the call): > > Shevan Albright > Daniel Manchella > Keith Moore (area director) > Patrick ?? (area director) > Kris Schaff > Tom Hastings > Jim Walker > Ron Bergman > Harry Lewis > Larry Masinter > Don Wright > Xavier Riley > Ira MacDonald > Carl Kugler > Peter ??? > Steve Gebert > Randy Turner > Paul Moore > Scott Issacson > > The call began at approximately 11:00am (Mountain Daylight Time) with > Carl-Uno > reviewing the agenda. It was agreed that the two major issues to be > discussed > were the issue of how to differentiate IPP for filtering purposes, and > what to > do about TLS. Carl-Uno asked Keith Moore to being the discussion by giving > his > thoughts on the first issue. > > In response, Keith Moore said that the goal was to be able to > differentiate IPP > from normal HTTP traffic going through firewalls. By tradition new > services run > on different port numbers. Keith's poll of the IESG found general > agreement > that IPP should run on a new port number. Larry Masinter reviewed his > proposal > for providing a new scheme name for IPP at the client. In this proposal, > IPP as > a scheme never appears on the wire. > > Randy Turner argued that requiring a new port number for IPP would be a > hardship on some implementations, specifically where a server is not > capabale > of listening to multiple ports, ports other than 80. Paul Moore agreed > with > the idea of a default IPP Port number (as long as could still use port > 80), > but thought that using IPP as a shorthand notation was nothing more than > an end > user convenience, and really had nothing to do with the protocol. Keith > Moore > expressed the opinion that there was benefit to using IPP. > > Carl-Uno then asked for comments on the proposal to define a new HTTP > method, > PRINT. Larry Masinter reviewed his recent communication on differences > between > filtering proxies and forwarding proxies. His claim is that forwarding > proxies > would all break with definition of a new method. Paul Moore disagreed, > indicating that Microsoft's polling of proxy vendors indicated that most > proxies would handle a new method without any problem. Larry said he does > not > believe this is the case. There was some debate about what the out-of box > condition of IPP should be, and what impact our direction would have on > this. > Keith Moore too a very strong position that it was up to the System > Adminsitrator to configure things so they worked, our responsibility was > to be > sure the System Administrator was not surprised. > > The resulting agreement from this debate was that we would focus on the > details > of using a new port number and using IPP as a naming scheme, per Larry > Masinter's proposal. We would not pursue the definition of a new method. > Randy > Turner agreed to write up a draft of how this would work. Carl-Uno agreed > to > take a work item to contact IANA about an IPP port number. > > We then turned to the TLS discussion. Keith Moore indicated that TLS is > currenly hung up wating for documents from the PCIKS group, which are > currently > in last call. Keith expects the TLS issue to be resolved soon and to have > TLS > progress down the standards track. Keith said that there is weak > agreement in > the IETF on doing security negotiation in-band. The idea of having a > reserved > port for TLS is still under discussion. Keith proposed that IPP use a > parameter > in the URL to indicate TLS use. After quite a bit of discussion, Keith > agreed > that he would support the use of SHOULD for IPP client support of TLS. > However, > he warned that others on the IESG may not approve with that wording. He > suggested that we articulate client instances where TLS may not be > appropriate, > e.g. on a Palm Pilot. > > > > > Roger K deBry > Senior Technical Staff Member > Architecture and Technology > IBM Printing Systems > email: rdebry@us.ibm.com > phone: 1-303-924-4080 From ipp-owner@pwg.org Mon Jun 15 08:21:16 1998 Delivery-Date: Mon, 15 Jun 1998 08:21:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA25359 for ; Mon, 15 Jun 1998 08:21:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02973 for ; Mon, 15 Jun 1998 08:23:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA28216 for ; Mon, 15 Jun 1998 08:21:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 08:11:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA27656 for ipp-outgoing; Mon, 15 Jun 1998 08:07:51 -0400 (EDT) From: Roger K Debry To: Subject: RE: IPP> Minutes of 6/10 IPP conference call Message-ID: <5030100021778476000002L062*@MHS> Date: Mon, 15 Jun 1998 08:06:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25359 The agreement, as I recorded in my note for the minutes, was that we agreed to focus our efforts on working out the details of the Larry Masinter's proposal, which did not include a new method. he only dissenter to going this direction (as I recall) was Paul Moore. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 06/12/98 06:13:28 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus cc: cmanros@cp10.es.xerox.com Subject: RE: IPP> Minutes of 6/10 IPP conference call Well i dont recall the agreement that we should abandon the new method path. As far as I could see we were arguing over facts (would it break proxies or not). Until the answer to this is known I dont see how we can decide. > -----Original Message----- > From: Roger K Debry [SMTP:rdebry@us.ibm.com] > Sent: Wednesday, June 10, 1998 2:09 PM > To: ipp@pwg.org > Cc: cmanros@cp10.es.xerox.com > Subject: IPP> Minutes of 6/10 IPP conference call > > When I agreed to take minutes, I did not agree to spell peoples names > corrrectly, remember everything that transpired during the discussion, or > get > it 1100% correct when transposing to paper. Please accept my apologies in > advance for such errors. With those caveats, here are the minutes of the > 6/10 > call. I won't feel bad if you have to correct me. Thanks ... > > Participating in the call ( mostly in the order joining the call): > > Shevan Albright > Daniel Manchella > Keith Moore (area director) > Patrick ?? (area director) > Kris Schaff > Tom Hastings > Jim Walker > Ron Bergman > Harry Lewis > Larry Masinter > Don Wright > Xavier Riley > Ira MacDonald > Carl Kugler > Peter ??? > Steve Gebert > Randy Turner > Paul Moore > Scott Issacson > > The call began at approximately 11:00am (Mountain Daylight Time) with > Carl-Uno > reviewing the agenda. It was agreed that the two major issues to be > discussed > were the issue of how to differentiate IPP for filtering purposes, and > what to > do about TLS. Carl-Uno asked Keith Moore to being the discussion by giving > his > thoughts on the first issue. > > In response, Keith Moore said that the goal was to be able to > differentiate IPP > from normal HTTP traffic going through firewalls. By tradition new > services run > on different port numbers. Keith's poll of the IESG found general > agreement > that IPP should run on a new port number. Larry Masinter reviewed his > proposal > for providing a new scheme name for IPP at the client. In this proposal, > IPP as > a scheme never appears on the wire. > > Randy Turner argued that requiring a new port number for IPP would be a > hardship on some implementations, specifically where a server is not > capabale > of listening to multiple ports, ports other than 80. Paul Moore agreed > with > the idea of a default IPP Port number (as long as could still use port > 80), > but thought that using IPP as a shorthand notation was nothing more than > an end > user convenience, and really had nothing to do with the protocol. Keith > Moore > expressed the opinion that there was benefit to using IPP. > > Carl-Uno then asked for comments on the proposal to define a new HTTP > method, > PRINT. Larry Masinter reviewed his recent communication on differences > between > filtering proxies and forwarding proxies. His claim is that forwarding > proxies > would all break with definition of a new method. Paul Moore disagreed, > indicating that Microsoft's polling of proxy vendors indicated that most > proxies would handle a new method without any problem. Larry said he does > not > believe this is the case. There was some debate about what the out-of box > condition of IPP should be, and what impact our direction would have on > this. > Keith Moore too a very strong position that it was up to the System > Adminsitrator to configure things so they worked, our responsibility was > to be > sure the System Administrator was not surprised. > > The resulting agreement from this debate was that we would focus on the > details > of using a new port number and using IPP as a naming scheme, per Larry > Masinter's proposal. We would not pursue the definition of a new method. > Randy > Turner agreed to write up a draft of how this would work. Carl-Uno agreed > to > take a work item to contact IANA about an IPP port number. > > We then turned to the TLS discussion. Keith Moore indicated that TLS is > currenly hung up wating for documents from the PCIKS group, which are > currently > in last call. Keith expects the TLS issue to be resolved soon and to have > TLS > progress down the standards track. Keith said that there is weak > agreement in > the IETF on doing security negotiation in-band. The idea of having a > reserved > port for TLS is still under discussion. Keith proposed that IPP use a > parameter > in the URL to indicate TLS use. After quite a bit of discussion, Keith > agreed > that he would support the use of SHOULD for IPP client support of TLS From ipp-owner@pwg.org Mon Jun 15 14:31:49 1998 Delivery-Date: Mon, 15 Jun 1998 14:31:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03066 for ; Mon, 15 Jun 1998 14:31:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05072 for ; Mon, 15 Jun 1998 14:34:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29592 for ; Mon, 15 Jun 1998 14:31:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 14:26:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28924 for ipp-outgoing; Mon, 15 Jun 1998 14:24:32 -0400 (EDT) Content-return: allowed Date: Mon, 15 Jun 1998 09:10:14 PDT From: "Zehler, Peter " Subject: IPP> Who should I talk to for IPP Protyping and interop testing To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org To any individual with IPP prototyping intentions that has not been contacted by me, I am building a list of contacts for prototyping/interop testing at various organizations involved with IPP. Could each of you answer a question? Who is the individual in your organization I should contact for first hand knowledge of IPP prototyping and interoperability testing? Thanks Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Mon Jun 15 16:46:46 1998 Delivery-Date: Mon, 15 Jun 1998 16:46:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04733 for ; Mon, 15 Jun 1998 16:46:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05739 for ; Mon, 15 Jun 1998 16:49:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00562 for ; Mon, 15 Jun 1998 16:46:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 16:41:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29940 for ipp-outgoing; Mon, 15 Jun 1998 16:38:14 -0400 (EDT) Message-Id: <3.0.5.32.19980615133500.0108c860@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Jun 1998 13:35:00 PDT To: ipp@pwg.org From: Keith Moore (by way of Carl-Uno Manros ) Subject: IPP> notes on the discuss@apps.ietf.org list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org It's been pointed out to me that my original message on the discuss@apps.ietf.org list may not have been very clear. 1. you have not been automatically subscribed to the list. If you want to be on the list, you need to send mail to discuss-REQUEST@apps.ietf.org asking to be added to the list. 2. Even though this particular invitiation was sent to the wg-chairs list, the list is open, and anyone may subscribe. Feel free to tell your working groups about the list. Keith From ipp-owner@pwg.org Mon Jun 15 16:51:33 1998 Delivery-Date: Mon, 15 Jun 1998 16:51:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04816 for ; Mon, 15 Jun 1998 16:51:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05777 for ; Mon, 15 Jun 1998 16:53:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01190 for ; Mon, 15 Jun 1998 16:51:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 16:47:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29930 for ipp-outgoing; Mon, 15 Jun 1998 16:38:01 -0400 (EDT) Message-Id: <3.0.5.32.19980615133444.010838e0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Jun 1998 13:34:44 PDT To: ipp@pwg.org From: Keith Moore (by way of Carl-Uno Manros ) Subject: IPP> announcing apps area discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Hi. I've set up a list for discussion of apps area-wide issues. It's called discuss@apps.ietf.org. Here's the welcome message from the list: Congratulations! You're now subscribed to the discuss@apps.ietf.org mailing list. If you want to be removed from the list, or you want your address changed, send mail to discuss-REQUEST@apps.ietf.org. This list is for discussion of matters related to the applications area of IETF. In particular, discussions of area-wide concerns or technical issues, and ideas for new applications area working groups, are appropriate. This list has been created as a result of the observation that many issues discussed in certain applications area working groups, have a much wider effect, and need a wider audience, than that particular group. I'm hoping that this list will facilitate more cross-wg discussion. At present anyone can post to the list, though there is a spam filter. However, the apps area directors reserve the right to moderate the list to filter inappropriate messages, or to automatically filter messages from those who habitually post inappropriate messages. Inappropriate, here, means either 'abusive' or 'wildly off topic'. Keith Moore From ipp-owner@pwg.org Mon Jun 15 18:25:44 1998 Delivery-Date: Mon, 15 Jun 1998 18:25:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA05909 for ; Mon, 15 Jun 1998 18:25:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06173 for ; Mon, 15 Jun 1998 18:28:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA02262 for ; Mon, 15 Jun 1998 18:25:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 18:21:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01683 for ipp-outgoing; Mon, 15 Jun 1998 18:17:18 -0400 (EDT) Message-Id: <3.0.5.32.19980615150424.009d2a10@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Jun 1998 15:04:24 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980617 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Agenda for PWG IPP Phone Conference 980617 ========================================== We will hold our normal weekly conference in Wednesday. I want to get to closure on the remaining show stoppers, so the editors can finish up the next set of drafts to be sent to the IESG for their final review. Based on the discussion with the Application Area Directors last weeek, I consider the discussion about a separate default port for IPP closed. This was the preferred method from the IESG to distinguish IPP from other HTTP traffic and seemed to get overall approval from the members of the WG. I have sent in the application for an IPP port to the IANA registry. Subjects from Keith Moore's review that might need some further discussion are: 1) Do we really need a new ipp: scheme, when we introduce the new port? Are we clear on all the consequences of introducing a new scheme? Can we fit in a security parameter, when we define the new scheme? (Larry Masinter and Randy Turner are working on a draft - hopefully ready for the Wednesday phone call). 2) Considering that we have the new default port number for IPP, do we need to also distinguish IPP by using a PRINT method rather than POST? Another subject which has been discussed on the DL is: 3) Do we want to keep the redundant (and potentially conflicting) operation attributes for Print-URI and Job-URI in the MIME structure, or take them out? I would like to focus the discussion around these three subjects. I do not think that there are any further issues to discuss at this point, apart from reviewing the minor editorials that we have already agreed on in principle. Here is the dial-in information: Time: June 17, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 16 11:04:29 1998 Delivery-Date: Tue, 16 Jun 1998 11:04:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26725 for ; Tue, 16 Jun 1998 11:04:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08884 for ; Tue, 16 Jun 1998 11:06:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA11010 for ; Tue, 16 Jun 1998 11:04:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 10:51:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09852 for ipp-outgoing; Tue, 16 Jun 1998 10:46:26 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: IPP> Re: PWG-ANNOUNCE> Schedule for Monterey Meeting Message-ID: <5030100021839436000002L062*@MHS> Date: Tue, 16 Jun 1998 10:45:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26725 Don - this is appropriate - THANK YOU! I am willing to forgo discussion of Notifications and SDP (and ALL post v1 topics) in order to focus on CLOSING v1 at Monterey! I think we should enter Monterey with a FINAL list of issues... we should limit discussion of each issue to a reasonable time period and be DECISIVE about each issue. We should focus MAINLY on closing the nitty-gritty technical issues that actually affect the specification, clarity etc. If we still have major controversy, such as web and firewall philosophy, it should be allowed to rain no longer than 1 or 2 hours, then put to rest. There has been PLENTY of time to resolve these issues via the reflector and it would be best if we had them resolved prior to the meeting. Interoperability testing and test results should be our secondary focus From pwg-announce-owner@pwg.org Tue Jun 16 11:07:35 1998 Delivery-Date: Tue, 16 Jun 1998 11:07:36 -0400 Return-Path: pwg-announce-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26769 for ; Tue, 16 Jun 1998 11:07:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08920 for ; Tue, 16 Jun 1998 11:09:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA11381 for ; Tue, 16 Jun 1998 11:07:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 10:56:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09845 for pwg-announce-outgoing; Tue, 16 Jun 1998 10:46:22 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: PWG-ANNOUNCE> Schedule for Monterey Meeting Message-ID: <5030100021839436000002L062*@MHS> Date: Tue, 16 Jun 1998 10:45:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-pwg-announce@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26769 Don - this is appropriate - THANK YOU! I am willing to forgo discussion of Notifications and SDP (and ALL post v1 topics) in order to focus on CLOSING v1 at Monterey! I think we should enter Monterey with a FINAL list of issues... we should limit discussion of each issue to a reasonable time period and be DECISIVE about each issue. We should focus MAINLY on closing the nitty-gritty technical issues that actually affect the specification, clarity etc. If we still have major controversy, such as web and firewall philosophy, it should be allowed to rain no longer than 1 or 2 hours, then put to rest. There has been PLENTY of time to resolve these issues via the reflector and it would be best if we had them resolved prior to the meeting. Interoperability testing and test results should be our secondary focus From ipp-owner@pwg.org Tue Jun 16 12:25:56 1998 Delivery-Date: Tue, 16 Jun 1998 12:25:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA27752 for ; Tue, 16 Jun 1998 12:25:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA09418 for ; Tue, 16 Jun 1998 12:28:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA12702 for ; Tue, 16 Jun 1998 12:25:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 12:21:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA12095 for ipp-outgoing; Tue, 16 Jun 1998 12:18:22 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 16 Jun 1998 10:17:31 -0600 From: "Scott Isaacson" To: pwg-announce@pwg.org, harryl@us.ibm.com Cc: don@lexmark.com, ipp@pwg.org Subject: IPP> Re: PWG-ANNOUNCE> Schedule for Monterey Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27752 I agree with Harry's statements. We need to lock down on IPP v1.0. Define it and be done with it. If we talk about anything else but IPP v1.0 until we resolve all issues, we are not doing the right thing. MIB access, notificaitons, SDP, should all be put on hold until v1.0 is signed, sealed, and delivered. In the last phone call I heard that if we defined a new default port and kept SHOULD for client TLS support, then we were DONE with all of the IESG issues besides editing fixes. I am surprised that we still think that we have issues. We have had basic consensus on most of this since the Munich IETF meetings. We can't allow ourselves to throw it all open again. Scott >>> Harry Lewis 06/16 8:45 AM >>> Don - this is appropriate - THANK YOU! I am willing to forgo discussion of Notifications and SDP (and ALL post v1 topics) in order to focus on CLOSING v1 at Monterey! I think we should enter Monterey with a FINAL list of issues... we should limit discussion of each issue to a reasonable time period and be DECISIVE about each issue. We should focus MAINLY on closing the nitty-gritty technical issues that actually affect the specification, clarity etc. If we still have major controversy, such as web and firewall philosophy, it should be allowed to rain no longer than 1 or 2 hours, then put to rest. There has been PLENTY of time to resolve these issues via the reflector and it would be best if we had them resolved prior to the meeting. Interoperability testing and test results should be our secondary focus From pwg-announce-owner@pwg.org Tue Jun 16 12:33:30 1998 Delivery-Date: Tue, 16 Jun 1998 12:33:30 -0400 Return-Path: pwg-announce-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA27798 for ; Tue, 16 Jun 1998 12:33:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA09456 for ; Tue, 16 Jun 1998 12:35:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA13597 for ; Tue, 16 Jun 1998 12:33:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 12:25:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA12088 for pwg-announce-outgoing; Tue, 16 Jun 1998 12:18:18 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 16 Jun 1998 10:17:31 -0600 From: "Scott Isaacson" To: pwg-announce@pwg.org, harryl@us.ibm.com Cc: don@lexmark.com, ipp@pwg.org Subject: IPP> Re: PWG-ANNOUNCE> Schedule for Monterey Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-pwg-announce@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27798 I agree with Harry's statements. We need to lock down on IPP v1.0. Define it and be done with it. If we talk about anything else but IPP v1.0 until we resolve all issues, we are not doing the right thing. MIB access, notificaitons, SDP, should all be put on hold until v1.0 is signed, sealed, and delivered. In the last phone call I heard that if we defined a new default port and kept SHOULD for client TLS support, then we were DONE with all of the IESG issues besides editing fixes. I am surprised that we still think that we have issues. We have had basic consensus on most of this since the Munich IETF meetings. We can't allow ourselves to throw it all open again. Scott >>> Harry Lewis 06/16 8:45 AM >>> Don - this is appropriate - THANK YOU! I am willing to forgo discussion of Notifications and SDP (and ALL post v1 topics) in order to focus on CLOSING v1 at Monterey! I think we should enter Monterey with a FINAL list of issues... we should limit discussion of each issue to a reasonable time period and be DECISIVE about each issue. We should focus MAINLY on closing the nitty-gritty technical issues that actually affect the specification, clarity etc. If we still have major controversy, such as web and firewall philosophy, it should be allowed to rain no longer than 1 or 2 hours, then put to rest. There has been PLENTY of time to resolve these issues via the reflector and it would be best if we had them resolved prior to the meeting. Interoperability testing and test results should be our secondary focus From ipp-owner@pwg.org Tue Jun 16 17:12:01 1998 Delivery-Date: Tue, 16 Jun 1998 17:12:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00966 for ; Tue, 16 Jun 1998 17:11:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10977 for ; Tue, 16 Jun 1998 17:14:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15826 for ; Tue, 16 Jun 1998 17:11:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 17:06:19 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15233 for ipp-outgoing; Tue, 16 Jun 1998 17:00:41 -0400 (EDT) Message-Id: <3.0.5.32.19980616114248.00cf57d0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Jun 1998 11:42:48 PDT To: ipp@pwg.org From: Internet-Drafts@ietf.org (by way of Carl-Uno Manros ) Subject: IPP> I-D ACTION:draft-reddy-enp-protocol-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, Carl-Uno --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Event Notification Protocol - ENP Author(s) : S. Reddy, M. Fisher Filename : draft-reddy-enp-protocol-00.txt Pages : 21 Date : 15-Jun-98 As the complexity of distributed applications increases, an increasing amount of processing is done using distributed processes, which typically execute without the direct supervision of an end user. The user must poll these processes periodically to check if they are completed successfully or not. This polling results in unnecessary wastage of network bandwidth as well as computing resources. The user generally cannot see intermediate results or progress reports for long running processes, they must wait till the process is completely finished before viewing the results. Thus the problem of monitoring events is central in distributed applications and protocols. A repeated need in such applications is receive notifications when a resource property value changes or event state changes. Current database systems provides mechanisms like constraints, triggers and active database rules. These facilities provides an automated means to ensure the database integrity or perform specific action when data changes. Need for such kind of requirement is fundamental is network applications. Event Notification Protocol(ENP) abstracts the notification requirements from the applications. ENP provides a lean and mean protocol with a client side semantics for processing notifications. The goal of ENP is to provide a service which allows users to select resources or events for which they wish to be notified in case changes of property values or state values occur. The Event Notification Protocol will also allow users to define what events or state changes they are interested in. This document describes the Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. 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-reddy-enp-protocol-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-reddy-enp-protocol-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-reddy-enp-protocol-00.txt". NOTE: The mail server at ietf.org 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: <19980615133250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-reddy-enp-protocol-00.txt From ipp-owner@pwg.org Tue Jun 16 17:35:17 1998 Delivery-Date: Tue, 16 Jun 1998 17:35:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01116 for ; Tue, 16 Jun 1998 17:35:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11099 for ; Tue, 16 Jun 1998 17:37:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA16525 for ; Tue, 16 Jun 1998 17:35:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 17:31:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15967 for ipp-outgoing; Tue, 16 Jun 1998 17:25:50 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Proposal for new IPP scheme Date: Tue, 16 Jun 1998 14:25:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD996D.40BEBC2E" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD996D.40BEBC2E Content-Type: text/plain Please review the attached summary of Larry's proposal for a new IPP scheme. I added some clarifications and a particular scenario for scheme interpretation. This summary is a brief version that was culled from my notes, and Larry's subsequent comments to me. The brevity of this summary is maintained due to the possible inclusion and modification should the WG (or IESG) decide some additional text is required for IPP-specific "secure" schemes. For this reason, please treat this proposal as a first draft. Randy <> ------ =_NextPart_000_01BD996D.40BEBC2E Content-Type: text/plain; name="maspro.txt" Content-Disposition: attachment; filename="maspro.txt" This is a proposal for the registration of a new URL scheme "ipp". The syntax for the new IPP scheme would be identical to the existing "http" scheme except for the scheme name itself: ipp://host[:port]/ Associated with this new IPP scheme would be an IANA-assigned TCP port number, which would be the default port number used by clients to contact IPP servers that are represented by IPP URLs. For the examples in this proposal the port number 374 is used as the port number that might be allocated by IANA. NOTE: this port number selection is for illustrative purposes of this text only. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 374. The semantics for clients configured for proxy access is different as described below. When an IPP client obtains an IPP URL, the interpretation of this URL by the client can take one of three forms, depending on the configuration and implementation of the client: ------------------------------------------------------ IPP Client Configured with no proxy server - ------------------------------------------------------ When an IPP client (no proxy configured) obtains an IPP-schemed URL such as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to port 374 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:374 Content-type: application/ipp Transfer-Encoding: chunked ... ------------------------------------------------------ IPP Client Configured for Proxy Service - ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:374/myprinter/myqueue HTTP/1.1 Host: myproxy.com:374 Content-type: application/ipp Transfer-Encoding: chunked ... It is likely that existing proxies will not understand IPP URLs, so the RequestURI should use the HTTP form of the URL. ------------------------------------------------------- IPP Clients with HTTP-only constraints ------------------------------------------------------- If a particular IPP client implementation uses a pre-packaged HTTP library or HTTP class that only supports HTTP-schemed URLs, then the following operation would be required: - The IPP client obtains the IPP-schemed URL and converts it to the following form: "http://myhost.com:374/myprinter/myqueue" The client then submits this URL to the pre-packaged HTTP library API. ------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers should accept "full" URLs as well, so IPP servers should also be able to accept requestURIs as specified in #2 and #3 as well. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g., http://myhost.com:374/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) ------ =_NextPart_000_01BD996D.40BEBC2E-- From ipp-owner@pwg.org Tue Jun 16 19:31:09 1998 Delivery-Date: Tue, 16 Jun 1998 19:31:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01606 for ; Tue, 16 Jun 1998 19:31:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11515 for ; Tue, 16 Jun 1998 19:33:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA17773 for ; Tue, 16 Jun 1998 19:31:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 19:26:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17184 for ipp-outgoing; Tue, 16 Jun 1998 19:24:52 -0400 (EDT) Message-Id: <3.0.5.32.19980616162207.00913610@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Jun 1998 16:22:07 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Proposal for new IPP scheme In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 02:25 PM 6/16/98 PDT, Turner, Randy wrote: > >Please review the attached summary of Larry's proposal for a new IPP >scheme. I added some clarifications and a particular scenario for scheme >interpretation. This summary is a brief version that was culled from my >notes, and Larry's subsequent comments to me. >The brevity of this summary is maintained due to the possible inclusion >and modification should the WG (or IESG) decide some additional text is >required for IPP-specific "secure" schemes. For this reason, please >treat this proposal as a first draft. > >Randy > > <> > >Attachment Converted: "C:\WINNT\profiles\cmanros\personal\Attach\maspro.txt" > Randy, Did you have any discussion with Larry about what a browser is expected to do if your enter an ipp: URL and hit Enter? All other URLs that I am aware of do something sensensible in that situation. The closest equivalent I can think of is the mailto: URL which usually comes up with a mail submission window. Should an ipp: URL come up with a print submission window? If so, do we have anybody that might commit to implement that? All in all, I think there is more than meets the eye to introduce a new scheme, in particular one that really is an alias for another scheme, which as far as I know, is a new kind of animal in the IETF garden of Eden. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 16 19:50:50 1998 Delivery-Date: Tue, 16 Jun 1998 19:50:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01683 for ; Tue, 16 Jun 1998 19:50:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA11567 for ; Tue, 16 Jun 1998 19:52:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18454 for ; Tue, 16 Jun 1998 19:50:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 19:46:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17899 for ipp-outgoing; Tue, 16 Jun 1998 19:40:29 -0400 (EDT) Message-ID: <3587017E.7F821B6F@underscore.com> Date: Tue, 16 Jun 1998 19:36:30 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP> Proposal for new IPP scheme References: <3.0.5.32.19980616162207.00913610@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Carl-Uno Manros wrote: > All in all, I think there is more than meets the eye to introduce a new > scheme, in particular one that really is an alias for another scheme, which > as far as I know, is a new kind of animal in the IETF garden of Eden. I agree. While the notion of mapping "ipp:" to "http://blah:nnn" sounds interesting, are we breaking too much ground here? It's the end-user experience I worry about. It's ok to say that "clients and servers will 'do the right thing'", but we also say that we'd like to put our IPP printer addresses on our business cards, etc. Sounds like we might be heading for a bit of a crash with regarding to user expectations. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Tue Jun 16 20:00:07 1998 Delivery-Date: Tue, 16 Jun 1998 20:00:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01727 for ; Tue, 16 Jun 1998 20:00:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11610 for ; Tue, 16 Jun 1998 20:02:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19576 for ; Tue, 16 Jun 1998 20:00:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 19:52:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17869 for ipp-outgoing; Tue, 16 Jun 1998 19:37:09 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> Proposal for new IPP scheme Date: Tue, 16 Jun 1998 16:36:50 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org We are getting way of course here - we are supposed to be defining a wire protocol. I would also push back against the pseudo addressing scheme being proposed since this entirely an artifact within the client (it has no impact on the protocol itself). > -----Original Message----- > From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com] > Sent: Tuesday, June 16, 1998 4:22 PM > To: ipp@pwg.org > Subject: Re: IPP> Proposal for new IPP scheme > > At 02:25 PM 6/16/98 PDT, Turner, Randy wrote: > > > >Please review the attached summary of Larry's proposal for a new IPP > >scheme. I added some clarifications and a particular scenario for scheme > >interpretation. This summary is a brief version that was culled from my > >notes, and Larry's subsequent comments to me. > >The brevity of this summary is maintained due to the possible inclusion > >and modification should the WG (or IESG) decide some additional text is > >required for IPP-specific "secure" schemes. For this reason, please > >treat this proposal as a first draft. > > > >Randy > > > > <> > > > >Attachment Converted: > "C:\WINNT\profiles\cmanros\personal\Attach\maspro.txt" > > > > Randy, > > Did you have any discussion with Larry about what a browser is expected to > do if your enter an ipp: URL and hit Enter? > > All other URLs that I am aware of do something sensensible in that > situation. The closest equivalent I can think of is the mailto: URL which > usually comes up with a mail submission window. Should an ipp: URL come up > with a print submission window? If so, do we have anybody that might > commit > to implement that? > > All in all, I think there is more than meets the eye to introduce a new > scheme, in particular one that really is an alias for another scheme, > which > as far as I know, is a new kind of animal in the IETF garden of Eden. > > Carl-Uno > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 16 20:00:53 1998 Delivery-Date: Tue, 16 Jun 1998 20:00:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01734 for ; Tue, 16 Jun 1998 20:00:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11613 for ; Tue, 16 Jun 1998 20:03:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA19735 for ; Tue, 16 Jun 1998 20:00:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 19:52:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17882 for ipp-outgoing; Tue, 16 Jun 1998 19:39:09 -0400 (EDT) Message-Id: <199806162334.QAA00186@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 16 Jun 1998 16:39:59 -0700 To: "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: Re: IPP> Proposal for new IPP scheme In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_18153122==_.ALT" Sender: owner-ipp@pwg.org --=====================_18153122==_.ALT Content-Type: text/plain; charset="us-ascii" This looked like a reasonable proposal until I got to the very last line: 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) The whole proposal is one of keeping ipp as a convenience notation and making ipp not appear on the wire. So why should a server ever have to accept #3 above? Bob Herriot At 02:25 PM 6/16/98 , Turner, Randy wrote: > >Please review the attached summary of Larry's proposal for a new IPP >scheme. I added some clarifications and a particular scenario for scheme >interpretation. This summary is a brief version that was culled from my >notes, and Larry's subsequent comments to me. >The brevity of this summary is maintained due to the possible inclusion >and modification should the WG (or IESG) decide some additional text is >required for IPP-specific "secure" schemes. For this reason, please >treat this proposal as a first draft. > >Randy > > <> > > >This is a proposal for the registration of a new URL scheme "ipp". >The syntax for the new IPP scheme would be identical to the existing >"http" scheme except for the scheme name itself: > >ipp://host[:port]/ > >Associated with this new IPP scheme would be an IANA-assigned TCP port >number, which would be the default port number used by clients to >contact IPP servers that are represented by IPP URLs. > >For the examples in this proposal the port number 374 is used as the >port number that might be allocated by IANA. NOTE: this port number >selection is for illustrative purposes of this text only. > >The IPP scheme implies all of the same protocol semantics as that of >the HTTP scheme, except that, by default, the port number used by clients >to connect to the server is port 374. The semantics for clients >configured for proxy access is different as described below. > >When an IPP client obtains an IPP URL, the interpretation of this URL by >the client can take one of three forms, depending on the configuration >and implementation of the client: > > >------------------------------------------------------ >IPP Client Configured with no proxy server - >------------------------------------------------------ > > >When an IPP client (no proxy configured) obtains an IPP-schemed URL such >as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to >port 374 on myhost.com, with the following example headers: > >POST /myprinter/myqueue HTTP/1.1 >Host: myhost.com:374 >Content-type: application/ipp >Transfer-Encoding: chunked >... > >------------------------------------------------------ >IPP Client Configured for Proxy Service - >------------------------------------------------------ > >When an IPP client that uses a proxy named "myproxy.com" obtains the URL >"ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to >myproxy.com with the following example headers: > >POST http://myhost.com:374/myprinter/myqueue HTTP/1.1 >Host: myproxy.com:374 >Content-type: application/ipp >Transfer-Encoding: chunked >... > >It is likely that existing proxies will not understand IPP URLs, >so the RequestURI should use the HTTP form of the URL. > >------------------------------------------------------- >IPP Clients with HTTP-only constraints >------------------------------------------------------- >If a particular IPP client implementation uses a pre-packaged HTTP library >or HTTP class that only supports HTTP-schemed URLs, then the following >operation would be required: > >- The IPP client obtains the IPP-schemed URL and converts it to the > following form: > "http://myhost.com:374/myprinter/myqueue" > >The client then submits this URL to the pre-packaged HTTP library API. > > >------------------------------------------------------- > >Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using >a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers >should accept "full" URLs as well, so IPP servers should also be able to >accept requestURIs as specified in #2 and #3 as well. > > > 1. A "abs_path" URL (e.g., /myprinter/myqueue) > 2. A full HTTP URL (e.g., http://myhost.com:374/myprinter/myqueue) > 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) > --=====================_18153122==_.ALT Content-Type: text/html; charset="us-ascii" This looked like a reasonable proposal until I got to the very last line:

        3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)

The whole proposal is one of keeping ipp as a convenience notation and
making ipp not appear on the wire. So why should a server ever have to
accept #3 above?

Bob Herriot

At 02:25 PM 6/16/98 , Turner, Randy wrote:
>       
>Please review the attached summary of Larry's proposal for a new IPP
>scheme. I added some clarifications and a particular scenario for scheme
>interpretation. This summary is a brief version that was culled from my
>notes, and Larry's subsequent comments to me.
>The brevity of this summary is maintained due to the possible inclusion
>and modification should the WG (or IESG) decide some additional text is
>required for IPP-specific "secure" schemes. For this reason, please
>treat this proposal as a first draft.
>
>Randy
>
> <<maspro.txt>>
>
>
>This is a proposal for the registration of a new URL scheme "ipp".
>The syntax for the new IPP scheme would be identical to the existing
>"http" scheme except for the scheme name itself:
>
>ipp://host[:port]/<IPP-specific-abs-path>
>
>Associated with this new IPP scheme would be an IANA-assigned TCP port
>number, which would be the default port number used by clients to
>contact IPP servers that are represented by IPP URLs.
>
>For the examples in this proposal the port number 374 is used as the
>port number that might be allocated by IANA. NOTE: this port number
>selection is for illustrative purposes of this text only.
>
>The IPP scheme implies all of the same protocol semantics as that of
>the HTTP scheme, except that, by default, the port number used by clients
>to connect to the server is port 374. The semantics for clients
>configured for proxy access is different as described below.
>
>When an IPP client obtains an IPP URL, the interpretation of this URL by
>the client can take one of three forms, depending on the configuration
>and implementation of the client:
>
>
>------------------------------------------------------
>IPP Client Configured with no proxy server -
>------------------------------------------------------
>
>
>When an IPP client (no proxy configured) obtains an IPP-schemed URL such
>as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to
>port 374 on myhost.com, with the following example headers:
>
>POST /myprinter/myqueue HTTP/1.1
>Host: myhost.com:374
>Content-type: application/ipp
>Transfer-Encoding: chunked
>...
>
>------------------------------------------------------
>IPP Client Configured for Proxy Service -
>------------------------------------------------------
>
>When an IPP client that uses a proxy named "myproxy.com" obtains the URL
>"ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to
>myproxy.com with the following example headers:
>
>POST http://myhost.com:374/myprinter/myqueue HTTP/1.1
>Host: myproxy.com:374
>Content-type: application/ipp
>Transfer-Encoding: chunked
>...
>
>It is likely that existing proxies will not understand IPP URLs,
>so the RequestURI should use the HTTP form of the URL.
>
>-------------------------------------------------------
>IPP Clients with HTTP-only constraints
>-------------------------------------------------------
>If a particular IPP client implementation uses a pre-packaged HTTP library
>or HTTP class that only supports HTTP-schemed URLs, then the following
>operation would be required:
>
>- The IPP client obtains the IPP-schemed URL and converts it to the
>  following form:
>                  "http://myhost.com:374/myprinter/myqueue"
>
>The client then submits this URL to the pre-packaged HTTP library API.
>
>
>-------------------------------------------------------
>
>Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using
>a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers
>should accept "full" URLs as well, so IPP servers should also be able to
>accept requestURIs as specified in #2 and #3 as well.
>
>
>              1. A "abs_path" URL (e.g., /myprinter/myqueue)
>              2. A full HTTP URL  (e.g., http://myhost.com:374/myprinter/myqueue)
>              3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)
>
--=====================_18153122==_.ALT-- From ipp-owner@pwg.org Tue Jun 16 20:25:39 1998 Delivery-Date: Tue, 16 Jun 1998 20:25:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01899 for ; Tue, 16 Jun 1998 20:25:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11666 for ; Tue, 16 Jun 1998 20:28:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA20528 for ; Tue, 16 Jun 1998 20:25:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 20:21:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA19854 for ipp-outgoing; Tue, 16 Jun 1998 20:09:49 -0400 (EDT) From: don@lexmark.com Message-Id: <199806170009.AA18904@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 16 Jun 1998 20:04:51 -0400 Subject: Re: IPP> Proposal for new IPP scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org The more I think about this, the more I think it is out of scope for the work we are doing. We are working on the wire protocol and encoding for IPP, so ... - Getting a port number allocated for IPP is OK - Specifying that port as the default port is OK - Creating a new scheme that never hits the wire and is handled inside clients and servers is NOT a wire protocol issue. While I think this material could be a interesting proposal and possibly an informational RFC or maybe even more, I don't think it belongs in the standard track RFCs that define IPP. While I am against a new method, at least it is a wire level issue. ... my 2 cents worth ... ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Jun 16 20:46:46 1998 Delivery-Date: Tue, 16 Jun 1998 20:46:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02060 for ; Tue, 16 Jun 1998 20:46:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11730 for ; Tue, 16 Jun 1998 20:49:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA21291 for ; Tue, 16 Jun 1998 20:46:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 20:41:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20659 for ipp-outgoing; Tue, 16 Jun 1998 20:36:12 -0400 (EDT) Message-Id: <199806170032.RAA00289@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 16 Jun 1998 17:37:38 -0700 To: don@lexmark.com, ipp@pwg.org From: Robert Herriot Subject: Re: IPP> Proposal for new IPP scheme In-Reply-To: <199806170009.AA18904@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_21611866==_.ALT" Sender: owner-ipp@pwg.org --=====================_21611866==_.ALT Content-Type: text/plain; charset="us-ascii" Actually the default port never hits the wire either. Both the default port and the ipp scheme-name are smoke and mirrors on the client which give the illusion of an ipp scheme. On the wire there is nothing but http with default port 80. If the IPP RFC's should specify wire protocol only, then they should not discuss ipp schemes or default ports. If we believe the IPP RFC's should give some hints for implementing clients, then the proposal from Randy about the ipp scheme and default ports is reasonable except for the last line. Bob Herriot At 05:04 PM 6/16/98 , don@lexmark.com wrote: >The more I think about this, the more I think it is out of scope for the >work we are doing. We are working on the wire protocol and encoding for >IPP, so ... > >- Getting a port number allocated for IPP is OK >- Specifying that port as the default port is OK >- Creating a new scheme that never hits the wire and is handled inside >clients and servers is NOT a wire protocol issue. > >While I think this material could be a interesting proposal and possibly an >informational RFC or maybe even more, I don't think it belongs in the >standard track RFCs that define IPP. While I am against a new method, at >least it is a wire level issue. > >... my 2 cents worth ... > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > --=====================_21611866==_.ALT Content-Type: text/html; charset="us-ascii" Actually the default port never hits the wire either.  Both the default port
and the ipp scheme-name are smoke and mirrors on the client which give the
illusion of an ipp scheme.

On the wire there is nothing but http with default port 80.

If the IPP RFC's should specify wire protocol only, then they should not
discuss ipp schemes or default ports. If we believe the IPP RFC's should
give some hints for implementing clients, then the proposal from Randy about
the ipp scheme and default ports is reasonable except for the last line.

Bob Herriot

At 05:04 PM 6/16/98 , don@lexmark.com wrote:
>The more I think about this, the more I think it is out of scope for the
>work we are doing.  We are working on the wire protocol and encoding for
>IPP, so ...
>
>- Getting a port number allocated for IPP is OK
>- Specifying that port as the default port is OK
>- Creating a new scheme that never hits the wire and is handled inside
>clients and servers is NOT a wire protocol issue.
>
>While I think this material could be a interesting proposal and possibly an
>informational RFC or maybe even more, I don't think it belongs in the
>standard track RFCs that define IPP.  While I am against a new method, at
>least it is a wire level issue.
>
>... my 2 cents worth ...
>
>**********************************************
>* Don Wright                 don@lexmark.com *
>* Product Manager, Strategic Alliances       *
>* Lexmark International                      *
>* 740 New Circle Rd                          *
>* Lexington, Ky 40550                        *
>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>**********************************************
>
--=====================_21611866==_.ALT-- From ipp-owner@pwg.org Tue Jun 16 20:55:40 1998 Delivery-Date: Tue, 16 Jun 1998 20:55:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02091 for ; Tue, 16 Jun 1998 20:55:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11759 for ; Tue, 16 Jun 1998 20:58:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA21944 for ; Tue, 16 Jun 1998 20:55:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 20:51:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20703 for ipp-outgoing; Tue, 16 Jun 1998 20:41:08 -0400 (EDT) Date: Tue, 16 Jun 1998 17:30:07 -0700 (Pacific Daylight Time) From: Ron Bergman To: ipp@pwg.org Subject: Re: IPP> Proposal for new IPP scheme In-Reply-To: <199806170009.AA18904@interlock2.lexmark.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org There have been several messages recently indicating that the ipp scheme proposal would not appear "on the wire". My understanding, both from the teleconference last week and the proposal recently submitted by Randy Turner, is that this is incorrect. The proposal is to send "ipp://...." on the wire! This is how a server is able to determine that the port number is the ipp default and not port 80. Now, how many out there still support this proposal? Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Tue Jun 16 21:01:33 1998 Delivery-Date: Tue, 16 Jun 1998 21:01:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02116 for ; Tue, 16 Jun 1998 21:01:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA11770 for ; Tue, 16 Jun 1998 21:03:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA22591 for ; Tue, 16 Jun 1998 21:01:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 16 Jun 1998 20:57:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA21187 for ipp-outgoing; Tue, 16 Jun 1998 20:45:39 -0400 (EDT) From: don@lexmark.com Message-Id: <199806170045.AA19903@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Robert Herriot Cc: Ipp@pwg.org Date: Tue, 16 Jun 1998 20:40:21 -0400 Subject: IPP> Proposal for new IPP scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Bob Herriot said: >Actually the default port never hits the wire either. Both the default port >and the ipp scheme-name are smoke and mirrors on the client which give the >illusion of an ipp scheme. > >On the wire there is nothing but http with default port 80. Oh, Bob, I disagree. The port does hit the wire one way or another. While the protocol encoding does not contain the port being used, what precedes the exchange of data does use a specific port (374 in Randy's and Larry's example) ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Jun 17 00:27:14 1998 Delivery-Date: Wed, 17 Jun 1998 00:27:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA09881 for ; Wed, 17 Jun 1998 00:27:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12312 for ; Wed, 17 Jun 1998 00:29:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA24879 for ; Wed, 17 Jun 1998 00:27:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 00:21:27 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA24286 for ipp-outgoing; Wed, 17 Jun 1998 00:19:11 -0400 (EDT) Message-Id: <1.5.4.32.19980617041459.007549f8@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, 16 Jun 1998 21:14:59 -0700 To: Robert Herriot , don@lexmark.com, ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> Proposal for new IPP scheme Sender: owner-ipp@pwg.org Bob, I do not agree with you on the port number. In every Internet protocol specification that I have seen there is talk about port numbers. You could argue that as we are using HTTP, we should use the port number for that. BTW, we are talking about DEFAULT port numbers, I hope that is still clear to everybody (you could still support port 80, but your printer must be able to use the new IPP port out of the box, at least that is my understanding). Unfortunately you did not make it to our phone conference with the Area Directors last week, in which they rather categorically declared that the IESG expects new protcols, such as IPP, to use new port numbers and if we want to get the IPP specifications past them, we WILL have a new DEFAULT port number for IPP. We can keep on arguing this point, but I think we are just wasting our time right now. As for the new scheme, I tend to agree that this really falls outside the protocol and does not neccessarily needs to be resolved as part of the IPP V1.0. Remains to also convince the Area Directors that this is the case. Carl-Uno At 05:37 PM 6/16/98 -0700, Robert Herriot wrote: >Actually the default port never hits the wire either. Both the default port >and the ipp scheme-name are smoke and mirrors on the client which give the >illusion of an ipp scheme. > >On the wire there is nothing but http with default port 80. > >If the IPP RFC's should specify wire protocol only, then they should not >discuss ipp schemes or default ports. If we believe the IPP RFC's should >give some hints for implementing clients, then the proposal from Randy about >the ipp scheme and default ports is reasonable except for the last line. > >Bob Herriot > >At 05:04 PM 6/16/98 , don@lexmark.com wrote: >>The more I think about this, the more I think it is out of scope for the >>work we are doing. We are working on the wire protocol and encoding for >>IPP, so ... >> >>- Getting a port number allocated for IPP is OK >>- Specifying that port as the default port is OK >>- Creating a new scheme that never hits the wire and is handled inside >>clients and servers is NOT a wire protocol issue. >> >>While I think this material could be a interesting proposal and possibly an >>informational RFC or maybe even more, I don't think it belongs in the >>standard track RFCs that define IPP. While I am against a new method, at >>least it is a wire level issue. >> >>... my 2 cents worth ... >> >>********************************************** >>* Don Wright don@lexmark.com * >>* Product Manager, Strategic Alliances * >>* Lexmark International * >>* 740 New Circle Rd * >>* Lexington, Ky 40550 * >>* 606-232-4808 (phone) 606-232-6740 (fax) * >>********************************************** >> > >Actually the default port never hits the wire either.  >Both the default port
>and the ipp scheme-name are smoke and mirrors on the client which give >the
>illusion of an ipp scheme.
>
>On the wire there is nothing but http with default port 80.
>
>If the IPP RFC's should specify wire protocol only, then they should not >
>discuss ipp schemes or default ports. If we believe the IPP RFC's should >
>give some hints for implementing clients, then the proposal from Randy >about
>the ipp scheme and default ports is reasonable except for the last >line.
>
>Bob Herriot
>
>At 05:04 PM 6/16/98 , don@lexmark.com wrote:
>>The more I think about this, the more I think it is out of scope for >the
>>work we are doing.  We are working on the wire protocol and >encoding for
>>IPP, so ...
>>
>>- Getting a port number allocated for IPP is OK
>>- Specifying that port as the default port is OK
>>- Creating a new scheme that never hits the wire and is handled >inside
>>clients and servers is NOT a wire protocol issue.
>>
>>While I think this material could be a interesting proposal and >possibly an
>>informational RFC or maybe even more, I don't think it belongs in >the
>>standard track RFCs that define IPP.  While I am against a new >method, at
>>least it is a wire level issue.
>>
>>... my 2 cents worth ...
>>
>>**********************************************
>>* Don >Wright           &nb sp;     >don@lexmark.com *
>>* Product Manager, Strategic >Alliances       *
>>* Lexmark >International          &n bsp;           >*
>>* 740 New Circle >Rd            & nbsp;             >*
>>* Lexington, Ky >40550           &nbs p;            >*
>>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>>**********************************************
>>
> > From ipp-owner@pwg.org Wed Jun 17 08:48:53 1998 Delivery-Date: Wed, 17 Jun 1998 08:48:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA15899 for ; Wed, 17 Jun 1998 08:48:52 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA13302 for ; Wed, 17 Jun 1998 08:51:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA28521 for ; Wed, 17 Jun 1998 08:48:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 08:36:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA27902 for ipp-outgoing; Wed, 17 Jun 1998 08:31:07 -0400 (EDT) Message-Id: <3587B5EB.E4F02DEA@dazel.com> Date: Wed, 17 Jun 1998 07:26:19 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Proposal for new IPP scheme References: <199806170009.AA18904@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org don@lexmark.com wrote: > > The more I think about this, the more I think it is out of scope for the > work we are doing. We are working on the wire protocol and encoding for > IPP, so ... > > - Getting a port number allocated for IPP is OK > - Specifying that port as the default port is OK > - Creating a new scheme that never hits the wire and is handled inside > clients and servers is NOT a wire protocol issue. > > While I think this material could be a interesting proposal and possibly an > informational RFC or maybe even more, I don't think it belongs in the > standard track RFCs that define IPP. While I am against a new method, at > least it is a wire level issue. I guess I am a bit confused as to why a new ipp: scheme is *not* a wire protocol issue. The last time that I checked, we are still returning URLs for printer and jobs in application/ipp responses. And, I am presuming that if we were to adopt an ipp: scheme (whether it is an alias for something or not) we would be returning those URLs with the ipp: scheme. So, why is this not a protocol issue? confused... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Wed Jun 17 09:00:25 1998 Delivery-Date: Wed, 17 Jun 1998 09:00:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16057 for ; Wed, 17 Jun 1998 09:00:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA13347 for ; Wed, 17 Jun 1998 09:02:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA29173 for ; Wed, 17 Jun 1998 09:00:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 08:56:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA28624 for ipp-outgoing; Wed, 17 Jun 1998 08:52:53 -0400 (EDT) From: Roger K Debry To: Subject: IPP> Proposal for new IPP scheme Message-ID: <5030100021890730000002L002*@MHS> Date: Wed, 17 Jun 1998 08:51:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA16057 In resposne to Randy's post ... POST http://myhost.com:374/myprinter/myqueue HTTP/1.1 Host: myproxy.com:374 Content-type: application/ipp Transfer-Encoding: chunked Why would the Host line have the 374 port? 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) I don't understand why this would be required. If it is, then I think it breaks the proposal. From ipp-owner@pwg.org Wed Jun 17 14:09:57 1998 Delivery-Date: Wed, 17 Jun 1998 14:09:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20875 for ; Wed, 17 Jun 1998 14:09:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14838 for ; Wed, 17 Jun 1998 14:12:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02017 for ; Wed, 17 Jun 1998 14:09:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 13:57:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00308 for ipp-outgoing; Wed, 17 Jun 1998 13:41:47 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> phone conference Date: Wed, 17 Jun 1998 10:20:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Can someone send me the number to call in for the IPP teleconference today? Thanks Randy From ipp-owner@pwg.org Wed Jun 17 14:09:59 1998 Delivery-Date: Wed, 17 Jun 1998 14:09:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20880 for ; Wed, 17 Jun 1998 14:09:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14842 for ; Wed, 17 Jun 1998 14:12:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02025 for ; Wed, 17 Jun 1998 14:09:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 13:57:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00338 for ipp-outgoing; Wed, 17 Jun 1998 13:45:51 -0400 (EDT) Message-Id: <199806171645.JAA03612@mail.pacifier.com> X-Sender: jrturner@mail.pacifier.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 17 Jun 1998 09:41:47 -0700 To: ipp@pwg.org From: Randy Turner Subject: IPP> phone conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Could someone resend the teleconference information for today to the DL? I seem to have lost my original... Thanks Randy From ipp-owner@pwg.org Wed Jun 17 14:10:10 1998 Delivery-Date: Wed, 17 Jun 1998 14:10:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20892 for ; Wed, 17 Jun 1998 14:10:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14846 for ; Wed, 17 Jun 1998 14:12:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02052 for ; Wed, 17 Jun 1998 14:10:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 13:59:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00347 for ipp-outgoing; Wed, 17 Jun 1998 13:45:55 -0400 (EDT) Message-Id: <199806171617.JAA19391@mail.pacifier.com> X-Sender: jrturner@mail.pacifier.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 17 Jun 1998 09:14:06 -0700 To: ipp@pwg.org From: Randy Turner Subject: IPP> IPP scheme proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The scenario in which the "ipp" scheme appears on the wire is not expected to actually be used. I believe the logic behind having the IPP server understand a "full" IPP URL is based upon the rationale in RFC 2068 for having HTTP servers be able to accept "full" URLs. Its just in the IPP case, it would be an "IPP" server, not an "HTTP" server. Basically, its to not "preclude" the future wherein full URLs might be passed around. Without this capability, full URL support would require retrofitting the entire HTTP/IPP deployment space. Again, this particular scenario for IPP schemes on the wire is only a "server" requirement in this proposal. Clients are still required to follow HTTP 1.1 guidelines set forth in 2068 (and later drafts). Which means (for now), the "ipp" scheme would NOT show up on the wire because clients would never send it. Randy -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Tuesday, June 16, 1998 5:30 PM To: ipp@pwg.org Subject: Re: IPP> Proposal for new IPP scheme There have been several messages recently indicating that the ipp scheme proposal would not appear "on the wire". My understanding, both from the teleconference last week and the proposal recently submitted by Randy Turner, is that this is incorrect. The proposal is to send "ipp://...." on the wire! This is how a server is able to determine that the port number is the ipp default and not port 80. Now, how many out there still support this proposal? Ron Bergman Dataproducts Corp. From ipp-owner@pwg.org Wed Jun 17 14:15:42 1998 Delivery-Date: Wed, 17 Jun 1998 14:15:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20942 for ; Wed, 17 Jun 1998 14:15:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14883 for ; Wed, 17 Jun 1998 14:18:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02746 for ; Wed, 17 Jun 1998 14:15:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 14:10:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01486 for ipp-outgoing; Wed, 17 Jun 1998 14:05:17 -0400 (EDT) Message-Id: <35880432.CA029563@dazel.com> Date: Wed, 17 Jun 1998 13:00:18 -0500 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: jrturner@pacifier.com, rturner@sharplabs.com Cc: ipp@pwg.org Subject: [Fwd: IPP> ADM - Agenda for PWG IPP Phone Conference 980617] Content-Type: multipart/mixed; boundary="------------A11D1A834D64888B7775ED0B" Sender: owner-ipp@pwg.org This is a multi-part message in MIME format. --------------A11D1A834D64888B7775ED0B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit come join us... ...walker --------------A11D1A834D64888B7775ED0B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from support.dazel.com by dazel.com (4.1/SMI-4.1) id AA21570; Mon, 15 Jun 98 17:22:24 CDT Received: from lists.underscore.com by support.dazel.com (8.8.7/dazel) id RAA04417 for ; Mon, 15 Jun 1998 17:22:22 -0500 (CDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01855 for ; Mon, 15 Jun 1998 18:22:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 18:21:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01683 for ipp-outgoing; Mon, 15 Jun 1998 18:17:18 -0400 (EDT) Message-Id: <3.0.5.32.19980615150424.009d2a10@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Jun 1998 15:04:24 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980617 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Agenda for PWG IPP Phone Conference 980617 ========================================== We will hold our normal weekly conference in Wednesday. I want to get to closure on the remaining show stoppers, so the editors can finish up the next set of drafts to be sent to the IESG for their final review. Based on the discussion with the Application Area Directors last weeek, I consider the discussion about a separate default port for IPP closed. This was the preferred method from the IESG to distinguish IPP from other HTTP traffic and seemed to get overall approval from the members of the WG. I have sent in the application for an IPP port to the IANA registry. Subjects from Keith Moore's review that might need some further discussion are: 1) Do we really need a new ipp: scheme, when we introduce the new port? Are we clear on all the consequences of introducing a new scheme? Can we fit in a security parameter, when we define the new scheme? (Larry Masinter and Randy Turner are working on a draft - hopefully ready for the Wednesday phone call). 2) Considering that we have the new default port number for IPP, do we need to also distinguish IPP by using a PRINT method rather than POST? Another subject which has been discussed on the DL is: 3) Do we want to keep the redundant (and potentially conflicting) operation attributes for Print-URI and Job-URI in the MIME structure, or take them out? I would like to focus the discussion around these three subjects. I do not think that there are any further issues to discuss at this point, apart from reviewing the minor editorials that we have already agreed on in principle. Here is the dial-in information: Time: June 17, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com --------------A11D1A834D64888B7775ED0B-- From ipp-owner@pwg.org Wed Jun 17 15:46:45 1998 Delivery-Date: Wed, 17 Jun 1998 15:46:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21674 for ; Wed, 17 Jun 1998 15:46:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15352 for ; Wed, 17 Jun 1998 15:49:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04518 for ; Wed, 17 Jun 1998 15:46:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 15:42:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03957 for ipp-outgoing; Wed, 17 Jun 1998 15:38:21 -0400 (EDT) Message-Id: <3.0.5.32.19980617123544.00b762c0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Jun 1998 12:35:44 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Results from the IPP Phone Conference 980617 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, In today's phone conference, which included the editors and most of the main stakeholders in the IPP project, the following agreements were arrived at: 1) We will update our documents to include a new default port for IPP. The application for that port has already been sent to IANA for processing. To use the default port number, it will need to be explicitly included in IPP URLs using the "http:" scheme. 2) Will will NOT pursue the "ipp:" scheme proposal for inclusion in IPP V1.0, as it seems to give us more issues than it resolves at present. We can continue this discussion as a separate topic after IPP V1.0 has been finished. 3) We will NOT pursue further discussion of a new HTTP method for IPP in IPP V1.0. 4) We will keep the Printer and Job URIs in the application/ipp as currently defined. They are mandated to be semantically equivalent with any corresponding URI information in the HTTP layer. No changes needed to the current specification. 5) We will document that the minimum length of all text strings are 0 unless otherwise specified. 6) Scott Isaacson will provide an updated version of the Model & Semantics document in time for next week's phone conference. 7) Paul Moore indicated that he wants to register a few new operations as extensions to IPP. These will be presented and discussed in the upcoming IPP meeting in Monterey. If any of you WG members who were not in the phone conference wants to object to any of these ananimous agreements, please speak up NOW. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 17 16:01:38 1998 Delivery-Date: Wed, 17 Jun 1998 16:01:48 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA21859 for ; Wed, 17 Jun 1998 16:01:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15433 for ; Wed, 17 Jun 1998 16:03:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA05128 for ; Wed, 17 Jun 1998 16:01:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 15:57:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04589 for ipp-outgoing; Wed, 17 Jun 1998 15:54:52 -0400 (EDT) From: "Larry Masinter" To: "Roger K Debry" Cc: Subject: RE: IPP> Proposal for new IPP scheme Date: Wed, 17 Jun 1998 12:52:58 PDT Message-ID: <000101bd9a29$86c2ec60$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <5030100021890730000002L002*@MHS> Sender: owner-ipp@pwg.org > In response to Randy's post ... > > POST http://myhost.com:374/myprinter/myqueue HTTP/1.1 > Host: myproxy.com:374 > Content-type: application/ipp > Transfer-Encoding: chunked > > Why would the Host line have the 374 port? Please see section 14.23 ("Host") of draft-ietf-http-v11-spec-rev-03.txt which lays out the requirements and conditions more clearly. > 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) > > I don't understand why this would be required. If it > is, then I think it breaks the proposal. Please see section 5.1.2 ("Request-URI") of draft-ietf-http-v11-spec-rev-03.txt. From ipp-owner@pwg.org Wed Jun 17 16:11:38 1998 Delivery-Date: Wed, 17 Jun 1998 16:11:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22006 for ; Wed, 17 Jun 1998 16:11:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15479 for ; Wed, 17 Jun 1998 16:13:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA05738 for ; Wed, 17 Jun 1998 16:11:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 16:07:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04625 for ipp-outgoing; Wed, 17 Jun 1998 15:57:32 -0400 (EDT) From: Harry Lewis To: Subject: Re: IPP> ADM - Results from the IPP Phone Conference 980617 Message-ID: <5030100021911682000002L022*@MHS> Date: Wed, 17 Jun 1998 15:56:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA22006 I am very sorry I was unable to make today's phone conference. However, I am in FULL agreement with all of the recorded decisions. Congratulations on the apparent decisive nature of today's call. Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 06/17/98 01:49:13 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> ADM - Results from the IPP Phone Conference 980617 All, In today's phone conference, which included the editors and most of the main stakeholders in the IPP project, the following agreements were arrived at: 1) We will update our documents to include a new default port for IPP. The application for that port has already been sent to IANA for processing. To use the default port number, it will need to be explicitly included in IPP URLs using the "http:" scheme. 2) Will will NOT pursue the "ipp:" scheme proposal for inclusion in IPP V1.0, as it seems to give us more issues than it resolves at present. We can continue this discussion as a separate topic after IPP V1.0 has been finished. 3) We will NOT pursue further discussion of a new HTTP method for IPP in IPP V1.0. 4) We will keep the Printer and Job URIs in the application/ipp as currently defined. They are mandated to be semantically equivalent with any corresponding URI information in the HTTP layer. No changes needed to the current specification. 5) We will document that the minimum length of all text strings are 0 unless otherwise specified. 6) Scott Isaacson will provide an updated version of the Model & Semantics document in time for next week's phone conference. 7) Paul Moore indicated that he wants to register a few new operations as extensions to IPP. These will be presented and discussed in the upcoming IPP meeting in Monterey. If any of you WG members who were not in the phone conference wants to object to any of these ananimous agreements, please speak up NOW. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jun 17 16:42:49 1998 Delivery-Date: Wed, 17 Jun 1998 16:42:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22218 for ; Wed, 17 Jun 1998 16:42:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15655 for ; Wed, 17 Jun 1998 16:45:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06523 for ; Wed, 17 Jun 1998 16:42:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 16:37:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05892 for ipp-outgoing; Wed, 17 Jun 1998 16:28:14 -0400 (EDT) Date: Wed, 17 Jun 1998 13:34:50 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9806172034.AA10572@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, manros@cp10.es.xerox.com Subject: Re: IPP> ADM - Results from the IPP Phone Conference 980617 Sender: owner-ipp@pwg.org Hi folks, Thanks for your quick positive confirmation, Harry Lewis. For the information of those NOT on today's telecon, the participants included: Carl-Uno M (Xerox) Tom H (Xerox) Pete Z (Xerox) Scott I (Novell) Bob H (Sun) Ron B (Dataproducts) Roger deBry (IBM) Paul Moore (Microsoft) Shivaun Albright (HP) Randy Turner (Sharp) Jim Walker (Dazel) Ira McDonald (High North) That list may not be complete. To the best of my knowledge, ALL of the above people participated in the unanimous concensus documented in Carl-Uno's note a little while ago this afternoon. Cheers, - Ira McDonald From ipp-owner@pwg.org Wed Jun 17 16:47:56 1998 Delivery-Date: Wed, 17 Jun 1998 16:47:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22264 for ; Wed, 17 Jun 1998 16:47:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA15710 for ; Wed, 17 Jun 1998 16:50:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07138 for ; Wed, 17 Jun 1998 16:47:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 16:43:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05910 for ipp-outgoing; Wed, 17 Jun 1998 16:29:44 -0400 (EDT) Message-Id: <199806172025.NAA01779@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 17 Jun 1998 13:31:17 -0700 To: don@lexmark.com, Robert Herriot From: Robert Herriot Subject: Re: IPP> Proposal for new IPP scheme Cc: Ipp@pwg.org In-Reply-To: <199806170045.AA19903@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_679967==_.ALT" Sender: owner-ipp@pwg.org --=====================_679967==_.ALT Content-Type: text/plain; charset="us-ascii" I agree that the port hits the wire, but there is nothing on the wire that identifies it as a default port. I think that we all agreed to this in today's teleconference. Bob Herriot At 05:40 PM 6/16/98 , don@lexmark.com wrote: >Bob Herriot said: > >>Actually the default port never hits the wire either. Both the default >port >>and the ipp scheme-name are smoke and mirrors on the client which give the >>illusion of an ipp scheme. >> >>On the wire there is nothing but http with default port 80. > >Oh, Bob, I disagree. The port does hit the wire one way or another. While >the protocol encoding does not contain the port being used, what precedes >the exchange of data does use a specific port (374 in Randy's and Larry's >example) > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > --=====================_679967==_.ALT Content-Type: text/html; charset="us-ascii" I agree that the port hits the wire, but there is nothing on the wire that identifies it as
a default port. I think that we all agreed to this in today's teleconference.

Bob Herriot

At 05:40 PM 6/16/98 , don@lexmark.com wrote:
>Bob Herriot said:
>
>>Actually the default port never hits the wire either.  Both the default
>port
>>and the ipp scheme-name are smoke and mirrors on the client which give the
>>illusion of an ipp scheme.
>>
>>On the wire there is nothing but http with default port 80.
>
>Oh, Bob, I disagree.  The port does hit the wire one way or another.  While
>the protocol encoding does not contain the port being used, what precedes
>the exchange of data does use a specific port (374 in Randy's and Larry's
>example)
>
>**********************************************
>* Don Wright                 don@lexmark.com *
>* Product Manager, Strategic Alliances       *
>* Lexmark International                      *
>* 740 New Circle Rd                          *
>* Lexington, Ky 40550                        *
>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>**********************************************
>
--=====================_679967==_.ALT-- From ipp-owner@pwg.org Wed Jun 17 23:47:39 1998 Delivery-Date: Wed, 17 Jun 1998 23:47:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id XAA11762 for ; Wed, 17 Jun 1998 23:47:39 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA17550 for ; Wed, 17 Jun 1998 23:50:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA10109 for ; Wed, 17 Jun 1998 23:47:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 17 Jun 1998 23:42:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09459 for ipp-outgoing; Wed, 17 Jun 1998 23:37:41 -0400 (EDT) From: Harry Lewis To: Cc: Roger K Debry , Subject: Re: IPP> ADM - Results from the IPP Phone Conference 980617 Message-ID: <5030100021928644000002L042*@MHS> Date: Wed, 17 Jun 1998 23:36:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA11762 Carl-Uno, in my review of the meeting with Roger, he also mentioned an agreement to not tie IPPv1 to TLS but to implement with SSL3 for now with plans to move to TLS when appropriate. I think you missed this in your "minutes". I think this is in line with recommendations form Keith under the circumstances regarding lack of closure of TLS. As with your other conclusions, today... I agree! Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 06/17/98 01:49:13 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: IPP> ADM - Results from the IPP Phone Conference 980617 All, In today's phone conference, which included the editors and most of the main stakeholders in the IPP project, the following agreements were arrived at: 1) We will update our documents to include a new default port for IPP. The application for that port has already been sent to IANA for processing. To use the default port number, it will need to be explicitly included in IPP URLs using the "http:" scheme. 2) Will will NOT pursue the "ipp:" scheme proposal for inclusion in IPP V1.0, as it seems to give us more issues than it resolves at present. We can continue this discussion as a separate topic after IPP V1.0 has been finished. 3) We will NOT pursue further discussion of a new HTTP method for IPP in IPP V1.0. 4) We will keep the Printer and Job URIs in the application/ipp as currently defined. They are mandated to be semantically equivalent with any corresponding URI information in the HTTP layer. No changes needed to the current specification. 5) We will document that the minimum length of all text strings are 0 unless otherwise specified. 6) Scott Isaacson will provide an updated version of the Model & Semantics document in time for next week's phone conference. 7) Paul Moore indicated that he wants to register a few new operations as extensions to IPP. These will be presented and discussed in the upcoming IPP meeting in Monterey. If any of you WG members who were not in the phone conference wants to object to any of these ananimous agreements, please speak up NOW. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jun 18 02:32:27 1998 Delivery-Date: Thu, 18 Jun 1998 02:32:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id CAA16156 for ; Thu, 18 Jun 1998 02:32:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA17871 for ; Thu, 18 Jun 1998 02:34:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA11367 for ; Thu, 18 Jun 1998 02:32:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Jun 1998 02:27:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10807 for ipp-outgoing; Thu, 18 Jun 1998 02:22:06 -0400 (EDT) Message-Id: <1.5.4.32.19980618061939.0068d270@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: Wed, 17 Jun 1998 23:19:39 -0700 To: From: Carl-Uno Manros Subject: Re: IPP> ADM - Results from the IPP Phone Conference 980617 Sender: owner-ipp@pwg.org Harry, No this is a misunderstanding. TLS is still in as a SHOULD, SSL3 will be crossed out except as one attribute value for possible security services. This was in our initial response back to Keith, and confirmed in our phone conference with the Area Directors last week. Carl-Uno At 11:36 PM 6/17/98 -0400, Harry Lewis wrote: >Carl-Uno, in my review of the meeting with Roger, he also mentioned an >agreement to not tie IPPv1 to TLS but to implement with SSL3 for now with plans >to move to TLS when appropriate. I think you missed this in your "minutes". I >think this is in line with recommendations form Keith under the circumstances >regarding lack of closure of TLS. > >As with your other conclusions, today... I agree! > >Harry Lewis - IBM Printing Systems > > > >owner-ipp@pwg.org on 06/17/98 01:49:13 PM >Please respond to owner-ipp@pwg.org >To: ipp@pwg.org >cc: >Subject: IPP> ADM - Results from the IPP Phone Conference 980617 > > >All, > >In today's phone conference, which included the editors and most of the >main stakeholders in the IPP project, the following agreements were arrived >at: > >1) We will update our documents to include a new default port for IPP. The >application for that port has already been sent to IANA for processing. >To use the default port number, it will need to be explicitly included in >IPP URLs using the "http:" scheme. > >2) Will will NOT pursue the "ipp:" scheme proposal for inclusion in IPP >V1.0, as it seems to give us more issues than it resolves at present. We >can continue this discussion as a separate topic after IPP V1.0 has been >finished. > >3) We will NOT pursue further discussion of a new HTTP method for IPP in >IPP V1.0. > >4) We will keep the Printer and Job URIs in the application/ipp as >currently defined. They are mandated to be semantically equivalent with any >corresponding URI information in the HTTP layer. No changes needed to the >current specification. > >5) We will document that the minimum length of all text strings are 0 >unless otherwise specified. > >6) Scott Isaacson will provide an updated version of the Model & Semantics >document in time for next week's phone conference. > >7) Paul Moore indicated that he wants to register a few new operations as >extensions to IPP. These will be presented and discussed in the upcoming >IPP meeting in Monterey. > >If any of you WG members who were not in the phone conference wants to >object to any of these ananimous agreements, please speak up NOW. > >Carl-Uno > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > > > > From ipp-owner@pwg.org Thu Jun 18 08:13:07 1998 Delivery-Date: Thu, 18 Jun 1998 08:13:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id IAA16949 for ; Thu, 18 Jun 1998 08:13:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA18571 for ; Thu, 18 Jun 1998 08:15:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA12475 for ; Thu, 18 Jun 1998 08:12:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 18 Jun 1998 08:02:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA11899 for ipp-outgoing; Thu, 18 Jun 1998 07:58:48 -0400 (EDT) From: don@lexmark.com Message-Id: <199806181156.AA04232@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Carl-Uno Manros Cc: Ipp@pwg.org Date: Thu, 18 Jun 1998 07:56:16 -0400 Subject: Re: IPP> ADM - Results from the IPP Phone Conference 980617 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Unfortunately I was unable to participate in the conference call as I was returning from PC-EXPO. Perhaps that is good because each and every decision (1 through 5 in the attached note) is exactly as I prefer. Maybe I should miss more calls??!!?? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Carl-Uno Manros on 06/17/98 03:35:44 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> ADM - Results from the IPP Phone Conference 980617 All, In today's phone conference, which included the editors and most of the main stakeholders in the IPP project, the following agreements were arrived at: 1) We will update our documents to include a new default port for IPP. The application for that port has already been sent to IANA for processing. To use the default port number, it will need to be explicitly included in IPP URLs using the "http:" scheme. 2) Will will NOT pursue the "ipp:" scheme proposal for inclusion in IPP V1.0, as it seems to give us more issues than it resolves at present. We can continue this discussion as a separate topic after IPP V1.0 has been finished. 3) We will NOT pursue further discussion of a new HTTP method for IPP in IPP V1.0. 4) We will keep the Printer and Job URIs in the application/ipp as currently defined. They are mandated to be semantically equivalent with any corresponding URI information in the HTTP layer. No changes needed to the current specification. 5) We will document that the minimum length of all text strings are 0 unless otherwise specified. 6) Scott Isaacson will provide an updated version of the Model & Semantics document in time for next week's phone conference. 7) Paul Moore indicated that he wants to register a few new operations as extensions to IPP. These will be presented and discussed in the upcoming IPP meeting in Monterey. If any of you WG members who were not in the phone conference wants to object to any of these ananimous agreements, please speak up NOW. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jun 19 13:51:18 1998 Delivery-Date: Fri, 19 Jun 1998 13:51:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA09199 for ; Fri, 19 Jun 1998 13:51:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA25303 for ; Fri, 19 Jun 1998 13:53:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19680 for ; Fri, 19 Jun 1998 13:51:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 19 Jun 1998 13:43:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19132 for ipp-outgoing; Fri, 19 Jun 1998 13:40:43 -0400 (EDT) Message-Id: <3.0.5.32.19980619084917.00b7ac20@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 19 Jun 1998 08:49:17 PDT Illegal-Object: Syntax error in To: address found on alpha.xerox.com: To: ipp@pwg.org@cp10.es.xerox.com ^-missing end of address From: Carl-Uno Manros To: To: Subject: IPP> SEC - PKIX is moving Cc: moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, I have just learned from Daniel Manchala from our Security team that the negotiations about PKIX have been sucessfully concluded. The document will now go out for a WG Last Call and then passed on to the IESG. This should resolve the bind in getting the TLS specifications out, and hence remove any delays of the IPP documents for that reason. If you want to see the new PKIX specification, please look at: http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-08.txt Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 22 13:59:02 1998 Delivery-Date: Mon, 22 Jun 1998 13:59:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA04445 for ; Mon, 22 Jun 1998 13:59:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05021 for ; Mon, 22 Jun 1998 14:01:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27242 for ; Mon, 22 Jun 1998 13:58:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Jun 1998 13:48:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26649 for ipp-outgoing; Mon, 22 Jun 1998 13:43:59 -0400 (EDT) Message-Id: <3.0.5.32.19980622104101.009e4580@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 22 Jun 1998 10:41:01 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - The default port-number for IPP is 631 Cc: sisaacson@novell.com, robert.herriot@Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, We have just got the port number for IPP allocated. As for editing of our documents, I suggest to put into the Model document that a new default port number will be allocated for each mapping, and that the new port number 631 is then specified in the Protocol document. All agreed? Carl-Uno >From: Internet Assigned Numbers Authority >Date: Mon, 22 Jun 1998 10:27:37 PDT >To: manros@cp10.es.xerox.com >Subject: Re: Application for port-number >Cc: iana@isi.edu >X-Sun-Charset: US-ASCII > > >Carl-Uno Manros, > >We have assigned port number 631 to ipp with you as the point of >contact. Thanks. > >Josh Elliott > >*************************************************************** >Information Sciences Institute >Internet Assigned Numbers Authority >4676 Admiralty Way, Suite 1001 >Marina del Rey, CA 90292 >USA > >Voice: (310) 822-1511 x302 >FAX: (310) 823-6714 >email: iana@iana.org >*************************************************************** > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 22 18:03:59 1998 Delivery-Date: Mon, 22 Jun 1998 18:04:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA06051 for ; Mon, 22 Jun 1998 18:03:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA07092 for ; Mon, 22 Jun 1998 18:06:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA28572 for ; Mon, 22 Jun 1998 18:03:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 22 Jun 1998 17:58:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28032 for ipp-outgoing; Mon, 22 Jun 1998 17:56:40 -0400 (EDT) Message-Id: <3.0.5.32.19980622145614.00f1a210@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 22 Jun 1998 14:56:14 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980624 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Agenda for PWG IPP Phone Conference 980624 ========================================== We will hold our normal weekly conference on Wednesday. As we successfully managed to reach agreements on all the major issues last week, we are now left with going over some of the smaller editorial changes that the editors have produced in response to the earlier comments from Keith Moore. We should have new versions available for at least the Model and the Rationale documents by tomorrow. Here is the dial-in information: Time: June 24, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jun 23 10:35:37 1998 Delivery-Date: Tue, 23 Jun 1998 10:35:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA20500 for ; Tue, 23 Jun 1998 10:35:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA09505 for ; Tue, 23 Jun 1998 10:37:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA13199 for ; Tue, 23 Jun 1998 10:35:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 10:23:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA12637 for ipp-outgoing; Tue, 23 Jun 1998 10:19:18 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP> New rationale Internet draft - draft Message-ID: <5030100022181389000002L092*@MHS> Date: Tue, 23 Jun 1998 10:18:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20500 I have posted a new draft of the rationale document with changes recommended by Keith Moore. Please review and comment. It can be found at ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-ietf-ipp-rat-03.txt Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From jmp-owner@pwg.org Tue Jun 23 11:03:54 1998 Delivery-Date: Tue, 23 Jun 1998 11:03:54 -0400 Return-Path: jmp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id LAA21045 for ; Tue, 23 Jun 1998 11:03:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA09744 for ; Tue, 23 Jun 1998 11:06:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA14527 for ; Tue, 23 Jun 1998 11:03:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 10:57:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13380 for jmp-outgoing; Tue, 23 Jun 1998 10:51:39 -0400 (EDT) Message-ID: <358FC0CC.2E1F88E2@underscore.com> Date: Tue, 23 Jun 1998 10:50:52 -0400 From: Jeff Schnitzer X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: fin@pwg.org, ipp@pwg.org, jmp@pwg.org, p1394@pwg.org, pmp@pwg.org, pwg@pwg.org, sdp@pwg.org, sense@pwg.org, upd@pwg.org Subject: JMP> Please ignore this test message. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jmp-owner@pwg.org Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From ipp-owner@pwg.org Tue Jun 23 11:13:49 1998 Delivery-Date: Tue, 23 Jun 1998 11:13:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21242 for ; Tue, 23 Jun 1998 11:13:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA09824 for ; Tue, 23 Jun 1998 11:16:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA15823 for ; Tue, 23 Jun 1998 11:13:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 11:06:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13391 for ipp-outgoing; Tue, 23 Jun 1998 10:51:54 -0400 (EDT) Message-ID: <358FC0CC.2E1F88E2@underscore.com> Date: Tue, 23 Jun 1998 10:50:52 -0400 From: Jeff Schnitzer X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: fin@pwg.org, ipp@pwg.org, jmp@pwg.org, p1394@pwg.org, pmp@pwg.org, pwg@pwg.org, sdp@pwg.org, sense@pwg.org, upd@pwg.org Subject: IPP> Please ignore this test message. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From pmp-owner@pwg.org Tue Jun 23 11:19:31 1998 Delivery-Date: Tue, 23 Jun 1998 11:19:32 -0400 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21367 for ; Tue, 23 Jun 1998 11:19:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA09753 for ; Tue, 23 Jun 1998 11:08:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA14757 for ; Tue, 23 Jun 1998 11:06:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 10:59:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13364 for pmp-outgoing; Tue, 23 Jun 1998 10:51:21 -0400 (EDT) Message-ID: <358FC0CC.2E1F88E2@underscore.com> Date: Tue, 23 Jun 1998 10:50:52 -0400 From: Jeff Schnitzer X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: fin@pwg.org, ipp@pwg.org, jmp@pwg.org, p1394@pwg.org, pmp@pwg.org, pwg@pwg.org, sdp@pwg.org, sense@pwg.org, upd@pwg.org Subject: PMP> Please ignore this test message. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: pmp-owner@pwg.org Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From ipp-owner@pwg.org Tue Jun 23 13:44:13 1998 Delivery-Date: Tue, 23 Jun 1998 13:44:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05447 for ; Tue, 23 Jun 1998 13:44:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA10876 for ; Tue, 23 Jun 1998 13:46:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17029 for ; Tue, 23 Jun 1998 13:44:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 13:38:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16463 for ipp-outgoing; Tue, 23 Jun 1998 13:36:57 -0400 (EDT) Message-Id: <3.0.5.32.19980623103623.00c774e0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Jun 1998 10:36:23 PDT To: ipp@pwg.org From: "Scott Isaacson" (by way of Tom Hastings ) Subject: IPP> MOD - New Model document posted - ipp-model-980619.pdf Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I've posted the updated Model document with all of the changes requested by the Area Director and agreed to by the WG at last week's telecon and previously: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619-rev.pdf The latter shows the revisions from the January I-D, and so includes the changes that were in the May 29 version (since it was not made an I-D). Please look at the revisions to make sure we are all in agreement on the telecon, tommorrow, Wed, 6/24/98, 10-12 PDT (1-3 EDT). Send e-mail and/or join the call if you see any problems. The plan is to send all the documents to the IESG as soon as possible BEFORE the Monterey meeting. Two salient points: 1. Section 6 is updated after initial discussions with Jon Postel of IANA as requested by Keith Moore in his comments. Jon requested a new section 12 be added for how to submit requests for registrations. Both sections 6 and 12 have not yet been reviewed by Jon. 2. We had to keep the 'name' attribute syntax at a maximum of 255 octets, since the Printer MIB has the prtInputMediaName as 255 octets which is the same as the IPP "media" attribute. Also since the Printer MIB has prtGeneralPrinterName as 127 octets and a number of other names as 63 octets (vendor name, etc.), we had to keep the concept that the 'name' attribute syntax, like the 'text' attribute syntax, can have a shortened maximum in the header line in the Model specification. Scott P.S. Scott asked me (Tom) to send the e-mail, because of a problem with his e-mail server. From ipp-owner@pwg.org Wed Jun 24 11:08:00 1998 Delivery-Date: Wed, 24 Jun 1998 11:08:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06106 for ; Tue, 23 Jun 1998 15:08:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11326 for ; Tue, 23 Jun 1998 15:10:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA18412 for ; Tue, 23 Jun 1998 15:08:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 15:03:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17848 for ipp-outgoing; Tue, 23 Jun 1998 14:59:51 -0400 (EDT) Date: Tue, 23 Jun 1998 11:26:11 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9806231826.AA11891@snorkel.eso.mc.xerox.com> To: SISAACSON@novell.com, ipp@pwg.org Subject: Re: IPP> MOD - New Model document posted - ipp-model-980619.pdf Sender: owner-ipp@pwg.org Hi Scott, Well done! Also, to Roger deBry for updating the Rationale. Bob Herriot, you got a new Protocol Encoding draft in the works? Let's keep our good concensus and good cooperation going forward. It was VERY productive having two IESG Area Directors (Keith Moore and Patrik Faltstrom) join our telecon and help us understand their concerns. See you all on the phone tomorrow, - Ira McDonald From ipp-owner@pwg.org Wed Jun 24 11:08:04 1998 Delivery-Date: Wed, 24 Jun 1998 11:08:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA05926 for ; Tue, 23 Jun 1998 14:37:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11133 for ; Tue, 23 Jun 1998 14:40:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17720 for ; Tue, 23 Jun 1998 14:37:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 23 Jun 1998 14:33:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17206 for ipp-outgoing; Tue, 23 Jun 1998 14:29:15 -0400 (EDT) Message-Id: <3.0.5.32.19980623112717.00ba8cd0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Jun 1998 11:27:17 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - New Model document posted - ipp-model-980619.pdf Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Scott just phoned me from an off site meeting and he was not able to do the diff with the January version. MS-WORD had problems with doing the diff. So the revision marks are against the May 29 version only (contrary to the message sent below). Tom >X-Sender: hastings@garfield >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Tue, 23 Jun 1998 10:36:23 PDT >To: ipp@pwg.org >From: "Scott Isaacson" (by way of Tom Hastings ) >Subject: IPP> MOD - New Model document posted - ipp-model-980619.pdf >Sender: owner-ipp@pwg.org > >I've posted the updated Model document with all of the changes requested >by the Area Director and agreed to by the WG at last week's telecon >and previously: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619.txt >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-980619-rev.pdf > >The latter shows the revisions from the January I-D, and so includes >the changes that were in the May 29 version (since it was not made an I-D). > >Please look at the revisions to make sure we are all in agreement on the >telecon, tommorrow, Wed, 6/24/98, 10-12 PDT (1-3 EDT). Send e-mail and/or >join the call if you see any problems. The plan is to send all the >documents to the IESG as soon as possible BEFORE the Monterey meeting. > >Two salient points: > >1. Section 6 is updated after initial discussions with Jon Postel of IANA >as requested by Keith Moore in his comments. > >Jon requested a new section 12 be added for how to submit requests >for registrations. > >Both sections 6 and 12 have not yet been reviewed by Jon. > >2. We had to keep the 'name' attribute syntax at a maximum of 255 octets, >since the Printer MIB has the prtInputMediaName as 255 octets which is >the same as the IPP "media" attribute. Also since the Printer MIB has >prtGeneralPrinterName as 127 octets and a number of other names as 63 octets >(vendor name, etc.), we had to keep the concept that the 'name' attribute >syntax, like the 'text' attribute syntax, can have a shortened maximum >in the header line in the Model specification. > >Scott > >P.S. Scott asked me (Tom) to send the e-mail, because of a problem with >his e-mail server. > > > > > > > > > From root@uscore.underscore.com Thu Jun 25 00:15:30 1998 Delivery-Date: Thu, 25 Jun 1998 00:20:30 -0400 Return-Path: root@uscore.underscore.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA02790 for ; Thu, 25 Jun 1998 00:06:29 -0400 (EDT) Received: from uscore.underscore.com (uscore.underscore.com [199.125.69.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA18407 for ; Thu, 25 Jun 1998 00:08:41 -0400 (EDT) Received: (from root@localhost) by uscore.underscore.com (8.8.4/8.7.2) id TAA08640; Wed, 24 Jun 1998 19:54:45 -0400 (EDT) Date: Wed, 24 Jun 1998 19:54:45 -0400 (EDT) From: Super-User Message-Id: <199806242354.TAA08640@uscore.underscore.com> To: AL_PIEPHO@HP-Greeley-om2.om.hp.com, Aillil_Halsema@es.xerox.com, Angelo.Caruso@usa.xerox.com, BERENGUER_TORELLO@non-hp-iberia-om2.om.hp.com, Brent.Thomas@eng.efi.com, CARLOS_F_BECERRA@HP-Guadalajara-om1.om.hp.com, Chris_Mason@csme.canon.co.uk, Chung-Mei_Sung@xn.xerox.com, DAVID_KUNTZ@HP-Roseville-om2.om.hp.com, DEK1%mimi@magic.itg.ti.com, DENISE_ZIMMERMAN@HP-Boise-om8.om.hp.com, DTAYLOR@novell.com, Diana.Klashman@East.Sun.COM, Don_Purpura@cissc.canon.com, ERIC_CLEMENT@HP-Roseville-om2.om.hp.com, Edward_R_Rhoads@ccm.intel.com, Eugene.Chen@eng.efi.com, Foteos.Macrides@gte.net, Gregg_Bonikowski@wb.xerox.com, Harish.Manepalli@eng.efi.com, JPODOJIL@genicom.com, JRackowitz@engpo.msmailgw.intermec.com, Jason.Chen@eng.efi.com, Joel.Bennett@usa.xerox.com, KEN_OAKESON@HP-Boise-om8.om.hp.com, KL@PNPTECH.dk, KRIS_SCHOFF@HP-Boise-om8.om.hp.com, Kevin_Brayton@wb.xerox.com, Kevin_Bross@ccm.intel.com, Kiyoshi_Katano@cbj.canon.co.jp, ListSaver-of-pmp@vault.findmail.com, Louis_Ormond@cissc.canon.com, Miyasaka.Takashi@exc.epson.co.jp, OWEN@MPA15AB.MV.UNISYS.COM, OYAMADA@jp.ibm.com, Onishi.Joji@exc.epson.co.jp, Ozay_Oktay@cissc.canon.com, PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com, Phil_Verghese@hp.com, RUSSELL_JOHNSTON@HP-Boise-om2.om.hp.com, Randy_Grohs@hp.com, Regis.Brochu@pwc.ca, Rich.Gray@Digital-Controls.Com, Roberto.SANNINO@st.com, Rod.Belshee@tek.COM, Rohlfingdg@agedwards.com, Ronald.Macera@usa.xerox.com, SHARPEG@CLIFFY.POLAROID.COM, SISAACSON@novell.com, STUART@KEI-CA.CCMAIL.CompuServe.COM, Scott_Barnes@es.xerox.com, Shinichi.Nakamura@fujixerox.co.jp, Shuyuan.Chen@crt.xerox.com, Stephen_Wilczek@es.xerox.com, Susumu_Takase@cbj.canon.co.jp, THERESA_RHOADES@HP-Boise-om8.om.hp.com, TLasko@genicom.com, TMCLTD@aol.com, TSUIC@CLIFFY.POLAROID.COM, TTRONSON@novell.com, Thomas_C_Jones@ccm.intel.com, Toshiyuki-AOKI@KDD.co.jp, Troncoso@corp.adaptec.com, Vivian_Cancio@xn.xerox.com, YUKI@KEI-CA.CCMAIL.CompuServe.COM, adamsc@pogo.WV.TEK.COM, adar@vnet.ibm.com, akasaka@tpp.epson.co.jp, akrsaito@ga3.mmlab.toshiba.co.jp, alan_berkema@hp.com, albrahme@byas.com, amiller@kodak.com, anders.olsson@axis.se, ando.makoto@fujixerox.co.jp, andrea@vividimage.com, andrew_barker@es.xerox.com, andyd@pogo.WV.TEK.COM, aoki@mita.co.jp, aoki@rdmg.mgcs.mei.co.jp, armon@wrc.xerox.com, arpalists+computing.ietf-ipp@andrew.cmu.edu, asada@sd.nara.sharp.co.jp, asain@jp.ibm.com, atsnaka@cbs.canon.co.jp, atsushi.yuki@kyocera.com, austin@sdsp.mc.xerox.com, awatanabe@Technoscope.co.jp, b_nixon@emulex.com, babakj@microsoft.com, barry@abcdprint.com, bathatcher@earthlink.net, berche@ocegr.fr, bgalten@rbi.com, bhasting@rbi.com, bill@xcd.com, bis@rose.hp.com, bixhorna@reston.btna.com, bkd@auratek.com, bob@sismicro.com, bob_mross@hp.com, bol@Axp1.IenD.wau.nl, bpathak@popmail1.vcd.hp.com, bpenteco@boi.hp.com, brian@quiotix.com, brian_griebe@hp.com, brianb@vcd.hp.com, briangl@pogo.WV.TEK.COM, broccolo@page.kodak.com, bruewer@uni-hohenheim.de, bsetterb@adobe.com, bstevens@zk3.dec.com, bva@allegrosoft.com, byuan@PRC.Sun.COM, caradec@piano.grenoble.hp.com, carl@manros.com, carney@vnet.ibm.com, carterk@us.ibm.com, catherine.mazier@ocegr.fr, cato@df.lth.se, ccb@pubweb.net, ccvlok@ust.hk, cgordon@digprod.com, chad@lexmark.com, chansler@adobe.com, charles@emerald.oucs.ox.ac.uk, chirag.bakshi@eng.efi.com, chodongi@samsung.co.kr, chrisw@iwl.com, cmanros@cp10.es.xerox.com, colinws@bristol.st.com, cpip@sesun87.cse.canon.co.jp, craigl@usa.net, cullen@sdsp.mc.xerox.com, d_willie@emulex.com, dalmer@bridge.net, danbold@apple.com, daved@gop.sps.mot.com, david_kellerman@nls.com, davidlroach@unn.unisys.com, db_murray@vnet.ibm.com, dbrean@stellar.East.Sun.COM, dcarney@us.ibm.com, dcrocker@brandenburg.com, debecker@lexmark.com, denise@rd.qms.com, devonw@microsoft.com, dgaucas@wrc.xerox.com, digirol@lexmark.com, dker@matrox.com, dker@total.net, dmitchell@ti.com, don@lexmark.com, douchida@vcd.hp.com, dtenbroe@csc.com, dumroese@3a.com, dwing@Cisco.COM, echen@cp10.es.xerox.com, ekelleher@spyglass.com, elenat@bpo.hp.com, emking@lexmark.com, endoh@cse.canon.co.jp, ericr@vcd.hp.com, ewa@apple.com, fhanzel@cp10.es.xerox.com, fhernandez@peerless.com, frank@pharos.co.nz, frankm@extendsys.com, fredrik.hugosson@axis.se, fujisawa@the.canon.co.jp, fujita@yamato.ibm.co.jp, fujitani@isp.rp.ricoh.co.jp, fukunaga@cbs.canon.co.jp, fullman@cp10.es.xerox.com, fumiona@venus.dtinet.or.jp, funazaki@den.fujifilm.co.jp, fw@hplb.hpl.hp.com, fweerdenburg@tulip.com, fzhao@ix.netcom.com, ganta@mutoh.co.jp, gary_padlipsky@cp10.es.xerox.com, gcurtis@ms.com, geoff@paypc.com, ggarbutt@earthlink.net, gleeson@zk3.dec.com, goldey@lexmark.com, gonda@tkb.ysknet.co.jp, grasool@ford.com, greg@erc.epson.com, gregs@sdd.hp.com, gsonger@tsoft.com, gwm@austin.ibm.com, gz@harlequin.com, hak@ocegr.fr, harald.ripa@axis.com, harald.t.alvestrand@uninett.no, harryl@us.ibm.com, hart@zk3.dec.com, hastings@cp10.es.xerox.com, hathaway@pubweb.com, havera@hpb18423.boi.hp.com, havera@hpb27925.boi.hp.com, hclark@lexmark.com, heilbron@nm.informatik.uni-muenchen.de, henrik.holst@i-data.com, herman@ti.com, hi-kohara@KDD.co.jp, hirao@ipdc.sanyo.co.jp, hirata@vip.iwa.fujixerox.co.jp, hiroshi.ishikawa@fujixerox.co.jp, hitoshis@microsoft.com, hparra@novell.com, hsato@cse.canon.co.jp, hshenava@fmi.fujitsu.com, hsidorsky@auco.com, ht@i-data.com, hyperm@hotair.hobl.lucent.com, ietf-archive@ns.cnri.reston.va.us, ietf-ipp@redist.uit.no, iitsuka@avrl.mei.co.jp, ikeda@micom.mec.mei.co.jp, imai@prg.nara.sharp.co.jp, imcdonal@eso.mc.xerox.com, ipp@dazel.com, ipp@xionics.com, isoda@cse.canon.co.jp, isr@ix.netcom.com, iwamoto@comg.ksp.fujixerox.co.jp, jack@netg.ksp.fujixerox.co.jp, james.smith@gte.com, jds@underscore.com, jeremy_powell@sbcss.k12.ca.us, jessica.murphey@mbv.tu-chemnitz.de, jfuller@microsoft.com, jfung@cp10.es.xerox.com, jgw@hprnd.rose.hp.com, jh@harlequin.com, jhollins@eng.adaptec.com, jhy@gsu.edu, jidomir@vcd.hp.com, jim.lo@Eng.Sun.COM, jjv@page.kodak.com, jkm@underscore.com, jldavis@adobe.com, jlinton@lexmark.com, jlo@oce.nl, jmp@dazel.com, joel@mw-inc.com, johan@holhouse.nl, jon_lewis@hp.com, joshco@microsoft.com, jshockey@jrl.com, jtu@oce.nl, jwenn@cp10.es.xerox.com, k_makoto@bsd.canon.co.jp, kadiyala@ti.com, kage@yh.msy.co.jp, kakihara@jp.ibm.com, kakinum@yamato.ibm.co.jp, kamimura@ffc.co.jp, kawasima@rsk-kitami.grp.ricoh.co.jp, kazuaki@sd.nara.sharp.co.jp, kcarter@vnet.ibm.com, keisuket@microsoft.com, keita@nikongw.nikon.co.jp, kenditt@us.ibm.com, kevin.osborn@East.Sun.COM, kevin@sun470.rd.qms.com, kevin_keaney@hp.com, kinji.kanie@brother.co.jp, kita@mol.minolta.co.jp, kjarvis@parc.xerox.com, kjo@ess.mc.xerox.com, komer@trinc.com, kono@hd.epson.co.jp, kpalmer@duplousa.com, krister.svard@skandia.se, kugler@us.ibm.com, kurokawa@prt.sony.co.jp, kusumi@lsi.nsc.co.jp, kyou@cp.cs.fujitsu.co.jp, laurentp@bpo.hp.com, laurie@sdd.hp.com, lawrence@agranat.com, lee_farrell@cissc.canon.com, leisner@sdsp.mc.xerox.com, leong@cp10.es.xerox.com, listsaver-of-fin@findmail.com, listsaver-of-ipp@vault.findmail.com, listsaver-of-jmp@findmail.com, listsaver-of-p1394@findmail.com, listsaver-of-sense@findmail.com, listsaver-of-upd@findmail.com, lpyoung@lexmark.com, lstein@fapo.com, lwang@sdsp.mc.xerox.com, mabry@rd.qms.com, maehara@naltec.co.jp, maezawa@iog.atsugi.fujixerox.co.jp, mamezaki@ffm.fujifilm.co.jp, manchala@cp10.es.xerox.com, marcodg@vcd.hp.com, marina_kalika@es.xerox.com, mario.scurati@st.com, masa-koi@on.rim.or.jp, masegi@cse.canon.co.jp, masinter@parc.xerox.com, matsuki@cse.canon.co.jp, mattj@blip.org, mayer@wrc.xerox.com, mdesai@auco.com, mfenelon@microsoft.com, mhn@cdl.ucop.edu, mhodges@hpb11302.boi.hp.com, mholser@adobe.com, michael@qms.com, michiakn@microsoft.com, middendo@us.ibm.com, mike@fireflyinc.com, mike@lexmark.com, mikee@extendsys.com, mikek@iwl.com, miller@filenet.com, mkumar@trinc.com, mlchen@pdd.att.com, mochi@cns.canon.co.jp, monte_g_johnson@ccm.intel.com, moody@lexmark.com, moore+ipp@cs.utk.edu, moore+printmib@cs.utk.edu, mori@yps.kyocera.co.jp, morita@ic.rdc.ricoh.co.jp, motoyama@str.ricoh.com, mps@mspratt.hpl.hp.com, mwhit@vcd.hp.com, myoung@boi.hp.com, nadler@chopper.us.dg.com, nagahashi.toshinori@exc.epson.co.jp, nagahasi@hdccgw.hd.epson.co.jp, nagy@kodak.com, nankou@avrl.mei.co.jp, nao@cbs.canon.co.jp, naviac@rd.qms.com, ned+ipp@innosoft.com, nemo@dibe.unige.it, nesbitt@cp10.es.xerox.com, nishi@cefiro.iod.ricoh.co.jp, nishi@iod.ricoh.co.jp, nishiwaki@avrl.mei.co.jp, nisikawa@mita.co.jp, nisimura@ipdc.sanyo.co.jp, niteeyes@3Sheep.COM, niwa@iod.ricoh.co.jp, noel@rim.crl.fujixerox.co.jp, noriko.kure@toshiba.co.jp, nschade@xionics.com, nwebb@auco.com, o-tomita@cp.cs.fujitsu.co.jp, ogawa@mos.fvd.fujitsu.co.jp, ogawa@yps.kyocera.co.jp, ogino@fine.ad.jp, ohirata@cbm.canon.com, ohm+ml-ipp@rcac.tdi.co.jp, ohuchi@ess.atsugi.fujixerox.co.jp, oka@pure.cpdc.canon.co.jp, okamoto@cp10.es.xerox.com, okigami@dsap.nara.sharp.co.jp, ootsu@kk1g.kme.mei.co.jp, osaki@lpd.sj.nec.com, otallman@in-system.com, papowell@astart.com, papowell@sdsu.edu, patrick_mckinley@om.cv.hp.com, paul_lei@es.xerox.com, paulmo@microsoft.com, peter.zehler@usa.xerox.com, peter@digideas.com.au, peterm@shinesoft.com, pgloger@cp10.es.xerox.com, phil@netbrand.com, pmp@dazel.com, polansky@raptor.com, pond2@apple.com, pshukla@novell.com, psutton@GGX.COM, pthambid@okidata.com, pwg-ipp@prd.fc.nec.co.jp, pwg-jmp@prd.fc.nec.co.jp, pwg-p1394@prd.fc.nec.co.jp, pwg-pmp@prd.fc.nec.co.jp, pwg-sense@prd.fc.nec.co.jp, pwg-upd@prd.fc.nec.co.jp, qqrob@oce.nl, r18786@email.sps.mot.com, ramnath@rrsycore.co.in, ravi@india.ti.com, ravikm@us.ibm.com, raylutz@cognisys.com, rbergma@dpc.com, rblancha@rbi.com, rchawla@adn.alcatel.com, rdebry@us.ibm.com, rdhondy@qosnet.com, rick@cp10.es.xerox.com, rjm2@cornell.edu, rmccomiskie@xionics.com, robert.bruell@i-data.com, robert.herriot@Eng.Sun.COM, robert_laman@es.xerox.com, robertt@vcd.hp.com, rommel@polgas.topmax.com.ph, ronnie@best.com, rorzol@okidata.com, rpotter@xsoft.xerox.com, rrussell@lexmark.com, rschneid@erc.epson.com, rsherer@peerless.com, rturner@sharplabs.com, s-seshadri1@ti.com, saito@optsys.cl.nec.co.jp, sakamoto@yps.kyocera.co.jp, sal.gurnani@ucop.edu, salm@roch875.mc.xerox.com, samitsu@hj.hro.epson.co.jp, sandram@boi.hp.com, sasaki@cse.canon.co.jp, sasaki@jci.co.jp, sasamori.takahide@fujixerox.co.jp, sathyan@trinc.com, satoshi.ishihara@rdmg.mgcs.mei.co.jp, sbeckst@dpc.com, sbonar@hpb16977.boi.hp.com, sbutler@boi.hp.com, sbutterfield@peerless.com, scott_isaacson@novell.com, scottr@cts.com, sdumas@francenet.fr, sense@dazel.com, sergi@bpo.hp.com, sgray@cp10.es.xerox.com, shimazu@iij.ad.jp, shimura@pure.cpdc.canon.co.jp, shin.ohtake@fujixerox.co.jp, shines@sdd.hp.com, shivaun@al712.rose.hp.com, shuichiro@kaneko.com, shuji@ccs.mt.nec.co.jp, shuyuan@wrc.xerox.com, sjohnson@cp10.es.xerox.com, slw1@cornell.edu, smaruo@hrl.hitachi.co.jp, smg1@vnet.ibm.com, solina_phan@es.xerox.com, srao@trinc.com, stang@adobe.com, stanmcc@cp10.es.xerox.com, starkey@lexmark.com, stephen_holmstead@hp.com, stevet@research.canon.com.au, suehiro@ed.fujitsu.co.jp, sumino@sddc.sps.mot.com, swire@kodak.com, szilles@adobe.com, takami.takeuchi@brother.co.jp, takata@jps.net, takeda@vrl.mei.co.jp, takeshi@netg.ksp.fujixerox.co.jp, taniyan@hd.epson.co.jp, tarl@East.Sun.COM, tatsuya.matsumoto@fujixerox.co.jp, tetsu@spdd.ricoh.co.jp, tgoto@ipdc.sanyo.co.jp, thayashi@mita.co.jp, thrasher@lexmark.com, timb@cv.hp.com, tkj@wipsys.soft.net, tmori@jp.ibm.com, todd_fischer@hp.com, trieu.nguyen@intel.com, tsuna@rd1.ebina.fujixerox.co.jp, ttruong@cp10.es.xerox.com, tuda@cp10.es.xerox.com, tvu@cp10.es.xerox.com, uchino@tpp.epson.co.jp, ueda@iml.mkhar.sharp.co.jp, ueda@pure.cpdc.canon.co.jp, uenaka@vrl.mei.co.jp, vandang@hprnd.rose.hp.com, verhelst@xs4all.nl, victor@kodak.com, vijay.kumar@tek.COM, wakai@slab.tnr.sharp.co.jp, walker@dazel.com, webbj@lexmark.com, wei@tecont1.teco-info.com.tw, william_mccuskey@es.xerox.com, wolff@crc.ricoh.com, ws@seh.de, wwagner@digprod.com, xriley@cp10.es.xerox.com, yamasy@yamato.ibm.co.jp, yaron@writeme.com, yasuaki@webjapan.com, yasushin@microsoft.com, ybanker@GGX.COM, yo-oonaka@KDD.co.jp, yokada@flab.fujitsu.co.jp, yokko@cse.canon.co.jp, yoram@minolta-mil.com, yoshim@erc.epson.com, yue_chen@wb.xerox.com, yuka@fuji.mol.minolta.co.jp, zandee@apple.com, zhi-hong@zeno.com Subject: PWG> The PWG Internet server remains DOWN "Some days you eat bear, and some days the bear eats you..." The PWG Internet server (providing web, mail and ftp services) has seriously died. We are actively working on the problem, but find we're going to have to replace the existing Sun server. As a result, PWG net services will not be available until some time tomorrow, Thursday, June 25. When service has been reestablished, we will send an email message to all persons registered on the pwg-announce mailing list. (Recall that the pwg-announce mailing list is a special, automatic list representing the unique union of all subscribers to any PWG mailing list.) If by chance the problem results in the system being down beyond close of business on Thursday (EDT), then we will also send a message so as to keep everyone informed. We apologize for this inconvenience. The PWG web staff at Underscore From ipp-owner@pwg.org Fri Jun 26 16:33:06 1998 Delivery-Date: Fri, 26 Jun 1998 16:33:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02568 for ; Fri, 26 Jun 1998 16:33:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA26526 for ; Fri, 26 Jun 1998 16:35:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01125 for ; Fri, 26 Jun 1998 16:33:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 26 Jun 1998 16:25:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00563 for ipp-outgoing; Fri, 26 Jun 1998 16:22:59 -0400 (EDT) Date: Thu, 25 Jun 1998 06:32:31 -0700 From: "TR Computing Solutions Inc." Message-Id: <199806251332.GAA01122@web04.bigbiz.com> To: ipp@pwg.org Subject: IPP> e-print Test Suite available from TRCS Sender: owner-ipp@pwg.org This is to announce the free availability of the second beta release of the e-print Test Suite at http://www.trcs.com. The e-print Test Suite is an IPP client that facilitates the testing of printers that implement the Internet Printing Protocol (IPP). The e-print Test Suite is built on the framework of the e-print Engine. The e-print Test Suite provides the IPP server developer essential tools to aid in the development and testing of IPP printers. The capabilities of the e-print Test Suite include: o Full tracing of requests and replies. o Allows reproduction of tests by providing a file interface to store tests. o Allows attributes to be specified that are not part of the IPP standard. o Allows the output of one request to "feed" the input of another request. o Provides the ability to specify "expected" values from a request. o Allows the specification of valid or invalid values to be sent to the IPP server. o Written entirely in Java. For more information or to download a copy of the beta software, please visit our website at http://www.trcs.com or e-mail Rajesh Chawla at rajesh@trcs.com. From ipp-owner@pwg.org Fri Jun 26 17:59:24 1998 Delivery-Date: Fri, 26 Jun 1998 17:59:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA03448 for ; Fri, 26 Jun 1998 17:59:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA26823 for ; Fri, 26 Jun 1998 18:01:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA01925 for ; Fri, 26 Jun 1998 17:59:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 26 Jun 1998 17:55:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01398 for ipp-outgoing; Fri, 26 Jun 1998 17:51:40 -0400 (EDT) From: don@lexmark.com Message-Id: <199806262151.AA06567@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 26 Jun 1998 17:45:46 -0400 Subject: IPP> New Design Goals Document (formerly Requirements) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org I have placed the following documents on the ftp server: The draft in TEXT format: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-980626.txt The draft in PDF format: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-980626.pdf ... and for Tom The diff-ed version compared against the currently published IETF requirements ID: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-980626-diff.pdf The contents of the first 2 are EXACTLY as I expect to submit, only the file name of the txt version would be changed assuming no changes have to be made to the content. Enjoy! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Fri Jun 26 20:00:03 1998 Delivery-Date: Fri, 26 Jun 1998 20:00:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA03857 for ; Fri, 26 Jun 1998 20:00:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA27105 for ; Fri, 26 Jun 1998 20:02:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA03902 for ; Fri, 26 Jun 1998 20:00:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 26 Jun 1998 19:55:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03339 for ipp-outgoing; Fri, 26 Jun 1998 19:54:16 -0400 (EDT) Message-Id: <3.0.5.32.19980626165340.0170e3b0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Jun 1998 16:53:40 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Rev 6 uploaded for PRO and LPD Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipp@pwg.org I have down line loaded the PRO and LPD documents as: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980623-rev-6.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980623-rev-6.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980623-rev-6.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980623-rev-6-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-980623-rev-6.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-980623-rev-6.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/Ipp-lpd-980623-rev-6.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-980623-rev-6-rev.pdf Tom >>>> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 23 Jun 1998 18:28:21 PDT To: Carl-Uno Manros From: Robert Herriot Subject: New Protocol and LPD documents Cc: Tom Hastings I am sending you the 2 revised encoding and lpd documents because the pwg site isn't responding and I won't be able to attend tomorrow's meeting. The documents are all MS Word 6.0 I hope that you can produce the pdf versions and download them. Bob Herriot <<<<<<<< From ipp-owner@pwg.org Fri Jun 26 20:25:56 1998 Delivery-Date: Fri, 26 Jun 1998 20:25:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04001 for ; Fri, 26 Jun 1998 20:25:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA27142 for ; Fri, 26 Jun 1998 20:28:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA05236 for ; Fri, 26 Jun 1998 20:26:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 26 Jun 1998 20:21:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA04012 for ipp-outgoing; Fri, 26 Jun 1998 20:11:55 -0400 (EDT) Message-Id: <3.0.5.32.19980626171124.00cf7920@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Jun 1998 17:11:24 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Results of IANA review of IANA Considerations section Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I had sent to Jon Sections 6 and 12 that Scott posted on Tuesday (version 10) of the Model document. We have completed the review by IANA of the IANA Considerations as requested by Keith. Tom >X-Sender: hastings@garfield >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Fri, 26 Jun 1998 13:42:01 -0700 >To: Jon Postel >From: Tom Hastings >Subject: Re: Minor questions on the IPP IANA Considerations and > registration >Cc: Keith Moore , cmanros, hastings > >Jon, > >Thanks for your replies to my questions and your review of the revised >IPP Model and Semantics specifications: > > revised Section 6 "IANA Considerations (registered and private extensions)" > new Section 12 "Formats for IPP Registration Proposals" > >that you requested to be added. > >The WG was pleased with your review and comments. We have added the >single sentence as you suggested to the beginning of Section 12: > > In order to propose an IPP extension for registration, the proposer must > submit an application to IANA by email to iana@iana.org" or by filling out > the appropriate form on the IANA web pages (http://www.iana.org). > >I believe that together we have completed Keith Moore's request that IANA >review Section 6. > >The WG also appreciates the flexibility that you offerred in stream-lining >the procedures for publishing approved registrations with IANA. > >Thanks, >Tom Hastings >for the IPP WG > > > >At 21:45 6/23/98 PDT, Jon Postel wrote: >> >>Tom: >> >>Sorry for the delay, and i do appreciate your persistance. Sorry i >>couldn't take your call today (i was on the line with a government >>minister in Australia). Also, i was sick on Sunday and have been >>operating a about 1/2 effectiveness this week. Enough of my troubles. >> >>I've now reviewed your proposed sections 6 and 12 and they look very >>good. >> >>Some points you asked about: >> >> 1. The email address "iana@iana.org" -- yes, that is the >> correct address to use. >> >> 2. A form filling way to make applications -- yes, we can set >> that up with your help and advice. >> >> 3. Applications by either email or web forms -- yes, we can >> accept either, no need to limit it to one or the other. >> >> 4. Mentioning the forms method in the specification -- hmm, i >> guess that should be mentioned in the new section 12. The new >> section 12 probably need a bit more of an introduction, saying >> explicity that an application should be submitted to the IANA >> by email to "iana@iana.org" or by filling out a form on the >> IANA web pages, even if that is a bit redundant with section 6. > >So we've added the following to the beginning of Section 12: > > In order to propose an IPP extension for registration, the proposer must > submit an application to IANA by email to iana@iana.org" or by filling out > the appropriate form on the IANA web pages (http://www.iana.org). > >> >> 5. Additional questions or prompting with the forms -- hmm, >> i've got mixed feelings about this. We have a lot of cases of >> clueless newbys filling in forms for they know not what just >> because it was there. Many of these we catch because of >> inconsistencies in the information or the kind of answer given >> for a question just doesn't make sense. If we give a lot of >> help it may be hard to spot this kind of mis-application. On >> the other have we do want to make it easy for the intended >> users to get their registrations. If you think it is a good >> idea we can work together to provide it. > >I'll ask the WG. It may be simpler to make the submitter copy the >format of the appropriate section from the Model document providing >the same kind of information. Only after experience, if we get some >incompleted proposals, might we need to add more questions to the >IANA registration submission UI for IPP. Lets wait and see. > >> >> 6. The distinction between the PWG and the IPP WG was not as >> clear to me before as it is now. I think we can have a pretty >> flexible arrangement so that reguests for assignments >> originating in the PWG can be handled with a minimum of fuss. >> Suppose the PWG maintained on it's server a copy of the >> ...iana/assignments/ipp/... directory and file structure. And >> suppose that when a PWG member wanted an assignment, through >> some process (unknown to the IANA) the result was that a message >> from the designated expert arrived in the IANA mailbox >> containing an exactly correct application preapproved by the >> designated expert with the comment that all IANA had to do was >> copy such and such files from the pwg.org machine to the >> iana.org machine to complete the assignment. The IANA would >> consider this very helpful. [By the way, loading the URL >> http://www.pwg.org/ just failed.] > >Speaking for our WG and the PWG this flexibility looks good for us >and will make it easier on IANA as well. Thank you. > >The PWG server has been down since Tuesday. However, it has been >remarkedly available during the past four years. > >> >> 7. I still think it makes sense for IANA to hold the registry >> in principle, though as i just said above we can be very >> flexible in the practice. The main reason in favor of the IANA >> involvement is the long term survial. The IANA is now the key >> contact for so many different kinds of parameters, codes, >> types, and so on that it can't be allowed to fail. Even if the >> current people for some reason were unable to continue, the >> IANA as a service would have to be reinstantiated. > >Sounds right to me too. > >> >> 8. The future of the IANA -- The IANA as an organization is a >> bit tied up in the ongoing discussion of how to evolve domain >> names. I think the organization part (not the the domain >> names) can be resolved in a couple of months and that a new >> not-for-profit corporation can be in place to provide the >> current service before the existing funding arrangements run >> out. I don't think that funding the new organization will be a >> major problem but there is some work to be done to make the >> arrangements. >> >>I hope this covers the questions you've got. If not give me a call on >>wednesday morning. > >Yes, you've answered the questions and provided the review. >Thanks again, > >Tom Hastings >> >>--jon. >> >> >> > > From ipp-owner@pwg.org Fri Jun 26 23:54:57 1998 Delivery-Date: Fri, 26 Jun 1998 23:55:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11619 for ; Fri, 26 Jun 1998 23:54:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA27532 for ; Fri, 26 Jun 1998 23:57:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA08108 for ; Fri, 26 Jun 1998 23:54:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 26 Jun 1998 23:50:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07583 for ipp-outgoing; Fri, 26 Jun 1998 23:47:09 -0400 (EDT) Message-Id: <1.5.4.32.19980627034116.0075f0ec@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: Fri, 26 Jun 1998 20:41:16 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Back to business Sender: owner-ipp@pwg.org All, Thanks to heroic, behind the scene efforts from the Underscore staff, the PWG server and services are now fully restored. Thanks to Jay and the other Underscorers! For those of you that did not dial in to our phone conference last Wednesday, I want to inform you that we went over all the edits that had been made to the IPP drafts (all apart from the Requirements document, which had only minor editorial changes anyway). The action plan is now to have all the revised drafts ready by early next week, so that we can send back a complete package to the ADs and the IESG in time for Memorial Day with our WG feedback and recommendation to go ahead with the publishing of the documents. I will send the whole package to the IETF secretariat after a final check-up and prepare a more formal reply to Keith Moore on his comments and how the WG has resolved them. This is an important mile stone. Hopefully we will not run into any further snags. I want to take the opportunity to thank the editors and all other contributors for your efforts and willingness to accept some compromises, after which we now seem to have complete consensus for the drafts that will come out next week. This also means that we can now spend our time on other important subjects in the PWG IPP meeting in Monterey to discuss subjects such as inter-operability testing, notifications, MIB access, and other IPP extensions. Carl-Uno From ipp-owner@pwg.org Mon Jun 29 09:36:35 1998 Delivery-Date: Mon, 29 Jun 1998 09:36:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA11900 for ; Mon, 29 Jun 1998 09:36:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA03781 for ; Mon, 29 Jun 1998 09:38:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA24504 for ; Mon, 29 Jun 1998 09:36:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 09:26:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA23926 for ipp-outgoing; Mon, 29 Jun 1998 09:24:03 -0400 (EDT) From: Roger K Debry To: Cc: Subject: IPP> IPP Rationale Document Message-ID: <5030100022433904000002L042*@MHS> Date: Mon, 29 Jun 1998 09:22:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA11900 The updated rationale document is now available at ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-ietf-ipp-rat-03.1.txt This version has been updated with Carl-Uno's common abstract and references. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Mon Jun 29 12:25:27 1998 Delivery-Date: Mon, 29 Jun 1998 12:25:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA16704 for ; Mon, 29 Jun 1998 12:25:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04967 for ; Mon, 29 Jun 1998 12:27:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26647 for ; Mon, 29 Jun 1998 12:25:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 12:21:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26102 for ipp-outgoing; Mon, 29 Jun 1998 12:18:47 -0400 (EDT) Message-Id: <3.0.5.32.19980629091822.00fcac50@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 09:18:22 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - You want to see your name in print? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, As the editors are making their final, final touches to the drafts, I wanted to check if there are people out there who have contributed to the documents, but have not yet had their name included in the list of contributors. Please send me a reply back at once if you want your name added (the Model & Semantics and the Encodong & Transfer documents are the important ones). Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 13:25:35 1998 Delivery-Date: Mon, 29 Jun 1998 13:25:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19145 for ; Mon, 29 Jun 1998 13:25:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA05286 for ; Mon, 29 Jun 1998 13:27:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27462 for ; Mon, 29 Jun 1998 13:25:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 13:21:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26891 for ipp-outgoing; Mon, 29 Jun 1998 13:15:43 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> upload instructions Date: Mon, 29 Jun 1998 10:15:31 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Where am I supposed to place an upload document (Details of new MS operations) From ipp-owner@pwg.org Mon Jun 29 13:56:15 1998 Delivery-Date: Mon, 29 Jun 1998 13:56:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20211 for ; Mon, 29 Jun 1998 13:56:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA05506 for ; Mon, 29 Jun 1998 13:58:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28174 for ; Mon, 29 Jun 1998 13:56:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 13:51:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27613 for ipp-outgoing; Mon, 29 Jun 1998 13:49:58 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> MS-new-operations.htm uploaded Date: Mon, 29 Jun 1998 10:49:50 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ Describes 7 new operations that MS may be using for IPP1.0 We should discuss whther we want to make any of these standard extensions From ipp-owner@pwg.org Mon Jun 29 14:51:54 1998 Delivery-Date: Mon, 29 Jun 1998 14:51:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22379 for ; Mon, 29 Jun 1998 14:51:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA06069 for ; Mon, 29 Jun 1998 14:54:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29032 for ; Mon, 29 Jun 1998 14:51:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 14:46:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA28460 for ipp-outgoing; Mon, 29 Jun 1998 14:43:54 -0400 (EDT) Message-Id: <3.0.5.32.19980629114334.01086660@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 11:43:34 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MS-new-operations.htm uploaded In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 10:49 AM 6/29/98 PDT, Paul Moore wrote: >to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >Describes 7 new operations that MS may be using for IPP1.0 > >We should discuss whther we want to make any of these standard extensions > > The complete path name for this HTML document is: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 15:11:57 1998 Delivery-Date: Mon, 29 Jun 1998 15:11:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23138 for ; Mon, 29 Jun 1998 15:11:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA06165 for ; Mon, 29 Jun 1998 15:14:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29744 for ; Mon, 29 Jun 1998 15:11:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 15:06:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29171 for ipp-outgoing; Mon, 29 Jun 1998 15:02:31 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> MS-new-operations.htm uploaded Message-ID: <5030100022451611000002L012*@MHS> Date: Mon, 29 Jun 1998 15:01:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23138 The list of new operations proposed by MS looks good, but shoudd be discussed as part of the next version, NOT v1.0! Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 06/29/98 12:47:54 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: Re: IPP> MS-new-operations.htm uploaded At 10:49 AM 6/29/98 PDT, Paul Moore wrote: >to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >Describes 7 new operations that MS may be using for IPP1.0 > >We should discuss whther we want to make any of these standard extensions > > The complete path name for this HTML document is: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 15:25:18 1998 Delivery-Date: Mon, 29 Jun 1998 15:25:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23466 for ; Mon, 29 Jun 1998 15:25:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA06234 for ; Mon, 29 Jun 1998 15:27:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00427 for ; Mon, 29 Jun 1998 15:25:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 15:21:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29830 for ipp-outgoing; Mon, 29 Jun 1998 15:15:51 -0400 (EDT) From: don@lexmark.com Message-Id: <199806291915.AA02718@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Roger K Debry Cc: ipp@pwg.org Date: Mon, 29 Jun 1998 15:09:54 -0400 Subject: Re: IPP> MS-new-operations.htm uploaded Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org I assumed that's what Paul meant. These are the enhancements that MS is making to their first shipping implementation of IPP. These are therefore enhancements _TO_ IPP V/1.0 that we should discuss including _IN_ a future version of the IPP standard. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Roger K Debry on 06/29/98 03:01:20 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> MS-new-operations.htm uploaded The list of new operations proposed by MS looks good, but shoudd be discussed as part of the next version, NOT v1.0! Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 06/29/98 12:47:54 PM Please respond to owner-ipp@pwg.org To: ipp@pwg.org cc: Subject: Re: IPP> MS-new-operations.htm uploaded At 10:49 AM 6/29/98 PDT, Paul Moore wrote: >to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >Describes 7 new operations that MS may be using for IPP1.0 > >We should discuss whther we want to make any of these standard extensions > > The complete path name for this HTML document is: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 16:30:30 1998 Delivery-Date: Mon, 29 Jun 1998 16:30:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24987 for ; Mon, 29 Jun 1998 16:30:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06708 for ; Mon, 29 Jun 1998 16:32:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01892 for ; Mon, 29 Jun 1998 16:12:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 16:07:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00705 for ipp-outgoing; Mon, 29 Jun 1998 16:02:48 -0400 (EDT) From: don@lexmark.com Message-Id: <199806292002.AA05508@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 29 Jun 1998 15:57:08 -0400 Subject: IPP> New Design Goals Document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org I have placed the following documents on the ftp server: The draft in TEXT format: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-980630.txt The draft in PDF format: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-980630.pdf The contents of the first 2 are EXACTLY as I expect to submit, only the file names would need to be changed for submission to the IETF. Enjoy! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Jun 29 16:40:23 1998 Delivery-Date: Mon, 29 Jun 1998 16:40:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25166 for ; Mon, 29 Jun 1998 16:40:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06783 for ; Mon, 29 Jun 1998 16:42:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01473 for ; Mon, 29 Jun 1998 16:09:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 16:03:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00632 for ipp-outgoing; Mon, 29 Jun 1998 15:55:11 -0400 (EDT) Message-Id: <3.0.5.32.19980629123700.0109f8a0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 12:37:00 PDT To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP> MS-new-operations.htm uploaded In-Reply-To: <5030100022451611000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Roger, I do not think it was Paul's intension to try to get these into the current IPP V1.0 documents, but rather to be considered as candidates for later inclusion using the extension mechanisms defined in the IPP V1.0 documents. Carl-Uno At 12:01 PM 6/29/98 PDT, Roger K Debry wrote: >The list of new operations proposed by MS looks good, but shoudd be discussed >as part of the next version, NOT v1.0! > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > > >owner-ipp@pwg.org on 06/29/98 12:47:54 PM >Please respond to owner-ipp@pwg.org >To: ipp@pwg.org >cc: >Subject: Re: IPP> MS-new-operations.htm uploaded > > >At 10:49 AM 6/29/98 PDT, Paul Moore wrote: >>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>Describes 7 new operations that MS may be using for IPP1.0 >> >>We should discuss whther we want to make any of these standard extensions >> >> > >The complete path name for this HTML document is: > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm > >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 > > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 16:55:33 1998 Delivery-Date: Mon, 29 Jun 1998 16:55:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25520 for ; Mon, 29 Jun 1998 16:55:33 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06898 for ; Mon, 29 Jun 1998 16:57:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA03273 for ; Mon, 29 Jun 1998 16:55:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 16:51:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02568 for ipp-outgoing; Mon, 29 Jun 1998 16:48:41 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl-Uno Manros'" , Roger K Debry , ipp@pwg.org Subject: RE: IPP> MS-new-operations.htm uploaded Date: Mon, 29 Jun 1998 13:48:12 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Paul's intentions are:- 1. To let the industry know that we are almost certainly going to use these commands 2. To get people's comments on them. 3. We have an extensibility mechanism (are operations a type 2 enum?) proposed in IPP1. Lets see if it works. Also if new oepration codes get assigned I'd like to us them. 4. Not to hold up V1 - Its finished are far as I'm concerned > -----Original Message----- > From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com] > Sent: Monday, June 29, 1998 12:37 PM > To: Roger K Debry; ipp@pwg.org > Subject: Re: IPP> MS-new-operations.htm uploaded > > Roger, > > I do not think it was Paul's intension to try to get these into the > current > IPP V1.0 documents, but rather to be considered as candidates for > later inclusion using the extension mechanisms defined in the IPP V1.0 > documents. > > Carl-Uno > > At 12:01 PM 6/29/98 PDT, Roger K Debry wrote: > >The list of new operations proposed by MS looks good, but shoudd be > discussed > >as part of the next version, NOT v1.0! > > > >Roger K deBry > >Senior Technical Staff Member > >Architecture and Technology > >IBM Printing Systems > >email: rdebry@us.ibm.com > >phone: 1-303-924-4080 > > > > > > > >owner-ipp@pwg.org on 06/29/98 12:47:54 PM > >Please respond to owner-ipp@pwg.org > >To: ipp@pwg.org > >cc: > >Subject: Re: IPP> MS-new-operations.htm uploaded > > > > > >At 10:49 AM 6/29/98 PDT, Paul Moore wrote: > >>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ > >>Describes 7 new operations that MS may be using for IPP1.0 > >> > >>We should discuss whther we want to make any of these standard > extensions > >> > >> > > > >The complete path name for this HTML document is: > > > > ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm > > > >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 > > > > > > > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 17:30:53 1998 Delivery-Date: Mon, 29 Jun 1998 17:30:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26269 for ; Mon, 29 Jun 1998 17:30:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA07092 for ; Mon, 29 Jun 1998 17:33:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03967 for ; Mon, 29 Jun 1998 17:30:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 17:26:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03414 for ipp-outgoing; Mon, 29 Jun 1998 17:23:34 -0400 (EDT) Message-Id: <3.0.5.32.19980629142320.00d0f8b0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 14:23:20 PDT To: Carl-Uno Manros From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded Cc: Roger K Debry , In-Reply-To: <3.0.5.32.19980629123700.0109f8a0@garfield> References: <5030100022451611000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org On the last IPP telecon, we discussed that we could register the new operations for use with IPP/1.0, rather than waiting to do a version 2.0, (or version 1.1) with all its inherent process overhead and delay. On the telecon, I believe we agreed to review these new operations as registration proposals at the Monterey meeting in July. It was expressed that this would also test our registration procedures. These operations appear to be simple operations, compared to the ones that we have specified in the current Model specification, so that in my opinion, they are suitable for registration. That is that advantage of having an extensible standard. These operations all seem to be very similar to DPA operations (some from DPA Part 1 and some from DPA Part 3), so that a number of companies already have extensive experience with implementing them. Tom At 12:37 6/29/98 PDT, Carl-Uno Manros wrote: >Roger, > >I do not think it was Paul's intention to try to get these into the current >IPP V1.0 documents, but rather to be considered as candidates for >later inclusion using the extension mechanisms defined in the IPP V1.0 >documents. > >Carl-Uno > >At 12:01 PM 6/29/98 PDT, Roger K Debry wrote: >>The list of new operations proposed by MS looks good, but shoudd be discussed >>as part of the next version, NOT v1.0! >> >>Roger K deBry >>Senior Technical Staff Member >>Architecture and Technology >>IBM Printing Systems >>email: rdebry@us.ibm.com >>phone: 1-303-924-4080 >> >> >> >>owner-ipp@pwg.org on 06/29/98 12:47:54 PM >>Please respond to owner-ipp@pwg.org >>To: ipp@pwg.org >>cc: >>Subject: Re: IPP> MS-new-operations.htm uploaded >> >> >>At 10:49 AM 6/29/98 PDT, Paul Moore wrote: >>>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>>Describes 7 new operations that MS may be using for IPP1.0 >>> >>>We should discuss whther we want to make any of these standard extensions >>> >>> >> >>The complete path name for this HTML document is: >> >> ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/MS-new-operations.htm >> >>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 >> >> >> >> >> >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Mon Jun 29 19:01:36 1998 Delivery-Date: Mon, 29 Jun 1998 19:01:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27463 for ; Mon, 29 Jun 1998 19:01:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA07472 for ; Mon, 29 Jun 1998 19:03:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05552 for ; Mon, 29 Jun 1998 19:01:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 18:56:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05006 for ipp-outgoing; Mon, 29 Jun 1998 18:53:55 -0400 (EDT) Message-Id: <3.0.5.32.19980629155323.010e9bd0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 15:53:23 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> 42nd IETF-CHICAGO, IL: MEETING ANNOUNCEMENT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org If you plan to attend the next IETF meeting, here is the information about location etc. In the upcoming PWG IPP meeting, we will need to discuss the agenda for the IPP WG in that meeting. Carl-Uno >To: IETF-Announce:; >Subject: 42nd IETF-CHICAGO, IL: MEETING ANNOUNCEMENT >Date: Mon, 29 Jun 1998 11:28:14 PDT >From: Marcia Beaulieu > >Registration for the 42nd IETF Meeting is now being accepted. Detailed >information will follow in a separate message. > >General meeting information is included below. Information can also >be obtained from the following places: > >IETF home page at: > http://www.ietf.org/meetings/meetings.html > >FTP sites: > US East Coast: ftp.ietf.org > US West Coast: ftp.isi.edu > Africa: ftp.is.co.za > Europe: ftp.nordu.net > ftp.nis.garr.it > Pacific Rim: munnari.oz.au > >cd ietf >ls 0mtg* >============================================== >42nd INTERNET ENGINEERING TASK FORCE >AT-A-GLANCE > >DATES: August 24-28, 1998 > >HOST: Motorola > >HOTEL/MEETING SITE: > Sheraton Chicago > 301 East North Water Street > Chicago, IL, USA 60611 > Phone: 800-233-4100 > 312-329-7000 > Fax: 312-329-6929 > Check-In: 1500; Check-Out: 1200 > Rooms reserved until Monday, July 27, 1998. > Single: US $152.00* > Double: US $152.00* > *These rates do not include sales tax on guest rooms which > is currently 14.9%. This is subject to change without notice. > Specify: IETF Group > >NEWCOMER'S Sunday, August 23 >ORIENTATION: 1530-1630 > Location: Sheraton 2 > >RECEPTION: Sunday, August 23 > 1700-1900 > Location: Chicago 6 & 7 > >REGISTRATION: Location: Ballroom Registration West > Time: Sunday, August 23 > 1200-1900 Pre-paid Packet Pick-up > 1500-1900 Pre-registered and On-site > Monday, August 24 > 0700-2000 > Tuesday, August 25 - Thursday, August 27 > 0800-1800 > Friday, August 28 > 0800-1000 > >TERMINAL ROOM: Location: Sheraton 3 > >REGISTRATION FEE: > The resgistration fee is US$325.00 if received by the cut-off date > of 1700 ET on 14 August 1998. After this date, a fee of US$425.00 > must be paid on-site, whether or not you have pre-registered. > Full-time students with proper ID will receive a US$100 off their > registration fee. Failure to provide proper ID on site will revoke > the $100 credit. > > PAYMENT BY: Credit Card, Check or Cash (US Dollars) > > CD-ROM (US$10) and Hard Copy (US$65) versions of the meeting Proceedings > will be available approximately 8-10 weeks following the meeting. If > you would like to receive either or both, check YES in the respective > boxes on the registration form. The appropriate amount will be added to > the total amount due. > >AIRLINES: > United Airlines will provide to attendees of the IETF round trip > transportation to Chicago, IL on United, Shuttle by United or United > Express scheduled service in the United States, Canada and Puerto Rico > at fares of a 5% discount off any United, Shuttle by United or United > Express published fare, including First Class, in effect when the tickets > are purchased subject to all applicable restrictions. > > Reservations, schedule and ticketing information may be obtained by > calling the Meeting Plus Reservation Center at 1-800-521-4041 (U.S. and > Canada) and referring to the Meeting Plus ID code 570PX. The Meeting Plus > Reservation Center hours are Monday thru Sunday 7:00am to 12:00 Midnight ET. > Your travel agency may also obtain this discount by calling United. > >Last updated: June 29, 1998 > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jun 29 20:00:21 1998 Delivery-Date: Mon, 29 Jun 1998 20:00:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA27773 for ; Mon, 29 Jun 1998 20:00:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA07639 for ; Mon, 29 Jun 1998 20:02:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06178 for ; Mon, 29 Jun 1998 20:00:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 29 Jun 1998 19:56:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05665 for ipp-outgoing; Mon, 29 Jun 1998 19:51:00 -0400 (EDT) Message-Id: <3.0.5.32.19980629165028.009d38d0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jun 1998 16:50:28 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - No PWG IPP Phone Confeence this week Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, Looking at the work at hand and the fact that many of us will met next week anyway, I decided to not to hold a phone conference this week. Instead, I will spend the time with editors to get our drafts completed, as wel as getting our agenda for next week's meeting sorted out. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From adm Tue Jun 30 10:27:09 1998 Delivery-Date: Tue, 30 Jun 1998 10:46:13 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA15304 for ietf-123-outbound.10@ietf.org; Tue, 30 Jun 1998 10:25:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA14168; Tue, 30 Jun 1998 09:37:06 -0400 (EDT) Message-Id: <199806301337.JAA14168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-delay-03.txt Date: Tue, 30 Jun 1998 09:37:05 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-way Delay Metric for IPPM Author(s) : G. Almes, S. Kalidindi, M. Zekauskas Filename : draft-ietf-ippm-delay-03.txt Pages : 15 Date : 29-Jun-98 This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2223 [1]; the reader is assumed to be familiar with that document. This memo is intended to be parallel in structure to a companion document for Packet Loss ('A Packet Loss Metric for IPPM' ) [2]. The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-One-way-Delay, will be introduced to measure a single observation of one-way delay. + Using this singleton metric, a 'sample', called Type-P-One-way- Delay-Poisson-Stream, will be introduced to measure a sequence of singleton delays measured at times taken from a Poisson process. + Using this sample, several 'statistics' of the sample will be defined and discussed. This progression from singleton to sample to statistics, with clear separation among them, is important. Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, 'term*' indicates that 'term' is defined in the Framework. 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-ippm-delay-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-delay-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-delay-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980629171816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-delay-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-delay-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980629171816.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jun 30 10:37:01 1998 Delivery-Date: Tue, 30 Jun 1998 10:55:56 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA15550 for ietf-123-outbound.10@ietf.org; Tue, 30 Jun 1998 10:35:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA14186; Tue, 30 Jun 1998 09:37:12 -0400 (EDT) Message-Id: <199806301337.JAA14186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ADVANCED.ORG From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-loss-03.txt Date: Tue, 30 Jun 1998 09:37:12 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Packet Loss Metric for IPPM Author(s) : G. Almes, S. Kalidindi, M. Zekauskas Filename : draft-ietf-ippm-loss-03.txt Pages : 12 Date : 29-Jun-98 This memo defines a metric for packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]; the reader is assumed to be familiar with that document. This memo is intended to be parallel in structure to a companion document for One-way Delay (currently 'A One-way Delay Metric for IPPM' ) [2]; the reader is assumed to be familiar with that document. The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-One-way-Loss, is introduced to measure a single observation of packet transmission or loss. + Using this singleton metric, a 'sample', called Type-P-One-way- Loss-Poisson-Stream, is introduced to measure a sequence of singleton transmissions and/or losses measured at times taken from a Poisson process. + Using this sample, several 'statistics' of the sample are defined and discussed. This progression from singleton to sample to statistics, with clear separation among them, is important. Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, 'term*' indicates that 'term' is defined in the Framework. 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-ippm-loss-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-loss-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-loss-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980629172141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-loss-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-loss-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980629172141.I-D@ietf.org> --OtherAccess-- --NextPart-- From pmp-owner@pwg.org Tue Jun 30 16:57:42 1998 Delivery-Date: Tue, 30 Jun 1998 16:57:42 -0400 Return-Path: pmp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22415 for ; Tue, 30 Jun 1998 16:57:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12479 for ; Tue, 30 Jun 1998 17:00:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA21695 for ; Tue, 30 Jun 1998 16:57:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 30 Jun 1998 16:55:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21341 for pmp-outgoing; Tue, 30 Jun 1998 16:52:37 -0400 (EDT) Message-Id: <3.0.5.32.19980630130244.00aaea70@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Jun 1998 13:02:44 PDT To: ipp@pwg.org From: Tom Hastings Subject: PMP> MIB - Updated IPP MIB Access specification posted Cc: pmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: pmp-owner@pwg.org I've posted the updated "IPP Device Object and MIB Access" specification, V0.4. ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-summary-980620.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-summary-980620.pdf I created a new directory: new_MIB, rather than clutter up new_MOD (and am using the MIB prefix in the IPP mail messages too). The ipp-mib-access-980620.* is about 27 pages. So I created a 9-page summary, like we did for notification. The former is intended to be a PWG standard and an IETF standards track extension to IPP/1.0. The latter is (and would remain) just a PWG White Paper. I have incorporated the agreements reached in Washington: 1. Add the "mib-arc-m.n. ..." group attribute name to get sub-trees. 2. Finish the Appendix which provides all of the IPP attribute names that correspond to accessible Printer MIB objects, include the Draft Printer MIB. (I did not include any Finisher MIB attribute names or table numbers, since it is only an Internet-Draft). 3. I've added sections to make this a proper Internet-Draft: Conformance Security Considerations IANA Considerations Updated the references, etc. We should see if at Monteray, we have "rough consensus" to sent it for Last Call and Final Approval as a PWG Proposed Standard and forward it as the first Internet-Draft. (Or should we forward it as the first Internet-Draft during Last Call, and then make the PWG Proposed standard (after Last Call) a second Internet-Draft, so that we can get any comments from outside during PWG Last Call). I've copied this to the PMP list, since it has a direct bearing on the Printer MIB. The appendix has IPP attribute names for every accessible Printer MIB object, including an IPP attribute syntax and a range for integers and text strings. *********************************************************** * Printer MIB experts: Please check the Appendix carfully * *********************************************************** There are also several issues listed from the Appendix mapping all related to the Printer MIB use of special negative integer values to mean other(-1), no-value(-1), unknown(-2), and room-for-more(-3) vs. IPP out-of-band values? I've extracted them here: 1. Use -1 vs 'no-value'? prtInputDefaultIndex Integer32, "prt-att-5-6" (integer(-1:MAX)) ISSUE 1: -1 means no default index specified (configured?) Should IPP change the range to (1:MAX) and use the out-of-band value 'no-value' to represent the -1 value in the MIB? prtOutputDefaultIndex Integer32, "prt-att-5-7" (integer(-1:MAX)) ISSUE 1a: Same as ISSUE 1. 2. Use -1 vs a new 'other' and -2 vs 'unknown'? prtInputMediaDimFeedDirDeclared Integer32, prt-att-8-4-r (integer(-2:MAX)) ISSUE 2: Should we change the lower limit to 0 and use out-of-bound values: 'unknown' for -2 and a new 'other' out-of-band keyword for -1? prtInputMediaDimXFeedDirDeclared Integer32, prt-att-8-5-r (integer(-2:MAX)) ISSUE 2a: Same as ISSUE 2? (repeated on about 26 more objects). 3. Use -3 vs a new 'room-for-more' ? prtOutputRemainingCapacity Integer32, prt-att-9-5-r (integer(-3:MAX) ISSUE 2k: Same as ISSUE 2 (but still need -3 for the room for one more value)? ISSUE 3: Or do we want to add (register for use with IPP) an additional 'room-for-more' out-of-band attribute value so that this range could also be changed to integer(0:MAX)? Send any comments to the IPP and PMP mailing lists and we will discuss at Monterey. Thanks, Tom -rw-r--r-- 1 pwg pwg 143872 Jun 30 19:29 ipp-mib-access-980620.doc -rw-r--r-- 1 pwg pwg 66708 Jun 30 19:29 ipp-mib-access-980620.pdf -rw-r--r-- 1 pwg pwg 176640 Jun 30 19:30 ipp-mib-access-980620-rev.doc -rw-r--r-- 1 pwg pwg 94055 Jun 30 19:30 ipp-mib-access-980620-rev.pdf -rw-r--r-- 1 pwg pwg 72192 Jun 30 19:31 ipp-mib-access-summary-980620.doc -rw-r--r-- 1 pwg pwg 25420 Jun 30 19:31 ipp-mib-access-summary-980620.pdf From ipp-owner@pwg.org Tue Jun 30 17:02:31 1998 Delivery-Date: Tue, 30 Jun 1998 17:02:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22471 for ; Tue, 30 Jun 1998 17:02:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12495 for ; Tue, 30 Jun 1998 17:04:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22254 for ; Tue, 30 Jun 1998 17:02:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 30 Jun 1998 16:57:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21334 for ipp-outgoing; Tue, 30 Jun 1998 16:52:33 -0400 (EDT) Message-Id: <3.0.5.32.19980630130244.00aaea70@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Jun 1998 13:02:44 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MIB - Updated IPP MIB Access specification posted Cc: pmp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I've posted the updated "IPP Device Object and MIB Access" specification, V0.4. ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-980620-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-summary-980620.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MIB/ipp-mib-access-summary-980620.pdf I created a new directory: new_MIB, rather than clutter up new_MOD (and am using the MIB prefix in the IPP mail messages too). The ipp-mib-access-980620.* is about 27 pages. So I created a 9-page summary, like we did for notification. The former is intended to be a PWG standard and an IETF standards track extension to IPP/1.0. The latter is (and would remain) just a PWG White Paper. I have incorporated the agreements reached in Washington: 1. Add the "mib-arc-m.n. ..." group attribute name to get sub-trees. 2. Finish the Appendix which provides all of the IPP attribute names that correspond to accessible Printer MIB objects, include the Draft Printer MIB. (I did not include any Finisher MIB attribute names or table numbers, since it is only an Internet-Draft). 3. I've added sections to make this a proper Internet-Draft: Conformance Security Considerations IANA Considerations Updated the references, etc. We should see if at Monteray, we have "rough consensus" to sent it for Last Call and Final Approval as a PWG Proposed Standard and forward it as the first Internet-Draft. (Or should we forward it as the first Internet-Draft during Last Call, and then make the PWG Proposed standard (after Last Call) a second Internet-Draft, so that we can get any comments from outside during PWG Last Call). I've copied this to the PMP list, since it has a direct bearing on the Printer MIB. The appendix has IPP attribute names for every accessible Printer MIB object, including an IPP attribute syntax and a range for integers and text strings. *********************************************************** * Printer MIB experts: Please check the Appendix carfully * *********************************************************** There are also several issues listed from the Appendix mapping all related to the Printer MIB use of special negative integer values to mean other(-1), no-value(-1), unknown(-2), and room-for-more(-3) vs. IPP out-of-band values? I've extracted them here: 1. Use -1 vs 'no-value'? prtInputDefaultIndex Integer32, "prt-att-5-6" (integer(-1:MAX)) ISSUE 1: -1 means no default index specified (configured?) Should IPP change the range to (1:MAX) and use the out-of-band value 'no-value' to represent the -1 value in the MIB? prtOutputDefaultIndex Integer32, "prt-att-5-7" (integer(-1:MAX)) ISSUE 1a: Same as ISSUE 1. 2. Use -1 vs a new 'other' and -2 vs 'unknown'? prtInputMediaDimFeedDirDeclared Integer32, prt-att-8-4-r (integer(-2:MAX)) ISSUE 2: Should we change the lower limit to 0 and use out-of-bound values: 'unknown' for -2 and a new 'other' out-of-band keyword for -1? prtInputMediaDimXFeedDirDeclared Integer32, prt-att-8-5-r (integer(-2:MAX)) ISSUE 2a: Same as ISSUE 2? (repeated on about 26 more objects). 3. Use -3 vs a new 'room-for-more' ? prtOutputRemainingCapacity Integer32, prt-att-9-5-r (integer(-3:MAX) ISSUE 2k: Same as ISSUE 2 (but still need -3 for the room for one more value)? ISSUE 3: Or do we want to add (register for use with IPP) an additional 'room-for-more' out-of-band attribute value so that this range could also be changed to integer(0:MAX)? Send any comments to the IPP and PMP mailing lists and we will discuss at Monterey. Thanks, Tom -rw-r--r-- 1 pwg pwg 143872 Jun 30 19:29 ipp-mib-access-980620.doc -rw-r--r-- 1 pwg pwg 66708 Jun 30 19:29 ipp-mib-access-980620.pdf -rw-r--r-- 1 pwg pwg 176640 Jun 30 19:30 ipp-mib-access-980620-rev.doc -rw-r--r-- 1 pwg pwg 94055 Jun 30 19:30 ipp-mib-access-980620-rev.pdf -rw-r--r-- 1 pwg pwg 72192 Jun 30 19:31 ipp-mib-access-summary-980620.doc -rw-r--r-- 1 pwg pwg 25420 Jun 30 19:31 ipp-mib-access-summary-980620.pdf From ipp-owner@pwg.org Wed Jul 1 16:19:23 1998 Delivery-Date: Wed, 01 Jul 1998 16:19:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA16144 for ; Wed, 1 Jul 1998 16:19:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18218 for ; Wed, 1 Jul 1998 16:21:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA08694 for ; Wed, 1 Jul 1998 16:19:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Jul 1998 16:11:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08127 for ipp-outgoing; Wed, 1 Jul 1998 16:09:52 -0400 (EDT) Message-Id: <3.0.5.32.19980701130925.0134b670@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 1 Jul 1998 13:09:25 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-garbrick-shtp-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Isn't this great? HTTPX - a new version of HTTP for "access to materials that may be objectionable". It seems absolutely everybody wants to use HTTP for something else these days... I have checked my calender, it is not April 1st. Carl-Uno >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-garbrick-shtp-00.txt >Date: Wed, 1 Jul 1998 07:29:40 PDT >Sender: cclark@ns.cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Content-Specific Hypertext Transfer Protocol > Author(s) : R. Garbrick > Filename : draft-garbrick-shtp-00.txt > Pages : 3 > Date : 30-Jun-98 > > This document describes HTTPX, a protocol for providing access to > materials that may be objectionable or that have age or locale-based > restrictions, while providing a simple method to filter such content > where required. > > HTTPX uses the protocol HTTP 1.1 ([RFC 2068]), with the single > exception of designating a separate range of TCP and UDP port > numbers that are allocated to a specific content type. > >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-garbrick-shtp-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-garbrick-shtp-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-garbrick-shtp-00.txt". > >NOTE: The mail server at ietf.org 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: <19980630165834.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-garbrick-shtp-00.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From cclark Wed Jul 1 21:50:25 1998 Delivery-Date: Wed, 01 Jul 1998 22:00:12 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id VAA19080 for ietf-outbound.10@ietf.org; Wed, 1 Jul 1998 21:50:02 -0400 (EDT) Received: from waste.silverserver.co.at (root@mail.silverserver.co.at [194.152.178.7]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA19054 for ; Wed, 1 Jul 1998 21:48:41 -0400 (EDT) Received: from isoc.vienna.org (caitanya.silverserver.co.at [194.152.178.163]) by waste.silverserver.co.at (8.8.7/8.6.9) with ESMTP id DAA00197; Thu, 2 Jul 1998 03:48:45 +0200 Received: from localhost (sascha@localhost) by isoc.vienna.org (8.8.2/8.8.2) with SMTP id DAA12702; Thu, 2 Jul 1998 03:45:56 +0200 Date: Thu, 2 Jul 1998 03:45:56 +0200 (MET DST) From: Sascha Ignjatovic X-Sender: sascha@caitanya.silverserver.co.at To: Simon Spero cc: ietf@ietf.org Subject: RE: Where is the RFC editor? In-Reply-To: <000301bda520$8c404280$9c9856d1@oit.unc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 1 Jul 1998, Simon Spero wrote: > This thread has given me a vision of how the forthcoming meeting will be. > > The audience enters and is seated by guards dressed in black uniform, with > red armbands bearing the Ietf logo. Music starts playing - "New World Order" > by Ministry. Lights come up on the stage. The IESG are seated on one hand, > the IAB to the other clad identically to the guards. Flags bearing the logo > surround the podium. They stand to attention. The audience rises. Postel > enters, his head shaved to a crew cut. The audience shouts something is > unison - it sounds like "Hail the Namebringer". He motions for silence, > then points to someone in the audience. "Bring him to me". The guards > comply. "Masataka Ohta - you have been Obsoleted". "Obsoleted! Obsoleted!" > the audience chants. A single gunshot. The chants grow louder, the vision > ends. and than you woke up and the bad was wet ... sascha From ipp-owner@pwg.org Wed Jul 1 22:44:45 1998 Delivery-Date: Wed, 01 Jul 1998 22:44:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA20256 for ; Wed, 1 Jul 1998 22:44:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19615 for ; Wed, 1 Jul 1998 22:47:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA10407 for ; Wed, 1 Jul 1998 22:44:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Jul 1998 22:37:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09850 for ipp-outgoing; Wed, 1 Jul 1998 22:33:23 -0400 (EDT) Message-Id: <199807020229.TAA02916@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 01 Jul 1998 19:34:38 -0700 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO new "encoding and transport" and LPD documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I have just downloaded documents to. These documents are intended to be the final version for IETF ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The "encoding and transport" documents are ipp-pro-980630.doc MS Word 97 ipp-pro-980630-6.doc MS Word 6 ipp-pro-980630.ps PostScript ipp-pro-980630.txt text The LPD documents are ipp-lpd-980630.doc MS Word 97 ipp-lpd-980630-6.doc MS Word 6 ipp-lpd-980630.ps PostScript ipp-lpd-980630.txt text From ipp-owner@pwg.org Wed Jul 1 23:06:32 1998 Delivery-Date: Wed, 01 Jul 1998 23:06:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA25894 for ; Wed, 1 Jul 1998 23:06:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19663 for ; Wed, 1 Jul 1998 23:08:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11099 for ; Wed, 1 Jul 1998 23:06:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Jul 1998 23:01:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA10530 for ipp-outgoing; Wed, 1 Jul 1998 22:59:32 -0400 (EDT) Message-Id: <3.0.5.32.19980701195903.009c1ad0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 1 Jul 1998 19:59:03 PDT To: moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> ADM - IPP WG Resolutions to your comments Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Keith, The IPP WG has been quite busy trying to resolve all your comments on the IPP drafts. The full set of IPP documents now includes: - Design Goals for an Internet Printing Protocol [IPP-REQ] (informational) - Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [IPP-RAT] (informational) - Internet Printing Protocol/1.0: Model and Semantics [IPP MOD] - Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] - Mapping between LPD and IPP Protocols [IPP LPD] (informational) Please note that we changed the names on two of the documents - We changed the name of the Requirements document to: "Design Goals for an Internet Printing Protocol" - We changed the name of the Protocol document to: "Internet Printing Protocol/1.0: Encoding and Transport" The latter change had been suggested in the WG, as it better reflects the actual content of that document. The editors have also taken the opportunity to fix a number of minor inconsistencies and have added a few clarifications in response to comments back from implementors, since the earlier drafts were published in January 1998. We do not think that any of these minor changes will require further review from your side. The WG Response to your comments as well as updated I-Ds for all 5 documents can now be found at: ftp://ftp.pwg.org/pub/pwg/ipp/Internet-Drafts/ I will also send the new I-Ds to the IETF secretariat, so the TXT versions should be available there too, problably after the holidays. We now have complete WG consensus for these revised IPP drafts. I hope that you are also satisfied with the resolutions to your comments. Carl-Uno Manros IETF IPP WG Chair Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jul 1 23:15:48 1998 Delivery-Date: Wed, 01 Jul 1998 23:15:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA25913 for ; Wed, 1 Jul 1998 23:15:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA19690 for ; Wed, 1 Jul 1998 23:18:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA11697 for ; Wed, 1 Jul 1998 23:15:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 1 Jul 1998 23:11:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA11162 for ipp-outgoing; Wed, 1 Jul 1998 23:09:29 -0400 (EDT) Message-Id: <199807020308.XAA03747@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: moore@cs.utk.edu, ipp@pwg.org Subject: IPP> Re: ADM - IPP WG Resolutions to your comments In-reply-to: Your message of "Wed, 01 Jul 1998 19:59:03 PDT." <3.0.5.32.19980701195903.009c1ad0@garfield> Date: Wed, 01 Jul 1998 23:08:03 -0400 Sender: owner-ipp@pwg.org Carl-Uno, I appreciate your and the group's diligent attention to these documents. I will recommend that the IESG adopt the revised versions at the same time that the TLS specs are approved. regards, Keith From ipp-owner@pwg.org Thu Jul 2 00:56:57 1998 Delivery-Date: Thu, 02 Jul 1998 00:56:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA26714 for ; Thu, 2 Jul 1998 00:56:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA19868 for ; Thu, 2 Jul 1998 00:59:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA12605 for ; Thu, 2 Jul 1998 00:56:51 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 00:51:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA12044 for ipp-outgoing; Thu, 2 Jul 1998 00:46:29 -0400 (EDT) Message-Id: <199807020446.AAA05817@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> regarding "ipp:" (I spoke too soon...) cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 02 Jul 1998 00:46:24 -0400 Sender: owner-ipp@pwg.org On a careful re-reading the list of resolutions for the IPP documents, I was surprised to see that the WG had decided not to adopt an "ipp:" URL prefix. (I was out of town last week and unable to follow the list as closely as I would have liked.) In my earlier poll of IESG there was strong agreement that both a separate port and a new URL prefix were needed, though the questions were not asked separately We're having a phone conference on July 2 (today or tomorrow depending on your current time zone), so I'll ask them again just to be sure. Other than the issue with interoperability with http proxies (which are easily addressed), I'd like to know what the technical problems were with using an "ipp:" prefix. I've reviewed most of the list discussion since the teleconference that I participated in, and didn't see any good explanation of why this would cause problems. Keith From ipp-owner@pwg.org Thu Jul 2 02:26:17 1998 Delivery-Date: Thu, 02 Jul 1998 02:26:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA00989 for ; Thu, 2 Jul 1998 02:26:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA20063 for ; Thu, 2 Jul 1998 02:28:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA14677 for ; Thu, 2 Jul 1998 02:26:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 02:22:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA14074 for ipp-outgoing; Thu, 2 Jul 1998 02:19:35 -0400 (EDT) Message-Id: <3.0.5.32.19980701231922.00ce5240@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 1 Jul 1998 23:19:22 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP>PRO new "encoding and transport" and LPD documents [.pdf files] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I made .pdf files with and without revison marks by diffing with the Internet-Draft .doc files from last January (PRO) and December (LPD). ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-980630.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-lpd-980630-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630-rev.pdf Tom >X-Sender: rherriot@woden.eng.sun.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 >Date: Wed, 1 Jul 1998 19:34:38 PDT >To: ipp@pwg.org >From: Robert Herriot >Subject: IPP>PRO new "encoding and transport" and LPD documents >Sender: owner-ipp@pwg.org > >I have just downloaded documents to. These documents are intended >to be the final version for IETF > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO > >The "encoding and transport" documents are > ipp-pro-980630.doc MS Word 97 > ipp-pro-980630-6.doc MS Word 6 > ipp-pro-980630.ps PostScript > ipp-pro-980630.txt text > >The LPD documents are > ipp-lpd-980630.doc MS Word 97 > ipp-lpd-980630-6.doc MS Word 6 > ipp-lpd-980630.ps PostScript > ipp-lpd-980630.txt text > > > From cclark Thu Jul 2 07:21:37 1998 Delivery-Date: Thu, 02 Jul 1998 07:31:25 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id HAA02137 for ietf-outbound.10@ietf.org; Thu, 2 Jul 1998 07:20:02 -0400 (EDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA02094 for ; Thu, 2 Jul 1998 07:11:53 -0400 (EDT) From: Masataka Ohta Message-Id: <199807021059.TAA00238@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA00238; Thu, 2 Jul 1998 19:58:46 +0859 Subject: RE: Where is the RFC editor? To: ses@tipper.oit.unc.edu (Simon Spero) Date: Thu, 2 Jul 98 19:58:45 JST Cc: ietf@ietf.org In-Reply-To: <000301bda520$8c404280$9c9856d1@oit.unc.edu>; from "Simon Spero" at Jul 1, 98 11:46 am X-Mailer: ELM [version 2.3 PL11] Simon; > This thread has given me a vision of how the forthcoming meeting will be. An interesting vision. However, the inconsistency is between the URL in the IETF home page and the announcement of the RFC editor. A puzzling fact is that I personally received a few guesses all of which were easilly confirmed to be wrong from an IAB member. How is your vision now? Masataka Ohta From ipp-owner@pwg.org Thu Jul 2 11:46:09 1998 Delivery-Date: Thu, 02 Jul 1998 11:46:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04788 for ; Thu, 2 Jul 1998 11:46:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA21743 for ; Thu, 2 Jul 1998 11:48:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA27097 for ; Thu, 2 Jul 1998 11:46:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 11:37:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26477 for ipp-outgoing; Thu, 2 Jul 1998 11:33:32 -0400 (EDT) Message-Id: <1.5.4.32.19980702153111.00745da0@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: multipart/mixed; boundary="=====================_899418671==_" Date: Thu, 02 Jul 1998 08:31:11 -0700 To: Keith Moore From: Carl-Uno Manros Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: ipp@pwg.org X-Attachments: C:\WINDOWS\Profiles\Carl-Uno\Desktop\maspro.txt; Sender: owner-ipp@pwg.org --=====================_899418671==_ Content-Type: text/plain; charset="us-ascii" Keith, Please see this attachment which describes the proposal worked out by Randy Turner and Larry Masinter. Case 3 in that proposal caused a number of people to object, pointing out that the previous assumption that ipp: would not be used over the wire was not true any more. There was also discussion about which format the IPP Printer generated Job URIs should have. They are hardly ever seen by and end user and could as well be in http: format. The result would have been that the client would have had to cover for URIs coming back in either scheme and always have to be able to convert between them. The more we discussed this, the more causes we found that the ipp: scheme was not such a bright idea after all. As for the suggestion to include a security paramter in the ipp: scheme, this was adviced against also by Randy and Larry, as it would make the ipp: non-mappable in the http: to ipp: direction. We believe that the current solution to identify what security is supported by a printer works well without the need for a parameter in the scheme. This is my short answer and explanation right now. I assume that other members of the WG can give you further arguments, but many have already started their July 4th celebrations. Carl-Uno At 12:46 AM 7/2/98 -0400, you wrote: >On a careful re-reading the list of resolutions for the IPP >documents, I was surprised to see that the WG had decided not >to adopt an "ipp:" URL prefix. (I was out of town last >week and unable to follow the list as closely as I would >have liked.) > >In my earlier poll of IESG there was strong agreement that both >a separate port and a new URL prefix were needed, though the >questions were not asked separately We're having a phone >conference on July 2 (today or tomorrow depending on your >current time zone), so I'll ask them again just to be sure. > >Other than the issue with interoperability with http proxies >(which are easily addressed), I'd like to know what the >technical problems were with using an "ipp:" prefix. I've >reviewed most of the list discussion since the teleconference >that I participated in, and didn't see any good explanation >of why this would cause problems. > >Keith > > --=====================_899418671==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="maspro.txt" This is a proposal for the registration of a new URL scheme "ipp". The syntax for the new IPP scheme would be identical to the existing "http" scheme except for the scheme name itself: ipp://host[:port]/ Associated with this new IPP scheme would be an IANA-assigned TCP port number, which would be the default port number used by clients to contact IPP servers that are represented by IPP URLs. For the examples in this proposal the port number 374 is used as the port number that might be allocated by IANA. NOTE: this port number selection is for illustrative purposes of this text only. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 374. The semantics for clients configured for proxy access is different as described below. When an IPP client obtains an IPP URL, the interpretation of this URL by the client can take one of three forms, depending on the configuration and implementation of the client: ------------------------------------------------------ IPP Client Configured with no proxy server - ------------------------------------------------------ When an IPP client (no proxy configured) obtains an IPP-schemed URL such as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to port 374 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:374 Content-type: application/ipp Transfer-Encoding: chunked ... ------------------------------------------------------ IPP Client Configured for Proxy Service - ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:374/myprinter/myqueue HTTP/1.1 Host: myproxy.com:374 Content-type: application/ipp Transfer-Encoding: chunked ... It is likely that existing proxies will not understand IPP URLs, so the RequestURI should use the HTTP form of the URL. ------------------------------------------------------- IPP Clients with HTTP-only constraints ------------------------------------------------------- If a particular IPP client implementation uses a pre-packaged HTTP library or HTTP class that only supports HTTP-schemed URLs, then the following operation would be required: - The IPP client obtains the IPP-schemed URL and converts it to the following form: "http://myhost.com:374/myprinter/myqueue" The client then submits this URL to the pre-packaged HTTP library API. ------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers should accept "full" URLs as well, so IPP servers should also be able to accept requestURIs as specified in #2 and #3 as well. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g., http://myhost.com:374/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) --=====================_899418671==_-- From ipp-owner@pwg.org Thu Jul 2 14:02:40 1998 Delivery-Date: Thu, 02 Jul 1998 14:02:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08837 for ; Thu, 2 Jul 1998 14:02:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22560 for ; Thu, 2 Jul 1998 14:04:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29868 for ; Thu, 2 Jul 1998 14:02:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 13:57:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29066 for ipp-outgoing; Thu, 2 Jul 1998 13:53:41 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" , ipp@pwg.org Subject: RE: IPP> regarding "ipp:" (I spoke too soon...) Date: Thu, 2 Jul 1998 10:53:32 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org My fundamental objection is that we are being asked to use a new concept 'psuedo-schemes' without this idea being drilled into at all. There should at least be an I-Draft discussing the idea. Secondly there were many details that needed to be clarified. Was this simply a client convenience or did 'ipp:' ever go over the wire being the deepest one. The general idea seems to be that it is a user convenience thing. In this case it is a client implementation issue and has nothing to do with the wire protocol (which is what this discussion is about) and so should not be accepted. If its meant to appear on the wire then this raises a whole bunch of issues that we havent even thought about - and the only benefit is to make the url slightly more user friendly. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Wednesday, July 01, 1998 9:46 PM To: ipp@pwg.org Cc: moore@cs.utk.edu Subject: IPP> regarding "ipp:" (I spoke too soon...) On a careful re-reading the list of resolutions for the IPP documents, I was surprised to see that the WG had decided not to adopt an "ipp:" URL prefix. (I was out of town last week and unable to follow the list as closely as I would have liked.) In my earlier poll of IESG there was strong agreement that both a separate port and a new URL prefix were needed, though the questions were not asked separately We're having a phone conference on July 2 (today or tomorrow depending on your current time zone), so I'll ask them again just to be sure. Other than the issue with interoperability with http proxies (which are easily addressed), I'd like to know what the technical problems were with using an "ipp:" prefix. I've reviewed most of the list discussion since the teleconference that I participated in, and didn't see any good explanation of why this would cause problems. Keith From ipp-owner@pwg.org Thu Jul 2 14:26:21 1998 Delivery-Date: Thu, 02 Jul 1998 14:26:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09303 for ; Thu, 2 Jul 1998 14:26:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22659 for ; Thu, 2 Jul 1998 14:28:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00886 for ; Thu, 2 Jul 1998 14:26:16 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 14:22:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00301 for ipp-outgoing; Thu, 2 Jul 1998 14:18:30 -0400 (EDT) Message-Id: <199807021816.OAA11217@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 10:53:32 PDT." Date: Thu, 02 Jul 1998 14:16:24 -0400 Sender: owner-ipp@pwg.org > My fundamental objection is that we are being asked to use a new concept > 'psuedo-schemes' without this idea being drilled into at all. There should > at least be an I-Draft discussing the idea. Actually, it's the other way around. IPP is designing a new protocol. It happens to look a lot like HTTP, and there's no problem with that. But the notion that IPP can insist that their protocol should use the same URL type as an existing protocol, is a significant departure from well-established practice that requires substantial justification. > Secondly there were many details that needed to be clarified. Was this > simply a client convenience or did 'ipp:' ever go over the wire being the > deepest one. The general idea seems to be that it is a user convenience > thing. No, ipp: needs to go over the wire in all of the IPP protocol elements. > In this case it is a client implementation issue and has nothing to > do with the wire protocol (which is what this discussion is about) and so > should not be accepted. It's not just a client implementation issue; it affects servers also. Nearly every new protocol these days gets a new URL type. The issues with use of ipp: are no worse than for any other protocol. Keith From ipp-owner@pwg.org Thu Jul 2 14:31:59 1998 Delivery-Date: Thu, 02 Jul 1998 14:31:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09427 for ; Thu, 2 Jul 1998 14:31:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22681 for ; Thu, 2 Jul 1998 14:34:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA01511 for ; Thu, 2 Jul 1998 14:31:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 14:27:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00698 for ipp-outgoing; Thu, 2 Jul 1998 14:24:56 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" Cc: ipp@pwg.org Subject: RE: IPP> regarding "ipp:" (I spoke too soon...) Date: Thu, 2 Jul 1998 11:24:48 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Not so. Every IPP packet is a fully conformant HTTP packet. We are not inventing a new protocol in the scheme sense. Point any lan sniffer at an IPP exchange and ask it what the protocol is - it will say its HTTP. The argument you are using would say that SMTP is not TCP/IP. IPP is layered on top of HTTP - same way that form-based upload is. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Thursday, July 02, 1998 11:16 AM To: Paul Moore Cc: 'Keith Moore'; ipp@pwg.org; moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) > My fundamental objection is that we are being asked to use a new concept > 'psuedo-schemes' without this idea being drilled into at all. There should > at least be an I-Draft discussing the idea. Actually, it's the other way around. IPP is designing a new protocol. It happens to look a lot like HTTP, and there's no problem with that. But the notion that IPP can insist that their protocol should use the same URL type as an existing protocol, is a significant departure from well-established practice that requires substantial justification. > Secondly there were many details that needed to be clarified. Was this > simply a client convenience or did 'ipp:' ever go over the wire being the > deepest one. The general idea seems to be that it is a user convenience > thing. No, ipp: needs to go over the wire in all of the IPP protocol elements. > In this case it is a client implementation issue and has nothing to > do with the wire protocol (which is what this discussion is about) and so > should not be accepted. It's not just a client implementation issue; it affects servers also. Nearly every new protocol these days gets a new URL type. The issues with use of ipp: are no worse than for any other protocol. Keith From ipp-owner@pwg.org Thu Jul 2 14:51:12 1998 Delivery-Date: Thu, 02 Jul 1998 14:51:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09737 for ; Thu, 2 Jul 1998 14:51:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22785 for ; Thu, 2 Jul 1998 14:53:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA02208 for ; Thu, 2 Jul 1998 14:51:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 14:47:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01635 for ipp-outgoing; Thu, 2 Jul 1998 14:43:17 -0400 (EDT) Message-Id: <199807021843.OAA11349@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Moore cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 11:24:48 PDT." Date: Thu, 02 Jul 1998 14:43:05 -0400 Sender: owner-ipp@pwg.org > Not so. Every IPP packet is a fully conformant HTTP packet. We are not > inventing a new protocol in the scheme sense. That's not the way IESG sees it. IPP is chartered to develop a protocol. If you are having problems that no other working group is having, because you're layering over http, maybe you're taking the wrong approach. > Point any lan sniffer at an > IPP exchange and ask it what the protocol is - it will say its HTTP. This could be considered a bug with IPP. > The argument you are using would say that SMTP is not TCP/IP. > IPP is layered on top of HTTP - same way that form-based upload is. HTTP is an application by itself. TCP/IP is not. IPP is trying to layer one application on top of another. Keith From ipp-owner@pwg.org Thu Jul 2 15:01:14 1998 Delivery-Date: Thu, 02 Jul 1998 15:01:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09903 for ; Thu, 2 Jul 1998 15:01:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA22831 for ; Thu, 2 Jul 1998 15:03:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA02874 for ; Thu, 2 Jul 1998 15:01:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 14:57:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02273 for ipp-outgoing; Thu, 2 Jul 1998 14:51:39 -0400 (EDT) Message-Id: <3.0.5.32.19980702115123.00bec240@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 11:51:23 PDT To: Keith Moore From: Carl-Uno Manros Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: ipp@pwg.org In-Reply-To: <199807021816.OAA11217@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 11:16 AM 7/2/98 PDT, Keith Moore wrote: >No, ipp: needs to go over the wire in all of the IPP protocol elements. Keith, I think that this is where the disconnect is. I know that most of the people who participated in the phone conference with you on this subject, heard you stating that ipp: was NOT going over the wire, which is why you thought that the WG had accepted your proposal. When it became clear that ipp: is INDEED going over the wire, people disagreed with your proposal. Are going to insist on ipp: in order to pass on the IPP specs? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jul 2 15:31:16 1998 Delivery-Date: Thu, 02 Jul 1998 15:31:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA10180 for ; Thu, 2 Jul 1998 15:31:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA22975 for ; Thu, 2 Jul 1998 15:33:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA03617 for ; Thu, 2 Jul 1998 15:31:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 15:27:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03034 for ipp-outgoing; Thu, 2 Jul 1998 15:22:47 -0400 (EDT) Message-Id: <3.0.5.32.19980702122223.00c079b0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 12:22:23 PDT To: Keith Moore From: Tom Hastings Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: Paul Moore , "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807021843.OAA11349@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 11:43 07/02/98 PDT, Keith Moore wrote: >> Not so. Every IPP packet is a fully conformant HTTP packet. We are not >> inventing a new protocol in the scheme sense. > >That's not the way IESG sees it. IPP is chartered to develop a protocol. Yes, but the WG chose to use an approach in which IPP server applications could be implemented on existing HTTP web servers. If it is a new protocol, then we can't use existing deployed web servers, correct? > >If you are having problems that no other working group is having, >because you're layering over http, maybe you're taking the wrong approach. > >> Point any lan sniffer at an >> IPP exchange and ask it what the protocol is - it will say its HTTP. > >This could be considered a bug with IPP. > >> The argument you are using would say that SMTP is not TCP/IP. >> IPP is layered on top of HTTP - same way that form-based upload is. > >HTTP is an application by itself. TCP/IP is not. >IPP is trying to layer one application on top of another. True. However, layering one application on another has been the experience in OSI and other layered architectures. Being constrained to only 7 levels is not allowing one application to build on another. > >Keith > > From ipp-owner@pwg.org Thu Jul 2 15:51:56 1998 Delivery-Date: Thu, 02 Jul 1998 15:51:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA10309 for ; Thu, 2 Jul 1998 15:51:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA23118 for ; Thu, 2 Jul 1998 15:54:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA04356 for ; Thu, 2 Jul 1998 15:51:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 15:47:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03739 for ipp-outgoing; Thu, 2 Jul 1998 15:38:00 -0400 (EDT) Message-Id: <3.0.5.32.19980702123740.00c13700@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 12:37:40 PDT To: Keith Moore , paf@swip.net From: Carl-Uno Manros Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: ipp@pwg.org In-Reply-To: <199807021843.OAA11349@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 11:43 AM 7/2/98 PDT, Keith Moore wrote: >HTTP is an application by itself. TCP/IP is not. >IPP is trying to layer one application on top of another. In a sense you are right, but in effect IPP is sending MIME packages over HTTP. This has been our stragegy for more than a year. Is MIME over SMTP considered a separate application that needs it's own scheme? It wasn't last time I checked. BTW, who determines whether an application can or cannot be layered on top of another? If is you who decides, we would have liked to hear this kind of strong objection much earlier in the project. If we are going to have these kind of discussions, it seems to me that the IAB should get involved, as they are rather fundamental Internet design decisions. Re-using existing infra-structure or not seems to be one important discussion point. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jul 2 16:26:28 1998 Delivery-Date: Thu, 02 Jul 1998 16:26:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10608 for ; Thu, 2 Jul 1998 16:26:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA23287 for ; Thu, 2 Jul 1998 16:28:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06040 for ; Thu, 2 Jul 1998 16:26:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 16:22:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05425 for ipp-outgoing; Thu, 2 Jul 1998 16:19:54 -0400 (EDT) Message-Id: <199807022018.QAA11535@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 11:51:23 PDT." <3.0.5.32.19980702115123.00bec240@garfield> Date: Thu, 02 Jul 1998 16:18:24 -0400 Sender: owner-ipp@pwg.org > Are going to insist on ipp: in order to pass on the IPP specs? IESG is. Nobody could make a case for it being any other way. Keith From ipp-owner@pwg.org Thu Jul 2 16:36:34 1998 Delivery-Date: Thu, 02 Jul 1998 16:36:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10728 for ; Thu, 2 Jul 1998 16:36:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA23309 for ; Thu, 2 Jul 1998 16:38:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA06695 for ; Thu, 2 Jul 1998 16:36:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 16:32:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06104 for ipp-outgoing; Thu, 2 Jul 1998 16:27:19 -0400 (EDT) Message-Id: <199807022025.QAA11567@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , Paul Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 12:22:23 PDT." <3.0.5.32.19980702122223.00c079b0@garfield> Date: Thu, 02 Jul 1998 16:25:51 -0400 Sender: owner-ipp@pwg.org > >> Not so. Every IPP packet is a fully conformant HTTP packet. We are not > >> inventing a new protocol in the scheme sense. > > > >That's not the way IESG sees it. IPP is chartered to develop a protocol. > > Yes, but the WG chose to use an approach in which IPP server applications > could be implemented on existing HTTP web servers. If it is a new protocol, > then we can't use existing deployed web servers, correct? There's a long tradition in IETF of reusing and/or adapting existing technology, so there's no problem with that per se. But there are several problems with overloading a new protocol on top of existing web *services*. And the idea that IPP should be able to tunnel through firewalls "by default" - thus overriding local site policy - does great harm to the overall Internet architecture. > >HTTP is an application by itself. TCP/IP is not. > >IPP is trying to layer one application on top of another. > > True. However, layering one application on another has been the experience > in OSI and other layered architectures. And one of the things we learned from OSI is that if you have too many layers - especially layers that don't fit well together - the result isn't very effective. Otherwise known as the 'leaning tower' effect. Keith From ipp-owner@pwg.org Thu Jul 2 16:46:01 1998 Delivery-Date: Thu, 02 Jul 1998 16:46:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10811 for ; Thu, 2 Jul 1998 16:46:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA23353 for ; Thu, 2 Jul 1998 16:48:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA07311 for ; Thu, 2 Jul 1998 16:45:57 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 16:42:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06764 for ipp-outgoing; Thu, 2 Jul 1998 16:40:20 -0400 (EDT) Message-Id: <3.0.5.32.19980702134000.00c78100@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 13:40:00 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Agenda for Monterey July 8-9, 1998 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org PWG IPP Agenda for Monterey July 8-9, 1998 ========================================== Sorry about the late publication of this agenda, but as you all know, the whole group has been busy trying to get the new set of drafts out before the July 4th holiday. I had hoped to have IPP V1.0 all squared away by our next meeting, but Keith Moore has again raised his objection about the IETF IPP WG leaving out the "ipp:" scheme in the latest drafts. So here are the points that I expect us to cover: 1) Discuss our reaction on Keith Moore's latest comments on IPP. See the IPP DL for discussion. 2) Discuss Microsoft's proposal to register IPP extra operations See document from Paul Moore. 3) Reactivate us on the registration of Printer MIB document types as MIME types. Old home work assignment that is still to be done. 4) Discuss latest plans for the IPP inter-operability testing. Peter Zehler will give an update. 5) Discuss and get started on the Implementor's Guide activities for IPP. Carl-Uno will re-introduce this subject. 6) Discuss a question from the IFAX group if the IPP group would be prepared to write a mapping document for IPP to IFAX. Larry Masinter might come. 7) MIB access over IPP. Tom Hastings has supplied new draft and overview documents. 8) IPP Notifications. Don't we have any new input on this. Not sure whether we are ripe for new discussion, or should wait for further written input. 9) Agenda for IPP WG in IETF42. We have a 1.5 hour slot in Chicago. We need to put the agenda together. I can see us getting through the first 4 - 5 agenda points on Wednesday and cover the remaining ones on Thursday. I have not yet seen any agenda or input for an SDP session, so we might be able to use all of Thursday for IPP if we should need to. Please let me know if I missed something. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jul 2 17:06:27 1998 Delivery-Date: Thu, 02 Jul 1998 17:06:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11058 for ; Thu, 2 Jul 1998 17:06:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23452 for ; Thu, 2 Jul 1998 17:08:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA08380 for ; Thu, 2 Jul 1998 17:06:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:02:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07473 for ipp-outgoing; Thu, 2 Jul 1998 16:52:41 -0400 (EDT) Message-Id: <199807022051.QAA11639@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , paf@swip.net, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 12:37:40 PDT." <3.0.5.32.19980702123740.00c13700@garfield> Date: Thu, 02 Jul 1998 16:51:10 -0400 Sender: owner-ipp@pwg.org > >HTTP is an application by itself. TCP/IP is not. > >IPP is trying to layer one application on top of another. > > In a sense you are right, but in effect IPP is sending MIME > packages over HTTP. This has been our stragegy for more than a year. > Is MIME over SMTP considered a separate application that needs > it's own scheme? It wasn't last time I checked. SMTP is not an application; end users don't use SMTP by itself. MIME is only the latest in a series of versions of the internet message format, which SMTP was tailor-made to carry. But there is at least some precedent. ARPAnet email was originally implemented by sending text messages over FTP and depositing them in a file named after the recipient. But this didn't work very well, and was soon replaced. Some TOPS-20 people layered their SMTP implementations on top of telnet support in their kernel, but eventually this turned out to be a Bad Idea. All of this was long before the net had tens of millions of users, back when casual experimentation had fewer risks associated with it. It was also before there was a formal standardization process. The belief in this case is that IPP is different enough from ordinary HTTP traffic that the two should be distinguished. > BTW, who determines whether an application can or cannot be layered > on top of another? If is you who decides, we would have liked to hear > this kind of strong objection much earlier in the project. Ultimately, the IESG determines what is acceptable in an Internet standards track protocol, with provision for appeal to the IAB. I agree that earlier notification would have been better. But IPP is trying to do something radically different than most other working groups (even though it intended to be conservative), and some of the implications of its approach were not apparent until recently. > If we are going to have these kind of discussions, it seems to me > that the IAB should get involved, as they are rather fundamental > Internet design decisions. Re-using existing infra-structure or not > seems to be one important discussion point. The IAB Chair participated in today's IESG conference call. A more detailed response will be forthcoming, and the IAB Chair has requested that IAB be in on the discussions. Keith From ipp-owner@pwg.org Thu Jul 2 17:26:15 1998 Delivery-Date: Thu, 02 Jul 1998 17:26:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11268 for ; Thu, 2 Jul 1998 17:26:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23537 for ; Thu, 2 Jul 1998 17:28:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09084 for ; Thu, 2 Jul 1998 17:26:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:22:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08516 for ipp-outgoing; Thu, 2 Jul 1998 17:19:52 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 02 Jul 1998 15:19:20 -0600 From: "Scott Isaacson" To: moore@cs.utk.edu, paulmo@microsoft.com Cc: ipp@pwg.org Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA11268 Keith, I find the following process very ineffective: 1. IESG charters IPP WG in 3/97 after a well attended BOF 12/96. 2. The WG has always been well staffed and work has progressed within the working group at a very good rate. We were essentially done at the end of 97. 3. The working group has reached consensus and produced a set of drafts that meet the objectives of the charter. 4. The decision to reuse HTTP/1.1 has been on the table (IPP WG email discussion list, IPP drafts) for over a year now. There was NEVER any discussion in the working group meetings in Munich, DC, and/or LA that IPP should not be layered on top of HTTP/1.1. The only question was POST vs PRINT. Both of which implied layering on top of HTTP/1.1 For a year we have said that IPP opertions would be use the "http:" scheme. 5. The working group had final call in 12/97. All comments were addressed. 6. The IESG held IEFT wide final call. There were virtually NO comments on the mailing list. All comments were addressed. Now, here is the real killer step: 7. 5 months after the end of the IESG final call on the IPP documents, we start to hear that "You MUST do it this way or else it will not be approved." Such comments were REQUIRED a year ago - they seem disruptive now. I don't buy the arguments about "layering is bad". Although not optimal, the argument is that re-using HTTP was a good thing becuase of the leveraging and growth path of HTTP. HTTP is already being used for network attached printers and for print servers in a big way - it is already deployed where it needs to be. I do understand that IPP needs to be distinguishable, therefore the default port is a great idea along with an obvious content-type. If every protocol did its own infrastructure, security, naming, identity, distribution model, header definitions, etc., the world would be a mess. In my mind, it is either HTTP/1.1 for leveraging exiting protocol stack rather than requiring new ones, or not. I would hate to have all of the disadvantages of using HTTP with none of the advantages. At least with re-use, you get some or all of the advantages. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-owner@pwg.org Thu Jul 2 17:38:57 1998 Delivery-Date: Thu, 02 Jul 1998 17:38:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11432 for ; Thu, 2 Jul 1998 17:38:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23575 for ; Thu, 2 Jul 1998 17:41:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA09761 for ; Thu, 2 Jul 1998 17:38:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:34:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09165 for ipp-outgoing; Thu, 2 Jul 1998 17:27:12 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2D09E@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Keith Moore'" , Tom Hastings Cc: Paul Moore , ipp@pwg.org Subject: RE: IPP> regarding "ipp:" (I spoke too soon...) Date: Thu, 2 Jul 1998 14:27:07 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, July 02, 1998 1:26 PM > To: Tom Hastings > Cc: Keith Moore; Paul Moore; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) > > There's a long tradition in IETF of reusing and/or adapting existing > technology, so there's no problem with that per se. But there are > several problems with overloading a new protocol on top of existing > web *services*. And the idea that IPP should be able to tunnel > through firewalls "by default" - thus overriding local site policy - > does great harm to the overall Internet architecture. > As you know, I totally agree with the policy issue, as that has been the crux of my argument in the POST draft issues. However, I feel strongly that HTTP is a valuable platform to be built upon in a layered or substrate model. I would characterize IPP as a "service" within the http framework. (You can pick better words for service and framework, but thats just picking nits). I beleive that for services within HTTP the best way to differentiate them is to use a new METHOD. Using a new method maintains the HTTP message format and transport scheme (http://) but is easily filterable. I think one of the main points here is that when traversing some infrastructure, wether it be end-node embedded web servers or application layer proxy/firewalls, does each node have to fully understand the IPP protocol? My opinion is that they do not. By being able to easily identify the "service" ,via the METHOD in my example, the node has enough information to enforce a security policy by rejecting or allowing it and can hand the message off to an method handler for IPP to process it. In the same way the TCP transport identifies different protocols by their port numbers, the HTTP application transport can identify different services by their methods. Intermediate nodes dont necessarily need to understand the message body, just the way that proxy servers today have no knowledge of HTML in typical web traffic. In cases where it is wise to have the intermediate nodes understand the content or semantics of an extension we address that in the form of the proposed Mandatory syntax. To sum up, HTTP as an application tansport layer provides added functionality compared to TCP which allows services running over HTTP to avoid reinventing an various wheels (authentication, mime-content body, caching, pipelining, message versioning (via etags), infrastructure traversal, filtering, etc) like if it was to run over TCP. In cases where the http functionality "wheels" are appropriate for a service, it makes sense to look at HTTP as an application transport service and to build upon it. When it does not, a "new" transport protocol should be used. The IPP authors chose to build on HTTP for good reason, IMHO, for many of features I mentioned above. An easy way to identify the IPP service is via a new method, it provides easy filtering and doesn not require IPP specific knowledge at each node in the infrastructure as a new scheme would. Josh Cohen From ipp-owner@pwg.org Thu Jul 2 17:46:36 1998 Delivery-Date: Thu, 02 Jul 1998 17:46:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11505 for ; Thu, 2 Jul 1998 17:46:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23603 for ; Thu, 2 Jul 1998 17:48:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA10425 for ; Thu, 2 Jul 1998 17:46:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:42:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09194 for ipp-outgoing; Thu, 2 Jul 1998 17:32:26 -0400 (EDT) Message-Id: <3.0.5.32.19980702143210.00a06330@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 14:32:10 PDT To: Keith Moore From: Carl-Uno Manros Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: paf@swip.net, ipp@pwg.org In-Reply-To: <199807022051.QAA11639@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 01:51 PM 7/2/98 PDT, Keith Moore wrote: >> >HTTP is an application by itself. TCP/IP is not. >> >IPP is trying to layer one application on top of another. >> >> In a sense you are right, but in effect IPP is sending MIME >> packages over HTTP. This has been our stragegy for more than a year. >> Is MIME over SMTP considered a separate application that needs >> it's own scheme? It wasn't last time I checked. > >SMTP is not an application; end users don't use SMTP by itself. >MIME is only the latest in a series of versions of the >internet message format, which SMTP was tailor-made to carry. > Keith, I still think your comparison does not hold up. In the same sense you could view HTTP as a transport protocol for HTML pages, and more lately XML pages. How about IFAX and various other application projects that have been impertinent enough to re-use rather than re-invent? Mind you, I have been involved in these kind of discussions for the last 20 years and believe that I know what I am talking about. I think the truth of the matter is that the current Internet application protocols kind of emerged without any architecture what-so-ever, and that maybe now the IESG and IAB are starting to try to clean up the act. The IPP project just happens to be a road kill in that process. Am I right? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Thu Jul 2 17:52:01 1998 Delivery-Date: Thu, 02 Jul 1998 17:52:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11539 for ; Thu, 2 Jul 1998 17:52:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23625 for ; Thu, 2 Jul 1998 17:54:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA11056 for ; Thu, 2 Jul 1998 17:51:58 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:47:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09229 for ipp-outgoing; Thu, 2 Jul 1998 17:34:48 -0400 (EDT) Message-ID: <359BFCD5.FAE3F6D0@agranat.com> Date: Thu, 02 Jul 1998 21:34:13 +0000 From: Scott Lawrence Organization: Agranat Systems http://www.agranat.com/ X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.32 i686) MIME-Version: 1.0 To: Keith Moore CC: IPP List Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) References: <199807022051.QAA11639@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Keith Moore wrote: > > > >HTTP is an application by itself. TCP/IP is not. > > >IPP is trying to layer one application on top of another. Actually, I've long been of the opinion that while the lines are blurred somewhat that current HTTP is really more a combination of Session and Presentation layers - it is used by web browsers to impelement interactions between web browsers and web servers, but it is clear that it is being adopted for other purposes as well. The request/response components of HTTP form brief 'sessions' - associations between application layer entities carried over a transport. Note that HTTP persistent connections do not even all carry requests from the same application endpoints (as in the case of a proxy combining requests from multiple clients to an origin server). MIME is really a form of presentation layer - it provides the metadata that enables the applications to communicate the form of the data being exchanged. Only the cache control features of HTTP are really application functions. It is my hope that the HTTP-NG effort can clarify the distinctions between the session-like, presentation-like, and application-like features, despite the fact that the Internet protocol family has historically behaved as though it was anathema to call anything above TCP anything but an application. > > In a sense you are right, but in effect IPP is sending MIME > > packages over HTTP. This has been our stragegy for more than a year. > > Is MIME over SMTP considered a separate application that needs > > it's own scheme? It wasn't last time I checked. > The belief in this case is that IPP is different enough from > ordinary HTTP traffic that the two should be distinguished. But that doesn't change the fact that the IPP group has been quite carefull not to alter or extend HTTP in order to do so - they have in fact layered thier work. -- Scott Lawrence Consulting Engineer Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/ From ipp-owner@pwg.org Thu Jul 2 19:13:18 1998 Delivery-Date: Thu, 02 Jul 1998 19:13:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11848 for ; Thu, 2 Jul 1998 19:13:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA23813 for ; Thu, 2 Jul 1998 19:15:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12205 for ; Thu, 2 Jul 1998 19:13:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 19:07:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11596 for ipp-outgoing; Thu, 2 Jul 1998 19:05:39 -0400 (EDT) Message-Id: <199807022304.TAA12750@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , paf@swip.net, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 14:32:10 PDT." <3.0.5.32.19980702143210.00a06330@garfield> Date: Thu, 02 Jul 1998 19:04:11 -0400 Sender: owner-ipp@pwg.org > I still think your comparison does not hold up. In the same sense you could > view HTTP as a transport protocol for HTML pages, and more lately XML > pages. And gif and jpeg files and java programs and etc. Obviously, HTTP is a general purpose file transfer protocol. But printing is not the same as file transfer. But the problem is not that IPP is layering on top of the HTTP protocol, the problem is that IPP wants to use the http: URL. > How about IFAX and various other application projects that have been > impertinent enough to re-use rather than re-invent? IFAX is also having a hard time trying to shoehorn their model for how they think fax works, into the model for Internet mail. But basically they are two services for exchanging interpersonal messages - one based on text and another based on images - and there's a lot of synergy to be gained by combining the two. On the other hand, when they try to violate the architecture of the email system, they're getting pushback. The difference is that they're getting it sooner in their lifespan than IPP did. On the other hand, reconciling these issues is of fundamental importance to the ifax folks. In the case of IPP we're not trying to fundamentally change how IPP works - we're just trying to fix some notational bugs. > Mind you, I have been involved in these kind of discussions for the last 20 > years and believe that I know what I am talking about. I think the truth of > the matter is that the current Internet application protocols kind of > emerged without any architecture what-so-ever, and that maybe now the IESG > and IAB are starting to try to clean up the act. The IPP project just > happens to be a road kill in that process. Am I right? Well, in a sense, yes. We've got millions of users, an explosion of new protocol development, vendor demands for quick development cycles, and we've got ISPs and content-providers interfering with the needs of users, and vendors interfering with the needs of ISPs, etc. ... all of a sudden it has become much more important to try to sort out the architecture, try to say who can do what, to prevent bad things from happening. Of course, if it weren't for these same forces, there wouldn't be nearly as much reason for IPP to try to tunnel itself through HTTP. It's not as if something has run over IPP; it's more like we've diverted IPP to a ditch to keep it from hitting something moving in the other direction and making an even larger mess. Keith From ipp-owner@pwg.org Thu Jul 2 19:17:56 1998 Delivery-Date: Thu, 02 Jul 1998 19:17:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11864 for ; Thu, 2 Jul 1998 19:17:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA23822 for ; Thu, 2 Jul 1998 19:20:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA12820 for ; Thu, 2 Jul 1998 19:17:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 19:13:09 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11775 for ipp-outgoing; Thu, 2 Jul 1998 19:08:29 -0400 (EDT) Message-Id: <199807022308.TAA12793@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Isaacson" cc: moore@cs.utk.edu, paulmo@microsoft.com, ipp@pwg.org Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 15:19:20 MDT." Date: Thu, 02 Jul 1998 19:08:18 -0400 Sender: owner-ipp@pwg.org [I'm using my reply to Scott's message to try to explain the IESG position, along with the difficulties that this WG has seen.] Scott, Ihe process has indeed been ineffective in this case, but IPP has been an unusual working group. IETF has traditionally relied heavily on participation by the extended IETF community, to ensure that different protocols don't "stomp on one another". This worked better when the community consisted of a few hundred people. IPP's practice of schedling frequent private meetings (that happened to be co-located with PWG meetings) and telephone conferences has, whether intentionally or not, biased its participation towards printer vendors, and away from users, and isolated it from the rest of IETF. This is one reason why there wasn't much discussion in the IETF conference meetings - IPP was too hard for an outsider to follow. None of these were violations of process rules, as far as I can tell, and yet they've had a definite effect. IETF will have to learn from the experience, and perhaps find new ways of letting groups move quickly (the frequent meetings and calls are quite helpful in this regard) while still making sure that the resulting pieces fit together. IPP has also been working from some very different assumptions from that of most IETF working groups. Most groups have no trouble making sure that their protocols are distinguished from other protocols. This is the only group I've ever seen that tried to get approval for their protocol to masquerade as another protocol! And finally, IPP produced a thick set of documents at a time when there was already far too much load on the ADs. We let ourselves take on too many working groups, and got spread too thin, and we're only now starting to get back to normal now that many of those groups are winding down. So the task of preventing "foot injuries" has fallen to me, and to a lesser degree, to IESG. I'd much rather have the extended IETF community do the job - they're better at it, and it's too much stress for me to do it alone. And for other groups that are similarly isolated, I'm working very hard to get other IETF folks in the group, so that their voices are heard before the group thinks it has finished its work. ... Now as to the technical issue: what I originally said was that you had to be able to distinguish the traffic. In my mind this was probably either a different port or a differnt HTTP method - with a different port being the well-established traditional approach, and also the one which probably caused the least pain for existing implementations. But a different default port also implies a different URL type. What's the sense of having a default port that you have to type in explicitly? And for that matter, what's the sense in forcing users to type in http://hostname:port/foobar when they could far more easily type ipp://hostname/foobar? (There's no precedent for it, but arguably a PRINT method would have also needed a different URL type.) To be frank, I have a difficult time understanding what all of the fuss is about...it seems like quite a simple change to the code... unless somebody has already produced thousands of mask- programmed ROMs with http: and not ipp: wired into them. To my mind this is a very minor change, not unlike changes that IESG often requests before approval. But I didn't want to be autocratic about this. So I went to IESG to make sure that I'm not the only one with this opinion, to make sure I'm not out on a limb. I went to IESG because they're the folks who do the final review, and it's their opinion that matters. The conversation goes something like this: me: "the IPP folks want to use http for their URL type instead of ipp" iesg: "why do they want to do that?" me: "because they're layering on top of HTTP, and because existing proxies and APIs can deal with http URLs but not ipp URLs" iesg: "why are they layering on top of HTTP?" me: "because it's familiar, and it has something resembling security, and especially because it can go through firewalls. To be honest, they're not the only group that wants to do this. And it's not a bad idea to reuse existing technology; I'm just claiming that firewall admins need to be able to distinguish ipp traffic from ordinary web traffic. A separate default port is the traditional way to do this, and a different URL type is the traditional way to indicate a different default port." iesg: "how do they use an HTTP firewall to talk to a different port?" me: "if you explicitly specify the port number in the URL, when talking to a proxy, the proxy will talk out that port." iesg: "so they want to use http: so that it can tunnel through firewalls?" me: "basically, yes. and APIs" So the conversation winds down, and the conclusion is that the IESG can't understand why IPP needs to use http: for its own purposes, nor why IPP expects to be able to bypass firewalls. And I can't explain it to them. Nobody likes what firewalls do to deployability of new applications, but it sets a bad precedent if we bless the practice of ipp bypassing them. The general feeling seemed to be that for better or worse, every new protocol has to punch another hole through firewalls, that it's up to the sysadmins to make decisions about whether the holes get punched, and IETF shouldn't be second-guessing them. To me the harm *to users* of using http: (and implicitly the default of port 80, no matter what the spec says) far outweighs the effort at doing a global search through the code for "http" and modifying it to support "ipp" instead/also. The end result is that IESG and IAB are going to discuss these issues and define rules for layering things on top of HTTP and/or reusing existing ports and URL types. In the meantime, I've essentially been told by a very skeptical IESG that the IPP WG is going to have to show substantial justification for using http: rather than ipp: I can't imagine what the justification might be, and I haven't seen anything resembling such justification on the list. But I and at least a few IESG folks seemed willing to listen once more. So here's what is going to happen. The IPP drafts should be formally considered by the IESG at its next telechat, or the one thereafter. (either 2 or 4 weeks from today) IPP shouldn't change anything until the IESG finishes its review, because it's always possible that IESG will request other changes. In the meantime, IPP needs to be aware that there's substantial IESG skepticism about using http: instead of ipp:. Perhaps the best thing for IPP to do in the meantime is to prepare a letter to IESG and/or IAB that states why it thinks it should be able to use http:. That way, I don't have to try to be an advocate for something I don't understand. Keith From ipp-owner@pwg.org Thu Jul 2 20:11:30 1998 Delivery-Date: Thu, 02 Jul 1998 20:11:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA11987 for ; Thu, 2 Jul 1998 20:11:29 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA23888 for ; Thu, 2 Jul 1998 20:13:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA13765 for ; Thu, 2 Jul 1998 20:11:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 20:07:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA13155 for ipp-outgoing; Thu, 2 Jul 1998 20:04:11 -0400 (EDT) Message-Id: <199807030005.RAA10539@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 02 Jul 1998 17:00:13 -0700 To: Carl-Uno Manros , Keith Moore From: Randy Turner Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: ipp@pwg.org In-Reply-To: <1.5.4.32.19980702153111.00745da0@pop3.holonet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org There were no operational problems with the proposal, I think what the group boiled down to was that creating a new "ipp" scheme just for end-user convenience was not enough justification. I don't remember any specific examples of how the proposal would break if deployed. Randy At 08:31 AM 7/2/98 -0700, Carl-Uno Manros wrote: >Keith, > >Please see this attachment which describes the proposal worked out by Randy >Turner and Larry Masinter. Case 3 in that proposal caused a number of people >to object, pointing out that the previous assumption that ipp: would not be >used over the wire was not true any more. There was also discussion about >which format the IPP Printer generated Job URIs should have. They are hardly >ever seen by and end user and could as well be in http: format. The result >would have been that the client would have had to cover for URIs coming >back in either scheme and always have to be able to convert between them. >The more we discussed this, the more causes we found that the ipp: scheme >was not such a bright idea after all. As for the suggestion to include a >security paramter in the ipp: scheme, this was adviced against also by Randy >and Larry, as it would make the ipp: non-mappable in the http: to ipp: >direction. We believe that the current solution to identify what security is >supported by a printer works well without the need for a parameter in the >scheme. > >This is my short answer and explanation right now. I assume that other >members of the WG can give you further arguments, but many have already >started their July 4th celebrations. > >Carl-Uno > >At 12:46 AM 7/2/98 -0400, you wrote: >>On a careful re-reading the list of resolutions for the IPP >>documents, I was surprised to see that the WG had decided not >>to adopt an "ipp:" URL prefix. (I was out of town last >>week and unable to follow the list as closely as I would >>have liked.) >> >>In my earlier poll of IESG there was strong agreement that both >>a separate port and a new URL prefix were needed, though the >>questions were not asked separately We're having a phone >>conference on July 2 (today or tomorrow depending on your >>current time zone), so I'll ask them again just to be sure. >> >>Other than the issue with interoperability with http proxies >>(which are easily addressed), I'd like to know what the >>technical problems were with using an "ipp:" prefix. I've >>reviewed most of the list discussion since the teleconference >>that I participated in, and didn't see any good explanation >>of why this would cause problems. >> >>Keith >> >> > > > From ipp-owner@pwg.org Thu Jul 2 20:31:51 1998 Delivery-Date: Thu, 02 Jul 1998 20:31:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12106 for ; Thu, 2 Jul 1998 20:31:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA23915 for ; Thu, 2 Jul 1998 20:34:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA14497 for ; Thu, 2 Jul 1998 20:31:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 20:27:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA13869 for ipp-outgoing; Thu, 2 Jul 1998 20:20:01 -0400 (EDT) Message-Id: <3.0.5.32.19980702171921.00c751e0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 2 Jul 1998 17:19:21 PDT To: Keith Moore , "Scott Isaacson" , paf@swip.net From: Carl-Uno Manros Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: paulmo@microsoft.com, ipp@pwg.org In-Reply-To: <199807022308.TAA12793@spot.cs.utk.edu> 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: owner-ipp@pwg.org Keith, I am sorry, but I want to send you one more reply before shutting up for a while and let others get a chance to comment after the holidays. I do not think that you have represented the WG particularly well, if the IESG discussion went as you described. You seem to be hang up on the belief that IPP was only designed to "sneak through firewalls". I believe that everybody in the WG gave up on that idea about a year ago. The more substantial reason was that we would make use of existing HTTP code and implementations, that had already been debugged and demonstated to work in a large scale, thereby expecting to shorten the time it would take to develop and deploy IPP implementations. Another reason was that HTTP is already being used in printers today for management (port 280 was defined to run management info over HTTP, in case you did not know), built-in HTML manuals etc., which means that using HTTP for IPP is one less transfer protocol to implement in a printer. Looking at things in retrospect, it would most certainly have costed us much less time and effort to invent our own protocol from scratch rather than spending valuable time in extended debates about how we can or cannot use HTTP. But at this stage, when many companies are already preparing IPP implementations for rollout, I do not see it as an alternative any more. On your point that mostly printer vendors have participated in the work. Who else then OS/NOS vendors supplying IPP clients, and printer and print server vendors supplying IPP Printers, do you image would have a strong interest to participate? Who else do you expect would actually implement IPP? Linux folks perhaps - possibly! Have a nice 4th of July holiday, Carl-Uno At 04:08 PM 7/2/98 PDT, Keith Moore wrote: >[I'm using my reply to Scott's message to try to explain the >IESG position, along with the difficulties that this WG has seen.] > >Scott, > >Ihe process has indeed been ineffective in this case, but IPP >has been an unusual working group. > >IETF has traditionally relied heavily on participation by >the extended IETF community, to ensure that different protocols >don't "stomp on one another". This worked better when the >community consisted of a few hundred people. IPP's practice >of schedling frequent private meetings (that happened to be >co-located with PWG meetings) and telephone conferences has, >whether intentionally or not, biased its participation towards >printer vendors, and away from users, and isolated it from the >rest of IETF. This is one reason why there wasn't much >discussion in the IETF conference meetings - IPP was too >hard for an outsider to follow. > >None of these were violations of process rules, as far as I >can tell, and yet they've had a definite effect. IETF will >have to learn from the experience, and perhaps find new >ways of letting groups move quickly (the frequent meetings >and calls are quite helpful in this regard) while still >making sure that the resulting pieces fit together. > >IPP has also been working from some very different assumptions >from that of most IETF working groups. Most groups have no >trouble making sure that their protocols are distinguished >from other protocols. This is the only group I've ever seen >that tried to get approval for their protocol to masquerade >as another protocol! > >And finally, IPP produced a thick set of documents at a time when >there was already far too much load on the ADs. We let ourselves >take on too many working groups, and got spread too thin, and >we're only now starting to get back to normal now that many of >those groups are winding down. > >So the task of preventing "foot injuries" has fallen to me, >and to a lesser degree, to IESG. I'd much rather have >the extended IETF community do the job - they're better at it, >and it's too much stress for me to do it alone. > >And for other groups that are similarly isolated, I'm working >very hard to get other IETF folks in the group, so that their >voices are heard before the group thinks it has finished its work. > >... > >Now as to the technical issue: what I originally said was that >you had to be able to distinguish the traffic. In my mind this >was probably either a different port or a differnt HTTP method - >with a different port being the well-established traditional >approach, and also the one which probably caused the least >pain for existing implementations. > >But a different default port also implies a different URL type. >What's the sense of having a default port that you have to type >in explicitly? And for that matter, what's the sense in forcing >users to type in http://hostname:port/foobar when they could >far more easily type ipp://hostname/foobar? (There's no >precedent for it, but arguably a PRINT method would have >also needed a different URL type.) > >To be frank, I have a difficult time understanding what all of >the fuss is about...it seems like quite a simple change to the >code... unless somebody has already produced thousands of mask- >programmed ROMs with http: and not ipp: wired into them. >To my mind this is a very minor change, not unlike changes that >IESG often requests before approval. > >But I didn't want to be autocratic about this. So I went to IESG >to make sure that I'm not the only one with this opinion, to make >sure I'm not out on a limb. I went to IESG because they're the >folks who do the final review, and it's their opinion that matters. >The conversation goes something like this: > > >me: "the IPP folks want to use http for their URL type instead of ipp" > >iesg: "why do they want to do that?" > >me: "because they're layering on top of HTTP, and because existing > proxies and APIs can deal with http URLs but not ipp URLs" > >iesg: "why are they layering on top of HTTP?" > >me: "because it's familiar, and it has something resembling security, > and especially because it can go through firewalls. To be honest, > they're not the only group that wants to do this. And it's not > a bad idea to reuse existing technology; I'm just claiming that > firewall admins need to be able to distinguish ipp traffic from > ordinary web traffic. A separate default port is the traditional > way to do this, and a different URL type is the traditional way to > indicate a different default port." > >iesg: "how do they use an HTTP firewall to talk to a different port?" > >me: "if you explicitly specify the port number in the URL, when > talking to a proxy, the proxy will talk out that port." > >iesg: "so they want to use http: so that it can tunnel through firewalls?" > >me: "basically, yes. and APIs" > > >So the conversation winds down, and the conclusion is that the IESG >can't understand why IPP needs to use http: for its own purposes, >nor why IPP expects to be able to bypass firewalls. And I can't explain >it to them. Nobody likes what firewalls do to deployability of new >applications, but it sets a bad precedent if we bless the practice of >ipp bypassing them. The general feeling seemed to be that for better >or worse, every new protocol has to punch another hole through firewalls, >that it's up to the sysadmins to make decisions about whether the holes >get punched, and IETF shouldn't be second-guessing them. > >To me the harm *to users* of using http: (and implicitly the default >of port 80, no matter what the spec says) far outweighs the effort >at doing a global search through the code for "http" and modifying >it to support "ipp" instead/also. > > > > >The end result is that IESG and IAB are going to discuss these issues >and define rules for layering things on top of HTTP and/or reusing >existing ports and URL types. In the meantime, I've essentially been >told by a very skeptical IESG that the IPP WG is going to have to >show substantial justification for using http: rather than ipp: > >I can't imagine what the justification might be, and I haven't seen >anything resembling such justification on the list. But I and at least >a few IESG folks seemed willing to listen once more. > >So here's what is going to happen. The IPP drafts should be formally >considered by the IESG at its next telechat, or the one thereafter. >(either 2 or 4 weeks from today) IPP shouldn't change anything until >the IESG finishes its review, because it's always possible that >IESG will request other changes. In the meantime, IPP needs to be >aware that there's substantial IESG skepticism about using http: >instead of ipp:. > > >Perhaps the best thing for IPP to do in the meantime is to prepare >a letter to IESG and/or IAB that states why it thinks it should >be able to use http:. That way, I don't have to try to be an advocate >for something I don't understand. > >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 From ipp-owner@pwg.org Thu Jul 2 20:41:56 1998 Delivery-Date: Thu, 02 Jul 1998 20:41:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12139 for ; Thu, 2 Jul 1998 20:41:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA23937 for ; Thu, 2 Jul 1998 20:44:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA15178 for ; Thu, 2 Jul 1998 20:41:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 20:37:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14550 for ipp-outgoing; Thu, 2 Jul 1998 20:32:15 -0400 (EDT) Message-Id: <199807030027.RAA06076@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 02 Jul 1998 17:32:49 -0700 To: Keith Moore , "Scott Isaacson" From: Robert Herriot Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: moore@cs.utk.edu, paulmo@microsoft.com, ipp@pwg.org In-Reply-To: <199807022308.TAA12793@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_793776380==_.ALT" Sender: owner-ipp@pwg.org --=====================_793776380==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keith, SWAP (http://people.netscape.com/kswenson/SWAP/charter.html ) is a project with much similarity to IPP. =20 It uses HTTP, but has special methods and encodes its parameters in XML. It is for workflow management, but it has a set of operations that are=20 rather similar to IPP (see below). The SWAP web page list you, Keith Moore,= =20 as one of the area directors. The following text comes from the SWAP charter: "The purpose of working group is to provide a simple HTTP based way to=20 invoke, monitor, control, and be informed about a generic asynchronous=20 service.=20 The protocol defines:=20 =B7 a standard way to invoke a generic service, which returns= an instance ID=20 Then, using the ID, the protocol defines how to=20 =B7 get the current status of that instance of the service,=20 =B7 give that instance of the service data values=20 =B7 pause or resume that instance of the service=20 =B7 retrieve preliminary results of that instance of the= service=20 =B7 register an address to receive event notifications from= the service=20 =B7 receive events from that instance of the service " What are your thoughts about SWAP? Are they going to be allowed to=20 use an http scheme?=20 Bob Herriot --=====================_793776380==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keith,

SWAP (http://people.netscape.com/kswenson/SWAP/charter.html<= /a> )
is a project with much similarity to IPP. 

It uses HTTP, but has special methods and encodes its parameters in XML.
It is for workflow management, but it has a set of operations that are
rather similar to IPP (see below).  The SWAP web page list you, Keith Moore,
as one of the area directors.

The following text comes from the SWAP charter:

   "The purpose of working group is to provide a simple HTTP based way to
   invoke, monitor, control, and be informed about a generic asynchronous
   service.

   The protocol defines:

        =B7=        a standard way to invoke a generic service, which returns an instance ID

   Then, using the ID, the protocol defines how to

        =B7=        get the current status of that instance of the service,
        =B7=        give that instance of the service data values
        =B7=        pause or resume that instance of the service
        =B7=        retrieve preliminary results of that instance of the service
        =B7=        register an address to receive event notifications from the service
        =B7=        receive events from that instance of the service "

What are your thoughts about SWAP?  Are they going to be allowed to
use an http scheme?

Bob Herriot
--=====================_793776380==_.ALT-- From ipp-owner@pwg.org Thu Jul 2 21:01:56 1998 Delivery-Date: Thu, 02 Jul 1998 21:01:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA12207 for ; Thu, 2 Jul 1998 21:01:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA23976 for ; Thu, 2 Jul 1998 21:04:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA15927 for ; Thu, 2 Jul 1998 21:01:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 20:57:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15327 for ipp-outgoing; Thu, 2 Jul 1998 20:55:54 -0400 (EDT) Message-Id: <199807030054.UAA13051@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Keith Moore , "Scott Isaacson" , paf@swip.net, paulmo@microsoft.com, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 17:19:21 PDT." <3.0.5.32.19980702171921.00c751e0@garfield> Date: Thu, 02 Jul 1998 20:54:22 -0400 Sender: owner-ipp@pwg.org > The more substantial reason was that we would make use of existing HTTP > code and implementations, that had already been debugged and demonstated to > work in a large scale, thereby expecting to shorten the time it would take > to develop and deploy IPP implementations. I was aware of this also, but had a hard time making the justification. It was obvious to me at the beginning that it would take less time to develop a simple protocol, or to model a new protocol on say SMTP, than to layer something on top of HTTP/1.1 with all of its warts. The implementation effort for the new protocol is nothing compared to the effort it takes to figure out what it means to layer something on top of HTTP. Still, I've never thought that IPP's use of HTTP (even with POST) was a really bad design choice; just that it was perhaps not the best. And the best is the enemy of the good, which is why I never pushed back more than to say "think carefully about this choice". Again, I don't think it's really the layering of IPP over HTTP that the IESG questions; rather, it's the odd use of the http URL. This may make sense to the IPP folks but looks really odd to IESG. (I suspect it won't make sense to users, either.) And when IESG starts to examine the assumptions behind the design choice, it starts to look even stranger. But a lot of this is beside the point - I really have no problem supporting the choice of HTTP as a substrate for IPP, and IESG isn't going to second-guess that choice. The issue is only the use of the http: prefix. It may be that IESG places a larger value on user friendliness than IPP does. And I don't see what it means to have a default port for the protocol if you have to type that port explicitly in the URL. (Another note: given the increasing prevalance of NAT boxes, IESG is increasingly suspicious of protocols that transmit IP addresses, or port numbers, as part of the protocol payload. Such protocols tend to fail in the presence of NATs. So if the IPP protocol has to return URLs that include port numbers, people get worried. It may be that this is not a problem - you probably have to set up a special tunnel through your NATs for IPP anyway - but the subject did come up in the IESG discussion and will probably be analyzed further.) > On your point that mostly printer vendors have participated in the work. > Who else then OS/NOS vendors supplying IPP clients, and printer and print > server vendors supplying IPP Printers, do you image would have a strong > interest to participate? Who else do you expect would actually implement > IPP? Linux folks perhaps - possibly! OS implementors in general, not just Linux folks. System and network administrators. People who had designed and/or implemented print spooler protocols in their own environments. It doesn't take large numbers of these people, just enough to provide an alternate perspective. Keith From ipp-owner@pwg.org Thu Jul 2 21:11:27 1998 Delivery-Date: Thu, 02 Jul 1998 21:11:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA12245 for ; Thu, 2 Jul 1998 21:11:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24012 for ; Thu, 2 Jul 1998 21:13:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA16609 for ; Thu, 2 Jul 1998 21:11:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 21:07:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16002 for ipp-outgoing; Thu, 2 Jul 1998 21:05:57 -0400 (EDT) Message-Id: <199807030105.VAA13098@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Herriot cc: Keith Moore , "Scott Isaacson" , paulmo@microsoft.com, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Thu, 02 Jul 1998 17:32:49 PDT." <199807030027.RAA06076@woden.eng.sun.com> Date: Thu, 02 Jul 1998 21:05:38 -0400 Sender: owner-ipp@pwg.org SWAP isn't yet a working group; they haven't even held a BOF. We plan to invite them to hold a BOF in Chicago. Their draft charter thus doesn't reflect any IETF direction. Because we haven't got to the point of charter review, we really haven't evaluated their proposal to see where it fits in the architecture. It would be premature for me to speculate about whether they should use http:. But SWAP aside, my feeling is that the only protocols that should use the http: scheme are those which operate on the same data sets as traditional HTTP. So WebDAV counts, as does probably DASL. Other uses of http:, like for instance iCalendar or EDI, are dubious. Keith From ipp-owner@pwg.org Thu Jul 2 21:41:46 1998 Delivery-Date: Thu, 02 Jul 1998 21:41:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA12329 for ; Thu, 2 Jul 1998 21:41:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24068 for ; Thu, 2 Jul 1998 21:44:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA17487 for ; Thu, 2 Jul 1998 21:41:41 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 21:37:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16879 for ipp-outgoing; Thu, 2 Jul 1998 21:34:20 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2D0AF@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Keith Moore'" , Robert Herriot Cc: Scott Isaacson , Paul Moore , ipp@pwg.org, "'lawrence@agranat.com'" Subject: RE: IPP> regarding "ipp:" (I spoke too soon...) Date: Thu, 2 Jul 1998 18:33:53 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org see below>>>> > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, July 02, 1998 6:06 PM > To: Robert Herriot > Cc: Keith Moore; Scott Isaacson; Paul Moore; ipp@pwg.org; > moore@cs.utk.edu > Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) > > But SWAP aside, my feeling is that the only protocols that should > use the http: scheme are those which operate on the same data > sets as traditional HTTP. So WebDAV counts, as does probably DASL. > Other uses of http:, like for instance iCalendar or EDI, are dubious. > I dont beleive that a new scheme is appropriate nor a new TCP port. I always thought that the scheme in the URL indicated which protocol you are actually speaking on the wire. IPP *is* speaking HTTP. It just has a different "service" than HTML, GIF, etc content or GET/HEAD semantics. How about if different services layered on HTTP are differentiated at a within the HTTP layer. Looking at IPP/SWAP/ or DAV from the TCP layer should make it appear to be HTTP. When examining the message at the HTTP layer, it should appear to be IPP/SWAP/DAV service. In an analogy, lets look at HTTP as being TCP and TCP being where IP is. (wait.. just give me a sec, I know this sounds wierd) So, TCP differentiates itself from another IP protocol such as UDP by using a different protocol number, right ? When a new service/protocol is built on top of TCP, do we expect the IP layer to understand it, or do we expect the TCP layer to understand differentiation? I beleive it is TCP. So, you wouldnt ask a new service built on top of TCP to allocate a new IP protocol number, would you ? To make IPP, which is a layer on top of HTTP to expose its differentiation at the TCP layer breaks the abstraction layer. TCP is, in a sense, delegating the differentiation to the HTTP layer, just like IP delegates to TCP to inspect port #s. Another analogy is RPC. If a firewall wants to filter all protocols on TCP ports, and it chooses to allow RPC, it must be all or nothing. To selectively filter RPC it must have an RPC proxy in the firewall. This is the scenario I beleive is common for HTTP. If you want to selectively allow certain HTTP messages of certain URL types, methods, or content-types, you must employ a proxy or device that can parse the HTTP layer. > Keith > From ipp-owner@pwg.org Fri Jul 3 14:47:40 1998 Delivery-Date: Fri, 03 Jul 1998 14:47:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28227 for ; Fri, 3 Jul 1998 14:47:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA25454 for ; Fri, 3 Jul 1998 14:49:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07588 for ; Fri, 3 Jul 1998 14:47:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 14:37:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06611 for ipp-outgoing; Fri, 3 Jul 1998 14:36:03 -0400 (EDT) Message-ID: <359D239A.1CE7D493@underscore.com> Date: Fri, 03 Jul 1998 14:31:54 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Moore CC: Carl-Uno Manros , Scott Isaacson , paf@swip.net, paulmo@microsoft.com, ipp@pwg.org Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) References: <199807030054.UAA13051@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Keith, > (Another note: given the increasing prevalance of NAT boxes, > IESG is increasingly suspicious of protocols that transmit > IP addresses, or port numbers, as part of the protocol payload. > Such protocols tend to fail in the presence of NATs. Sorry, but what is a "NAT box" ? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Jul 3 14:49:15 1998 Delivery-Date: Fri, 03 Jul 1998 14:49:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28232 for ; Fri, 3 Jul 1998 14:49:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA25463 for ; Fri, 3 Jul 1998 14:51:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA07876 for ; Fri, 3 Jul 1998 14:49:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 14:43:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06621 for ipp-outgoing; Fri, 3 Jul 1998 14:36:10 -0400 (EDT) Message-ID: <359D2493.AA6A13FD@underscore.com> Date: Fri, 03 Jul 1998 14:36:03 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> The impact on users for "ipp:" URL notation? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Keith Moore wrote on a related thread: > Again, I don't think it's really the layering of IPP over HTTP that > the IESG questions; rather, it's the odd use of the http URL. > This may make sense to the IPP folks but looks really odd to IESG. > (I suspect it won't make sense to users, either.) And when IESG > starts to examine the assumptions behind the design choice, it > starts to look even stranger. But a lot of this is beside the > point - I really have no problem supporting the choice of HTTP > as a substrate for IPP, and IESG isn't going to second-guess that > choice. The issue is only the use of the http: prefix. It may be > that IESG places a larger value on user friendliness than IPP does. User-friendliness is extrememly important to all of us. For this reason, I remain concerned about how an "ipp:" prefix really impacts a user. We have heard PWG people say things like: "You can put your IPP printer URL on your business card!" But what does this really mean? That is, how (and when and where) would a user enter an IPP printer URL? We have long come to admit that it won't be applicable to mainstream browsers (one of the top three reasons we wanted to use HTTP in the first place, since fallen by the wayside in terms of IPP benefits). >From what I can tell, IPP URLs are effectively hidden from end users; instead, the end user's local printing system will front-end any/all IPP interaction. Is this an accurate depiction? ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Fri Jul 3 15:11:38 1998 Delivery-Date: Fri, 03 Jul 1998 15:11:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28328 for ; Fri, 3 Jul 1998 15:11:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA25512 for ; Fri, 3 Jul 1998 15:13:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA08678 for ; Fri, 3 Jul 1998 15:11:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 15:07:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08031 for ipp-outgoing; Fri, 3 Jul 1998 14:58:43 -0400 (EDT) Message-Id: <199807031857.OAA18419@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jay Martin cc: Keith Moore , Carl-Uno Manros , Scott Isaacson , paf@swip.net, paulmo@microsoft.com, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) In-reply-to: Your message of "Fri, 03 Jul 1998 14:31:54 EDT." <359D239A.1CE7D493@underscore.com> Date: Fri, 03 Jul 1998 14:57:06 -0400 Sender: owner-ipp@pwg.org > Sorry, but what is a "NAT box" ? Network address translator. It's a kind of IP router that changes the source or destination address, or the source or destination port, as the packets pass through. A popular kind of NAT box is one that provides the illusion of Internet access to a private IP network, mapping one or more external IP addresses to a number of private IP addresses. Such boxes do not necessarily provide a one-to-one mapping between an internal IP address and the one that appears on the global Internet. So they sometimes change the port number, as well as the address, to avoid conflicts between multiple hosts using the same external address and the same port. And the mappings between external and internal addresses may be dynamically assigned and change from time to time. What this means is that a client or server's notion of the IP address or port used in the conversation, may not be the same as the server or client's view from the other end of the connection. Pure NAT boxes break a number of protocols that, for one reason or another, depend on the client and server sharing the same notion of endpoint identifiers. So real NAT boxes tend to perform not only IP-level translation, but serve as translating proxies for a number of higher level protocols. NATs thus share many characteristics as firewalls, and often these functions are combined in one box. But NAT boxes are more evil (from an application protocol designer's point-of-view) than firewalls that don't do NAT. Lots of us hate these things, but for a variety of reasons including scarcity of IP address space, and commodity pricing of dialup accounts limited to one IP address, they're widely deployed. Keith From ipp-owner@pwg.org Fri Jul 3 17:13:26 1998 Delivery-Date: Fri, 03 Jul 1998 17:13:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28809 for ; Fri, 3 Jul 1998 17:13:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25738 for ; Fri, 3 Jul 1998 17:15:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA10569 for ; Fri, 3 Jul 1998 17:13:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 17:07:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09897 for ipp-outgoing; Fri, 3 Jul 1998 17:04:06 -0400 (EDT) Message-Id: <3.0.5.32.19980703133722.0096c910@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 3 Jul 1998 13:37:22 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - what are the problems with the new IPP scheme proposal? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org To the IPP WG, Someone, please state what the problems that we found with this proposal and send them to the mailing list. I'm afraid that we've had good agreement amongst the IPP WG about not wanting to do the new scheme, but we haven't been very good at writing them down for others to understand and critique (and help us solve the problems we see). (Or did I miss a message?) Until we state clearly what the problems are, we aren't going to get our standard accepted by the IESG. Here is what Keith wrote to us in his review of IPP on 5/29 where he clearly stated that ipp was on the wire (in the example): At 13:29 05/29/1998 PDT, Keith Moore wrote: snip... >The biggest change that I think is needed, is that IPP's use >of HTTP doesn't allow a firewall to distinguish between IPP >traffic and ordinary HTTP traffic. Also, IPP's insistence on >using port 80 could conflict with ordinary use of that port, in >those cases where the IPP server was not designed to "plug in" to >the HTTP server. For these reasons, I suggest that a separate >port be allocated for IPP, and an "ipp" URL defined which defaults >to the IPP port rather than port 80. An alternative would be to >have IPP use the PRINT method rather than POST, but to me the >separate port seems cleaner and more likely to be compatible >with firewalls. One could still use IPP on port 80, by using >the port override notation: ipp://hostname:80/etc. Thanks, Tom This is the same proposal that Randy and Larry produced on June 16, 1998 and send to the IPP mailing list. I have only changed the port number from 374 to the one assigned to IPP as the IPP default port by IANA on June 22, namely, 631. - TNH This is a proposal for the registration of a new URL scheme "ipp". The syntax for the new IPP scheme would be identical to the existing "http" scheme except for the scheme name itself: ipp://host[:port]/ Associated with this new IPP scheme would be an IANA-assigned TCP port number, which would be the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. When an IPP client obtains an IPP URL, the interpretation of this URL by the client can take one of three forms, depending on the configuration and implementation of the client: ------------------------------------------------------ IPP Client Configured with no proxy server - ------------------------------------------------------ When an IPP client (no proxy configured) obtains an IPP-schemed URL such as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... ------------------------------------------------------ IPP Client Configured for Proxy Service - ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... It is likely that existing proxies will not understand IPP URLs, so the RequestURI should use the HTTP form of the URL. ------------------------------------------------------- IPP Clients with HTTP-only constraints ------------------------------------------------------- If a particular IPP client implementation uses a pre-packaged HTTP library or HTTP class that only supports HTTP-schemed URLs, then the following operation would be required: - The IPP client obtains the IPP-schemed URL and converts it to the following form: "http://myhost.com:631/myprinter/myqueue" The client then submits this URL to the pre-packaged HTTP library API. ------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers should accept "full" URLs as well, so IPP servers should also be able to accept requestURIs as specified in #2 and #3 as well. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) From ipp-owner@pwg.org Fri Jul 3 17:25:19 1998 Delivery-Date: Fri, 03 Jul 1998 17:25:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28844 for ; Fri, 3 Jul 1998 17:25:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25747 for ; Fri, 3 Jul 1998 17:27:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA11947 for ; Fri, 3 Jul 1998 17:25:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 17:16:25 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09901 for ipp-outgoing; Fri, 3 Jul 1998 17:04:09 -0400 (EDT) Message-Id: <3.0.5.32.19980703132617.0093ea50@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 3 Jul 1998 13:26:17 PDT To: Keith Moore From: Tom Hastings Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)[any problems with proposal?] Cc: ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807020446.AAA05817@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Keith, Here is the techical proposal to use a new IPP scheme that we discussed on the telecon. It does include the IPP scheme being on the wire in HTTP headers and in IPP requests and responses within the IPP MIME type. But it also allows the HTTP scheme in HTTP headers and in both directions in IPP requests and responses within the IPP MIME type. As stated in the proposal in order to work with existing proxies, the client would have to change the scheme from ipp to http. We assumed that that was ok, since the client would also introduce the default port number, 631, into the URL, so that the outbound gateway system administrator could restrict or allow traffic on port 631. See the example below. Same for clients working through existing HTTP-only libraries. Do you or the IESG have any technical problems with this complete proposal? It is a correct description of how a new IPP scheme would work with clients, proxies, and servers? There is no point in discussing problems with the new IPP scheme, if we don't all agree as to what a new IPP scheme really is. Thanks, Tom **************************************************************************** **** Proposal for an IPP scheme This is the same proposal that Randy and Larry produced on June 16, 1998 and send to the IPP mailing list. I have only changed the port number from 374 to the one assigned to IPP as the IPP default port by IANA on June 22, namely, 631. - TNH This is a proposal for the registration of a new URL scheme "ipp". The syntax for the new IPP scheme would be identical to the existing "http" scheme except for the scheme name itself: ipp://host[:port]/ Associated with this new IPP scheme would be an IANA-assigned TCP port number, which would be the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. When an IPP client obtains an IPP URL, the interpretation of this URL by the client can take one of three forms, depending on the configuration and implementation of the client: ------------------------------------------------------ IPP Client Configured with no proxy server - ------------------------------------------------------ When an IPP client (no proxy configured) obtains an IPP-schemed URL such as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... ------------------------------------------------------ IPP Client Configured for Proxy Service - ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... It is likely that existing proxies will not understand IPP URLs, so the RequestURI should use the HTTP form of the URL. ------------------------------------------------------- IPP Clients with HTTP-only constraints ------------------------------------------------------- If a particular IPP client implementation uses a pre-packaged HTTP library or HTTP class that only supports HTTP-schemed URLs, then the following operation would be required: - The IPP client obtains the IPP-schemed URL and converts it to the following form: "http://myhost.com:631/myprinter/myqueue" The client then submits this URL to the pre-packaged HTTP library API. ------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers should accept "full" URLs as well, so IPP servers should also be able to accept requestURIs as specified in #2 and #3 as well. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) End of Proposal for a new IPP scheme **************************************************************************** ******* At 21:46 7/1/98 PDT, Keith Moore wrote: >On a careful re-reading the list of resolutions for the IPP >documents, I was surprised to see that the WG had decided not >to adopt an "ipp:" URL prefix. (I was out of town last >week and unable to follow the list as closely as I would >have liked.) > >In my earlier poll of IESG there was strong agreement that both >a separate port and a new URL prefix were needed, though the >questions were not asked separately We're having a phone >conference on July 2 (today or tomorrow depending on your >current time zone), so I'll ask them again just to be sure. > >Other than the issue with interoperability with http proxies >(which are easily addressed), I'd like to know what the >technical problems were with using an "ipp:" prefix. I've >reviewed most of the list discussion since the teleconference >that I participated in, and didn't see any good explanation >of why this would cause problems. > >Keith > > From ipp-owner@pwg.org Fri Jul 3 17:27:02 1998 Delivery-Date: Fri, 03 Jul 1998 17:27:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28849 for ; Fri, 3 Jul 1998 17:27:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25750 for ; Fri, 3 Jul 1998 17:29:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA12235 for ; Fri, 3 Jul 1998 17:26:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 17:19:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10710 for ipp-outgoing; Fri, 3 Jul 1998 17:15:28 -0400 (EDT) Message-Id: <199807032113.RAA19184@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)[any problems with proposal?] In-reply-to: Your message of "Fri, 03 Jul 1998 13:26:17 PDT." <3.0.5.32.19980703132617.0093ea50@garfield> Date: Fri, 03 Jul 1998 17:13:57 -0400 Sender: owner-ipp@pwg.org Tom, The best thing to do at this point would be for me to run this proposal by the entire IESG when it is balloted. So I'll include it in the formal ballot that gets sent to IESG. Keith From ipp-owner@pwg.org Fri Jul 3 17:51:43 1998 Delivery-Date: Fri, 03 Jul 1998 17:51:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28936 for ; Fri, 3 Jul 1998 17:51:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25801 for ; Fri, 3 Jul 1998 17:54:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA13086 for ; Fri, 3 Jul 1998 17:51:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 17:47:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA12474 for ipp-outgoing; Fri, 3 Jul 1998 17:42:49 -0400 (EDT) Message-Id: <3.0.5.32.19980703144211.009725f0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 3 Jul 1998 14:42:11 PDT To: Keith Moore From: Tom Hastings Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)[any problems with proposal?] Cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807032113.RAA19184@spot.cs.utk.edu> 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: owner-ipp@pwg.org Keith, How long does an IESG ballot take? When would it be done? Isn't there some IESG expert that can bless this proposal now, so that we can discuss it and put it in our documents? I'm afraid that the WG is running out of patience with this prolonged process and I'm trying to see how we can work out a technical solution. Can't you forward the ipp scheme proposal to some experts for review now to see if it is acceptable and correct? Thanks, Tom At 14:13 07/03/98 PDT, Keith Moore wrote: >Tom, > >The best thing to do at this point would be for me to run this proposal >by the entire IESG when it is balloted. So I'll include it in the >formal ballot that gets sent to IESG. > >Keith > > From ipp-owner@pwg.org Fri Jul 3 19:28:17 1998 Delivery-Date: Fri, 03 Jul 1998 19:28:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA29233 for ; Fri, 3 Jul 1998 19:28:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA25882 for ; Fri, 3 Jul 1998 19:30:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA14929 for ; Fri, 3 Jul 1998 19:28:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 19:22:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA14308 for ipp-outgoing; Fri, 3 Jul 1998 19:19:58 -0400 (EDT) Message-Id: <199807032318.TAA21362@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)[any problems with proposal?] In-reply-to: Your message of "Fri, 03 Jul 1998 14:42:11 PDT." <3.0.5.32.19980703144211.009725f0@garfield> Date: Fri, 03 Jul 1998 19:18:33 -0400 Sender: owner-ipp@pwg.org > How long does an IESG ballot take? When would it be done? IESG normally meets every other Thursday. Our last meeting was yesterday. IPP should be formally discussed by IESG in either two or four weeks' time. (Normally it would just be two weeks, but these are long documents.) Up until this point, IESG has been waiting until I could recommend the documents to it; and until recently I was waiting for the revisions in response to my suggestions for changes. (IESG won't ballot the document unless/until the AD in charge of the working group recommends that it do so.) > Isn't there some IESG expert that can bless this proposal now, so that we can > discuss it and put it in our documents? > > I'm afraid that the WG is running out of patience with this prolonged > process and I'm trying to see how we can work out a technical solution. > Can't you forward the ipp scheme proposal to some experts for review > now to see if it is acceptable and correct? With all due respect, there's a shortage of patience on both sides, and the "other side" includes a number of IESG and IAB folks. *I'm* the expert. The rest of IESG would prefer to avoid reading the IPP documents; they'd far rather trust my judgement and vote "No Objection" But a strong objection from any IESG member can cause the process to take a lot longer. But my opinion is irrelevant, as is the opinion of other experts, if there's strong objection from other IESG members who have read the documents. I personally think the overall proposal to use ipp: is sound and reasonably detailed, but the solution to allow both ipp: and http: in IPP protocol elements is marginal. I'd like the proposal better if it said "clients and servers SHOULD use ipp: URLs in IPP protocol elements". The proposal would be stronger if it provided some justification for using http: in IPP protocol elements at all. It should also explain why using http: when talking to proxies isn't an attempt to subvert a site's firewall security policy. It probably needs to describe a common case where talking directly to the server's IPP port doesn't work, and the reason it doesn't work is something other than "access to the IPP port is turned off at the firewall". My opinion is irrelevant, as is the opinion of other experts, if there's strong objection from other IESG members to any use of http: in IPP protocol elements. It's not like this is the only problem with the documents. If past history is any guide, it's going to be an tough sell for me to talk the rest of IESG into letting IPP get away with "SHOULD implement" TLS, but I agreed that I would make that pitch. And I seem to recall (I don't have the document in front of me) that IPP refused to add the security considerations text regarding downloadable drivers - I'm not the only one on IESG who cares about such things. And it's always possible that IESG folks will find other things to object to. But at this point I think it's to the point that I can should it to IESG, let them comment on it and recommend changes, and have the IPP editors do at most one more pass. Assuming, of course, that IPP is willing to make the changes that IESG requests. The IPP group's work (at least on these documents) is 99% done. It mostly remains for me to sell the work to the IESG. But because this group has generated a fair amount of unfavorable attention from day one, it wouldn't surprise me if a number of IESG members paid particular attention to it. So the group should expect that there will be one more round of changes requested. Most of the changes that IESG requests are minor and they're usually editorial in nature. Keith From ipp-owner@pwg.org Fri Jul 3 19:46:31 1998 Delivery-Date: Fri, 03 Jul 1998 19:46:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA29319 for ; Fri, 3 Jul 1998 19:46:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA25917 for ; Fri, 3 Jul 1998 19:48:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA15681 for ; Fri, 3 Jul 1998 19:46:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 19:42:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15039 for ipp-outgoing; Fri, 3 Jul 1998 19:33:46 -0400 (EDT) Message-Id: <199807032333.TAA21425@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jay Martin cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: The impact on users for "ipp:" URL notation? In-reply-to: Your message of "Fri, 03 Jul 1998 14:36:03 EDT." <359D2493.AA6A13FD@underscore.com> Date: Fri, 03 Jul 1998 19:33:33 -0400 Sender: owner-ipp@pwg.org > We have heard PWG people say things like: > > "You can put your IPP printer URL on your business card!" > > But what does this really mean? That is, how (and when and where) > would a user enter an IPP printer URL? We have long come to > admit that it won't be applicable to mainstream browsers (one > of the top three reasons we wanted to use HTTP in the first > place, since fallen by the wayside in terms of IPP benefits). > > From what I can tell, IPP URLs are effectively hidden from > end users; instead, the end user's local printing system will > front-end any/all IPP interaction. > > Is this an accurate depiction? from UNIX, I'd expect to be able to do % setenv PRINTER ipp://spot.cs.utk.edu/slug % lpr filename.pdf (much like I do now) >From a GUI interface, I'd expect to be able to pull-down a File menu and select a Print option which would pop up a dialog box that gave me the option of entering an ipp: URL as an alternative to choosing one of the preconfigured printers. (similar to the option that lets me type in a network printer accessed by SMB) In an really nice world, the printer chooser would then talk to the printer and figure out what kind of driver it needed to print. If the driver were not already installed, the dialog box would then give me the option of either installing a driver from disk, downloading one from the net (hopefully with adequate authenticity/integrity protection), or using a generic driver to talk to the printer. (assuming my system already has a driver for common PDLs) Of course, the IPP group can't dictate OS vendors' user interfaces, but I see no reason why the IPP protocol cannot be used in this way. Keith From ipp-owner@pwg.org Fri Jul 3 20:06:30 1998 Delivery-Date: Fri, 03 Jul 1998 20:06:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA29374 for ; Fri, 3 Jul 1998 20:06:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA25929 for ; Fri, 3 Jul 1998 20:08:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA16465 for ; Fri, 3 Jul 1998 20:06:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 20:02:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15808 for ipp-outgoing; Fri, 3 Jul 1998 19:52:52 -0400 (EDT) Message-Id: <199807032351.TAA21523@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: IPP> clarification needed re: "ipp:" proposal In-reply-to: Your message of "Fri, 03 Jul 1998 13:26:17 PDT." <3.0.5.32.19980703132617.0093ea50@garfield> Date: Fri, 03 Jul 1998 19:51:26 -0400 Sender: owner-ipp@pwg.org On re-reading the proposal again, I realize that I might have misunderstood it. The proposal doesn't seem to say whether http: URLs are allowed in IPP protocol elements (as opposed to HTTP request headers when talking to a proxy.) On earlier readings I thought it had said that http: would be allowed. So it would help to have the proposal explicitly state whether ipp: URLs (SHOULD|MUST) be used in IPP protocol elements when referring to printer or job objects, and whether http: URLs (MAY|SHOULD NOT|MUST NOT) be used. And if http: URLs are going to be allowed at this level, please explain why they are needed or useful. thanks, Keith From ipp-owner@pwg.org Fri Jul 3 20:37:18 1998 Delivery-Date: Fri, 03 Jul 1998 20:37:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA29503 for ; Fri, 3 Jul 1998 20:37:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA25951 for ; Fri, 3 Jul 1998 20:39:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA17369 for ; Fri, 3 Jul 1998 20:37:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 20:32:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16747 for ipp-outgoing; Fri, 3 Jul 1998 20:30:50 -0400 (EDT) Message-ID: <359D77AE.7F583A51@underscore.com> Date: Fri, 03 Jul 1998 20:30:38 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Keith Moore CC: ipp@pwg.org Subject: IPP> Re: The impact on users for "ipp:" URL notation? References: <199807032333.TAA21425@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Keith, Thanks for the reply. Your vision sounds pretty good, assuming the non-Unix platform vendors provide that (new) capability in the future. Given that Microsoft is somewhat involved in the IPP process, then perhaps such capabilities will appear before the end of the millenium. (no joke) A quick aside, your Unix example is quite nice, I agree. However, those not familiar with Unix (and all the common variants) should understand that your example is actually not valid, at least from stock O/S vendors. Perhaps you were thinking of the capabilities provided by Patrick Powell's fine LPRng suite, which exposes network- attached printers using standard hostname conventions (rather than sysadmin-defined printer objects on the local platform). ...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 -- ---------------------------------------------------------------------- Keith Moore wrote: > > > We have heard PWG people say things like: > > > > "You can put your IPP printer URL on your business card!" > > > > But what does this really mean? That is, how (and when and where) > > would a user enter an IPP printer URL? We have long come to > > admit that it won't be applicable to mainstream browsers (one > > of the top three reasons we wanted to use HTTP in the first > > place, since fallen by the wayside in terms of IPP benefits). > > > > From what I can tell, IPP URLs are effectively hidden from > > end users; instead, the end user's local printing system will > > front-end any/all IPP interaction. > > > > Is this an accurate depiction? > > from UNIX, I'd expect to be able to do > > % setenv PRINTER ipp://spot.cs.utk.edu/slug > % lpr filename.pdf > > (much like I do now) > > >From a GUI interface, I'd expect to be able to pull-down a File menu > and select a Print option which would pop up a dialog box that gave > me the option of entering an ipp: URL as an alternative to choosing one of > the preconfigured printers. (similar to the option that lets me type > in a network printer accessed by SMB) > > In an really nice world, the printer chooser would then talk to the > printer and figure out what kind of driver it needed to print. > If the driver were not already installed, the dialog box would then > give me the option of either installing a driver from disk, downloading > one from the net (hopefully with adequate authenticity/integrity > protection), or using a generic driver to talk to the printer. > (assuming my system already has a driver for common PDLs) > > Of course, the IPP group can't dictate OS vendors' user interfaces, > but I see no reason why the IPP protocol cannot be used in this way. > > Keith From ipp-owner@pwg.org Fri Jul 3 20:57:09 1998 Delivery-Date: Fri, 03 Jul 1998 20:57:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA29571 for ; Fri, 3 Jul 1998 20:57:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA25981 for ; Fri, 3 Jul 1998 20:59:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA18151 for ; Fri, 3 Jul 1998 20:57:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 20:52:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA17545 for ipp-outgoing; Fri, 3 Jul 1998 20:50:29 -0400 (EDT) Message-Id: <199807040050.RAA27752@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 03 Jul 1998 17:45:23 -0700 To: Keith Moore , Tom Hastings From: Randy Turner Subject: Re: IPP> clarification needed re: "ipp:" proposal Cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807032351.TAA21523@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org What Larry and I worked on was a quick brief of what we thought were the major elements of the proposal. It was not an I-D. If sufficient interest exists in pursuing the proposal (by the WG, IESG, or anyone else), then we will definitely translate the brief into a draft. The I-D would outline the exact details, however just FYI, I believe either "ipp" or "http" schemes MAY be included, but this is dependent upon the means used to determine the URL in the first place. The administrator of such a service would publish which ever URL was appropriate for how his/her server is configured. Randy At 07:51 PM 7/3/98 -0400, Keith Moore wrote: >On re-reading the proposal again, I realize that I might have misunderstood >it. The proposal doesn't seem to say whether http: URLs are allowed in IPP >protocol elements (as opposed to HTTP request headers when talking to >a proxy.) On earlier readings I thought it had said that http: would be >allowed. > >So it would help to have the proposal explicitly state whether ipp: >URLs (SHOULD|MUST) be used in IPP protocol elements when referring to >printer or job objects, and whether http: URLs (MAY|SHOULD NOT|MUST NOT) >be used. And if http: URLs are going to be allowed at this level, >please explain why they are needed or useful. > >thanks, > >Keith > From ipp-owner@pwg.org Fri Jul 3 21:02:55 1998 Delivery-Date: Fri, 03 Jul 1998 21:02:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29611 for ; Fri, 3 Jul 1998 21:02:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA25990 for ; Fri, 3 Jul 1998 21:05:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA18806 for ; Fri, 3 Jul 1998 21:02:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 20:58:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA17481 for ipp-outgoing; Fri, 3 Jul 1998 20:44:51 -0400 (EDT) Date: Fri, 3 Jul 1998 17:55:48 -0700 (PDT) From: papowell@astart.com Message-Id: <199807040055.RAA10880@astart4.astart.com> To: manros@cp10.es.xerox.com, moore@cs.utk.edu Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) Cc: ipp@pwg.org, paf@swip.net, paulmo@microsoft.com, SISAACSON@novell.com Sender: owner-ipp@pwg.org When the first discussions about the URI/URL and related transport issues first came up, there were serious discussions and ranting arguments about the need to 'make as few changes in the HTTP protocol to allow printing from browsers', and why we could not change the URI/URL scheme. At the time I pointed out the problems with trying to alias the HTTP port/service to the IPP port/service and was roundly trashed for this ... umm... heretical suggestion. I would now like to comment that adding a new protocol/method such as ipp: is nothing major, and has been accommodated by most browser developers in a pretty trivial way. How and why do you ask? Look at Real Video and Real Audio. Try feeding 'npm://:/realaudiofile.ra' to your browser, and VOILA! it works. Sorta. Based on existing 'state of the art' and 'current technology', I find the argument of the difficulty of using ipp: in the URL rather hard to swallow, but did not want to rock the boat so close to closure on the standard. Note carefully that I did not say that it works CLEANLY, just that it works. Of course, somebody would have to write a program to assist the Internet Explorer (I gather that this is now a generic term for browser) to connect to and send the file to the server, but this is clearly akin to distributing a print driver for a printer... Something that most printer manufacturers seem to regard as part of the cost of doing business. Patrick Powell Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 619-874-6543 FAX 619-279-8424 LPRng - Print Spooler (http://www.astart.com) From ipp-owner@pwg.org Fri Jul 3 21:42:21 1998 Delivery-Date: Fri, 03 Jul 1998 21:42:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29715 for ; Fri, 3 Jul 1998 21:42:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA26047 for ; Fri, 3 Jul 1998 21:44:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA19801 for ; Fri, 3 Jul 1998 21:42:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 21:37:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19169 for ipp-outgoing; Fri, 3 Jul 1998 21:32:59 -0400 (EDT) Message-Id: <1.5.4.32.19980704012824.006819e0@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: Fri, 03 Jul 1998 18:28:24 -0700 To: moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> What is a Firewall? - Repeated contribution Cc: ipp@pwg.org Sender: owner-ipp@pwg.org Keith, As we still seem to be talking primarily about a firewall issue, or it least it was in your earlier comment paper (now it seems that is suddenly become a user issue), here is a reprint of a contribution from a from a few weeks ago, which I am not sure that you ever saw. The contribution was made to the IPP and HTTP DLs. FYI, the contribution was based on detailed discussions that I held with real life designers/developers of firewall software, who do this for a living. ------ I have been trying to figure out how we can get the discussion about how to distinguish IPP in firewalls a little more structured and not talk past each other. Let me try to sketch up a simple model of how I think firewalls work, and where the different proposals come in. NOTE, that there is no standard what-so-ever for firewalls, so whatever model you come up with will not fit every firewall implementation. If there was a firewall standard in the IETF, we would not have this discussion. I think a common feature of all firewalls is that they have a hierachy, which sometimes is shallow and sometimes is deep. Here is my try at describing the more important "layers". 1) Host address TCP/IP address 2) Port number Default 80 for HTTP 3) Protocol "http" for HTTP 4) Method POST etc. for HTTP 5) Content HTML etc. Filtering in the firewall can be done on any of these layers. Usually the firewall only let things through that it can identify and refuses the rest. Keith Moore suggests that we need to change both layer 2) and 3) above to give the firewall a chance to distinguish IPP from HTPP traffic. MS experts and a couple of others have suggested that the filtering takes place on layer 4), by allocating a new PRINT method for IPP and we do not need to touch layers 2) and 3). In discussions that I had with firewall experts last year, they indicated that they had no problem to filter on layer 5), e.g. distinguishing IPP from HTML etc. by identifying the content as an "application/ipp" MIME type. So what it all boils down to is how versatile the firewall implementation is. To make a concious decision about filtering in/out IPP from other HTTP traffic, any current firewall will need to be reconfigured or modified in same way. Looking at my hierachy, I suggest that if a firewall do all levels, there is NO need to modify anything in the current IPP specs. (Note: This referred to the earlier set of IPP drafts!) ---- Since I wrote this contribution, it has been pointed out that values in layers 2) and 3) are often linked when defaults are used, but non-default combinations are usually allowed. The latest IPP proposals now gives a firewall administrator the possibility to filter IPP traffic on 1), 2) and 5). Do REALLY think that it is necessary that filtering also has to be done on layer 3)? There might actually be people who want to allow IPP to come in fairly unrestricted e.g. sales organizations. Firewall people are generally very clever and very flexibel people; if not they are quickly out of business. I realize that they would probably never come to the IETF to develop a standard. Maybe you want to share this contribution with your fellow IESG members? Carl-Uno From ipp-owner@pwg.org Fri Jul 3 22:01:45 1998 Delivery-Date: Fri, 03 Jul 1998 22:01:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA29778 for ; Fri, 3 Jul 1998 22:01:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA26058 for ; Fri, 3 Jul 1998 22:04:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA20600 for ; Fri, 3 Jul 1998 22:01:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 21:57:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19924 for ipp-outgoing; Fri, 3 Jul 1998 21:51:01 -0400 (EDT) Message-Id: <199807040150.VAA21826@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jay Martin cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: The impact on users for "ipp:" URL notation? In-reply-to: Your message of "Fri, 03 Jul 1998 20:30:38 EDT." <359D77AE.7F583A51@underscore.com> Date: Fri, 03 Jul 1998 21:50:45 -0400 Sender: owner-ipp@pwg.org > A quick aside, your Unix example is quite nice, I agree. > However, those not familiar with Unix (and all the common > variants) should understand that your example is actually > not valid, at least from stock O/S vendors. > > Perhaps you were thinking of the capabilities provided by > Patrick Powell's fine LPRng suite, which exposes network- > attached printers using standard hostname conventions > (rather than sysadmin-defined printer objects on the local > platform). Actually, I was thinking about the lpr client that I wrote many years ago, that allows the user to specify host and printer name on the command-line. Sadly, most current UNIX print systems also require explicit configuration, even for a remote printer with a lpd interface. Keith From ipp-owner@pwg.org Fri Jul 3 22:11:52 1998 Delivery-Date: Fri, 03 Jul 1998 22:11:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA29802 for ; Fri, 3 Jul 1998 22:11:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA26063 for ; Fri, 3 Jul 1998 22:14:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA21289 for ; Fri, 3 Jul 1998 22:11:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 22:07:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA20561 for ipp-outgoing; Fri, 3 Jul 1998 22:01:29 -0400 (EDT) Message-Id: <199807040159.VAA21847@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Turner cc: Keith Moore , Tom Hastings , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> clarification needed re: "ipp:" proposal In-reply-to: Your message of "Fri, 03 Jul 1998 17:45:23 PDT." <199807040050.RAA27752@mail.pacifier.com> Date: Fri, 03 Jul 1998 21:59:54 -0400 Sender: owner-ipp@pwg.org > however just FYI, I believe either "ipp" or "http" schemes > MAY be included, but this is dependent upon the means used to determine the > URL in the first place. The administrator of such a service would publish > which ever URL was appropriate for how his/her server is configured. I don't understand. If you want to advertise a printer, you should use ipp: If you want to advertise a web server, you should use http: Seems like the two should have very different user interfaces, which is one of the reasons for exposing the ipp/http difference in the URL. For instance, if I click on an http link, I expect my browser or OS to display that file in a window or offer to save it locally. If I click on an ipp link, my browser or OS should pop up a window offering to print something to that printer, display the pending jobs in the queue, install a driver for that printer, tell me where the printer is and how much it costs to use it, etc. Or maybe I can drag some other object and drop it on the printer link, which causes it to be printed. etc. Or I drag the printer link to my desktop, which causes an interface to that printer to be installed on my system. Whatever. The point is that just by looking at an ipp: URL, a browser or OS or a human being can tell that it's a printer, and make use of that information without actually having to talk to the thing. Keith From ipp-owner@pwg.org Fri Jul 3 22:31:42 1998 Delivery-Date: Fri, 03 Jul 1998 22:31:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA01497 for ; Fri, 3 Jul 1998 22:31:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA26071 for ; Fri, 3 Jul 1998 22:34:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA22079 for ; Fri, 3 Jul 1998 22:31:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 22:27:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA21419 for ipp-outgoing; Fri, 3 Jul 1998 22:17:31 -0400 (EDT) Message-Id: <199807040217.WAA21909@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: What is a Firewall? - Repeated contribution In-reply-to: Your message of "Fri, 03 Jul 1998 18:28:24 PDT." <1.5.4.32.19980704012824.006819e0@pop3.holonet.net> Date: Fri, 03 Jul 1998 22:17:15 -0400 Sender: owner-ipp@pwg.org > Keith, > > As we still seem to be talking primarily about a firewall issue, or it least > it was in your earlier comment paper (now it seems that is suddenly become > a user issue), here is a reprint of a contribution from a from a few weeks > ago, which I am not sure that you ever saw. Yes, I saw it soon after you first posted it. The reason for using ipp: instead of http: is not to allow firewall filtering. Rather, it's implied by the use of a separate port for ipp, and the firewall argument is one of several reasons for a separate port. (There's also a lot of utility to be gained by using ipp:) As for the ability to filter on content, rather than port. Yes, firewalls do this. And many of them do it poorly. The higher on the stack that you try to do the filtering, the more complex the filter is, which increases the potential for errors or corruption of the data. It's also more difficult to configure the firewall to do the right thing. The last thing IESG and IAB want to do is to encourage more filtering at higher levels by failing to provide a way to distinguish at lower levels. Port numbers work just as well, are a lot simpler to get right, and we have 18 or so years experience with them. (more, if you count the experience with NCP that predated TCP) I have no doubt whatsoever that firewall vendors believe their products - no matter how complex they are - are the best things since sliced bread. But as a user I've fought too many battles with broken firewalls from major vendors, to have confidence in anything but the simplest ones. It's not that port blocking provides any security in a strong sense, but it does narrow down the number of vulnerabilities that you have to analyze. And while content-filtering could potentially work better, you end up buying a lot of complexity for marginal gain. > Maybe you want to share this contribution with your fellow IESG members? Tell you what. If you seriously want to argue to IESG that http: is the way to go, and if you're willing to incur the extra delay that will inevitably result, along with an extremely low chance of success, AND if you can get the backing of the working group to take this approach... then go right ahead. Set up a web page with your argument as to why things should be this way, and I'll pass it along to IESG. Or just send it to iesg@ietf.org. Keith From ipp-owner@pwg.org Fri Jul 3 23:38:06 1998 Delivery-Date: Fri, 03 Jul 1998 23:38:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA07544 for ; Fri, 3 Jul 1998 23:38:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA26142 for ; Fri, 3 Jul 1998 23:40:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA23290 for ; Fri, 3 Jul 1998 23:38:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 23:32:39 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA22661 for ipp-outgoing; Fri, 3 Jul 1998 23:28:51 -0400 (EDT) Message-Id: <199807040330.UAA12233@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 03 Jul 1998 20:25:06 -0700 To: Keith Moore From: Randy Turner Subject: Re: IPP> clarification needed re: "ipp:" proposal Cc: ipp@pwg.org In-Reply-To: <199807040159.VAA21847@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org On reflection, I should worded my last statement as "clients SHOULD use ipp schemes, but MAY use http schemes to contact servers. Servers MUST support connections using either http or ipp schemes. Like I said earlier, I think this will all work, but a detailed I-D will be more complete with examples and such. On a different tack, I was hoping we could just get away with using different methods for IPP, but I was soundly voted down in a past conference call. If the IESG requirement covers more than just being able to distinguish IPP traffic from HTTP traffic, then I think a separate scheme is the way to go. I'm still re-reading your (Keith) last few messages to see if I can extract the exact issue(s) the IESG is concerned with. I'm hitting the road tomorrow for our meeting so I hope to have a handle on this by Monday. Randy At 09:59 PM 7/3/98 -0400, Keith Moore wrote: >> however just FYI, I believe either "ipp" or "http" schemes >> MAY be included, but this is dependent upon the means used to determine the >> URL in the first place. The administrator of such a service would publish >> which ever URL was appropriate for how his/her server is configured. > >I don't understand. If you want to advertise a printer, you should use ipp: >If you want to advertise a web server, you should use http: > >Seems like the two should have very different user interfaces, which is >one of the reasons for exposing the ipp/http difference in the URL. > >For instance, if I click on an http link, I expect my browser or OS >to display that file in a window or offer to save it locally. > >If I click on an ipp link, my browser or OS should pop up >a window offering to print something to that printer, display >the pending jobs in the queue, install a driver for that printer, >tell me where the printer is and how much it costs to use it, etc. >Or maybe I can drag some other object and drop it on the >printer link, which causes it to be printed. etc. >Or I drag the printer link to my desktop, which causes an interface >to that printer to be installed on my system. Whatever. The >point is that just by looking at an ipp: URL, a browser or OS or >a human being can tell that it's a printer, and make use of that >information without actually having to talk to the thing. > >Keith > From ipp-owner@pwg.org Sat Jul 4 04:24:31 1998 Delivery-Date: Sat, 04 Jul 1998 04:24:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA13395 for ; Sat, 4 Jul 1998 04:24:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA26394 for ; Sat, 4 Jul 1998 04:26:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA29991 for ; Sat, 4 Jul 1998 04:24:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 4 Jul 1998 04:17:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA29142 for ipp-outgoing; Sat, 4 Jul 1998 04:14:11 -0400 (EDT) Message-Id: <3.0.5.32.19980704011315.00a18c90@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 4 Jul 1998 01:13:15 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> NOT - Updated short notification papers - uploaded Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I've updated the two short notification papers that we reviewed at the Washington meeting and posted them: "IPP Event Notification (Very Short)", version 0.3: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701-re v.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701-re v.pdf "Job-Independent Subscriptions for IPP", version 0.3: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701-rev.pdf I'll bring copies with me to the Monterey meeting next week. They are still short: 12 pages and 5 pages. Summary of Changes ------------------ For "IPP Event Notification (Very Short)", version 0.3 (12 pages): 1. In Washington, we agreed to get rid of collections all together, and pass: notify-event-groups (1setOf type2 keyword) notity-recipients (1setOf uri) as individual subscription operation attributes in a create job operation. These are not parallel attributes. All event group apply to all recipients, except: 2. Fix the events for the mailto: delivery method to just job-completion (completed, aborted, canceled). Then other delivery methods can be used with mailto and specify event groups for those other delivery methods. Then the event groups only apply to the other delivery methods. This ad hoc handling of mailto: allows us to get rid of using the collection attribute syntax while allows a job to have multiple notification recipients, some with mailto: and some not. All the others will be subscribed to the same event groups. [If this approach isn't satifactory, we could further simplify the very short specification use of 'collection' and have each member attribute only be single values, not multi-valued. If more than one event group is needed, then supply another collection value. The "subscriptions" attribute would be a multi-valued collection where each collection value is: notify-event-groups (type2 keyword) notify-recipients (uri) ] 4. Also we did agree in Washington to add 'ipp-udp-datagram' that didn't have acknowledgement, because the 'sense-datagram' did. 5. We agreed to make the 'ipp-tcp-socket' and 'ipp-udp-datagram' delivery methods REQUIRED for IPP Printer objects conforming to the notification specification. 5. I also changed the word printer to device when it did not relate to the IPP Printer object, so that we can use this for other types of devices that the IPP Printer object might control, such as scanners and fax devices. This is in alignment with the MIB access paper. Ok? If you disagree, I'll change it back. 6. I added the fixed table of job and printer attributes to be included in the notirfication content for job and device events and listed as an issue whether there was agreement on these or not. 7. I removed half of the issues at the end and added one. All issues are highlighted. Here they are: ISSUE 1: Now that "notify-event-groups" and "notify-recipients" are separately specified, we need to say what happens when each is specified without the other. We could say that the "notify-event-groups" defaults to 'job-completion', but only if "notify-recipients" is supplied. If "notify-event-groups" is supplied without "notify-recipients", then the IPP Printer object rejects the create operation and returns the 'client-error-bad-syntax' status code. Ok? ISSUE 2: Do we agree to the fixed attributes that come back in notification content in Table 1 and Table 2? ISSUE 3: Do we agree that these are REQUIRED for an IPP Printer to support? Issues at the end of the document: 1. Do we want a Mixed Format for event reports? If so we can add 'multi-part/alternative' back in as a supported format. 2. Do we want to allow the client to specify the format of the event report independent of the delivery method? If so, we can add "notify-content-type" back into the "subscriptions" attribute. 3. Do we want to extended the list of uriScheme values defined for standard delivery methods to include: 'ftp', 'pager', 'http', etc.? If so, they are easy to add. Should we add them now? Or register them later? 4. Should we make "subscriptions" also be a Job Description attribute, so that a user can query to determine what subscriptions were supplied (and help an implementation remember job submission subscriptions on the job object - useful whether the implementation is using a notification service or not), as we have done for attributes-charset and attributes-natural-language operation attributes? For "Job-Independent Subscriptions for IPP", version 0.3 (5 pages): I also updated the second short paper, "Job Independent Subscriptions for IPP" based on the agreements reached in Washington: 1. Added a third operation: Renew-Subscription. 2. Added a third operation attribute for use with SubScribe only: "notify-lease-time (integer(0:MAX)) - time to live in minutes before subscription is automatically canceled. 3. Added 'client-error-not-found' status code is returned if the subscription id is not found (or has expired). 4. Added 'server-error-temporary-error' status code is returned if the Printer or subscription service is full or cannot otherwise accept the subscription due to a condition that is likely to go away soon enough that the client should try again shortly. The following issues need to be addressed: 1. If the IPP Printer is forwarding Subscribe operations to a notification service which rejects the subscription, is there any way the IPP Printer can return that implementation specific error condition back to the client? Or is it better for the IPP Printer to map the error codes to standard IPP error status codes for interoperability? 2. Should we allow for an "Unsubscribe ALL" feature in some operation? 3. Should we define subscription service events? Such as: "subscription-about- to-expire", "subscription-expired", "are-you-alive" notification events as an additional event group, say 'subscription-events'? The notification recipient would have to know to issue the Renew-Subscription operation, (not the original client). The 'subscription-events' event group would be one that is available with the Subscribe operation, but not create operations, correct? I'll bring copies of these documents with and without revision marks. They are short and we've seen them at previous meeting. Tom From ipp-owner@pwg.org Sat Jul 4 05:07:27 1998 Delivery-Date: Sat, 04 Jul 1998 05:07:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA13531 for ; Sat, 4 Jul 1998 05:07:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA26429 for ; Sat, 4 Jul 1998 05:09:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA01867 for ; Sat, 4 Jul 1998 05:07:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 4 Jul 1998 05:03:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA01085 for ipp-outgoing; Sat, 4 Jul 1998 05:00:08 -0400 (EDT) Message-Id: <3.0.5.32.19980704015924.009702e0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 4 Jul 1998 01:59:24 PDT To: Keith Moore From: Tom Hastings Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)[any problems with proposal?] Cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807032318.TAA21362@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 16:18 07/03/98 PDT, Keith Moore wrote: snip... >> Isn't there some IESG expert that can bless this proposal now, so that we can >> discuss it and put it in our documents? snip... >*I'm* the expert. The rest of IESG would prefer to avoid reading the >IPP documents; they'd far rather trust my judgement and vote "No Objection" >But a strong objection from any IESG member can cause the process to >take a lot longer. But my opinion is irrelevant, as is the opinion of >other experts, if there's strong objection from other IESG members >who have read the documents. Good! Then its very important that you review the detailed proposal that the IPP has been considering to satify your requirements for a new IPP scheme (but has so far rejected). It sounds like you like parts of it, but have some concerns too. I would think that the proper steps BEFORE taking IPP to the IESG would be: 1) you finish giving us your feed back on our detailed proposal to use an IPP scheme (that Randy Turner and Larry Masinter wrote up), including conformance wording, etc. 2) we update that proposal and make sure you agree with it. 3) then the IPP WG reviews whether they support the proposal or not and writes down the problems that they have for your review. We have an IPP meeting this Wednesday/Thursday, July 8/9, in Monterey. It would be nice if we could finish steps 1-3 by the end of that meeting. Can you participate with us if we setup a phone conference? Question: should this usage of the IPP scheme be a separate document or part of the "Encoding and Transport" (was called Protocol) document? Thanks, Tom > >I personally think the overall proposal to use ipp: is sound and >reasonably detailed, but the solution to allow both ipp: and http: >in IPP protocol elements is marginal. I'd like the proposal better >if it said "clients and servers SHOULD use ipp: URLs in IPP protocol >elements". > >The proposal would be stronger if it provided some justification for >using http: in IPP protocol elements at all. It should also >explain why using http: when talking to proxies isn't an attempt >to subvert a site's firewall security policy. It probably needs >to describe a common case where talking directly to the server's >IPP port doesn't work, and the reason it doesn't work is something >other than "access to the IPP port is turned off at the firewall". snip... >But at this point I think it's to the point that I can should it to >IESG, let them comment on it and recommend changes, and have the >IPP editors do at most one more pass. Assuming, of course, that >IPP is willing to make the changes that IESG requests. snip... >Keith > > From ipp-owner@pwg.org Sat Jul 4 07:10:02 1998 Delivery-Date: Sat, 04 Jul 1998 07:10:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA14111 for ; Sat, 4 Jul 1998 07:10:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA26537 for ; Sat, 4 Jul 1998 07:12:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA08375 for ; Sat, 4 Jul 1998 07:09:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 4 Jul 1998 06:57:59 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id GAA07026 for ipp-outgoing; Sat, 4 Jul 1998 06:55:38 -0400 (EDT) Message-Id: <199807041055.GAA25841@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Turner cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> clarification needed re: "ipp:" proposal In-reply-to: Your message of "Fri, 03 Jul 1998 20:25:06 PDT." <199807040330.UAA12233@mail.pacifier.com> Date: Sat, 04 Jul 1998 06:55:26 -0400 Sender: owner-ipp@pwg.org > On reflection, I should worded my last statement as "clients SHOULD use ipp > schemes, but MAY use http schemes to contact servers. Servers MUST support > connections using either http or ipp schemes. Okay. If we're talking about URLs that go in HTTP request and response headers, I'd agree with that. The big question I have is the URLs that go in IPP protocol elements. I think they SHOULD (perhaps MUST) be ipp:. More to the point, regardless of what is done on the wire, I think the user should always use and see ipp: URLs when referring to a printer. Keith > Like I said earlier, I think this will all work, but a detailed I-D will be > more complete with examples and such. > > On a different tack, I was hoping we could just get away with using > different methods for IPP, but I was soundly voted down in a past > conference call. If the IESG requirement covers more than just being able > to distinguish IPP traffic from HTTP traffic, then I think a separate > scheme is the way to go. I'm still re-reading your (Keith) last few > messages to see if I can extract the exact issue(s) the IESG is concerned > with. I'm hitting the road tomorrow for our meeting so I hope to have a > handle on this by Monday. From ipp-owner@pwg.org Mon Jul 6 11:13:09 1998 Delivery-Date: Mon, 06 Jul 1998 11:13:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA24768 for ; Mon, 6 Jul 1998 11:13:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03066 for ; Mon, 6 Jul 1998 11:15:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24833 for ; Mon, 6 Jul 1998 11:13:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 11:08:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA24254 for ipp-outgoing; Mon, 6 Jul 1998 11:02:16 -0400 (EDT) Message-Id: <3.0.5.32.19980706080149.009c36a0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 08:01:49 PDT To: Jay Martin , ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> The impact on users for "ipp:" URL notation? In-Reply-To: <359D2493.AA6A13FD@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 11:36 AM 7/3/98 PDT, Jay Martin wrote: >User-friendliness is extrememly important to all of us. >For this reason, I remain concerned about how an "ipp:" >prefix really impacts a user. > >We have heard PWG people say things like: > > "You can put your IPP printer URL on your business card!" > >But what does this really mean? That is, how (and when and where) >would a user enter an IPP printer URL? Jay, I was probably the one who brought this up. About the where, I think the primary place would be to insert it in a printing dialogue window dedicated to IPP printing. Based on more recent discussions in the WG, I do not see a major difference whether I write: PRINTER: ipp://www.manros.com/ipp-printer or PRINTER: http://www.manros.com/ipp-printer the same way as you use telephone numbers for both TEL: and FAX: on you cards today. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jul 6 11:18:15 1998 Delivery-Date: Mon, 06 Jul 1998 11:18:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA24824 for ; Mon, 6 Jul 1998 11:18:15 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03103 for ; Mon, 6 Jul 1998 11:20:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25445 for ; Mon, 6 Jul 1998 11:18:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 11:14:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA24630 for ipp-outgoing; Mon, 6 Jul 1998 11:11:05 -0400 (EDT) Date: Mon, 6 Jul 1998 07:58:16 -0700 (Pacific Daylight Time) From: Ron Bergman To: ipp@pwg.org, Josh Cohen cc: moore@cs.utk.edu Subject: RE: IPP> regarding "ipp:" (I spoke too soon...) In-Reply-To: <8B57882C41A0D1118F7100805F9F68B502D2D0AF@red-msg-45.dns.microsoft.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipp@pwg.org Josh did an excellent job of expressing my concern regarding Keith Moore's and the IETF's position on a new scheme for ipp. It appears that the IETF prefers to "munge" HTTP and it's data content into one layer. Then why is a "content-type" field needed? An why just selectively apply this rule? I have read the many emails over the last several months, and I have seriously tried to understand the IETF's position. But some how I still do not get it. Why is HTTP not HTTP when the content-type is IPP? Ron Bergman Dataproducts Corp. On Thu, 2 Jul 1998, Josh Cohen wrote: > see below>>>> > > -----Original Message----- > > From: Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Thursday, July 02, 1998 6:06 PM > > To: Robert Herriot > > Cc: Keith Moore; Scott Isaacson; Paul Moore; ipp@pwg.org; > > moore@cs.utk.edu > > Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) > > > > But SWAP aside, my feeling is that the only protocols that should > > use the http: scheme are those which operate on the same data > > sets as traditional HTTP. So WebDAV counts, as does probably DASL. > > Other uses of http:, like for instance iCalendar or EDI, are dubious. > > > > I dont beleive that a new scheme is appropriate nor a new TCP port. > > I always thought that the scheme in the URL indicated which protocol > you are actually speaking on the wire. IPP *is* speaking HTTP. > It just has a different "service" than HTML, GIF, etc content > or GET/HEAD semantics. > > How about if different services layered on HTTP are differentiated > at a within the HTTP layer. Looking at IPP/SWAP/ or DAV from the > TCP layer should make it appear to be HTTP. > When examining the message at the HTTP layer, it should appear > to be IPP/SWAP/DAV service. > > In an analogy, lets look at HTTP as being TCP and TCP being where IP is. > (wait.. just give me a sec, I know this sounds wierd) > So, TCP differentiates itself from another IP protocol such as > UDP by using a different protocol number, right ? > When a new service/protocol is built on top of TCP, do > we expect the IP layer to understand it, or do we expect the TCP > layer to understand differentiation? I beleive it is > TCP. > > So, you wouldnt ask a new service built on top of TCP > to allocate a new IP protocol number, would you ? > > To make IPP, which is a layer on top of HTTP to expose > its differentiation at the TCP layer breaks the abstraction > layer. TCP is, in a sense, delegating the differentiation to the > HTTP layer, just like IP delegates to TCP to inspect port #s. > > Another analogy is RPC. If a firewall wants to filter all > protocols on TCP ports, and it chooses to allow RPC, it must > be all or nothing. To selectively filter RPC it must have > an RPC proxy in the firewall. > > This is the scenario I beleive is common for HTTP. If you > want to selectively allow certain HTTP messages of certain > URL types, methods, or content-types, you must employ a proxy > or device that can parse the HTTP layer. > > > Keith > > > From ipp-owner@pwg.org Mon Jul 6 11:54:11 1998 Delivery-Date: Mon, 06 Jul 1998 11:54:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25092 for ; Mon, 6 Jul 1998 11:54:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03465 for ; Mon, 6 Jul 1998 11:56:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26210 for ; Mon, 6 Jul 1998 11:54:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 11:48:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25561 for ipp-outgoing; Mon, 6 Jul 1998 11:42:45 -0400 (EDT) From: "Larry Masinter" To: "Carl-Uno Manros" , "Jay Martin" , Subject: RE: IPP> The impact on users for "ipp:" URL notation? Date: Mon, 6 Jul 1998 08:42:11 PDT Message-ID: <000001bda8f4$a4202aa0$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.19980706080149.009c36a0@garfield> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org > Based on more recent discussions in the WG, I do not see a major difference > whether I write: > > PRINTER: ipp://www.manros.com/ipp-printer > > or > > PRINTER: http://www.manros.com/ipp-printer > > the same way as you use telephone numbers for both TEL: and FAX: on you > cards today. The former would imply the IPP port, while the latter would imply port 80. The port used is a major difference. Larry -- http://www.parc.xerox.com/masinter <--- NOT MY PRINTER From ipp-owner@pwg.org Mon Jul 6 12:02:12 1998 Delivery-Date: Mon, 06 Jul 1998 12:02:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA25165 for ; Mon, 6 Jul 1998 12:02:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03586 for ; Mon, 6 Jul 1998 12:04:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27009 for ; Mon, 6 Jul 1998 12:02:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 11:58:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26157 for ipp-outgoing; Mon, 6 Jul 1998 11:53:46 -0400 (EDT) Message-Id: <3.0.5.32.19980706085316.00b062d0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 08:53:16 PDT To: "Larry Masinter" , "Jay Martin" , From: Carl-Uno Manros Subject: RE: IPP> The impact on users for "ipp:" URL notation? In-Reply-To: <000001bda8f4$a4202aa0$15d0000d@copper-208.parc.xerox.com> References: <3.0.5.32.19980706080149.009c36a0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 08:42 AM 7/6/98 PDT, Larry Masinter wrote: >> Based on more recent discussions in the WG, I do not see a major difference >> whether I write: >> >> PRINTER: ipp://www.manros.com/ipp-printer >> >> or >> >> PRINTER: http://www.manros.com/ipp-printer >> >> the same way as you use telephone numbers for both TEL: and FAX: on you >> cards today. > >The former would imply the IPP port, while the latter would imply >port 80. > >The port used is a major difference. > >Larry >-- >http://www.parc.xerox.com/masinter <--- NOT MY PRINTER > Larry, You are right the examples should have been: PRINTER: ipp://www.manros.com/ipp-printer or PRINTER: http://www.manros.com:631/ipp-printer but I still do not think that the difference is that big. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jul 6 13:58:49 1998 Delivery-Date: Mon, 06 Jul 1998 13:58:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26251 for ; Mon, 6 Jul 1998 13:58:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04375 for ; Mon, 6 Jul 1998 14:01:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27919 for ; Mon, 6 Jul 1998 13:58:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 13:53:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27336 for ipp-outgoing; Mon, 6 Jul 1998 13:47:54 -0400 (EDT) Message-ID: From: Paul Moore To: "'Keith Moore'" , Randy Turner Cc: Tom Hastings , ipp@pwg.org Subject: RE: IPP> clarification needed re: "ipp:" proposal Date: Mon, 6 Jul 1998 10:47:39 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org If I click on an ipp link, my browser or OS should pop up a window offering to print something to that printer, display the pending jobs in the queue, install a driver for that printer, tell me where the printer is and how much it costs to use it, etc. Or maybe I can drag some other object and drop it on the printer link, which causes it to be printed. etc. Or I drag the printer link to my desktop, which causes an interface to that printer to be installed on my system. Whatever. The point is that just by looking at an ipp: URL, a browser or OS or a human being can tell that it's a printer, and make use of that information without actually having to talk to the thing. This has nothing to do with the IPP protocol - these are suggestions as to what the users experience should be. There are a million and one web links that when you click on them do things on the client side. I suspect that a lot of OS vendors are going to do exactly what you describe. A printer URL will be HTTP://xxxx/printerA (or whatever). This bears no relationship whatsoever to the URL used by IPP for pumping print over the network - I doubt that a user will ever see that URL (in a lot of cases it wont be http://www.acme.com/myprinter (or IPP: or HTTP:....:370). It will be something like http://www.acme.com/scripts/IPP/submit.pl?pr=myprinter or some equally memorable string. > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: Friday, July 03, 1998 7:00 PM > To: Randy Turner > Cc: Keith Moore; Tom Hastings; ipp@pwg.org; moore@cs.utk.edu > Subject: Re: IPP> clarification needed re: "ipp:" proposal > > > however just FYI, I believe either "ipp" or "http" schemes > > MAY be included, but this is dependent upon the means used to determine > the > > URL in the first place. The administrator of such a service would > publish > > which ever URL was appropriate for how his/her server is configured. > > I don't understand. If you want to advertise a printer, you should use > ipp: > If you want to advertise a web server, you should use http: > > Seems like the two should have very different user interfaces, which is > one of the reasons for exposing the ipp/http difference in the URL. > > For instance, if I click on an http link, I expect my browser or OS > to display that file in a window or offer to save it locally. > > If I click on an ipp link, my browser or OS should pop up > a window offering to print something to that printer, display > the pending jobs in the queue, install a driver for that printer, > tell me where the printer is and how much it costs to use it, etc. > Or maybe I can drag some other object and drop it on the > printer link, which causes it to be printed. etc. > Or I drag the printer link to my desktop, which causes an interface > to that printer to be installed on my system. Whatever. The > point is that just by looking at an ipp: URL, a browser or OS or > a human being can tell that it's a printer, and make use of that > information without actually having to talk to the thing. > > Keith From ipp-owner@pwg.org Mon Jul 6 15:08:36 1998 Delivery-Date: Mon, 06 Jul 1998 15:08:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA27823 for ; Mon, 6 Jul 1998 15:08:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04746 for ; Mon, 6 Jul 1998 15:10:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA29435 for ; Mon, 6 Jul 1998 15:08:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 15:03:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28863 for ipp-outgoing; Mon, 6 Jul 1998 15:01:37 -0400 (EDT) From: don@lexmark.com Message-Id: <199807061901.AA04631@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Mon, 6 Jul 1998 14:24:39 -0400 Subject: IPP> IPP and the IESG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Three points on this issue: #1. I think Ron Bergman said it best when he said: "Why is HTTP not HTTP when the content-type is IPP?" #2. Keith Moore is wrong when he said: "Obviously, HTTP is a general purpose file transfer protocol. But printing is not the same as file transfer." Why is printing not just another case of file transfer? We already have many ways of doing file transfers: - ftp - tftp - smtp - http - etc. Perhaps the IPP group was a little smarter than so many of these other groups that had perhaps an NIH attitude and created yet another file transfer protocol. Rather than clog the net with another protocol that must be dealt with, we used an existing protocol and simply tagged our content appropriately (application/IPP.) Many printers today use TFTP or FTP to accept print jobs. Given some setup (which all file transfer protocols do at least to some extent), printing is really just another case of file transfer, i.e. I have a file and I want to send it to device "P". In the print case, the file is "transferred to paper" while in the Web case, the file is "transferred to the screen" and in the FTP case, the file is usually "transferred to disk." What is done with the content is irrelevant to the discussion, but it is still a file transfer. #3. Firewalls are not the issue, network infrastructure is. One of the major reasons we chose HTTP as the transport for application/ipp was the existing network infrastructure. I'll agree that firewalls are a part of that infrastructure, so are proxies, caches, etc. By transporting application/ipp on HTTP, we can take advantage of that infrastructure to speed the roll-out of IPP. Given that the vast majority of firewalls can filter on port(631) and/or content type (application/IPP), I content we are not try to "punch through" firewalls. If we were trying to do that, we would need to use port 80 and application/text or something else that couldn't be distinguished from normal web content. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Jul 6 15:22:58 1998 Delivery-Date: Mon, 06 Jul 1998 15:22:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28090 for ; Mon, 6 Jul 1998 15:22:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04817 for ; Mon, 6 Jul 1998 15:25:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00105 for ; Mon, 6 Jul 1998 15:22:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 15:17:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29501 for ipp-outgoing; Mon, 6 Jul 1998 15:10:06 -0400 (EDT) Message-Id: <3.0.5.32.19980706120948.013ec390@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 12:09:48 PDT To: Keith Moore From: Tom Hastings Subject: IPP> On clarifying the proposal for a new IPP scheme Cc: ipp@pwg.org In-Reply-To: <199807032113.RAA19184@spot.cs.utk.edu> 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: owner-ipp@pwg.org At 14:13 07/03/98 PDT, Keith Moore wrote: >Tom, > >The best thing to do at this point would be for me to run this proposal >by the entire IESG when it is balloted. So I'll include it in the >formal ballot that gets sent to IESG. > >Keith Keith has said that he wants to forward our proposal (that Randy and Larry sent to the IPP mailing list on 6/16) for a new IPP scheme to the IESG along with our documents. Until the following shortcomings with the current proposal for a new IPP scheme are fixed, we are not all talking about the same thing: 1. There are no MUST verbs. 2. There are 3 SHOULD verbs. 3. There are no MAY or NEED NOT verbs. 4. Only the outbound gateway is considered, not the inbound gateway. (Isn't Keith Moore worried about filtering by an inbound gateway?). 5. There is no statements MUST or SHOULD or MAY or NEED NOT about the scheme in the URI attributes in the application/ipp MIME type itself, i.e, in "printer-uri", "job-uri", "printer-uri-supported", etc.. I suggest that we try to improve our proposal in the above areas, working with Keith, before sending it to the IESG. If we agree on something at our Wednesday, IPP meeting, July 8, is there any chance of interacting with Keith on it at our meeting on Thursday, July 9, by phone? This is the same proposal that Randy and Larry produced on June 16, 1998 and send to the IPP mailing list. I have only changed the port number from 374 to the one assigned to IPP as the IPP default port by IANA on June 22, namely, 631. I also capitalized the "shoulds" to make them stand out. - TNH Proposal for an IPP scheme This is a proposal for the registration of a new URL scheme "ipp". The syntax for the new IPP scheme would be identical to the existing "http" scheme except for the scheme name itself: ipp://host[:port]/ Associated with this new IPP scheme would be an IANA-assigned TCP port number, which would be the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. When an IPP client obtains an IPP URL, the interpretation of this URL by the client can take one of three forms, depending on the configuration and implementation of the client: ------------------------------------------------------ IPP Client Configured with no proxy server - ------------------------------------------------------ When an IPP client (no proxy configured) obtains an IPP-schemed URL such as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... ------------------------------------------------------ IPP Client Configured for Proxy Service - ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... It is likely that existing proxies will not understand IPP URLs, so the RequestURI SHOULD use the HTTP form of the URL. ------------------------------------------------------- IPP Clients with HTTP-only constraints ------------------------------------------------------- If a particular IPP client implementation uses a pre-packaged HTTP library or HTTP class that only supports HTTP-schemed URLs, then the following operation would be required: - The IPP client obtains the IPP-schemed URL and converts it to the following form: "http://myhost.com:631/myprinter/myqueue" The client then submits this URL to the pre-packaged HTTP library API. ------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be able to accept requestURIs as specified in #2 and #3 as well. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) End of Proposal for a new IPP scheme From ipp-owner@pwg.org Mon Jul 6 15:57:26 1998 Delivery-Date: Mon, 06 Jul 1998 15:57:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28961 for ; Mon, 6 Jul 1998 15:57:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04990 for ; Mon, 6 Jul 1998 15:59:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01022 for ; Mon, 6 Jul 1998 15:57:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 15:53:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00396 for ipp-outgoing; Mon, 6 Jul 1998 15:50:39 -0400 (EDT) Message-Id: <3.0.5.32.19980706125019.00ce0310@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 12:50:19 PDT To: ipp@pwg.org, Keith Moore From: Tom Hastings Subject: IPP> How important is inbound firewall filtering? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org How much do corporations/organizations really depend on filtering by inbound firewalls? Many corporations just decide whether a server (HTTP, FTP, IPP) is inside the corporate firewall or outside. Those (few) that are outside are accessible by anyone on the Internet. Those that are inside the firewall are not accessible from the outside, but are accessible to all from inside the firewall that doesn't cross the firewall. No filtering is required. For example, at Xerox, we hav: - a public web server that is outside the firewall for customer and employee access - physically different web servers for internal use only that are inside the firewall. Presumably, from inside such a corporation, people can access the (few) servers that their corporation has put outside the firewall, provided that the outbound firewall places no restriction on such traffic. So by discussing inbound firewall filtering, are we really talking about a real problem that needs solving? Thanks, Tom From ipp-owner@pwg.org Mon Jul 6 16:02:55 1998 Delivery-Date: Mon, 06 Jul 1998 16:02:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29116 for ; Mon, 6 Jul 1998 16:02:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05010 for ; Mon, 6 Jul 1998 16:05:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01663 for ; Mon, 6 Jul 1998 16:02:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 15:58:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00894 for ipp-outgoing; Mon, 6 Jul 1998 15:56:35 -0400 (EDT) Message-Id: <199807061954.PAA08497@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: ipp@pwg.org, Keith Moore , moore@cs.utk.edu Subject: IPP> Re: How important is inbound firewall filtering? In-reply-to: Your message of "Mon, 06 Jul 1998 12:50:19 PDT." <3.0.5.32.19980706125019.00ce0310@garfield> Date: Mon, 06 Jul 1998 15:54:52 -0400 Sender: owner-ipp@pwg.org > So by discussing inbound firewall filtering, are we really talking about a > real problem that needs solving? Different kinds of sites have different ways of configuring firewalls, reflecting their different needs. IETF doesn't want to be in the business of telling people how to set up their security, but it does want to make sure that there are adequate means to do so. Keith From manros@cp10.es.xerox.com Mon Jul 6 17:04:31 1998 Delivery-Date: Mon, 06 Jul 1998 17:04:31 -0400 Return-Path: manros@cp10.es.xerox.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00780 for ; Mon, 6 Jul 1998 17:04:26 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05353 for ; Mon, 6 Jul 1998 17:06:48 -0400 (EDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA00777 for ; Mon, 6 Jul 1998 17:04:24 -0400 (EDT) Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <55629(5)>; Mon, 6 Jul 1998 14:04:24 PDT Received: from garfield.cp10.es.xerox.com (garfield.cp10.es.xerox.com [13.240.124.50]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id OAA01129; Mon, 6 Jul 1998 14:04:34 -0700 (PDT) Received: from dellcp-9 (csg122-29 [13.240.122.29]) by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id OAA11154; Mon, 6 Jul 1998 14:05:13 -0700 (PDT) Message-Id: <3.0.5.32.19980706140405.00b90830@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 14:04:05 PDT To: iesg@ietf.org, brian@hursley.ibm.com From: Carl-Uno Manros Subject: Architectural Issues Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, w3c-http-ng@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Members of the IESG, In recent discussions with Keith Moore in his role as Applications Area Director, a couple of rather fundamental questions about Internet protocol architecture have come up. As chair of one of the Application Area WGs, I have had some difficulty to understand the current policy within the IESG and the IAB on the following two aspects, and might have given my WG wrong advice on the acceptability of certain technical solutions vs. others from an IESG/IAB perspective. Issue 1 - Firewalls =================== Although I have been unable to find much said about firewalls in the IETF RFCs (RFC1579 and RFC2356 are the only references that come up), there seems to be some undocumented views within the IESG about what is appropriate and what is not when it comes to distinguishing different applications in firewalls. If such criteria are indeed used by the IESG, I think it is urgently needed to document them. They should distinguish between outgoing vs. incoming firewalls and should clearly state on which, and how many "parameters", filtering must be possible (such as TCP/IP address, scheme, port, method, content-type). Issue 2 - Layering of Applications ================================== It has also been discussed whether layering one application on another is allowed, and if so, which kind of things can be layered on what, and which combinations would be disallowed. This has resulted in debates such as if HTTP is specific to web traffic or a more generic transport protocol. I think it is particularly important to answer this question in anticipation of the HTTP-NG protocol, which is planned for introduction in the IETF later this year. To my knowledge, the designers of that protocol have explicitly wanted to make a protocol that is a more genereric than the current HTTP. Would that be in conflict with the IESGs ideas about what is allowed or not over that protocol? Again, any criteria that the IESG will be using for this kind of layering decisions should be clearly documented, so the WGs have a reasonable chance to stay within the boundaries of what the IESG considers to be "correct" design. Thankful for your feedback on this, Carl-Uno Manros Chair of IETF WG on IPP Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jul 6 17:08:07 1998 Delivery-Date: Mon, 06 Jul 1998 17:08:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00854 for ; Mon, 6 Jul 1998 17:08:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05364 for ; Mon, 6 Jul 1998 17:10:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA02538 for ; Mon, 6 Jul 1998 17:08:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 17:03:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA01938 for ipp-outgoing; Mon, 6 Jul 1998 17:01:49 -0400 (EDT) Message-ID: From: Rich Gray To: ipp@pwg.org Subject: RE: IPP> IPP and the IESG Date: Mon, 6 Jul 1998 17:00:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Although I have come late to this list and have to wonder about the overhead of putting an http server into printers, I must also express my sense of wonderment at the IESG's stance on ipp: instead of http:. I guess the main beauty of ipp over straight http: can be summarized best in two words: BOLT IN. Put the appropriate software in the client and add a CGI or similar to any reasonable web server and you have implemented a printing system without breaking anything in between. No special ipp: needed, no special port# (and no PRINT either!) This is simple, clean modularity. This I believe is what layered protocols strive to achieve. Why muck this up? By forcing ipp:, you potentially break a lot of infrastructure. Web servers, firewalls, etc. may need to be upgraded to understand "ipp:". The SMTP does not become something else when one does an FTP file retrieval via e-mail. As many have asked, why should http: change because the content is application/ipp? Should every other application protocol that comes along on top of http also cause the same breakage instead of just bolting in cleanly?? This just seems rather clumsy and disruptive. It will inhibit deployment because infrastructure upgrades will be required to make it work. What is gained by doing this?? Filtering? A simpler URI for the user? I do not believe "ipp:" provides any filtering which cannot be achieved in other ways. As been pointed out, the application/ipp MIME type is there as a generic check for incoming and outgoing traffic. Aside from that, while a company might be inclined to prevent it's users from coping a peek at www.hotporno.com, I really doubt that it will care as much about users coping a print to some external site. Mostly, folks will want to protect their printers from incoming requests. This would seem to be easily accomplished by protecting the printer's address from external access or by running the ipp service at a non-80 port# and filtering on whatever that is. Ultimately, authentication techniques will handle this. As to URI simplification, I don't see where most users are going to ever come into contact with the address, except maybe once as yet another incantation to be said when configuring the print facility on their client. Thereafter, they will just click [PRINT]. Or the address will be buried in the web page/java script/applet or whatever directory service thingy the user clicks on to invoke requests. The user will not/should not see it. My printer's address on my business card?? No thanks. Maybe on my web page and that might embed the printer address if I care to. (I'd just as soon forward their e-mail to the printer myself...) As I hinted above, I see no reason why the ipp service cannot hang on port 80 along with the other http traffic. Simplicity! Even if the user does manage to get and enter an ipp printer address into a browser, what's the worst which can happen?? An error message?? So? So IESG, show some reasons for breaking/complicating the world for each new application protocol which wants to ride on an existing transport protocol. Guess I'm largely echoing things others have said, but what the hey, it's my possibly off-base $.02, Rich Richard B. Gray, Sr. Software Egr.| Tel: 513/746-8118 ext. 2405 Digital Controls Corporation | Fax: 513/743-8575 305 South Pioneer Blvd. | Net: rich.gray@digital-controls.com Springboro OH 45066-1100, USA | Http://lpplus.digital-controls.com From ipp-owner@pwg.org Mon Jul 6 17:13:13 1998 Delivery-Date: Mon, 06 Jul 1998 17:13:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00981 for ; Mon, 6 Jul 1998 17:13:12 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05393 for ; Mon, 6 Jul 1998 17:15:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03175 for ; Mon, 6 Jul 1998 17:13:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 17:09:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02134 for ipp-outgoing; Mon, 6 Jul 1998 17:04:44 -0400 (EDT) Message-Id: <3.0.5.32.19980706140405.00b90830@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 14:04:05 PDT To: iesg@ietf.org, brian@hursley.ibm.com From: Carl-Uno Manros Subject: IPP> Architectural Issues Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, w3c-http-ng@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Dear Members of the IESG, In recent discussions with Keith Moore in his role as Applications Area Director, a couple of rather fundamental questions about Internet protocol architecture have come up. As chair of one of the Application Area WGs, I have had some difficulty to understand the current policy within the IESG and the IAB on the following two aspects, and might have given my WG wrong advice on the acceptability of certain technical solutions vs. others from an IESG/IAB perspective. Issue 1 - Firewalls =================== Although I have been unable to find much said about firewalls in the IETF RFCs (RFC1579 and RFC2356 are the only references that come up), there seems to be some undocumented views within the IESG about what is appropriate and what is not when it comes to distinguishing different applications in firewalls. If such criteria are indeed used by the IESG, I think it is urgently needed to document them. They should distinguish between outgoing vs. incoming firewalls and should clearly state on which, and how many "parameters", filtering must be possible (such as TCP/IP address, scheme, port, method, content-type). Issue 2 - Layering of Applications ================================== It has also been discussed whether layering one application on another is allowed, and if so, which kind of things can be layered on what, and which combinations would be disallowed. This has resulted in debates such as if HTTP is specific to web traffic or a more generic transport protocol. I think it is particularly important to answer this question in anticipation of the HTTP-NG protocol, which is planned for introduction in the IETF later this year. To my knowledge, the designers of that protocol have explicitly wanted to make a protocol that is a more genereric than the current HTTP. Would that be in conflict with the IESGs ideas about what is allowed or not over that protocol? Again, any criteria that the IESG will be using for this kind of layering decisions should be clearly documented, so the WGs have a reasonable chance to stay within the boundaries of what the IESG considers to be "correct" design. Thankful for your feedback on this, Carl-Uno Manros Chair of IETF WG on IPP Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Mon Jul 6 19:28:47 1998 Delivery-Date: Mon, 06 Jul 1998 19:28:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02371 for ; Mon, 6 Jul 1998 19:28:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05958 for ; Mon, 6 Jul 1998 19:30:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA04318 for ; Mon, 6 Jul 1998 19:28:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 19:23:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA03731 for ipp-outgoing; Mon, 6 Jul 1998 19:21:06 -0400 (EDT) Message-Id: <3.0.5.32.19980706162037.01412930@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 16:20:37 PDT To: Paul Moore From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded [some questions/answers] Cc: "'ipp@pwg.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 10:49 6/29/98 PDT, Paul Moore wrote: >to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >Describes 7 new operations that MS may be using for IPP1.0 > >We should discuss whther we want to make any of these standard extensions I welcome the proposal for new operations. These look very reasonable and useful. ISO DPA has had them as well. Implementations of ISO DPA have had experience with their implementations that can be brought to bear (and to simplify IPP). However, in order to gain full interoperability between various implementations there are a number of questions that need to be answered and the agreements added to the specification of these operations. I have indicated the questions and suggested answers with highlighting like this. See if you think if answering such questions is a good way to nail down the details, rather than review the details of a (longer) specification. Occasionally, I have an issue with what is being proposed. That is indicated as ISSUE, instead of QUESTION. I've uploaded my questions on the new operations: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms-new-operations-questions.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms-new-operations-questions.pdf Here is that document in plain text: Questions and answers about proposed new operations From: Tom Hastings Date: 7/6/1998 File: ms-ipp-operations-questions.doc I welcome the proposal for new operations. These look very reasonable and useful. ISO DPA has had them as well. Implementations of ISO DPA have had experience with their implementations that can be brought to bear (and to simplify IPP). However, in order to gain full interoperability between various implementations there are a number of questions that need to be answered and the agreements added to the specification of these operations. I have indicated the questions and suggested answers with highlighting like this. See if you think if answering such questions is a good way to nail down the details, rather than review the details of a (longer) specification. Occasionally, I have an issue with what is being proposed. That is indicated as ISSUE, instead of QUESTION. New IPP 1.0 Operations Microsoft has added several new operations to its implementation of IPP 1.0. They are currently added in the private extension space but we believe that they are generally useful and so propose that some (if not all) of them are moved into the main operation set. [model] refers to the current IPP model and semantics document. Operation attributes and responses Job Operations The operation attributes and responses for the job operations are the same as the standard Cancel-Job operation (see [model] 3.3.3). QUESTION 1: Shouldn't we use the hyphenation conventions for these operatioins? SUGGESTED ANSWER: Yes, so Hold-Job, Pause-Printer, Release-Job, Resume-Printer, Purge-Printer, Reprint-Job. QUESTION 2: Which operations are Job operations: SUGGESTED ANSWEr: Hold-Job, Release-Job, Reprint-Job Printer Operations QUESTION 3: Which operations are Printer operations: SUGGESTED ANSWER: Pause-Printer, Resume-Printer, Purge-Printer The operation attributes for the printer operations are as follows:- Target: Printer-URI - see 3.1.3 of [model] Natural Language and Charset: See 3.1.4.1 of [model] Requesting User Name: Should be supplied - see [model] 8.3 Response: Status code and message as described in [model]3.1.5 HoldJob Requests that a job be held in the queue - that means it is not eligible for scheduling. If the job is not waiting to be printed than this operation has no effect (but completes successfully). QUESTION 4: What state does the job go into after the operation? SUGGESTED ANSWER: I suggest that the job go into the 'pending-held' job state. QUESTION 5: What job-state-reason is set, if the job-state-reasons attribute is supported? SUGGESTED ANSWER: Add two new job state reason keywords: 'job-held-by-user', and 'job-held-by-operation' (analogous to Cancel-Job). Also use the current 'processing-to-stop-point', as in the Cancel-Job, if the operation is accepted, but the job is not able to be put into the 'pending-held' state immediately. ISSUE 1: I suggest that the request be rejected if the implementation cannot or does not put the job into the 'pending-held' state, rather than just accepting the operation. SUGGESTED FIX: For authorized users, I suggest that an IPP object: For a job in the 'pending' or 'pending-held' state, MUST accept the request and move the job into the 'pending-held' state. For a job in the 'pending' or 'pending-stopped' states, an implementation MAY either (1) accept the operation and move the job to the 'pending-held' state if the implementation can process other jobs on that Printer and later support the Release-Job operation for this job or (2) reject the operation with the 'client-error-not-possible', depending on implementation. NOTE: The former is ISO DPA Pause-Job semantics, but is hard to implement we have found. Stopping a job in the middle and then resuming it later is difficult. For a job in the 'completed', 'aborted', or 'canceled' states, MUST reject the operation with the 'client-error-not-possible' status code. Current Code: 0X4000 Access Rights: The requesting user must either be the submitter of the job or an administrator of the printer QUESTION 6: What error codes if the access rights aren't satisfied? SUGGESTED ANSWER: Return: client-error-forbidden, client-error-not-authenticated, and client-error-not-authorized. ReleaseJob Requests that a previously held job be made eligible for scheduling once more. QUESTION 7: What job states MUST the job be in in order to accept this operation? SUGGESTED ANSWER: The IPP object MUST reject this operation, unless the identified job is in the 'pending-held' state and, if implemented, the 'held-by-user' or 'held-by-operation' value is present in the job's "job-state-reasons" attribute, if the user is the submitter of the job or an administrator, respectively . If the job is not in the 'pending-held' state, the IPP object MUST reject the request and return the 'client-error-not-possible' status code. QUESTION 8: What happens to the job's job state? SUGGESTED ANSWER: If there are no other reasons to hold the job, such as the "job-hold-until" specifies a period of time in the future, the IPP object MUST move the job from the 'pending-held' state to the 'pending' state, whereupon it MAY move immediately to the 'processing' state, if there are no other jobs pending with a higher priority. Current Code: 0X4002 Access Rights: The requesting user must either be the submitter of the job or an administrator of the printer QUESTION 9: What error codes if the access rights aren't satisfied? SUGGESTED ANSWER: Return: client-error-forbidden, client-error-not-authenticated, and client-error-not-authorized. PausePrinter Requests that the printer stops scheduling new jobs. Any job that is currently being printed is completed. The printer will still accept new jobs. QUESTION 10: What state does the Printer go into? SUGGESTED ANSWER: The Printer goes into the 'stopped' state QUESTION 11: What printer-state-reason is set, if the printer-state-reasons attribute is supported? SUGGESTED ANSWER: The 'paused' value is added to the Printer object's "printer-state-reasons" attribute. ISSUE 2: Why does the current job continue printing? This doesn't sound like pushing the pause button on the device. The name suggests that the IPP Printer should go into the 'stopped' state and, if implemented, the 'paused' value added to the Printer object's "printer-state-reasons" attribute. Also the current job go into the 'processing-stopped' state and, if implemented, the 'printer-stopped' value added to the job object's "job-state-reasons" attribute. The user can go look at the Printer's "printer-state-reasons" attribute to see why the printer is stopped. SUGGESTED FIX: Either require the above, or rename this operation to something like Stop-Scheduling-Jobs, so that we can also have a Pause-Printer operation that does the above. QUESTION 13: What states must the Printer be in/not it in order to accept/reject the Pause-Printer? SUGGESTED ANSWER: The Printer object MUST accept this operation if the Printer is in the 'idle' or 'processing' state. The Printer object MUST reject the operation if the Printer has previously accepted a Pause-Printer operation without an intervening Resume-Printer, i.e., if the ' paused' value, if supported, is present in the Printer's "printer-state-reasons" attribute. Current Code: 0X4001 Access Rights: The requesting user must be an administrator of the printer ResumePrinter Un-pauses a printer (see PausePrinter). QUESTION 14: What states must the Printer be in/not it in order to accept/reject the Resume-Printer operation? SUGGESTED ANSWER: The Printer object MUST accept this operation if the Printer has previously accepted a Pause-Printer operation without an intervening Resume-Printer, i.e., if the ' paused' value, if supported, is present in the Printer's "printer-state-reasons" attribute. Otherwise, the Printer object MUST reject the operation and return the 'client-error-not-possible' status code. Current Code: 0X4003 Access Rights: The requesting user must be an administrator of the printer PurgePrinter Removes all jobs queued for a printer. Any job that is currently printing is also cancelled. Current Code: 0X4004 Access Rights: The requesting user must be an administrator of the printer ReprintJob Requests that a print job that is retained in the queue be (re)printed. In this case the job is sent to the printer from the beginning. QUESTION 15: Is this operation also used to move a job to another printer (after printing)? SUGGESTED ANSWER: No. ISO DPA has a very complicated operation called ResubmitJob, which works before or after the job has been printed and allows the printer to be specified as a different one. QUESTION 16: What states must the Job be in/not it in order to accept/reject the Reprint operation? SUGGESTED ANSWER: The IPP object MUST accept this operation if the Job is in the 'completed', 'aborted', or 'canceled' job states. If the job is in another other state ('pending-held', 'pending', 'processing', or 'processing-stopped'), the IPP object MUST reject the operation and return the 'client-error-not-possible' status code. Current Code: 0X4005 Access Rights: The requesting user must either be the submitter of the job or an administrator of the printer From ipp-owner@pwg.org Mon Jul 6 19:37:20 1998 Delivery-Date: Mon, 06 Jul 1998 19:37:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02422 for ; Mon, 6 Jul 1998 19:37:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05978 for ; Mon, 6 Jul 1998 19:39:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA04980 for ; Mon, 6 Jul 1998 19:37:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 19:33:12 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04300 for ipp-outgoing; Mon, 6 Jul 1998 19:28:07 -0400 (EDT) Message-Id: <199807062326.TAA10077@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom Hastings cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: On clarifying the proposal for a new IPP scheme In-reply-to: Your message of "Mon, 06 Jul 1998 12:09:48 PDT." <3.0.5.32.19980706120948.013ec390@garfield> Date: Mon, 06 Jul 1998 19:26:33 -0400 Sender: owner-ipp@pwg.org > Proposal for an IPP scheme > > This is a proposal for the registration of a new URL scheme "ipp". > The syntax for the new IPP scheme would be identical to the existing > "http" scheme except for the scheme name itself: > > ipp://host[:port]/ > > Associated with this new IPP scheme would be an IANA-assigned TCP port > number, which would be the default port number used by clients to > contact IPP servers that are represented by IPP URLs. > > The IPP scheme implies all of the same protocol semantics as that of > the HTTP scheme, except that, by default, the port number used by clients > to connect to the server is port 631. The semantics for clients > configured for proxy access is different as described below. change this to: The IPP scheme implies use of the Internet Printing Protocol, which is layered on top of the Hypertext Transfer Protocol (HTTP). By default, IPP clients connect to IPP servers using TCP port 631. > When an IPP client obtains an IPP URL, the interpretation of this URL by > the client can take one of three forms, depending on the configuration > and implementation of the client: > > > ------------------------------------------------------ > IPP Client Configured with no proxy server - > ------------------------------------------------------ > > > When an IPP client (no proxy configured) obtains an IPP-schemed URL such > as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to > port 631 on myhost.com, with the following example headers: > > POST /myprinter/myqueue HTTP/1.1 > Host: myhost.com:631 change the above line to: Host: myhost.com "631" should probably not appear, since it's the default port. However servers should accept the port # if it does appear. > Content-type: application/ipp > Transfer-Encoding: chunked > ... > > ------------------------------------------------------ > IPP Client Configured for Proxy Service - > ------------------------------------------------------ > > When an IPP client that uses a proxy named "myproxy.com" obtains the URL > "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to > myproxy.com with the following example headers: > > POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 > Host: myproxy.com:631 > Content-type: application/ipp > Transfer-Encoding: chunked > ... > > It is likely that existing proxies will not understand IPP URLs, > so the RequestURI SHOULD use the HTTP form of the URL. This section needs justification - why should an IPP client talk to an HTTP proxy rather than talking directly to the IPP server, unless the reason is to circumvent the local site's filtering of outbound traffic on port 631? (There may well be a good reason, but offhand I can't think of one.) > ------------------------------------------------------- > IPP Clients with HTTP-only constraints > ------------------------------------------------------- > If a particular IPP client implementation uses a pre-packaged HTTP library > or HTTP class that only supports HTTP-schemed URLs, then the following > operation would be required: > > - The IPP client obtains the IPP-schemed URL and converts it to the > following form: > "http://myhost.com:631/myprinter/myqueue" > > The client then submits this URL to the pre-packaged HTTP library API. (FWIW, This is an implementation issue. As long as the protocol on the wire is the same, IETF doesn't care what you have to do to talk to an API.) > Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers > using a requestURI specified in #1 below. However, RFC 2068 states that > HTTP 1.1 > servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be > able to > accept requestURIs as specified in #2 and #3 as well. > > > 1. A "abs_path" URL (e.g., /myprinter/myqueue) > 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) > 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) Servers MUST treat all of above forms as equivalent. Servers MAY provide different services at different domains using either full URLs (those that include the domain), or the Host header (if one is supplied by the client) to distinguish one domain from another. Servers that look at the Host: request header field MUST treat "Host: foo.com" and "Host: foo.com:631" as equivalent. Finally: The use of http: URLs within IPP is only to allow reuse of HTTP libraries, (or HTTP proxies). Within IPP protocol elements, ipp: URLs MUST always be used for URLs that refer to IPP objects. Keith From ipp-owner@pwg.org Mon Jul 6 19:47:32 1998 Delivery-Date: Mon, 06 Jul 1998 19:47:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02452 for ; Mon, 6 Jul 1998 19:47:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06000 for ; Mon, 6 Jul 1998 19:49:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05660 for ; Mon, 6 Jul 1998 19:47:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 19:43:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05059 for ipp-outgoing; Mon, 6 Jul 1998 19:41:31 -0400 (EDT) Message-Id: <199807062341.TAA10143@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IPP and the IESG In-reply-to: Your message of "Mon, 06 Jul 1998 14:24:39 EDT." <199807061901.AA04631@interlock2.lexmark.com> Date: Mon, 06 Jul 1998 19:41:18 -0400 Sender: owner-ipp@pwg.org Don, It's really very simple. Most of the time HTTP is used to fetch web pages or to upload form data. Printing is viewed by IESG to be sufficiently different than either of these two that it needs to be distinguished from ordinary HTTP, both by having a different port # and a different URL type. Making such judgements is part of IESG's job. I refer you to RFC 2026, section 6, first paragraph: 6. THE INTERNET STANDARDS PROCESS The mechanics of the Internet Standards Process involve decisions of the IESG concerning the elevation of a specification onto the standards track or the movement of a standards-track specification from one maturity level to another. Although a number of reasonably objective criteria (described below and in section 4) are available to guide the IESG in making a decision to move a specification onto, along, or off the standards track, there is no algorithmic guarantee of elevation to or progression along the standards track for any specification. The experienced collective judgment of the IESG *********************************************** concerning the technical quality of a specification proposed for ***************************************************************** elevation to or advancement in the standards track is an essential ****************************************************************** component of the decision-making process. **************************************** Keith From ipp-owner@pwg.org Mon Jul 6 21:04:59 1998 Delivery-Date: Mon, 06 Jul 1998 21:04:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA03027 for ; Mon, 6 Jul 1998 21:04:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA06137 for ; Mon, 6 Jul 1998 21:07:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA06533 for ; Mon, 6 Jul 1998 21:04:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 20:58:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05959 for ipp-outgoing; Mon, 6 Jul 1998 20:56:17 -0400 (EDT) Message-Id: <3.0.5.32.19980706175605.00fad550@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 17:56:05 PDT To: Keith Moore , Tom Hastings From: Carl-Uno Manros Subject: Re: IPP> Re: On clarifying the proposal for a new IPP scheme Cc: ipp@pwg.org In-Reply-To: <199807062326.TAA10077@spot.cs.utk.edu> 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: owner-ipp@pwg.org Keith, Thanks for your constructive proposal on how to improve the proposal. This shows more in detail what you believe is the right solution. I expect that we will discuss this in the upcoming IPP meeting, and be able to give you feedback later in the week on how the experts in that meeting view your proposed changes. Carl-Uno At 04:26 PM 7/6/98 PDT, Keith Moore wrote: >> Proposal for an IPP scheme >> >> This is a proposal for the registration of a new URL scheme "ipp". >> The syntax for the new IPP scheme would be identical to the existing >> "http" scheme except for the scheme name itself: >> >> ipp://host[:port]/ >> >> Associated with this new IPP scheme would be an IANA-assigned TCP port >> number, which would be the default port number used by clients to >> contact IPP servers that are represented by IPP URLs. >> >> The IPP scheme implies all of the same protocol semantics as that of >> the HTTP scheme, except that, by default, the port number used by clients >> to connect to the server is port 631. The semantics for clients >> configured for proxy access is different as described below. > >change this to: > >The IPP scheme implies use of the Internet Printing Protocol, which >is layered on top of the Hypertext Transfer Protocol (HTTP). By >default, IPP clients connect to IPP servers using TCP port 631. > >> When an IPP client obtains an IPP URL, the interpretation of this URL by >> the client can take one of three forms, depending on the configuration >> and implementation of the client: >> >> >> ------------------------------------------------------ >> IPP Client Configured with no proxy server - >> ------------------------------------------------------ >> >> >> When an IPP client (no proxy configured) obtains an IPP-schemed URL such >> as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to >> port 631 on myhost.com, with the following example headers: >> >> POST /myprinter/myqueue HTTP/1.1 >> Host: myhost.com:631 > >change the above line to: > >Host: myhost.com > >"631" should probably not appear, since it's the default port. > >However servers should accept the port # if it does appear. > >> Content-type: application/ipp >> Transfer-Encoding: chunked >> ... >> >> ------------------------------------------------------ >> IPP Client Configured for Proxy Service - >> ------------------------------------------------------ >> >> When an IPP client that uses a proxy named "myproxy.com" obtains the URL >> "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to >> myproxy.com with the following example headers: >> >> POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 >> Host: myproxy.com:631 >> Content-type: application/ipp >> Transfer-Encoding: chunked >> ... >> >> It is likely that existing proxies will not understand IPP URLs, >> so the RequestURI SHOULD use the HTTP form of the URL. > > >This section needs justification - why should an IPP client talk to an >HTTP proxy rather than talking directly to the IPP server, unless >the reason is to circumvent the local site's filtering of outbound >traffic on port 631? (There may well be a good reason, but offhand I >can't think of one.) > >> ------------------------------------------------------- >> IPP Clients with HTTP-only constraints >> ------------------------------------------------------- >> If a particular IPP client implementation uses a pre-packaged HTTP library >> or HTTP class that only supports HTTP-schemed URLs, then the following >> operation would be required: >> >> - The IPP client obtains the IPP-schemed URL and converts it to the >> following form: >> "http://myhost.com:631/myprinter/myqueue" >> >> The client then submits this URL to the pre-packaged HTTP library API. > >(FWIW, This is an implementation issue. As long as the protocol on the wire >is the same, IETF doesn't care what you have to do to talk to an API.) > > >> Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers >> using a requestURI specified in #1 below. However, RFC 2068 states that >> HTTP 1.1 >> servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be >> able to >> accept requestURIs as specified in #2 and #3 as well. >> >> >> 1. A "abs_path" URL (e.g., /myprinter/myqueue) >> 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) >> 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) > >Servers MUST treat all of above forms as equivalent. > >Servers MAY provide different services at different domains using >either full URLs (those that include the domain), or the Host header >(if one is supplied by the client) to distinguish one domain from another. >Servers that look at the Host: request header field MUST treat >"Host: foo.com" and "Host: foo.com:631" as equivalent. > > >Finally: > >The use of http: URLs within IPP is only to allow reuse of HTTP libraries, >(or HTTP proxies). Within IPP protocol elements, ipp: URLs MUST always >be used for URLs that refer to IPP objects. > >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 From carl@manros.com Mon Jul 6 23:32:55 1998 Delivery-Date: Mon, 06 Jul 1998 23:32:55 -0400 Return-Path: carl@manros.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11631 for ; Mon, 6 Jul 1998 23:32:55 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA06387 for ; Mon, 6 Jul 1998 23:35:15 -0400 (EDT) Received: from holonet.net (zen.holonet.net [198.207.169.5]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11628 for ; Mon, 6 Jul 1998 23:32:51 -0400 (EDT) Message-Id: <1.5.4.32.19980707032555.0074d23c@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Jul 1998 20:25:55 -0700 To: iesg@ietf.org, brian@hursley.ibm.com From: Carl-Uno Manros Subject: Re: Architectural Issues - Additional Comment Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, w3c-http-ng@w3.org Dear Members of the IESG, An added comment to my previous post, is that I consider that Keith Moore has indeed recently given the IPP WG more clear guidance on these issues. However, the IPP WG has spent several months of sometimes almost religious discussions on these subjects (shared with the HTTP WG), so if the IESG could come up with some general guidelines for these kind of issues, it might save other WGs considerable time and effort in the future. Carl-Uno Manros At 02:04 PM 7/6/98 PDT, you wrote: >Dear Members of the IESG, > >In recent discussions with Keith Moore in his role as Applications Area >Director, a couple of rather fundamental questions about Internet protocol >architecture have come up. As chair of one of the Application Area WGs, I >have had some difficulty to understand the current policy within the IESG >and the IAB on the following two aspects, and might have given my WG wrong >advice on the acceptability of certain technical solutions vs. others from >an IESG/IAB perspective. > >Issue 1 - Firewalls >=================== > >Although I have been unable to find much said about firewalls in the IETF >RFCs (RFC1579 and RFC2356 are the only references that come up), there >seems to be some undocumented views within the IESG about what is >appropriate and what is not when it comes to distinguishing different >applications in firewalls. If such criteria are indeed used by the IESG, I >think it is urgently needed to document them. They should distinguish >between outgoing vs. incoming firewalls and should clearly state on which, >and how many "parameters", filtering must be possible (such as TCP/IP >address, scheme, port, method, content-type). > >Issue 2 - Layering of Applications >================================== > >It has also been discussed whether layering one application on another is >allowed, and if so, which kind of things can be layered on what, and which >combinations would be disallowed. This has resulted in debates such as if >HTTP is specific to web traffic or a more generic transport protocol. I >think it is particularly important to answer this question in anticipation >of the HTTP-NG protocol, which is planned for introduction in the IETF >later this year. To my knowledge, the designers of that protocol have >explicitly wanted to make a protocol that is a more genereric than the >current HTTP. Would that be in conflict with the IESGs ideas about what is >allowed or not over that protocol? Again, any criteria that the IESG will >be using for this kind of layering decisions should be clearly documented, >so the WGs have a reasonable chance to stay within the boundaries of what >the IESG considers to be "correct" design. > >Thankful for your feedback on this, > >Carl-Uno Manros >Chair of IETF WG on IPP > > > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Mon Jul 6 23:43:00 1998 Delivery-Date: Mon, 06 Jul 1998 23:43:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11744 for ; Mon, 6 Jul 1998 23:42:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA06391 for ; Mon, 6 Jul 1998 23:45:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA07494 for ; Mon, 6 Jul 1998 23:42:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 23:38:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA06925 for ipp-outgoing; Mon, 6 Jul 1998 23:33:10 -0400 (EDT) Message-Id: <1.5.4.32.19980707032555.0074d23c@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Jul 1998 20:25:55 -0700 To: iesg@ietf.org, brian@hursley.ibm.com From: Carl-Uno Manros Subject: IPP> Re: Architectural Issues - Additional Comment Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, w3c-http-ng@w3.org Sender: owner-ipp@pwg.org Dear Members of the IESG, An added comment to my previous post, is that I consider that Keith Moore has indeed recently given the IPP WG more clear guidance on these issues. However, the IPP WG has spent several months of sometimes almost religious discussions on these subjects (shared with the HTTP WG), so if the IESG could come up with some general guidelines for these kind of issues, it might save other WGs considerable time and effort in the future. Carl-Uno Manros At 02:04 PM 7/6/98 PDT, you wrote: >Dear Members of the IESG, > >In recent discussions with Keith Moore in his role as Applications Area >Director, a couple of rather fundamental questions about Internet protocol >architecture have come up. As chair of one of the Application Area WGs, I >have had some difficulty to understand the current policy within the IESG >and the IAB on the following two aspects, and might have given my WG wrong >advice on the acceptability of certain technical solutions vs. others from >an IESG/IAB perspective. > >Issue 1 - Firewalls >=================== > >Although I have been unable to find much said about firewalls in the IETF >RFCs (RFC1579 and RFC2356 are the only references that come up), there >seems to be some undocumented views within the IESG about what is >appropriate and what is not when it comes to distinguishing different >applications in firewalls. If such criteria are indeed used by the IESG, I >think it is urgently needed to document them. They should distinguish >between outgoing vs. incoming firewalls and should clearly state on which, >and how many "parameters", filtering must be possible (such as TCP/IP >address, scheme, port, method, content-type). > >Issue 2 - Layering of Applications >================================== > >It has also been discussed whether layering one application on another is >allowed, and if so, which kind of things can be layered on what, and which >combinations would be disallowed. This has resulted in debates such as if >HTTP is specific to web traffic or a more generic transport protocol. I >think it is particularly important to answer this question in anticipation >of the HTTP-NG protocol, which is planned for introduction in the IETF >later this year. To my knowledge, the designers of that protocol have >explicitly wanted to make a protocol that is a more genereric than the >current HTTP. Would that be in conflict with the IESGs ideas about what is >allowed or not over that protocol? Again, any criteria that the IESG will >be using for this kind of layering decisions should be clearly documented, >so the WGs have a reasonable chance to stay within the boundaries of what >the IESG considers to be "correct" design. > >Thankful for your feedback on this, > >Carl-Uno Manros >Chair of IETF WG on IPP > > > > >Carl-Uno Manros >Principal Engineer - Advanced Printing Standards - Xerox Corporation >701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >Phone +1-310-333 8273, Fax +1-310-333 5514 >Email: manros@cp10.es.xerox.com > > From ipp-owner@pwg.org Tue Jul 7 01:39:01 1998 Delivery-Date: Tue, 07 Jul 1998 01:39:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA16613 for ; Tue, 7 Jul 1998 01:38:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA06650 for ; Tue, 7 Jul 1998 01:40:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA08631 for ; Tue, 7 Jul 1998 01:38:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 01:33:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA07990 for ipp-outgoing; Tue, 7 Jul 1998 01:27:25 -0400 (EDT) Message-Id: <3.0.5.32.19980706222659.014936d0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 22:26:59 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Notify job progress attributes uploaded Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The six new job progress attributes that were in the long notification proposal from May and were just listed in the very short notification proposal have been made a short 8 page white paper: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-prog-attr-980706.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-prog-attr-980706.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-prog-attr-980706.txt I'll bring copies of it to the meeting. Here is the abstract: Proposed Job Progress Attributes for IPP Version 0.1 Abstract This white paper proposes six new Job Description attributes to be registered for use with IPP/1.0 [ipp-mod]. These attributes are drawn from the PWG Job Monitoring MIB [jmp-mib]. They were contained in the long notification proposal [ipp-not-long], and have been placed in a separate more manageable-sized specification. These attributes are be used with the IPP notification event report. They may also be used by themselves as useful job progress monitoring attributes. The six new attributes are: "output-bin" (1setOf text(63)) "sheet-completed-copy-number" (integer(-2:MAX)) "sheet-completed-document-number" (integer(-2:MAX)) "job-collation-type" (enum) "impressions-interpreted" (integer(-2:MAX)) "impressions-completed-current-copy" (integer(-2:MAX)) Tom From ipp-owner@pwg.org Tue Jul 7 01:47:44 1998 Delivery-Date: Tue, 07 Jul 1998 01:47:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA16661 for ; Tue, 7 Jul 1998 01:47:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA06677 for ; Tue, 7 Jul 1998 01:50:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA09415 for ; Tue, 7 Jul 1998 01:47:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 01:43:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA08655 for ipp-outgoing; Tue, 7 Jul 1998 01:38:43 -0400 (EDT) Message-Id: <3.0.5.32.19980706223823.0142bbe0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 6 Jul 1998 22:38:23 PDT To: Paul Moore From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded [Reprint and job-id] Cc: ipp@pwg.org In-Reply-To: <3.0.5.32.19980706162037.01412930@garfield> 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: owner-ipp@pwg.org At 16:20 7/6/98 PDT, Tom Hastings wrote: >At 10:49 6/29/98 PDT, Paul Moore wrote: >>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>Describes 7 new operations that MS may be using for IPP1.0 >> >>We should discuss whther we want to make any of these standard extensions > One further question about Reprint-Job: For ISO DPA Resubmit-Job, we finally decided that a new copy of the job should be created and assigned a new job-identifier. This was so that accounting would not get confused with a job that was resubmitted several times. Also by making a copy, any accounting done using the PWG Job Monitoring MIB, can be safely done while the job is in the 'completed' state, even if the job is resubmitted immediately before the accounting can be gathered for the job just completed, since a new job is created with a copy of all of the originally submitted attributes. For the Reprint-Job, we could do the same and require that the IPP object return a new job-id and make a copy of the job. On the other hand, since the user cannot modify the job, a simpler approach to keep the accounting straight (and reflect the true state of the job), would be to add a Job Description attribute which is a count of the number of Reprint-Job operations performed. This "number-of-reprints" Job Description attribute would be REQUIRED to be supported, if the IPP object supports the Reprint-Job operation. An accounting application would take note of the value for the "number-of-reprints" which is normally 0 if no Reprint-Job operation has been performed. So we can save the harder ISO DPA Modify-Job and Resubmit-Job operations which modify the job to later. Thanks, Tom From ipp-owner@pwg.org Tue Jul 7 02:32:30 1998 Delivery-Date: Tue, 07 Jul 1998 02:32:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA16833 for ; Tue, 7 Jul 1998 02:32:29 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06772 for ; Tue, 7 Jul 1998 02:34:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA10879 for ; Tue, 7 Jul 1998 02:32:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 02:28:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10256 for ipp-outgoing; Tue, 7 Jul 1998 02:24:13 -0400 (EDT) Message-Id: <199807070619.XAA19325@slafw.enet.sharplabs.com> From: "Randy Turner" To: "Keith Moore" , "Tom Hastings" Cc: Subject: Re: IPP> On clarifying the proposal for a new IPP scheme Date: Mon, 6 Jul 1998 23:18:10 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Keith, If you can wait a couple of days, we will forward you a *final* version of this proposal before you forward this to the IESG......(?) Randy ---------- > From: Tom Hastings > To: Keith Moore > Cc: ipp@pwg.org > Subject: IPP> On clarifying the proposal for a new IPP scheme > Date: Monday, July 06, 1998 12:09 PM > > At 14:13 07/03/98 PDT, Keith Moore wrote: > >Tom, > > > >The best thing to do at this point would be for me to run this proposal > >by the entire IESG when it is balloted. So I'll include it in the > >formal ballot that gets sent to IESG. > > > >Keith > > Keith has said that he wants to forward our proposal (that Randy and Larry > sent to > the IPP mailing list on 6/16) for a new IPP scheme to the IESG along with > our documents. Until the following shortcomings with the current proposal > for a new IPP scheme are fixed, we are not all talking about the same thing: > > 1. There are no MUST verbs. > > 2. There are 3 SHOULD verbs. > > 3. There are no MAY or NEED NOT verbs. > > 4. Only the outbound gateway is considered, not the inbound gateway. > (Isn't Keith Moore worried about filtering by an inbound gateway?). > > 5. There is no statements MUST or SHOULD or MAY or NEED NOT about the > scheme in the URI attributes in the application/ipp MIME type itself, i.e, > in "printer-uri", "job-uri", "printer-uri-supported", etc.. > > I suggest that we try to improve our proposal in the above areas, working > with Keith, before sending it to the IESG. If we agree on something at our > Wednesday, IPP meeting, July 8, is there any chance of interacting with > Keith on it at our meeting on Thursday, July 9, by phone? > > This is the same proposal that Randy and Larry produced on June 16, 1998 > and send to the IPP mailing list. I have only changed the port number from > 374 to the one assigned to IPP as the IPP default port by IANA on June 22, > namely, 631. I also capitalized the "shoulds" to make them stand out. - TNH > > > > > > Proposal for an IPP scheme > > This is a proposal for the registration of a new URL scheme "ipp". > The syntax for the new IPP scheme would be identical to the existing > "http" scheme except for the scheme name itself: > > ipp://host[:port]/ > > Associated with this new IPP scheme would be an IANA-assigned TCP port > number, which would be the default port number used by clients to > contact IPP servers that are represented by IPP URLs. > > The IPP scheme implies all of the same protocol semantics as that of > the HTTP scheme, except that, by default, the port number used by clients > to connect to the server is port 631. The semantics for clients > configured for proxy access is different as described below. > > When an IPP client obtains an IPP URL, the interpretation of this URL by > the client can take one of three forms, depending on the configuration > and implementation of the client: > > > ------------------------------------------------------ > IPP Client Configured with no proxy server - > ------------------------------------------------------ > > > When an IPP client (no proxy configured) obtains an IPP-schemed URL such > as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to > port 631 on myhost.com, with the following example headers: > > POST /myprinter/myqueue HTTP/1.1 > Host: myhost.com:631 > Content-type: application/ipp > Transfer-Encoding: chunked > ... > > ------------------------------------------------------ > IPP Client Configured for Proxy Service - > ------------------------------------------------------ > > When an IPP client that uses a proxy named "myproxy.com" obtains the URL > "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to > myproxy.com with the following example headers: > > POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 > Host: myproxy.com:631 > Content-type: application/ipp > Transfer-Encoding: chunked > ... > > It is likely that existing proxies will not understand IPP URLs, > so the RequestURI SHOULD use the HTTP form of the URL. > > ------------------------------------------------------- > IPP Clients with HTTP-only constraints > ------------------------------------------------------- > If a particular IPP client implementation uses a pre-packaged HTTP library > or HTTP class that only supports HTTP-schemed URLs, then the following > operation would be required: > > - The IPP client obtains the IPP-schemed URL and converts it to the > following form: > "http://myhost.com:631/myprinter/myqueue" > > The client then submits this URL to the pre-packaged HTTP library API. > > > ------------------------------------------------------- > > Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers > using a requestURI specified in #1 below. However, RFC 2068 states that > HTTP 1.1 > servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be > able to > accept requestURIs as specified in #2 and #3 as well. > > > 1. A "abs_path" URL (e.g., /myprinter/myqueue) > 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) > 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) > > End of Proposal for a new IPP scheme From ipp-owner@pwg.org Tue Jul 7 02:48:54 1998 Delivery-Date: Tue, 07 Jul 1998 02:48:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA16868 for ; Tue, 7 Jul 1998 02:48:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06807 for ; Tue, 7 Jul 1998 02:51:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id CAA12090 for ; Tue, 7 Jul 1998 02:48:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 02:43:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA11093 for ipp-outgoing; Tue, 7 Jul 1998 02:39:11 -0400 (EDT) Message-Id: <199807070637.XAA19359@slafw.enet.sharplabs.com> From: "Randy Turner" To: Cc: Subject: Re: IPP> Re: On clarifying the proposal for a new IPP scheme Date: Mon, 6 Jul 1998 23:38:47 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org ---------- > From: Keith Moore > To: Tom Hastings > Cc: Keith Moore ; ipp@pwg.org; moore@cs.utk.edu > Subject: IPP> Re: On clarifying the proposal for a new IPP scheme > Date: Monday, July 06, 1998 4:26 PM > > > Proposal for an IPP scheme > > > > This is a proposal for the registration of a new URL scheme "ipp". > > The syntax for the new IPP scheme would be identical to the existing > > "http" scheme except for the scheme name itself: > > > > ipp://host[:port]/ > > > > Associated with this new IPP scheme would be an IANA-assigned TCP port > > number, which would be the default port number used by clients to > > contact IPP servers that are represented by IPP URLs. > > > > The IPP scheme implies all of the same protocol semantics as that of > > the HTTP scheme, except that, by default, the port number used by clients > > to connect to the server is port 631. The semantics for clients > > configured for proxy access is different as described below. > > change this to: > > The IPP scheme implies use of the Internet Printing Protocol, which > is layered on top of the Hypertext Transfer Protocol (HTTP). By > default, IPP clients connect to IPP servers using TCP port 631. > > > When an IPP client obtains an IPP URL, the interpretation of this URL by > > the client can take one of three forms, depending on the configuration > > and implementation of the client: > > > > > > ------------------------------------------------------ > > IPP Client Configured with no proxy server - > > ------------------------------------------------------ > > > > > > When an IPP client (no proxy configured) obtains an IPP-schemed URL such > > as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to > > port 631 on myhost.com, with the following example headers: > > > > POST /myprinter/myqueue HTTP/1.1 > > Host: myhost.com:631 > > change the above line to: > > Host: myhost.com > > "631" should probably not appear, since it's the default port. > > However servers should accept the port # if it does appear. > > > Content-type: application/ipp > > Transfer-Encoding: chunked > > ... > > > > ------------------------------------------------------ > > IPP Client Configured for Proxy Service - > > ------------------------------------------------------ > > > > When an IPP client that uses a proxy named "myproxy.com" obtains the URL > > "ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to > > myproxy.com with the following example headers: > > > > POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 > > Host: myproxy.com:631 > > Content-type: application/ipp > > Transfer-Encoding: chunked > > ... > > > > It is likely that existing proxies will not understand IPP URLs, > > so the RequestURI SHOULD use the HTTP form of the URL. > > > This section needs justification - why should an IPP client talk to an > HTTP proxy rather than talking directly to the IPP server, unless > the reason is to circumvent the local site's filtering of outbound > traffic on port 631? (There may well be a good reason, but offhand I > can't think of one.) The corporate HTTP proxy was the number one reason identified. Alot of corporations using application gateways for firewalls (like proxies) will not have a special app gateway for IPP. Therefore, the case outlined above is probably the most widely deployed proxy scenario. Again, this is the case where HTTP traffic (and like it or not, IPP is HTTP traffic) is always gatewayed through an HTTP proxy and no generic firewall product (like Checkpoint, etc.) is in use. If a site uses HTTP proxies and SOCKS style approaches for isolation, this technique is basically "the" way to do this. > > > ------------------------------------------------------- > > IPP Clients with HTTP-only constraints > > ------------------------------------------------------- > > If a particular IPP client implementation uses a pre-packaged HTTP library > > or HTTP class that only supports HTTP-schemed URLs, then the following > > operation would be required: > > > > - The IPP client obtains the IPP-schemed URL and converts it to the > > following form: > > "http://myhost.com:631/myprinter/myqueue" > > > > The client then submits this URL to the pre-packaged HTTP library API. > > (FWIW, This is an implementation issue. As long as the protocol on the wire > is the same, IETF doesn't care what you have to do to talk to an API.) I agree. This scenario was put in for *informational* reasons, and specifically to address a particular WG member's concerns. Whether this scenario would be included in our final spec is "up for grabs", it probably shouldn't be normative text if it is included. > > > > Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers > > using a requestURI specified in #1 below. However, RFC 2068 states that > > HTTP 1.1 > > servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be > > able to > > accept requestURIs as specified in #2 and #3 as well. > > > > > > 1. A "abs_path" URL (e.g., /myprinter/myqueue) > > 2. A full HTTP URL (e.g., http://myhost.com:631/myprinter/myqueue) > > 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) > > Servers MUST treat all of above forms as equivalent. I believe that is implied by the text. > > Servers MAY provide different services at different domains using > either full URLs (those that include the domain), or the Host header > (if one is supplied by the client) to distinguish one domain from another. > Servers that look at the Host: request header field MUST treat > "Host: foo.com" and "Host: foo.com:631" as equivalent. > Sounds ok I guess. > > Finally: > > The use of http: URLs within IPP is only to allow reuse of HTTP libraries, > (or HTTP proxies). Within IPP protocol elements, ipp: URLs MUST always > be used for URLs that refer to IPP objects. It depends on what kind of IPP object you're talking about.. We have printer-object and job-objects. We can probably get away with using MUST in the case of printer-objects, but for job-objects, it's probably not the case but we'll see. I agree that within IPP protocol elements we SHOULD attempt to use "ipp" URLs when it makes sense. Randy > > Keith From ipp-owner@pwg.org Tue Jul 7 10:47:28 1998 Delivery-Date: Tue, 07 Jul 1998 10:47:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03285 for ; Tue, 7 Jul 1998 10:47:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02776 for ; Tue, 7 Jul 1998 10:49:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA23276 for ; Tue, 7 Jul 1998 10:47:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 10:43:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA22714 for ipp-outgoing; Tue, 7 Jul 1998 10:42:03 -0400 (EDT) Message-Id: <199807071441.KAA03123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-10.txt Date: Tue, 07 Jul 1998 10:41:53 -0400 Sender: owner-ipp@pwg.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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-10.txt Pages : 188 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 10:57:27 1998 Delivery-Date: Tue, 07 Jul 1998 10:57:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03621 for ; Tue, 7 Jul 1998 10:57:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02905 for ; Tue, 7 Jul 1998 10:59:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA23955 for ; Tue, 7 Jul 1998 10:57:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 10:53:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23373 for ipp-outgoing; Tue, 7 Jul 1998 10:51:31 -0400 (EDT) Message-Id: <199807071451.KAA03433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 10:51:22 -0400 Sender: owner-ipp@pwg.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 : Requirements for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. The full set of IPP documents include: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure and Model and Protocol for the Internet Printing Protocol 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 11:04:23 1998 Delivery-Date: Tue, 07 Jul 1998 11:04:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA03802 for ; Tue, 7 Jul 1998 11:04:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03013 for ; Tue, 7 Jul 1998 11:06:41 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24589 for ; Tue, 7 Jul 1998 11:04:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 10:58:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23363 for ipp-outgoing; Tue, 7 Jul 1998 10:51:25 -0400 (EDT) Message-Id: <199807071451.KAA03416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-rat-03.txt Date: Tue, 07 Jul 1998 10:51:14 -0400 Sender: owner-ipp@pwg.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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-03.txt Pages : 9 Date : 06-Jul-98 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-rat-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 11:13:04 1998 Delivery-Date: Tue, 07 Jul 1998 11:13:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04046 for ; Tue, 7 Jul 1998 11:13:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03113 for ; Tue, 7 Jul 1998 11:15:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25718 for ; Tue, 7 Jul 1998 11:13:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 11:04:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23353 for ipp-outgoing; Tue, 7 Jul 1998 10:51:16 -0400 (EDT) Message-Id: <199807071451.KAA03399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-lpd-ipp-map-04.txt Date: Tue, 07 Jul 1998 10:51:05 -0400 Sender: owner-ipp@pwg.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) : J. Martin, T. Hasting, R. Herriot, N. Jacobs Filename : draft-ietf-ipp-lpd-ipp-map-04.txt Pages : 24 Date : 06-Jul-98 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 11:13:59 1998 Delivery-Date: Tue, 07 Jul 1998 11:14:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04057 for ; Tue, 7 Jul 1998 11:13:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03122 for ; Tue, 7 Jul 1998 11:16:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25838 for ; Tue, 7 Jul 1998 11:13:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 11:07:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA23343 for ipp-outgoing; Tue, 7 Jul 1998 10:50:13 -0400 (EDT) Message-Id: <199807071450.KAA03353@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-06.txt Date: Tue, 07 Jul 1998 10:50:03 -0400 Sender: owner-ipp@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-06.txt Pages : 33 Date : 06-Jul-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 12:46:54 1998 Delivery-Date: Tue, 07 Jul 1998 13:01:42 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA07200 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 12:45:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03123; Tue, 7 Jul 1998 10:41:53 -0400 (EDT) Message-Id: <199807071441.KAA03123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-10.txt Date: Tue, 07 Jul 1998 10:41:53 -0400 Sender: scoya@ns.cnri.reston.va.us --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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-10.txt Pages : 188 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 12:56:32 1998 Delivery-Date: Tue, 07 Jul 1998 13:09:53 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA07509 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 12:55:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03353; Tue, 7 Jul 1998 10:50:04 -0400 (EDT) Message-Id: <199807071450.KAA03353@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-06.txt Date: Tue, 07 Jul 1998 10:50:03 -0400 Sender: scoya@ns.cnri.reston.va.us --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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-06.txt Pages : 33 Date : 06-Jul-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 13:06:30 1998 Delivery-Date: Tue, 07 Jul 1998 13:18:48 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA07944 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 13:05:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03399; Tue, 7 Jul 1998 10:51:05 -0400 (EDT) Message-Id: <199807071451.KAA03399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-lpd-ipp-map-04.txt Date: Tue, 07 Jul 1998 10:51:05 -0400 Sender: scoya@ns.cnri.reston.va.us --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) : J. Martin, T. Hasting, R. Herriot, N. Jacobs Filename : draft-ietf-ipp-lpd-ipp-map-04.txt Pages : 24 Date : 06-Jul-98 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 13:16:29 1998 Delivery-Date: Tue, 07 Jul 1998 13:30:03 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA08359 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 13:15:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03416; Tue, 7 Jul 1998 10:51:15 -0400 (EDT) Message-Id: <199807071451.KAA03416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-03.txt Date: Tue, 07 Jul 1998 10:51:14 -0400 Sender: scoya@ns.cnri.reston.va.us --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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-03.txt Pages : 9 Date : 06-Jul-98 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-rat-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 13:26:30 1998 Delivery-Date: Tue, 07 Jul 1998 13:39:07 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA08757 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 13:25:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03433; Tue, 7 Jul 1998 10:51:23 -0400 (EDT) Message-Id: <199807071451.KAA03433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 10:51:22 -0400 Sender: scoya@ns.cnri.reston.va.us --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 : Requirements for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. The full set of IPP documents include: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure and Model and Protocol for the Internet Printing Protocol 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 13:48:29 1998 Delivery-Date: Tue, 07 Jul 1998 13:48:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA09709 for ; Tue, 7 Jul 1998 13:48:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04462 for ; Tue, 7 Jul 1998 13:50:48 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA26807 for ; Tue, 7 Jul 1998 13:48:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 13:43:30 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26240 for ipp-outgoing; Tue, 7 Jul 1998 13:40:43 -0400 (EDT) Message-Id: <3.0.5.32.19980707103947.00b3db10@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 7 Jul 1998 10:39:47 PDT To: Paul Moore , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded [Disable-Accepting-Jobs] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org >At 10:49 6/29/98 PDT, Paul Moore wrote: >to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >Describes 7 new operations that MS may be using for IPP1.0 > >We should discuss whther we want to make any of these standard extensions > snip... > >PausePrinter > >Requests that the printer stops scheduling new jobs. Any job that is currently >being printed is completed. The printer will still accept new jobs. > >Current Code: 0X4001 > >Access Rights: The requesting user must be an administrator of the printer > > >ResumePrinter > >Un-pauses a printer (see PausePrinter). > >Access Rights: The requesting user must be an administrator of the printer > Another pair of administrative operations that are strongly related to these and which would set the existing "printer-accepting-jobs" Printer Description attribute and relate to the proposed notification event (to be added to the Printer MIB): 'printer-is-accepting-jobs', 'printer-is-not-accepting-jobs' would be to add a pair of operations: Disable-Accepding-Jobs Causes the Printer object to no longer accept jobs, i.e., the Printer object MUST reject further Print-Job, Print-URI, Validate-Job, and Create-Job operations. If one of these operations is attempted to be submitted to the Printer object, the Printer object MUST reject the request and return the 'server-error-not-accepting-jobs' status code. The Printer object MUST continue to accept all other operations, including Add-Document and Send-Document operations, if supported, so that a partial job can be closed and printed. All currently submitted jobs continue to scheduled and printed. The Printer object sets its "printer-accepting-jobs" to 'false'. The Printer object MUST accept this operation no matter what state the Printer object is in, but MUST reject the operation if the value of the "printer-accepting-jobs" is already 'false'. This operation does not change the value of the Printer's "printer-state" attribute. Access Rights: The requesting user must be an administrator of the printer Enable-Accepting-Jobs Enables the Printer object to accept jobs. The Printer object sets its "printer-accepting-jobs" to 'true'. The Printer object MUST accept this operation no matter what state the Printer object is in, but MUST reject the operation if the value of its "printer-accepting-jobs" is already 'true'. This operation does not change the value of the Printer's "printer-state" attribute. Access Rights: The requesting user must be an administrator of the printer ISSUE: What should the power up value of the Printer's "printer-is-accepting-jobs" attribute be: 'true', 'false', depends on site policy, depends on implementation? From ipp-owner@pwg.org Tue Jul 7 14:33:21 1998 Delivery-Date: Tue, 07 Jul 1998 14:33:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11458 for ; Tue, 7 Jul 1998 14:33:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA04883 for ; Tue, 7 Jul 1998 14:35:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA27539 for ; Tue, 7 Jul 1998 14:33:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 14:28:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA26969 for ipp-outgoing; Tue, 7 Jul 1998 14:25:49 -0400 (EDT) Message-Id: <199807071825.OAA11162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 14:25:38 -0400 Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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 : Design Goals for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 The design goals document, Design Goals for an Internet Printing Protocol, takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 7 14:36:34 1998 Delivery-Date: Tue, 07 Jul 1998 14:50:45 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA11523 for ietf-123-outbound.10@ietf.org; Tue, 7 Jul 1998 14:35:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11162; Tue, 7 Jul 1998 14:25:38 -0400 (EDT) Message-Id: <199807071825.OAA11162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 14:25:38 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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 : Design Goals for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 The design goals document, Design Goals for an Internet Printing Protocol, takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 15:58:53 1998 Delivery-Date: Tue, 07 Jul 1998 15:58:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA13704 for ; Tue, 7 Jul 1998 15:58:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05865 for ; Tue, 7 Jul 1998 16:01:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA28482 for ; Tue, 7 Jul 1998 15:58:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 15:53:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27874 for ipp-outgoing; Tue, 7 Jul 1998 15:47:29 -0400 (EDT) Message-Id: <199807071947.PAA16460@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> Call for implementations cc: moore@cs.utk.edu reply-to: moore@cs.utk.edu From: Keith Moore Date: Tue, 07 Jul 1998 15:47:19 -0400 Sender: owner-ipp@pwg.org folks, I'm writing up the review sheet for IESG, and one of the questions is whether there are already implementations. (it helps if there are). I know that some of you have implementations, but I don't remember specifically who has claimed to implement the protocol. So if you have a prototype implementation of IPP, and are willing to claim this in the announcement, please let me know by private mail. thanks, Keith From ipp-owner@pwg.org Tue Jul 7 16:03:45 1998 Delivery-Date: Tue, 07 Jul 1998 16:03:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13846 for ; Tue, 7 Jul 1998 16:03:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05924 for ; Tue, 7 Jul 1998 16:06:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA29109 for ; Tue, 7 Jul 1998 16:03:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 15:59:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28067 for ipp-outgoing; Tue, 7 Jul 1998 15:54:54 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071441.KAA03123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-10.txt Date: Tue, 07 Jul 1998 10:41:53 -0400 X-UIDL: 619a31d6eabc4a4d5451f03a7d5a0f1e X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-10.txt Pages : 188 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164022.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 16:13:22 1998 Delivery-Date: Tue, 07 Jul 1998 16:13:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14078 for ; Tue, 7 Jul 1998 16:13:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05994 for ; Tue, 7 Jul 1998 16:15:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00196 for ; Tue, 7 Jul 1998 16:13:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 16:05:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28077 for ipp-outgoing; Tue, 7 Jul 1998 15:54:58 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071451.KAA03399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-lpd-ipp-map-04.txt Date: Tue, 07 Jul 1998 10:51:05 -0400 X-UIDL: 53eb04ef85a2c5bce50da590982ada1d X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.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) : J. Martin, T. Hasting, R. Herriot, N. Jacobs Filename : draft-ietf-ipp-lpd-ipp-map-04.txt Pages : 24 Date : 06-Jul-98 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. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. 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 implementers. 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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164101.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 16:15:05 1998 Delivery-Date: Tue, 07 Jul 1998 16:15:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14126 for ; Tue, 7 Jul 1998 16:15:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06023 for ; Tue, 7 Jul 1998 16:17:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA00446 for ; Tue, 7 Jul 1998 16:15:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 16:07:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA28066 for ipp-outgoing; Tue, 7 Jul 1998 15:54:54 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071450.KAA03353@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-06.txt Date: Tue, 07 Jul 1998 10:50:03 -0400 X-UIDL: f7a91d2a7ce6fbde605578be6402967d X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.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. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-06.txt Pages : 33 Date : 06-Jul-98 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 [dpa]. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Requirements for an Internet Printing Protocol [ipp-req] Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Protocol Specification (this document) The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and printer (server) side components. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164050.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 16:31:36 1998 Delivery-Date: Tue, 07 Jul 1998 16:31:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14591 for ; Tue, 7 Jul 1998 16:31:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06105 for ; Tue, 7 Jul 1998 16:33:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01613 for ; Tue, 7 Jul 1998 16:31:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 16:22:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29540 for ipp-outgoing; Tue, 7 Jul 1998 16:09:01 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071825.OAA11162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 14:25:38 -0400 X-UIDL: 5076275422d9f8f01ab4daab1de6a266 X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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 : Design Goals for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 The design goals document, Design Goals for an Internet Printing Protocol, takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980707141429.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 16:33:28 1998 Delivery-Date: Tue, 07 Jul 1998 16:33:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14609 for ; Tue, 7 Jul 1998 16:33:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06121 for ; Tue, 7 Jul 1998 16:35:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA01916 for ; Tue, 7 Jul 1998 16:33:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 16:23:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29298 for ipp-outgoing; Tue, 7 Jul 1998 16:07:07 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071451.KAA03433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-req-02.txt Date: Tue, 07 Jul 1998 10:51:22 -0400 X-UIDL: a1551b00586b668c1c6a53f0b3446bb0 X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.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 : Requirements for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-02.txt Pages : 57 Date : 06-Jul-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. The full set of IPP documents include: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure and Model and Protocol for the Internet Printing Protocol 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-req-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-req-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164129.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 16:37:03 1998 Delivery-Date: Tue, 07 Jul 1998 16:37:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14670 for ; Tue, 7 Jul 1998 16:37:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06133 for ; Tue, 7 Jul 1998 16:39:22 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02383 for ; Tue, 7 Jul 1998 16:36:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 16:30:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA29300 for ipp-outgoing; Tue, 7 Jul 1998 16:07:08 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <199807071451.KAA03416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-rat-03.txt Date: Tue, 07 Jul 1998 10:51:14 -0400 X-UIDL: 4b92bb053daa0468e4a0e7bcda41b1dd X-MDaemon-Deliver-To: ipp@pwg.org Sender: owner-ipp@pwg.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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-03.txt Pages : 9 Date : 06-Jul-98 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: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol 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-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-rat-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980706164115.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Tue Jul 7 17:27:41 1998 Delivery-Date: Tue, 07 Jul 1998 17:27:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA15871 for ; Tue, 7 Jul 1998 17:27:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06464 for ; Tue, 7 Jul 1998 17:30:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03325 for ; Tue, 7 Jul 1998 17:27:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 17:23:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02739 for ipp-outgoing; Tue, 7 Jul 1998 17:17:48 -0400 (EDT) Message-Id: <199807072116.RAA17464@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Randy Turner" cc: "Keith Moore" , "Tom Hastings" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> On clarifying the proposal for a new IPP scheme In-reply-to: Your message of "Mon, 06 Jul 1998 23:18:10 PDT." <199807070619.XAA19325@slafw.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Jul 1998 17:16:11 -0400 Sender: owner-ipp@pwg.org > If you can wait a couple of days, we will forward you a *final* > version of this proposal before you forward this to the > IESG......(?) yes, I'll wait until I receive a "final" version from the chair. Keith From ipp-owner@pwg.org Tue Jul 7 17:52:54 1998 Delivery-Date: Tue, 07 Jul 1998 17:52:54 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16319 for ; Tue, 7 Jul 1998 17:52:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06567 for ; Tue, 7 Jul 1998 17:54:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04036 for ; Tue, 7 Jul 1998 17:52:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 17:48:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03446 for ipp-outgoing; Tue, 7 Jul 1998 17:46:31 -0400 (EDT) Message-Id: <3.0.5.32.19980707144539.00a26c80@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 7 Jul 1998 14:45:39 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Last Call: Internet X.509 Public Key Infrastructure Certificate Management Protocols to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I believe that these are the documents that are still holding up TLS. At least they have now progressed to the IESG Last Call stage. Carl-Uno >To: IETF-Announce:; >Cc: ietf-pkix@tandem.com >From: The IESG >SUBJECT: Last Call: Internet X.509 Public Key Infrastructure > Certificate Management Protocols to Proposed Standard >Reply-to: iesg@ietf.org >Date: Tue, 7 Jul 1998 11:09:13 PDT >Sender: scoya@ns.cnri.reston.va.us > > >The IESG has received a request from the Public-Key Infrastructure >(X.509) Working Group to consider the following two Internet-Drafts for >publication as Proposed Standards: > > o Internet X.509 Public Key Infrastructure Certificate Management > Protocols > > > o Internet X.509 Certificate Request Message Format > > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by July 21, 1998. > >Files can be obtained via: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki3cmp-08.txt >ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jul 7 17:58:09 1998 Delivery-Date: Tue, 07 Jul 1998 17:58:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16368 for ; Tue, 7 Jul 1998 17:58:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06612 for ; Tue, 7 Jul 1998 18:00:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04685 for ; Tue, 7 Jul 1998 17:58:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 17:54:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA03798 for ipp-outgoing; Tue, 7 Jul 1998 17:50:54 -0400 (EDT) Message-Id: <3.0.5.32.19980707145001.0112de10@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 7 Jul 1998 14:50:01 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - New drafts with old text Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I assume that you are all confused about some of the new IPP draft document announcements that have come round. Somebody in the IETF secretariat has simply taken the previous announcements and just changed the version numbers on the documents - sigh.. I have written to the IETF secretariat and complained. The first document has now been re-announced with the updated info, the rest should hopefully follow soon. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jul 7 18:22:53 1998 Delivery-Date: Tue, 07 Jul 1998 18:22:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA16603 for ; Tue, 7 Jul 1998 18:22:53 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06758 for ; Tue, 7 Jul 1998 18:25:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05446 for ; Tue, 7 Jul 1998 18:22:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 18:18:28 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA04842 for ipp-outgoing; Tue, 7 Jul 1998 18:14:20 -0400 (EDT) Message-Id: <3.0.5.32.19980707151402.00ba5d70@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 7 Jul 1998 15:14:02 PDT To: Paul Moore , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded [Disable-Accepting-Jobs] In-Reply-To: <3.0.5.32.19980707103947.00b3db10@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org There seems to be a useful distinction between disabling an IPP Printer object from accepting jobs for its device (or its devices when it controls more than one device) - attached previously sent proposal for Disable-Accepting-Jobs and Enable-Accepting-Jobs and disabling the IPP Printer from submitting jobs to the device (MS Pause-Job semantics) while the IPP Printer continues to accept jobs for the device. One way to get both would be to pattern the Disable-Accepting-Jobs/Enable-Accepting-Jobs after the extension for accessing MIBs, in which we introduced the Device object. The device object is selectable in Get-Printer-Attributes, if the client supplies the "which-device" operation attribute. If the client doesn't supply the "which-device" attribute, the client is talking about the IPP Printer object itself. So we could have a Disable-Accepting-Jobs which has an OPTIONAL "which-device" operation attribute. When supplied, the "which-device" operation attribute prevents the IPP Printer object from submitting additional jobs to the device, but the device keeps printing the current job and any other jobs that it may have. Comments? Tom At 10:39 07/07/98 PDT, Tom Hastings wrote: >>At 10:49 6/29/98 PDT, Paul Moore wrote: >>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>Describes 7 new operations that MS may be using for IPP1.0 >> >>We should discuss whther we want to make any of these standard extensions >> snip... >> >>PausePrinter >> >>Requests that the printer stops scheduling new jobs. Any job that is >currently >being printed is completed. The printer will still accept new jobs. >> >>Current Code: 0X4001 >> >>Access Rights: The requesting user must be an administrator of the printer >> >> >>ResumePrinter >> >>Un-pauses a printer (see PausePrinter). >> >>Access Rights: The requesting user must be an administrator of the printer >> > >Another pair of administrative operations that are strongly related to these >and which would set the existing "printer-accepting-jobs" Printer Description >attribute and relate to the proposed notification event (to be added to >the Printer MIB): 'printer-is-accepting-jobs', 'printer-is-not-accepting-jobs' >would be to add a pair of operations: > > >Disable-Accepding-Jobs > >Causes the Printer object to no longer accept jobs, i.e., the Printer >object MUST reject further Print-Job, Print-URI, Validate-Job, and >Create-Job operations. If one of these operations is attempted to be >submitted to the >Printer object, the Printer object MUST reject the request and return >the 'server-error-not-accepting-jobs' status code. The Printer object >MUST continue to accept all other operations, including Add-Document and >Send-Document operations, if supported, so that a partial job can be >closed and printed. All currently submitted jobs continue to scheduled >and printed. > >The Printer object sets its "printer-accepting-jobs" to 'false'. >The Printer object MUST accept this operation no matter what state the >Printer object is in, but MUST reject the operation if the value of the >"printer-accepting-jobs" is already 'false'. This operation does not >change the value of the Printer's "printer-state" attribute. > >Access Rights: The requesting user must be an administrator of the printer > > > >Enable-Accepting-Jobs > >Enables the Printer object to accept jobs. The Printer object sets its >"printer-accepting-jobs" to 'true'. The Printer object MUST accept this >operation no matter what state the Printer object is in, but MUST reject >the operation if the value of its "printer-accepting-jobs" is already >'true'. This operation does not change the value of the Printer's >"printer-state" attribute. > >Access Rights: The requesting user must be an administrator of the printer > > >ISSUE: What should the power up value of the Printer's >"printer-is-accepting-jobs" attribute be: 'true', 'false', depends on >site policy, depends >on implementation? > > From ipp-owner@pwg.org Tue Jul 7 18:28:46 1998 Delivery-Date: Tue, 07 Jul 1998 18:28:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA16676 for ; Tue, 7 Jul 1998 18:28:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06793 for ; Tue, 7 Jul 1998 18:31:06 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA06080 for ; Tue, 7 Jul 1998 18:28:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 18:24:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05317 for ipp-outgoing; Tue, 7 Jul 1998 18:21:50 -0400 (EDT) Message-Id: <3.0.5.32.19980707152130.00c63960@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 7 Jul 1998 15:21:30 PDT To: Paul Moore , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MS-new-operations.htm uploaded [Reprint and job-id] In-Reply-To: <3.0.5.32.19980706223823.0142bbe0@garfield> References: <3.0.5.32.19980706162037.01412930@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I made a mistake in my proposal below about re-using the same job-id on a Reprint-Job (and adding the "number-of-reprints" Job Description attribute). Presumably, the job description attributes, like "job-media-sheets-completed", "job-k-octets-processed", and "job-impressions-completed" are reset on a Reprint-Job. But if the accounting hasn't copied the data, the accounting program has lost some valuable charges. Not resetting such progress attributes doesn't seem to be a good solution. To fix this problem, we should do what ISO DPA finally had to do, namely, have the Printer use a new job-id for the new job (and make a copy of the old job attributes, but not the document data). Then the old job remains in the 'completed', 'aborted', or 'cancelled' state and its Job Description attributes do not get reset. The new job starts off with these job progress job description attributes set to 0, such as "job-media-sheets-completed". Ok? Tom At 22:38 07/06/98 PDT, Tom Hastings wrote: >At 16:20 7/6/98 PDT, Tom Hastings wrote: >>At 10:49 6/29/98 PDT, Paul Moore wrote: >>>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ >>>Describes 7 new operations that MS may be using for IPP1.0 >>> >>>We should discuss whther we want to make any of these standard extensions >> > >One further question about Reprint-Job: > >For ISO DPA Resubmit-Job, we finally decided that a new copy of the job >should be created and assigned a new job-identifier. This was so that >accounting would not get confused with a job that was resubmitted several >times. Also by making a copy, any accounting done using the PWG Job >Monitoring MIB, can be safely done while the job is in the 'completed' >state, even if the job is resubmitted immediately before the accounting >can be gathered for the job just completed, since a new job is created >with a copy of all of the originally submitted attributes. > >For the Reprint-Job, we could do the same and require that the IPP object >return a new job-id and make a copy of the job. On the other hand, since >the user cannot modify the job, a simpler approach to keep the accounting >straight (and reflect the true state of the job), would be to add a Job >Description attribute which is a count >of the number of Reprint-Job operations performed. This "number-of-reprints" >Job Description attribute would be REQUIRED to be supported, if the IPP >object >supports the Reprint-Job operation. An accounting application would take >note of the value for the "number-of-reprints" which is normally 0 if >no Reprint-Job operation has been performed. > >So we can save the harder ISO DPA Modify-Job and Resubmit-Job operations >which modify the job to later. > >Thanks, >Tom > > From ipp-owner@pwg.org Tue Jul 7 20:24:07 1998 Delivery-Date: Tue, 07 Jul 1998 20:24:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA17762 for ; Tue, 7 Jul 1998 20:24:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA07195 for ; Tue, 7 Jul 1998 20:26:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA07284 for ; Tue, 7 Jul 1998 20:24:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 7 Jul 1998 20:18:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA06701 for ipp-outgoing; Tue, 7 Jul 1998 20:14:10 -0400 (EDT) From: don@lexmark.com Message-Id: <199807080006.AA17177@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Tom Hastings Cc: Paul Moore , Ipp@pwg.org Date: Tue, 7 Jul 1998 18:17:56 -0400 Subject: IPP> Disable-Accepding-Jobs & Enable-Accepting-Jobs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org I think we have quickly gone over the edge already. Once we start adding these kind of functions, we are starting the "function creep" process all over again. One of the problems with the existing IPP definition is that taken individually, each and ever function and enhancement we added made sense. However, on the whole, IPP swelled to enormous proportions. We need to strongly push back on going beyond the simple MS operational enhancements until we have some real world experience and customer feedback on IPP 1.0. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Wed Jul 8 09:43:09 1998 Delivery-Date: Wed, 08 Jul 1998 09:43:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04598 for ; Wed, 8 Jul 1998 09:43:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA08962 for ; Wed, 8 Jul 1998 09:43:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23198 for ; Wed, 8 Jul 1998 09:43:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 8 Jul 1998 09:28:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22054 for ipp-outgoing; Wed, 8 Jul 1998 09:25:59 -0400 (EDT) Message-Id: <199807081325.JAA04126@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-rat-03.txt Date: Wed, 08 Jul 1998 09:25:53 -0400 Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-03.txt Pages : 9 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-rat-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-rat-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091157.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Jul 8 09:43:10 1998 Delivery-Date: Wed, 08 Jul 1998 09:43:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04603 for ; Wed, 8 Jul 1998 09:43:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA08964 for ; Wed, 8 Jul 1998 09:43:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23201 for ; Wed, 8 Jul 1998 09:43:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 8 Jul 1998 09:33:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22024 for ipp-outgoing; Wed, 8 Jul 1998 09:25:34 -0400 (EDT) Message-Id: <199807081325.JAA04072@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-06.txt Date: Wed, 08 Jul 1998 09:25:26 -0400 Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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: Encoding and Transport Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-06.txt Pages : 33 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708090951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708090951.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Jul 8 09:52:12 1998 Delivery-Date: Wed, 08 Jul 1998 09:52:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04855 for ; Wed, 8 Jul 1998 09:52:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA09022 for ; Wed, 8 Jul 1998 09:52:10 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA24302 for ; Wed, 8 Jul 1998 09:52:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 8 Jul 1998 09:44:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22034 for ipp-outgoing; Wed, 8 Jul 1998 09:25:43 -0400 (EDT) Message-Id: <199807081325.JAA04091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-10.txt Date: Wed, 08 Jul 1998 09:25:32 -0400 Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-10.txt Pages : 188 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091126.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Wed Jul 8 09:53:36 1998 Delivery-Date: Wed, 08 Jul 1998 09:53:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04897 for ; Wed, 8 Jul 1998 09:53:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA09032 for ; Wed, 8 Jul 1998 09:53:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA24530 for ; Wed, 8 Jul 1998 09:53:29 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 8 Jul 1998 09:46:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22044 for ipp-outgoing; Wed, 8 Jul 1998 09:25:48 -0400 (EDT) Message-Id: <199807081325.JAA04109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-lpd-ipp-map-04.txt Date: Wed, 08 Jul 1998 09:25:42 -0400 Sender: owner-ipp@pwg.org --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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) : J. Martin, T. Hasting, R. Herriot, N. Jacobs Filename : draft-ietf-ipp-lpd-ipp-map-04.txt Pages : 24 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-lpd-ipp-map-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091140.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jul 8 10:56:30 1998 Delivery-Date: Wed, 08 Jul 1998 11:10:49 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA07013 for ietf-123-outbound.10@ietf.org; Wed, 8 Jul 1998 10:55:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04072; Wed, 8 Jul 1998 09:25:27 -0400 (EDT) Message-Id: <199807081325.JAA04072@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-protocol-06.txt Date: Wed, 08 Jul 1998 09:25:26 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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: Encoding and Transport Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-06.txt Pages : 33 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708090951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708090951.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jul 8 11:08:06 1998 Delivery-Date: Wed, 08 Jul 1998 11:18:31 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA07450 for ietf-123-outbound.10@ietf.org; Wed, 8 Jul 1998 11:05:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04091; Wed, 8 Jul 1998 09:25:33 -0400 (EDT) Message-Id: <199807081325.JAA04091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-10.txt Date: Wed, 08 Jul 1998 09:25:32 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-10.txt Pages : 188 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091126.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jul 8 11:17:50 1998 Delivery-Date: Wed, 08 Jul 1998 11:27:38 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA07855 for ietf-123-outbound.10@ietf.org; Wed, 8 Jul 1998 11:15:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04109; Wed, 8 Jul 1998 09:25:42 -0400 (EDT) Message-Id: <199807081325.JAA04109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-lpd-ipp-map-04.txt Date: Wed, 08 Jul 1998 09:25:42 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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) : J. Martin, T. Hasting, R. Herriot, N. Jacobs Filename : draft-ietf-ipp-lpd-ipp-map-04.txt Pages : 24 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-lpd-ipp-map-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-lpd-ipp-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-lpd-ipp-map-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091140.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jul 8 11:26:48 1998 Delivery-Date: Wed, 08 Jul 1998 11:37:02 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA08193 for ietf-123-outbound.10@ietf.org; Wed, 8 Jul 1998 11:25:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04126; Wed, 8 Jul 1998 09:25:54 -0400 (EDT) Message-Id: <199807081325.JAA04126@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-03.txt Date: Wed, 08 Jul 1998 09:25:53 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart Note: This announcement is a retransmission with a corrected title and abstract. 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 Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-03.txt Pages : 9 Date : 06-Jul-98 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 technologies. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses 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-rat-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-rat-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980708091157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980708091157.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jul 10 00:03:31 1998 Delivery-Date: Fri, 10 Jul 1998 00:03:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA20493 for ; Fri, 10 Jul 1998 00:03:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA18430 for ; Fri, 10 Jul 1998 00:03:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA13191 for ; Fri, 10 Jul 1998 00:03:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 9 Jul 1998 23:58:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA12621 for ipp-outgoing; Thu, 9 Jul 1998 23:55:42 -0400 (EDT) Message-Id: <3.0.5.32.19980709205413.01356100@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 9 Jul 1998 20:54:13 PDT To: don@lexmark.com From: Tom Hastings Subject: Re: IPP> Disable-Accepding-Jobs & Enable-Accepting-Jobs Cc: Paul Moore , Ipp@pwg.org In-Reply-To: <199807080006.AA17177@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I agree that we need to be careful on "function creep". On the other hand: 1. some of the useful new operations being proposed are also only for operators, such as PausePrinter and PurgePrinter. 2. More over, a way to disable/disable an IPP Printer from accepting jobs fits in as an optional operation for use with IPP/1.0, in that there is already a Printer attribute: "printer-is-accepting" jobs that has no way to be set true or false in the protocol, even though there is also an IPP/1.0 error status to return if the value is 'false' and a client attempts to submit a job. 3. Finally, the operations being proposed (PausePrinter) also stop new jobs from being submitted from an IPP Printer to a device, so also being able to prevent jobs from being submitted to the IPP Printer is a natural operation to have. Tom At 15:17 07/07/98 PDT, don@lexmark.com wrote: >I think we have quickly gone over the edge already. Once we start adding >these kind of functions, we are starting the "function creep" process all >over again. One of the problems with the existing IPP definition is that >taken individually, each and ever function and enhancement we added made >sense. However, on the whole, IPP swelled to enormous proportions. We >need to strongly push back on going beyond the simple MS operational >enhancements until we have some real world experience and customer feedback >on IPP 1.0. > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > From ipp-owner@pwg.org Fri Jul 10 04:21:20 1998 Delivery-Date: Fri, 10 Jul 1998 04:21:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA26203 for ; Fri, 10 Jul 1998 04:21:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA18863 for ; Fri, 10 Jul 1998 04:21:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id EAA19155 for ; Fri, 10 Jul 1998 04:21:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Jul 1998 04:14:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id EAA18101 for ipp-outgoing; Fri, 10 Jul 1998 04:10:31 -0400 (EDT) Message-Id: <1.5.4.32.19980710080714.00758eb0@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: Fri, 10 Jul 1998 01:07:14 -0700 To: ipp@pwg.org From: Keith Moore (by way of Carl-Uno Manros ) Subject: IPP> Call for implementations - Reminder Sender: owner-ipp@pwg.org All, This is a reminder to everybody who is working on prototypes, alphas, betas, or products for IPP clients or IPP servers to please send a note to Keith to give him a proper view of the number of projects that already work on IPP. This is not a question about if and when you might plan to release products, I assume that Keith will handle any information as confidential if you tell him so. It might also be a good idea to inform him about the dates of the drafts that you have written code against. Thanks, Carl-Uno -------- folks, I'm writing up the review sheet for IESG, and one of the questions is whether there are already implementations. (it helps if there are). I know that some of you have implementations, but I don't remember specifically who has claimed to implement the protocol. So if you have a prototype implementation of IPP, and are willing to claim this in the announcement, please let me know by private mail. thanks, Keith From adm Fri Jul 10 09:09:25 1998 Delivery-Date: Fri, 10 Jul 1998 09:20:28 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id JAA27888 for ietf-123-outbound.10@ietf.org; Fri, 10 Jul 1998 09:05:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27757; Fri, 10 Jul 1998 09:01:07 -0400 (EDT) Message-Id: <199807101301.JAA27757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-ipdv-01.txt Date: Fri, 10 Jul 1998 09:01:06 -0400 Sender: scoya@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Instantaneous Packet Delay Variation Metric for IPPM Author(s) : C. Demichelis Filename : draft-ietf-ippm-ipdv-01.txt Pages : 15 Date : 09-Jul-98 This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on statistics of the difference in One-way Delay of consecutive packets. This particular definition of variation is called "Instantaneous Packet Delay Variation (ipdv)". The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. In the second case it allows an evaluation of the relative skew. Measurements performed on both directions (Two-ways measurements) allow a better estimation of clock differences. The precision that can be obtained is evaluated. This memo is intended to have, as much as possible, the structure of the ippm draft on one-way delay metric. 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-ippm-ipdv-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-ipdv-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980709092814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-ipdv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-ipdv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980709092814.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-owner@pwg.org Fri Jul 10 14:14:56 1998 Delivery-Date: Fri, 10 Jul 1998 14:15:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA02750 for ; Fri, 10 Jul 1998 14:14:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21649 for ; Fri, 10 Jul 1998 14:14:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA26460 for ; Fri, 10 Jul 1998 14:14:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Jul 1998 14:04:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA25889 for ipp-outgoing; Fri, 10 Jul 1998 13:59:49 -0400 (EDT) Message-Id: <3.0.5.32.19980710105922.009ce5f0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Jul 1998 10:59:22 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Internet-Draft Cutoff Date Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, Carl-Uno >To: IETF-Announce:; >Subject: Internet-Draft Cutoff Date >From: Internet-Drafts >Date: Thu, 9 Jul 1998 11:49:19 PDT >Sender: scoya@ns.cnri.reston.va.us > > >The cut-off for Internet-Draft submissions prior to the Chicago IETF >meeting is Friday, August 7, 1998 at 5pm US-ET. Internet-Drafts >received after this time will not be announced nor made available in >the Internet-drafts Directories. > >Internet-Draft submissions received after the IETF Meeting begins >(after August 23) will be processed, but announcements will not >be sent until after the meeting. > >Thank you for your understanding and cooperation. Please do not >hesitate to contact the Secretariat if you have any questions or >concerns. > > > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jul 10 20:04:58 1998 Delivery-Date: Fri, 10 Jul 1998 20:04:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA07540 for ; Fri, 10 Jul 1998 20:04:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA23259 for ; Fri, 10 Jul 1998 20:04:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA29387 for ; Fri, 10 Jul 1998 20:04:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Jul 1998 19:59:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28832 for ipp-outgoing; Fri, 10 Jul 1998 19:55:35 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 10 Jul 1998 17:55:04 -0600 From: "Hugo Parra" To: ipp@pwg.org Cc: moore@cs.utk.edu Subject: Re: IPP> Call for implementations Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA07540 >>> Keith Moore 07/07 1:47 PM >>> folks, I'm writing up the review sheet for IESG, and one of the questions is whether there are already implementations. (it helps if there are). I know that some of you have implementations, but I don't remember specifically who has claimed to implement the protocol. So if you have a prototype implementation of IPP, and are willing to claim this in the announcement, please let me know by private mail. thanks, Keith From ipp-owner@pwg.org Fri Jul 10 22:34:59 1998 Delivery-Date: Fri, 10 Jul 1998 22:34:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA09736 for ; Fri, 10 Jul 1998 22:34:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA23490 for ; Fri, 10 Jul 1998 22:34:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA00307 for ; Fri, 10 Jul 1998 22:34:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Jul 1998 22:29:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29705 for ipp-outgoing; Fri, 10 Jul 1998 22:26:35 -0400 (EDT) Message-Id: <1.5.4.32.19980711022345.008755ac@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: Fri, 10 Jul 1998 19:23:45 -0700 To: ipp@pwg.org From: Keith Moore (by way of Carl-Uno Manros ) Subject: IPP> Re: IPP Scheme Sender: owner-ipp@pwg.org IPP WG members, Please look over Keith's reply to each of the concerns that were raised in the Monterey meeting earlier this week. I would like to have your quick feedback on Keith's latests suggestions. Does his proposed resolutions in combination with the offer to get some real expert help (which we have been loooking for for a long time), change your attitude towards the IPP scheme proposal? Keith would like to get our reaction by July 15th. I will be on the road on July 13 and 14 and will probably only be able to check mail early and late in the day. Carl-Uno > ------------------------------------------------------------------- > Summary Conclusions > ------------------------------------------------------------------- > > The IPP working group has serious concerns regarding integrating a new > "ipp:" URL into our specifications. The following issues have been > raised with regards to usage of the "ipp:" scheme. > > 1. There is currently no defined way for a single "ipp:" URL to > indicate whether or not a particular IPP server offers "secure" > connections. Throughout the IPP model document, numerous > assumptions are made with regards to our usage of the "http:" URL > to reference IPP objects, chief among these assumptions is that > IPP clients treat URL syntax beyond the "host" part of an HTTP URL > as opaque. > > The IPP working group feels that any specification for security > parameters within URL syntax should be a "standard" solution and not > specifically a "one-off" or one-time only solution for IPP. > The effort required to put together a group or effort to accomplish > this is out-of-scope for our current charter. I agree that there is a need to be able to specify the security technology which is to be used, especially because there is currently no effective way for client and server to negotiate security technology. The emerging consensus for indicating authentication technology in a URL is to use an AUTH= parameter. However, as far as I can tell, this parameter has not been extended to specify uses of TLS. However, a separate URL type such as "https" is also insufficient for IPP's purposes. SSL was designed to authenticate servers to clients, not the other way around, and this heritage still shows in TLS. The TLS protocol does not have any way for a server to inform a client about which certificate authorities it trusts. Unless all IPP servers are going to trust the same certificate authority (highly unlikely), an IPP client that talks to different servers will need multiple key certificates (up to one for each IPP server it wants to talk to), and therefore the client either needs to know which certificate to send to each server, or it needs to know which CAs the server supports. If some sort of prior, out-of-band, authorization is used to establish an association between an IPP client and an IPP server, this step will need to return credentials (perhaps an X.509 certificate, perhaps a password for use with digest authentication) that the client can use when authenticating itself to that server. In this case, no extra parameters are needed for the printer URL - rather, the client will internally maintain lists of authentication credentials indexed by the printer name or URL. The authentication method to be used can be considered part of those credentials. If it's desired to make IPP work without prior authorization (and assuming the server requires authentication at all), the client is still going to need to know what authentication method to use and which CAs the server supports. This is more information than can be conveyed in one bit (the difference between using "http" and "https"). > 2. There is no straightforward way to configure HTTP client proxy > capability for "proxying" IPP. Currently, there are specific proxy > configuration options for HTTP clients, such as FTP, GOPHER, HTTP, > WAIS, etc. There is no option for proxying "ipp:" URLs and this > deficiency could lead to confusion for the end user. Also, to correctly > configure a proxy service for IPP, the user will have to "know" > that IPP actually uses HTTP, and that for IPP proxy service the user > must configure an HTTP proxy. I don't understand why this is a problem, because existing web clients can't usefully talk to IPP servers anyway. They can't generate application/ipp requests nor can they parse application/ipp responses. So naturally they don't have configuration options to talk to IPP proxies either. As for the potential for end-user confusion: there's far greater potential for end user confusion if printers are named with http: URLs. I don't think the configuration management issues for proxies are that difficult to deal with. The IPP configuration can simply have a box like: ------------------------------------------------------ [ ] make direct connections to an IPP server [x] tunnel outgong IPP requests through an HTTP proxy. proxy host name: [foo.bar.com] proxy port number: [8080] ------------------------------------------------------ This isn't any worse than for any other protocol. These are nothing in comparison to the configuration management issues for security. How is an IPP client is going to be able to authenticate itself to arbitrary IPP servers around the world? If it uses TLS, it's potentially going to need to have a variety of key certificates on hand (each signed by a different CA), and know which CAs and certificate types are recognized by each server, so that it knows which certificates to send to which servers. > 3. Similar to the end-user configuration problem in #2 above, there is > currently no proxy configuration option for IPP proxy in existing > proxy server software. IPP will be a "special case" wherein the > administrator will have to know the special relationship between > IPP URLs and HTTP URLs. I don't see why this is a problem with the IPP proposal. The IPP proposal is to use an http: URL with an explicit port number, so that it will be compatible with http proxies. > 4. Future use of the "ipp" scheme is compromised by using the new "ipp" > scheme in the translated form implied by the proposed "ipp:" scheme. > The IPP working group would like to reserve use of the "ipp" scheme > for a pure IPP client/server protocol implementation in the future > (one that does not require utilization of an existing HTTP > infrastructure). In this environment, it seems appropriate to attach > the "ipp" URL to this future protocol, rather than the initial IPP > protocol that is just carried in a MIME type within HTTP. > > For example, in a future implementation of an IPP scheme that does > not utilize HTTP, existing IPP clients would still attempt to > translate the "ipp:" scheme into an "http:" scheme, and would do so > incorrectly, since the future "ipp:" scheme protocol might not use > HTTP as a transport. Anytime a new URI scheme name is defined, it is "compromised" against some future use of the scheme name with a different protocol. That's not a real problem; we could always define "ipp2" or some other name for the new protocol. Chances are we'd want to do that anyway; if there were two versions of IPP it would be confusing to use "http" to talk to IPP version 1 and "ipp" to talk to IPP version 2 servers. If what you're saying is that HTTP was a Bad Idea and you want to do something different in the future, that implies that this protocol is not yet suitable for standardization. If a future version of IPP would not make use of the "HTTP infrastructure", then there is no reason *not* to use "ipp:" for the current protocol -- since the only problems with the use of "ipp:" are the lack of support in the HTTP infrastructure. Might as well cross this bridge now. My opinion is that HTTP is a sub-optimal but sufficient transport for IPP, and that it is better to settle on the current version of IPP and make it work with the ipp: URL now, than to try to do it later. By the time there is a completely new printing protocol, it is likely that there will be a standard URI resolution mechanism - which would allow a client to look up an ipp: URL and find out which printing protocols the server supports, before opening up a connection to the server. This would allow a smooth transition from IPP 1.0 to the new protocol, while using the same URLs. > 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme > and transparently translating it to an "http:" scheme An initial > concern was the fact that there was no way to tell that IPP was > actually being used by looking at an HTTP URL. However, publishing > and using only IPP URLs to the user and administrator community might > hide the fact that IPP is actually using HTTP. This is not a problem. IPP's use of HTTP is an implementation artifact, not something that users need to be concerned with. Yes, users might end up needing to know that they can tunnel IPP over an HTTP proxy. But this is easily communicated through user interfaces such as that above. And if this technique is approved, it is likely to be regarded as a convenience. (Some folks on the IAB and IESG are still not convinced that IPP should be able to tunnel over existing proxies; the counter argument is that IPP is going to need proxies anyway, so you might as well use one that already exists.) It's a bit misleading to call this "compound" spoofing, since there is only one layer of "spoofing" going on. > 6. Compound schemes is a new idea and not well understood in its' > ramifications. In the current IANA registry for URL schemes, there > are no examples that indicate that scheme "translation" to another > scheme is required. IPP is the first group to try to layer something on top of HTTP. So naturally there are no examples for how to do this. That's what comes with breaking new ground. Note that the translation is only required to talk to HTTP proxies. The general case is that the IPP client talks directly to the IPP server, and there's no URI translation going on at all. > 7. All applications that include URI/URL recognition features will have > to be updated to include support for the new "ipp:" URL. The applications have to be updated anyway. There are lots of new URI types being defined; any generic URI parsing application that can only handle specific URL types is already broken. And any application that is actually going to make use of ipp: URLs (as opposed to just parsing them), is going to have to be updated to generate application/ipp requests, parse application/ipp results, and otherwise provide a useful user interface to printers. > 8. Existing network infrastructure tools and utilities would need to > be modified in order to understand the "special" relationship > between IPP and HTTP URLs. > > The working group considers IPP printing an "HTTP application", and > therefore the usage of an "ipp:" URL scheme must maintain a special > relationship with "http:" URLs. The definition of such a "compound" > URL scheme, wherein an "ipp:" scheme is layered or translated to an > "http:" scheme, is somewhat unusual, and the impact of such a definition > on the protocol design and deployment is not generally well understood. The IESG considers IPP separate and distinct from normal web service, requiring a separate URI type. The layering of IPP on top of HTTP, while somewhat unusual, does not change this. > This analysis document has identified a partial list of issues regarding > the integration of the new "ipp:" scheme. It is anticipated that other > unforeseen issues exist, since this technique has not been prototyped. > > If the usage model described herein were adopted, these issues raised in > this analysis pose a significant negative impact on the implementation > and deployment of current IPP specifications, as well as potential > interoperability with future revisions of the protocol. This negative impact has to be weighed against the considerable negative impact associated with use of the http: scheme. Summary of my position: 1. I agree that more work needs to be done to specify security level in IPP URLs. The "https" scheme (which wouldn't be accepted anyway) is insufficient, and use of the AUTH= parameter with TLS is not sufficiently well defined for any other URL scheme, to allow IPP to cut-and-paste another specification. Note that these are as much limitations of HTTP and TLS (to fail to provide adequate negotiation of security parameters) as of URLs. If there were a better way for client and server to negotiate security, this would lessen the need to expose this information in the URL. Note that this is much a limitation of HTTP and TLS (to fail to provide adequate negotiation) as of URLs. 2. I believe the "negative impact" claimed by the IPP group is exaggerated, and does not consider the negative impact to the community of overloading the http: URI scheme. I respect the IPP group's concern that translation of IPP URLs while tunneling over HTTP proxies is untried and may cause operational problems. However, the IPP group is ignoring IESG concerns about operational problems that might be caused by reusing HTTP proxies in the first place to circumvent firewall policy, or the confusion resulting from users' inability to distinguish printer URLs from http: URLs. If IPP's use of HTTP proxies causes too many problems, it may be necessary to reconsider using HTTP proxies - or to allow people to use them, but warn that this might not always work. Sooner or later the proxies will support IPP. Of course it's nice if proxies support a new protocol immediately, but if they don't - this is no more of a barrier than any other new protocol has to face. My proposal: The IPP documents will not be approved as a Proposed Standard until they are fixed to use ipp: URLs instead of http: URLs. With an eye toward making them acceptable to IESG while addressing the IPP group's concerns: - I will recruit a team of experts from the HTTP working group and ask them to quickly review the ipp: scheme proposal for potential interoperability problems with proxies. - I will recruit experts from the web and TLS communities to design appropriate URL parameters for use with TLS, which can be shared by other URL schemes besides ipp:. The IPP documents have been submitted for IESG ballot, and may be on IESG's agenda for discussion as early as July 16th. I would therefore like a decision from IPP by July 15th as to whether the IPP working group is willing to pursue this course of action. Note that there may still be other IESG concerns with this protocol, particularly on security. We won't know about those until the IESG finishes its ballot. Keith From ipp-owner@pwg.org Sat Jul 11 17:13:42 1998 Delivery-Date: Sat, 11 Jul 1998 17:13:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA25248 for ; Sat, 11 Jul 1998 17:13:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25044 for ; Sat, 11 Jul 1998 17:13:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14980 for ; Sat, 11 Jul 1998 17:13:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 11 Jul 1998 17:09:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14415 for ipp-outgoing; Sat, 11 Jul 1998 17:06:52 -0400 (EDT) From: don@lexmark.com Message-Id: <199807112106.AA28738@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Sat, 11 Jul 1998 17:00:16 -0400 Subject: IPP> New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org After reading Keith's comments, I think I can capture the arguments on ipp: versus http: .... From ipp-owner@pwg.org Sat Jul 11 17:33:10 1998 Delivery-Date: Sat, 11 Jul 1998 17:33:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA25401 for ; Sat, 11 Jul 1998 17:33:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA25060 for ; Sat, 11 Jul 1998 17:33:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA15641 for ; Sat, 11 Jul 1998 17:33:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 11 Jul 1998 17:29:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15065 for ipp-outgoing; Sat, 11 Jul 1998 17:21:38 -0400 (EDT) From: don@lexmark.com Message-Id: <199807112121.AA28852@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Sat, 11 Jul 1998 17:15:11 -0400 Subject: IPP> New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org After reading Keith's comments, I think I can capture the arguments on ipp: versus http: .... Yes, it is! No, it isn't! Yes, it is! No, it isn't Yes, it is! No, it isn't It seems to me there are few if any clear, overwhelming technical merits on either side of the proposals. The printing community is firm on how it believes customers and users will perceive and use IPP and believes "ipp:" is not the right approach. Since other than encoded within the application/ipp body, "ipp:" is never on the wire, there is no real difference from the network's infrastructure (perhaps with the exception of the security problems of AUTH = or something similar which is another can of worms.) Sorry, but I'm still in favor of the product oriented people (the IPP WG) dealing with user requirements, perception and usability and letting the networking folks (IESG, etc.) handle the infrastructure details. Therefore, I continue to not support the use of "ipp:" as described in the latest text. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Sat Jul 11 19:59:43 1998 Delivery-Date: Sat, 11 Jul 1998 19:59:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26639 for ; Sat, 11 Jul 1998 19:59:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA25293 for ; Sat, 11 Jul 1998 19:59:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA16521 for ; Sat, 11 Jul 1998 19:59:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sat, 11 Jul 1998 19:54:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15956 for ipp-outgoing; Sat, 11 Jul 1998 19:49:09 -0400 (EDT) Message-Id: <199807112349.TAA21923@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: New IPP Scheme In-reply-to: Your message of "Sat, 11 Jul 1998 17:15:11 EDT." <199807112121.AA28852@interlock2.lexmark.com> Date: Sat, 11 Jul 1998 19:49:00 -0400 Sender: owner-ipp@pwg.org > It seems to me there are few if any clear, overwhelming technical merits on > either side of the proposals. The printing community is firm on how it > believes customers and users will perceive and use IPP and believes "ipp:" > is not the right approach. Since other than encoded within the > application/ipp body, "ipp:" is never on the wire, there is no real > difference from the network's infrastructure That's not true. ipp: would appear "on the wire" in all sorts of places -- in HTML documents, LDAP responses, ACAP responses, etc. -- any time someone needs to refer to a printer. Keith From ipp-owner@pwg.org Sun Jul 12 00:31:02 1998 Delivery-Date: Sun, 12 Jul 1998 00:31:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA05790 for ; Sun, 12 Jul 1998 00:31:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA25667 for ; Sun, 12 Jul 1998 00:30:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA17791 for ; Sun, 12 Jul 1998 00:30:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 00:24:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA17236 for ipp-outgoing; Sun, 12 Jul 1998 00:22:00 -0400 (EDT) Message-Id: <199807120424.VAA19119@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 11 Jul 1998 21:18:31 -0700 To: moore@cs.utk.edu, ipp@pwg.org From: Randy Turner Subject: Re: IPP> Re: IPP Scheme In-Reply-To: <1.5.4.32.19980711022345.008755ac@pop3.holonet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Some comments on Keith's responses below. Randy > >> ------------------------------------------------------------------- >> Summary Conclusions >> ------------------------------------------------------------------- >> >> The IPP working group has serious concerns regarding integrating a new >> "ipp:" URL into our specifications. The following issues have been >> raised with regards to usage of the "ipp:" scheme. >> >> 1. There is currently no defined way for a single "ipp:" URL to >> indicate whether or not a particular IPP server offers "secure" >> connections. Throughout the IPP model document, numerous >> assumptions are made with regards to our usage of the "http:" URL >> to reference IPP objects, chief among these assumptions is that >> IPP clients treat URL syntax beyond the "host" part of an HTTP URL >> as opaque. >> >> The IPP working group feels that any specification for security >> parameters within URL syntax should be a "standard" solution and not >> specifically a "one-off" or one-time only solution for IPP. >> The effort required to put together a group or effort to accomplish >> this is out-of-scope for our current charter. > >I agree that there is a need to be able to specify the security >technology which is to be used, especially because there is currently >no effective way for client and server to negotiate security technology. >The emerging consensus for indicating authentication technology in a >URL is to use an AUTH= parameter. However, as far as I can tell, >this parameter has not been extended to specify uses of TLS. > >However, a separate URL type such as "https" is also insufficient for >IPP's purposes. SSL was designed to authenticate servers to clients, >not the other way around, and this heritage still shows in TLS. >The TLS protocol does not have any way for a server to inform a >client about which certificate authorities it trusts. Unless all >IPP servers are going to trust the same certificate authority >(highly unlikely), an IPP client that talks to different servers will >need multiple key certificates (up to one for each IPP server it >wants to talk to), and therefore the client either needs to know which >certificate to send to each server, or it needs to know which CAs >the server supports. I assumed that the client and/or server would use the CA that issued the certicate in the first place. I believe this information is a part of the certificate itself. > >If some sort of prior, out-of-band, authorization is used to establish >an association between an IPP client and an IPP server, this step >will need to return credentials (perhaps an X.509 certificate, perhaps >a password for use with digest authentication) that the client can >use when authenticating itself to that server. In this case, no extra >parameters are needed for the printer URL - rather, the client will >internally maintain lists of authentication credentials indexed by the >printer name or URL. The authentication method to be used can be >considered part of those credentials. > >If it's desired to make IPP work without prior authorization >(and assuming the server requires authentication at all), the >client is still going to need to know what authentication method to >use and which CAs the server supports. This is more information than >can be conveyed in one bit (the difference between using "http" >and "https"). The authentication method is negotiated when the client sends its "preferred" list of auth/privacy methods to use during TLS startup. It is assumed that for "server-initiated" authentication, that pre-configuration of the server's idea of "who" is authorized to use the resource will be done so the credentials of the client can be "checked". > >> 2. There is no straightforward way to configure HTTP client proxy >> capability for "proxying" IPP. Currently, there are specific proxy >> configuration options for HTTP clients, such as FTP, GOPHER, HTTP, >> WAIS, etc. There is no option for proxying "ipp:" URLs and this >> deficiency could lead to confusion for the end user. Also, to correctly >> configure a proxy service for IPP, the user will have to "know" >> that IPP actually uses HTTP, and that for IPP proxy service the user >> must configure an HTTP proxy. > >I don't understand why this is a problem, because existing web clients >can't usefully talk to IPP servers anyway. They can't generate >application/ipp requests nor can they parse application/ipp responses. >So naturally they don't have configuration options to talk to IPP proxies >either. > >As for the potential for end-user confusion: there's far greater >potential for end user confusion if printers are named with http: URLs. > >I don't think the configuration management issues for proxies are >that difficult to deal with. The IPP configuration can simply have >a box like: > > ------------------------------------------------------ > [ ] make direct connections to an IPP server > [x] tunnel outgong IPP requests through an HTTP proxy. > > proxy host name: [foo.bar.com] > proxy port number: [8080] > ------------------------------------------------------ > >This isn't any worse than for any other protocol. > >These are nothing in comparison to the configuration management issues >for security. How is an IPP client is going to be able to authenticate >itself to arbitrary IPP servers around the world? If it uses TLS, >it's potentially going to need to have a variety of key certificates >on hand (each signed by a different CA), and know which CAs and >certificate types are recognized by each server, so that it knows >which certificates to send to which servers. IPP clients will "not" arbitrarily authenticate itself to IPP servers around the world. TLS-enabled IPP servers will be pre-configured with ACLs or some such to allow specifically authorized clients to access the resource. Typically, IPP servers that arbitrarily open up their resources to any client around the world will be preconfigured to allow this type of "anonymous" access, much as their publicly accessible fax machines or web servers. > > >> 3. Similar to the end-user configuration problem in #2 above, there is >> currently no proxy configuration option for IPP proxy in existing >> proxy server software. IPP will be a "special case" wherein the >> administrator will have to know the special relationship between >> IPP URLs and HTTP URLs. > >I don't see why this is a problem with the IPP proposal. The IPP >proposal is to use an http: URL with an explicit port number, so >that it will be compatible with http proxies. > > >> 4. Future use of the "ipp" scheme is compromised by using the new "ipp" >> scheme in the translated form implied by the proposed "ipp:" scheme. >> The IPP working group would like to reserve use of the "ipp" scheme >> for a pure IPP client/server protocol implementation in the future >> (one that does not require utilization of an existing HTTP >> infrastructure). In this environment, it seems appropriate to attach >> the "ipp" URL to this future protocol, rather than the initial IPP >> protocol that is just carried in a MIME type within HTTP. >> >> For example, in a future implementation of an IPP scheme that does >> not utilize HTTP, existing IPP clients would still attempt to >> translate the "ipp:" scheme into an "http:" scheme, and would do so >> incorrectly, since the future "ipp:" scheme protocol might not use >> HTTP as a transport. > >Anytime a new URI scheme name is defined, it is "compromised" against >some future use of the scheme name with a different protocol. That's >not a real problem; we could always define "ipp2" or some other name >for the new protocol. Chances are we'd want to do that anyway; >if there were two versions of IPP it would be confusing to use "http" >to talk to IPP version 1 and "ipp" to talk to IPP version 2 servers. > >If what you're saying is that HTTP was a Bad Idea and you want to >do something different in the future, that implies that this protocol >is not yet suitable for standardization. If a future version of IPP >would not make use of the "HTTP infrastructure", then there is no >reason *not* to use "ipp:" for the current protocol -- since the only >problems with the use of "ipp:" are the lack of support in the >HTTP infrastructure. Might as well cross this bridge now. > >My opinion is that HTTP is a sub-optimal but sufficient transport >for IPP, and that it is better to settle on the current version of >IPP and make it work with the ipp: URL now, than to try to do it later. > >By the time there is a completely new printing protocol, it is likely that >there will be a standard URI resolution mechanism - which would allow >a client to look up an ipp: URL and find out which printing protocols >the server supports, before opening up a connection to the server. >This would allow a smooth transition from IPP 1.0 to the new protocol, >while using the same URLs. > > >> 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme >> and transparently translating it to an "http:" scheme An initial >> concern was the fact that there was no way to tell that IPP was >> actually being used by looking at an HTTP URL. However, publishing >> and using only IPP URLs to the user and administrator community might >> hide the fact that IPP is actually using HTTP. > >This is not a problem. IPP's use of HTTP is an implementation artifact, >not something that users need to be concerned with. Yes, users might >end up needing to know that they can tunnel IPP over an HTTP proxy. >But this is easily communicated through user interfaces such as that >above. And if this technique is approved, it is likely to be regarded >as a convenience. > >(Some folks on the IAB and IESG are still not convinced that IPP should >be able to tunnel over existing proxies; the counter argument is that >IPP is going to need proxies anyway, so you might as well use one that >already exists.) > >It's a bit misleading to call this "compound" spoofing, since there >is only one layer of "spoofing" going on. > > >> 6. Compound schemes is a new idea and not well understood in its' >> ramifications. In the current IANA registry for URL schemes, there >> are no examples that indicate that scheme "translation" to another >> scheme is required. > >IPP is the first group to try to layer something on top of HTTP. >So naturally there are no examples for how to do this. That's >what comes with breaking new ground. > >Note that the translation is only required to talk to HTTP proxies. >The general case is that the IPP client talks directly to the IPP >server, and there's no URI translation going on at all. Your previous comments that say something like "IPP clients will only use HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These generic web servers will not understand IPP URLs either, and this case of generic web server extension could make up a significant set of initial releases of IPP. > > >> 7. All applications that include URI/URL recognition features will have >> to be updated to include support for the new "ipp:" URL. > >The applications have to be updated anyway. There are lots of new URI >types being defined; any generic URI parsing application that can only >handle specific URL types is already broken. And any application that >is actually going to make use of ipp: URLs (as opposed to just parsing >them), is going to have to be updated to generate application/ipp >requests, parse application/ipp results, and otherwise provide a useful >user interface to printers. > > >> 8. Existing network infrastructure tools and utilities would need to >> be modified in order to understand the "special" relationship >> between IPP and HTTP URLs. >> >> The working group considers IPP printing an "HTTP application", and >> therefore the usage of an "ipp:" URL scheme must maintain a special >> relationship with "http:" URLs. The definition of such a "compound" >> URL scheme, wherein an "ipp:" scheme is layered or translated to an >> "http:" scheme, is somewhat unusual, and the impact of such a definition >> on the protocol design and deployment is not generally well understood. > >The IESG considers IPP separate and distinct from normal web service, >requiring a separate URI type. The layering of IPP on top of HTTP, >while somewhat unusual, does not change this. > >> This analysis document has identified a partial list of issues regarding >> the integration of the new "ipp:" scheme. It is anticipated that other >> unforeseen issues exist, since this technique has not been prototyped. >> >> If the usage model described herein were adopted, these issues raised in >> this analysis pose a significant negative impact on the implementation >> and deployment of current IPP specifications, as well as potential >> interoperability with future revisions of the protocol. > >This negative impact has to be weighed against the considerable negative >impact associated with use of the http: scheme. > > > >Summary of my position: > >1. I agree that more work needs to be done to specify security level >in IPP URLs. The "https" scheme (which wouldn't be accepted anyway) >is insufficient, and use of the AUTH= parameter with TLS is not >sufficiently well defined for any other URL scheme, to allow IPP >to cut-and-paste another specification. > >Note that these are as much limitations of HTTP and TLS (to fail to >provide adequate negotiation of security parameters) as of URLs. >If there were a better way for client and server to negotiate security, >this would lessen the need to expose this information in the URL. > >Note that this is much a limitation of HTTP and TLS (to fail to >provide adequate negotiation) as of URLs. > > >2. I believe the "negative impact" claimed by the IPP group is >exaggerated, and does not consider the negative impact to the >community of overloading the http: URI scheme. > >I respect the IPP group's concern that translation of IPP URLs >while tunneling over HTTP proxies is untried and may cause operational >problems. However, the IPP group is ignoring IESG concerns about >operational problems that might be caused by reusing HTTP proxies >in the first place to circumvent firewall policy, or the confusion >resulting from users' inability to distinguish printer URLs from >http: URLs. > >If IPP's use of HTTP proxies causes too many problems, it may be >necessary to reconsider using HTTP proxies - or to allow people >to use them, but warn that this might not always work. Sooner >or later the proxies will support IPP. Of course it's nice if >proxies support a new protocol immediately, but if they don't - >this is no more of a barrier than any other new protocol has to face. There is no problem with our current version and HTTP proxies. Its the introduction of an unsupported URL scheme that has generated concerns about breaking the infrastructure. We have layered where appropriate, and have taken special care not to "break" the infrastructure. We have a default port number that eliminates the majority of concern over which protocol is in use, so we think the price to paid by having to go out and set up all of this other support/work with other groups is not going to give us the benefit. Its basically alot of work and prototyping that has to be done for not much benefit. I'm concerned that if we did work on a "standardized" URL, that it would "still" be a "one-off" solution only used by IPP, since the majority of internet protocols I am seeing working on security (IMAP/POP/FTP/SMTP/LDAP, etc) are working on SASL profiles for accomplishing this functionality. Which would make all of this work even less of a benefit. > > >My proposal: > >The IPP documents will not be approved as a Proposed Standard until >they are fixed to use ipp: URLs instead of http: URLs. > >With an eye toward making them acceptable to IESG while addressing >the IPP group's concerns: > >- I will recruit a team of experts from the HTTP working group >and ask them to quickly review the ipp: scheme proposal for potential >interoperability problems with proxies. > >- I will recruit experts from the web and TLS communities to design >appropriate URL parameters for use with TLS, which can be shared >by other URL schemes besides ipp:. > >The IPP documents have been submitted for IESG ballot, and may be >on IESG's agenda for discussion as early as July 16th. I would >therefore like a decision from IPP by July 15th as to whether >the IPP working group is willing to pursue this course of action. If we subscribe to your schedule I think its only fair that we get a schedule back from you for completion of this work, provided we agree to it. Thanks Randy > >Note that there may still be other IESG concerns with this protocol, >particularly on security. We won't know about those until the IESG >finishes its ballot. > >Keith > From ipp-owner@pwg.org Sun Jul 12 03:40:02 1998 Delivery-Date: Sun, 12 Jul 1998 03:40:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA04826 for ; Sun, 12 Jul 1998 03:40:02 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA00323 for ; Sun, 12 Jul 1998 03:40:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id DAA22060 for ; Sun, 12 Jul 1998 03:39:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 03:34:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA21078 for ipp-outgoing; Sun, 12 Jul 1998 03:29:23 -0400 (EDT) Message-Id: <3.0.5.32.19980712002818.00a519e0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 12 Jul 1998 00:28:18 PDT To: ipp@pwg.org, moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> Agenda for IPP Phone Conference 980715 Cc: chandler@cp10.es.xerox.com, nelli@cp10.es.xerox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_900253698==_" Sender: owner-ipp@pwg.org --=====================_900253698==_ Content-Type: text/plain; charset="us-ascii" Agenda for IPP Phone Conference 980715 ====================================== We will hold our normal weekly conference on Wednesday. Contrary to our belief that the IPP scheme discussion might be finished by now, it has turned out it isn't quite. Keith Moore has come back with his comments on the Monterey output document on the IPP scheme and wants to have new feedback from the group if the proposal is now more palatable. It seems that there is still a disconnect about which infrastructure services are needed for IPP, and what the user experience should be for IPP. For those of you who may not yet have seen the Monterey document, I have attached that as a text file. I expect that the discussion will continue on the DL for the next few days, and we will review any new input on the subject in the phone conference. By copy of this message, I am also inviting Keith to participate. Keith, can you please confirm back to me whether you can attend? Here is the dial-in information: Time: July 15, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno --=====================_900253698==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ipp_scheme1.txt" Monterey, July 9, 1998 IPP Working Group Analysis of Proposed IPP URL Scheme ---------------------------------------------------------------------- Introduction The IETF Applications Area Director has proposed that the IPP working group consider creating a new URL scheme, "ipp:", to reference IPP objects, as defined in the IPP Model Document. The IPP working group has created a usage model of how a potential IPP URL would be used, if implemented and deployed. This usage model is included in this document analysis, for completeness. A subsequent analysis of the usage model for this new scheme has exposed some critical issues and concerns that the IPP working group has with the proposed "ipp:" scheme. Considering the impact of these issues, the working group feels that the integration of a new URL scheme into the IPP model and protocol specifications is not feasible at this time. Usage Model for "ipp" Scheme ----------------------------------------------------------------------- In its current definition, IPP uses HTTP 1.1 as a transport protocol, and hence uses the existing "http:" URL scheme, in which URL path names and MIME types are used to multiplex and demultiplex IPP from the HTTP protocol data stream. The conventional model for the introduction of a new protocol scheme assumes that the URL scheme maps directly to an application protocol, network transport protocol and default transport "port number". Typically, this transport protocol includes a multiplexing/demultiplexing capability based on the idea of a port number (e.g., TCP, UDP). The working group considered using the "ipp:" URL scheme using the conventional model, but the current HTTP infrastructure (existing HTTP 1.1 servers and proxies) does not understand "ipp:" URLs, and would not reliably transport HTTP messages containing headers that reference "ipp:" URLs. We finally considered a "compound" URL scheme, wherein a translation from "ipp:" to "http:" URL schemes is performed. The syntax for the new IPP scheme is identical to the existing "http" scheme except for the scheme name itself. The similarity is maintained to ease the IPP-to-HTTP translation burden: ipp://host[:port]/ Associated with this new IPP scheme is an IANA-assigned TCP port number, 631, which is the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. The implementation impact of using the new scheme on the existing specifications is divided into two key areas: HTTP headers and the application/ipp MIME body part. ------------------------------------------------------ HTTP Header Usage ------------------------------------------------------ When an IPP client obtains an IPP URL, the interpretation (translation) of this URL by the client can take one of two forms, depending upon whether the client is configured to use an HTTP 1.1 proxy server. IPP Client Configured with no proxy server ------------------------------------------------------ When an IPP client (no proxy configured) obtains an "ipp:" URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... IPP Client Configured for Proxy Service ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:8080 Content-type: application/ipp Transfer-Encoding: chunked ... Existing proxies will not understand IPP URLs, so the RequestURI MUST use the HTTP form of the URL. After proxy processing, the proxy would connect to the IPP origin server with headers that are the same as the "no-proxy" example above. IPP/HTTP Server Implications ------------------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP origin servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers MUST accept "full" URLs as well, so IPP servers MUST also be able to accept a requestURI as specified in #2 as well. Also, IPP servers SHOULD be able to accept a full requestURI as specified in #3 below. Servers MUST interpret all of the forms below as equivalent. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) NOTE: Example #3 is included to support the possible future deployment of IPP services that utilize full IPP requestURIs. Currently, this specification does not allow clients to generate full IPP requestURIs. In all forms of "ipp" URL translation, if an explicit port number is specified then this port number MUST be used by the clients and proxies to initiate connections to IPP/HTTP origin servers. ------------------------------------------------- application/ipp MIME body ------------------------------------------------- Printer and job URI attributes in the protocol MUST utilize the "ipp" scheme. The application/ipp body part contains the following URI components that are affected: job attributes - job-uri job-printer-uri printer attributes - printer-uri-supported operation attributes - job-uri printer-uri Other URI attributes in the protocol can contain any number of different URL schemes, e.g., document-uri, printer-more-info, and are not affected by the "ipp" scheme. ------------------------------------------------------------------- Summary Conclusions ------------------------------------------------------------------- The IPP working group has serious concerns regarding integrating a new "ipp:" URL into our specifications. The following issues have been raised with regards to usage of the "ipp:" scheme. 1. There is currently no defined way for a single "ipp:" URL to indicate whether or not a particular IPP server offers "secure" connections. Throughout the IPP model document, numerous assumptions are made with regards to our usage of the "http:" URL to reference IPP objects, chief among these assumptions is that IPP clients treat URL syntax beyond the "host" part of an HTTP URL as opaque. The IPP working group feels that any specification for security parameters within URL syntax should be a "standard" solution and not specifically a "one-off" or one-time only solution for IPP. The effort required to put together a group or effort to accomplish this is out-of-scope for our current charter. 2. There is no straightforward way to configure HTTP client proxy capability for "proxying" IPP. Currently, there are specific proxy configuration options for HTTP clients, such as FTP, GOPHER, HTTP, WAIS, etc. There is no option for proxying "ipp:" URLs and this deficiency could lead to confusion for the end user. Also, to correctly configure a proxy service for IPP, the user will have to "know" that IPP actually uses HTTP, and that for IPP proxy service the user must configure an HTTP proxy. 3. Similar to the end-user configuration problem in #2 above, there is currently no proxy configuration option for IPP proxy in existing proxy server software. IPP will be a "special case" wherein the administrator will have to know the special relationship between IPP URLs and HTTP URLs. 4. Future use of the "ipp" scheme is compromised by using the new "ipp" scheme in the translated form implied by the proposed "ipp:" scheme. The IPP working group would like to reserve use of the "ipp" scheme for a pure IPP client/server protocol implementation in the future (one that does not require utilization of an existing HTTP infrastructure). In this environment, it seems appropriate to attach the "ipp" URL to this future protocol, rather than the initial IPP protocol that is just carried in a MIME type within HTTP. For example, in a future implementation of an IPP scheme that does not utilize HTTP, existing IPP clients would still attempt to translate the "ipp:" scheme into an "http:" scheme, and would do so incorrectly, since the future "ipp:" scheme protocol might not use HTTP as a transport. 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme and transparently translating it to an "http:" scheme An initial concern was the fact that there was no way to tell that IPP was actually being used by looking at an HTTP URL. However, publishing and using only IPP URLs to the user and administrator community might hide the fact that IPP is actually using HTTP. 6. Compound schemes is a new idea and not well understood in its' ramifications. In the current IANA registry for URL schemes, there are no examples that indicate that scheme "translation" to another scheme is required. 7. All applications that include URI/URL recognition features will have to be updated to include support for the new "ipp:" URL. 8. Existing network infrastructure tools and utilities would need to be modified in order to understand the "special" relationship between IPP and HTTP URLs. The working group considers IPP printing an "HTTP application", and therefore the usage of an "ipp:" URL scheme must maintain a special relationship with "http:" URLs. The definition of such a "compound" URL scheme, wherein an "ipp:" scheme is layered or translated to an "http:" scheme, is somewhat unusual, and the impact of such a definition on the protocol design and deployment is not generally well understood. This analysis document has identified a partial list of issues regarding the integration of the new "ipp:" scheme. It is anticipated that other unforeseen issues exist, since this technique has not been prototyped. If the usage model described herein were adopted, these issues raised in this analysis pose a significant negative impact on the implementation and deployment of current IPP specifications, as well as potential interoperability with future revisions of the protocol. --=====================_900253698==_ Content-Type: text/plain; charset="us-ascii" Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com --=====================_900253698==_-- From ipp-owner@pwg.org Sun Jul 12 17:34:01 1998 Delivery-Date: Sun, 12 Jul 1998 17:34:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA08837 for ; Sun, 12 Jul 1998 17:34:00 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01166 for ; Sun, 12 Jul 1998 17:33:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03166 for ; Sun, 12 Jul 1998 17:33:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 17:24:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA02590 for ipp-outgoing; Sun, 12 Jul 1998 17:22:20 -0400 (EDT) From: don@lexmark.com Message-Id: <199807122121.AA11663@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Keith Moore Cc: Ipp@pwg.org, Moore@cs.utk.edu Date: Sun, 12 Jul 1998 17:13:56 -0400 Subject: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org >> It seems to me there are few if any clear, overwhelming technical merits on >> either side of the proposals. The printing community is firm on how it >> believes customers and users will perceive and use IPP and believes "ipp:" >> is not the right approach. Since other than encoded within the >> application/ipp body, "ipp:" is never on the wire, there is no real >> difference from the network's infrastructure > >That's not true. ipp: would appear "on the wire" in all sorts of >places -- in HTML documents, LDAP responses, ACAP responses, etc. -- >any time someone needs to refer to a printer. > >Keith Yes, but in all these cases, a human being does not see this raw material. It is technically irrelevant whether the responses say "ipp:", "http:", or anything else for that matter. My argue stands, the right people to deal with the user's perception are the people shipping the products and they have reach consensus that "ipp:" is the wrong answer. One of the major scenarios this group continues to discuss is what does the naive person do with a URL received from another individual? It is a common belief among those of us developing products that they will stick them in a browser and see what happens. With "ipp:", nothing will happen except the browser complaining. We firmly believe that well designed IPP servers when presented with a GET operation at its HTTP URL will return something of significance and use to the person trying it out. Specifically, we expect the server to return an HTML page that will help the user "bootstrap" themselves into being able to print to that printer. That scenario is completely broken with the "ipp:" scheme. If we don't do our work to enable IPP to work for those who have only minimal experience then we have done no one (especially ourselves) a favor. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Sun Jul 12 18:34:38 1998 Delivery-Date: Sun, 12 Jul 1998 18:34:38 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA09114 for ; Sun, 12 Jul 1998 18:34:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01249 for ; Sun, 12 Jul 1998 18:34:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03970 for ; Sun, 12 Jul 1998 18:34:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 18:29:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03381 for ipp-outgoing; Sun, 12 Jul 1998 18:24:55 -0400 (EDT) Message-Id: <199807122224.SAA28065@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: Keith Moore , Ipp@pwg.org Subject: IPP> Re: New IPP Scheme In-reply-to: Your message of "Sun, 12 Jul 1998 17:13:56 EDT." <199807122121.AA11663@interlock2.lexmark.com> Date: Sun, 12 Jul 1998 18:24:44 -0400 Sender: owner-ipp@pwg.org > >> It seems to me there are few if any clear, overwhelming technical merits > >> on either side of the proposals. The printing community is firm on how it > >> believes customers and users will perceive and use IPP and believes > >> "ipp:" is not the right approach. Since other than encoded within the > >> application/ipp body, "ipp:" is never on the wire, there is no real > >> difference from the network's infrastructure > > > >That's not true. ipp: would appear "on the wire" in all sorts of > >places -- in HTML documents, LDAP responses, ACAP responses, etc. -- > >any time someone needs to refer to a printer. > > > >Keith > > Yes, but in all these cases, a human being does not see this raw material. > It is technically irrelevant whether the responses say "ipp:", "http:", or > anything else for that matter. No, that's not true either. People deal with these things all the time. People explicitly type URLs into web pages, into their directory entries, etc. People will type printer URLs into dialog boxes and printcap files. This stuff doesn't just appear out of thin air. > My argue stands, the right people to deal > with the user's perception are the people shipping the products and they > have reach consensus that "ipp:" is the wrong answer. The folks who are shipping printers aren't even close to representative of the people who are going to be using this stuff. > One of the major scenarios this group continues to discuss is what does the > naive person do with a URL received from another individual? It is a > common belief among those of us developing products that they will stick > them in a browser and see what happens. With "ipp:", nothing will happen > except the browser complaining. We firmly believe that well designed IPP > servers when presented with a GET operation at its HTTP URL will return > something of significance and use to the person trying it out. > > Specifically, we expect the server to return an HTML page that will help > the user "bootstrap" themselves into being able to print to that printer. > That scenario is completely broken with the "ipp:" scheme. If we don't do > our work to enable IPP to work for those who have only minimal experience > then we have done no one (especially ourselves) a favor. No, ipp: doesn't prevent that at all. If someone wants to put up a web page with an http: URL that tells someone how to bootstrap a connection to their ipp: printer, and if they want to export that http: URL in HTML documents and directory entries and so forth, they're quite welcome to do so -- nobody can stop them. The same is true for any printer vendor that wants to build this functionality into its printers. But if IPP gets to overload the http: URL, then you're *forcing* the user to go through such a mechanism, because he has no other way to know that he's talking to a printer. And you're somehow expecting that in every case doing a GET on the http: URL is going to return something reasonable that lets the user configure that printer on his system. This is putting the functionality in the wrong place, because it expects that the server knows what the user needs to do. That just doesn't fly in a heterogeneous world. If you use ipp: the client will realize that the other end is a printer, and it will (eventually) know what to do with it. Keith From ipp-owner@pwg.org Sun Jul 12 18:39:55 1998 Delivery-Date: Sun, 12 Jul 1998 18:39:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA09134 for ; Sun, 12 Jul 1998 18:39:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01266 for ; Sun, 12 Jul 1998 18:39:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04596 for ; Sun, 12 Jul 1998 18:39:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 18:35:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03391 for ipp-outgoing; Sun, 12 Jul 1998 18:26:15 -0400 (EDT) Message-Id: <3.0.5.32.19980712152510.009ecb20@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 12 Jul 1998 15:25:10 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> IPP scheme dilemma Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, As I will be on the road Monday and Tuesday, I thought I would give you my view before I take to the road. It seems that we have narrowed down the IPP scheme discussion to be mainly about the "user experience". This is a tricky one because it is not really clear to me who is "right" and who is "wrong" in this debate. My understanding of the WGs thinking on this is: - We never had any intension to specifically involve or make IPP dependent on web browsers (apart from the fact that an IPP URL will most certainly be found on HTML pages - which does not determine which scheme is used). - We believed that the "user experience" will initially be a competetive element among different IPP implementations, after which we might decide later on whether a standardized behaviour in web browsers or other user interfaces would be needed. - We believed further that a user would seldom or never have to actually see an IPP URL, it would typically be buried somewhere in the IPP client code, or behind a user friendly name on an HTML page. - We believed that in the most common case, which is to print from an application, an IPP printer would look no different to a user than the proprietary print solution he/she uses today. There could be some differences in a print manager software, but again user friendly names are typically used in those for end users. The Area Director / IESG view seems to be: - The IPP scheme has to be introduced so that users can distinguish an IPP printer from any other type of object (by looking at the scheme in the URL), in directories, web browsers, on HTML pages etc. - In order to achieve this, it is neccesarry to introduce the IPP scheme, even if it has different characterists and behaviour than most other schemes in use today. It is obvious to me that the IPP WG and the AD/IESG sees the world differently. However, according to the IETF rules the IESG is eventually right. This means that if the WG ever wants to see the IPP specs mature to the IETF standards track, we will have to accept the world as the IESG views it. My recommendation is to go along with the official IESG view, when we have it fully documented, and see where it takes us. Remember that in the IETF a Proposed Standard is supposed to be the basis for prototyping. In the event that such protoyping would show that the IPP scheme is less than ideal, I assume that the IESG can reverse decisions that turn out not to work in practise. A real life problem though, is that we might see a number of implementations which do not use the IPP scheme, before such prototyping has been performed. This will lead to the same situation as with HTTP, where products came before the standard. On the subject of how IPP should or should not use proxies, I can only hope that some people who actually build the things would speak up and tell us what can and cannot be used. There must be some more experts out there who can help sort that out. I have no opionion on that matter. Finally, if we should decide to go along with the IPP scheme, I recommend to use the scheme name "ipp-http", which better describes the dual naming of the scheme, and would not use up the name "ipp" for something better that might show up later. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Sun Jul 12 19:50:58 1998 Delivery-Date: Sun, 12 Jul 1998 19:50:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09470 for ; Sun, 12 Jul 1998 19:50:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01370 for ; Sun, 12 Jul 1998 19:50:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05469 for ; Sun, 12 Jul 1998 19:50:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 19:44:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04877 for ipp-outgoing; Sun, 12 Jul 1998 19:39:38 -0400 (EDT) Message-Id: <199807122339.TAA28271@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Turner cc: moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IPP Scheme In-reply-to: Your message of "Sat, 11 Jul 1998 21:18:31 PDT." <199807120424.VAA19119@mail.pacifier.com> Date: Sun, 12 Jul 1998 19:39:29 -0400 Sender: owner-ipp@pwg.org > >However, a separate URL type such as "https" is also insufficient for > >IPP's purposes. SSL was designed to authenticate servers to clients, > >not the other way around, and this heritage still shows in TLS. > >The TLS protocol does not have any way for a server to inform a > >client about which certificate authorities it trusts. Unless all > >IPP servers are going to trust the same certificate authority > >(highly unlikely), an IPP client that talks to different servers will > >need multiple key certificates (up to one for each IPP server it > >wants to talk to), and therefore the client either needs to know which > >certificate to send to each server, or it needs to know which CAs > >the server supports. > > I assumed that the client and/or server would use the CA that issued > the certicate in the first place. I believe this information is a part of the > certificate itself. No, that's not the issue. Yes, the CA is part of the certificate. The client may need several certificates to authenticate itself to each of several different servers, because each client certificate is signed by only one CA, and not all servers trust the same CA. The client has no knowledge of which certificate to use, and TLS doesn't give it a way find out which CAs the server trusts. So this has to be configured into the client on a per-printer basis - either explicitly or as part of the URL. > >If it's desired to make IPP work without prior authorization > >(and assuming the server requires authentication at all), the > >client is still going to need to know what authentication method to > >use and which CAs the server supports. This is more information than > >can be conveyed in one bit (the difference between using "http" > >and "https"). > > The authentication method is negotiated when the client sends its > "preferred" list of auth/privacy methods to use during TLS startup. Only if it uses TLS. How does the client find out whether to use TLS or digest or both? (it might use TLS for privacy, and digest for authentication) > IPP clients will "not" arbitrarily authenticate itself to IPP servers > around the world. TLS-enabled IPP servers will be pre-configured with > ACLs or some such to allow specifically authorized clients to access > the resource. Yes, but how does this work for the client who wants to print on the printer at Kinko's? (whether nearby or across the world) Presumably, the user's going to have to establish a billing account, and when he does that he'll get a certificate back from Kinko's that he can use to authenticate himself to Kinko's printer. (my guess is that it's a lot easier for Kinko's to issue a certificate that says "this is Kinko's user #23434" than for Kinko's to decide whether to accept some certificate that the user already has, signed by some random CA, that says "this is Keith Moore".) (note that there's a big gap in defining "ACLs or some such") > >> 6. Compound schemes is a new idea and not well understood in its' > >> ramifications. In the current IANA registry for URL schemes, there > >> are no examples that indicate that scheme "translation" to another > >> scheme is required. > > > >IPP is the first group to try to layer something on top of HTTP. > >So naturally there are no examples for how to do this. That's > >what comes with breaking new ground. > > > >Note that the translation is only required to talk to HTTP proxies. > >The general case is that the IPP client talks directly to the IPP > >server, and there's no URI translation going on at all. > > Your previous comments that say something like "IPP clients will only use > HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP > as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These > generic web servers will not understand IPP URLs either, and this case > of generic web server extension could make up a significant set of > initial releases of IPP. This is a reasonable concern. I'm thinking that it's not such a problem if http: URLs are always used at the HTTP layer - as long as they're only used at the HTTP layer. I might be able to convince IESG of this. > >I respect the IPP group's concern that translation of IPP URLs > >while tunneling over HTTP proxies is untried and may cause operational > >problems. However, the IPP group is ignoring IESG concerns about > >operational problems that might be caused by reusing HTTP proxies > >in the first place to circumvent firewall policy, or the confusion > >resulting from users' inability to distinguish printer URLs from > >http: URLs. > > > >If IPP's use of HTTP proxies causes too many problems, it may be > >necessary to reconsider using HTTP proxies - or to allow people > >to use them, but warn that this might not always work. Sooner > >or later the proxies will support IPP. Of course it's nice if > >proxies support a new protocol immediately, but if they don't - > >this is no more of a barrier than any other new protocol has to face. > > There is no problem with our current version and HTTP proxies. Its the > introduction of an unsupported URL scheme that has generated > concerns about breaking the infrastructure. We have layered where > appropriate, and have taken special care not to "break" the infrastructure. With due respect, the IESG disagrees. The layering of a new protocol over HTTP, and the proposed reuse of http: URLs, has generated concerns about breaking widely-held assumptions - specifically, firewall policies and assumptions about what http: means and how it is used. > I'm concerned that if we did work on a "standardized" URL, that it would > "still" be a "one-off" solution only used by IPP, since the majority of > internet protocols I am seeing working on security > (IMAP/POP/FTP/SMTP/LDAP, etc) are working on SASL profiles for > accomplishing this functionality. Which would make all of this > work even less of a benefit. I don't think this would be a one-off. There's a lot of interest in using TLS for most of these protocols, and the mechanism for negotiating TLS (typically a STARTTLS command) sort of sits alongside of SASL. So I think we're going to be needing URLS that can specify use of either SASL methods, or TLS, or both, for several different protocols. I've already been asked by someone else from outside of the IPP group, to hold a discussion at the next IETF meeting, about a reusable mechanism for specifying various kinds of security in URLs. > >With an eye toward making them acceptable to IESG while addressing > >the IPP group's concerns: > > > >- I will recruit a team of experts from the HTTP working group > >and ask them to quickly review the ipp: scheme proposal for potential > >interoperability problems with proxies. > > > >- I will recruit experts from the web and TLS communities to design > >appropriate URL parameters for use with TLS, which can be shared > >by other URL schemes besides ipp:. > > > >The IPP documents have been submitted for IESG ballot, and may be > >on IESG's agenda for discussion as early as July 16th. I would > >therefore like a decision from IPP by July 15th as to whether > >the IPP working group is willing to pursue this course of action. > > If we subscribe to your schedule I think its only fair that we get a > schedule back from you for completion of this work, provided we agree > to it. Well, if I can get IESG to agree to let IPP use http: in HTTP protocol elements, then we don't need the first team of experts. As for the second, I would need to talk to security experts before I could even get a time estimate. But it might be that this doesn't have to be critical path for IPP going to proposed. I'll ask the security ADs what they think. Keith From ipp-owner@pwg.org Sun Jul 12 19:55:16 1998 Delivery-Date: Sun, 12 Jul 1998 19:55:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09485 for ; Sun, 12 Jul 1998 19:55:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01377 for ; Sun, 12 Jul 1998 19:54:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA06091 for ; Sun, 12 Jul 1998 19:54:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Sun, 12 Jul 1998 19:50:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05241 for ipp-outgoing; Sun, 12 Jul 1998 19:47:41 -0400 (EDT) Message-Id: <199807122347.TAA28324@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> possible compromise? cc: moore@cs.utk.edu From: Keith Moore Date: Sun, 12 Jul 1998 19:47:32 -0400 Sender: owner-ipp@pwg.org I was thinking about the problem where using ipp: URLs in the HTTP POST operation potentially makes IPP incompatible with existing servers, and came up with the following possible compromise solution. I'm willing to defend this to IESG if the IPP group buys into it. 1. use the http: form of the URL in HTTP protocol elements if you're talking to a proxy, do POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 if you're talking to an origin server, you should really do POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 but origin servers are *also* expected to accept POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 just as in vanilla HTTP 1.1. This way, the HTTP layer never has to see ipp: at all. This should preserve compatibility with HTTP servers and HTTP client libraries. 2. use the ipp: form of the URL in IPP protocol elements that refer to printer objects 3. define ipp: URLs as a standard external notation for referring to printers - and the IPP protocol document describes how to take an ipp: URL and generate the appropriate HTTP/1.1 POST request. Printer clients are expected to be able to do this. That way, the ipp: URL can be used when it's useful to expose the fact that the named object is a printer. The IPP server is free to respond to a GET on the its printer URL, and return HTML that describes the printer, how to talk to it, etc. And users are free to export this URL as an http: URL if they want to do so and their printers support it. But users and clients should be cautioned to not assume that the "GET URL" is the same as the "print URL". Keith From ipp-owner@pwg.org Mon Jul 13 07:38:17 1998 Delivery-Date: Mon, 13 Jul 1998 07:38:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA24947 for ; Mon, 13 Jul 1998 07:38:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA02553 for ; Mon, 13 Jul 1998 07:38:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id HAA20648 for ; Mon, 13 Jul 1998 07:38:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 07:24:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA20070 for ipp-outgoing; Mon, 13 Jul 1998 07:22:58 -0400 (EDT) From: don@lexmark.com Message-Id: <199807131122.AA01871@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Keith Moore Cc: Ipp@pwg.org Date: Mon, 13 Jul 1998 07:22:19 -0400 Subject: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Keith Moore said: >> My argument stands, the right people to deal >> with the user's perception are the people shipping the products and they >> have reach consensus that "ipp:" is the wrong answer. > >The folks who are shipping printers aren't even close to representative >of the people who are going to be using this stuff. Too bad you don't know the people that have been working on this for more than a year. The group includes people not only from the printer manufacturers you seem to think haven't the foggiest what their users want but also _people_ with a great deal of experience in Operating Systems (employees of Microsoft, Sun & IBM), Network Operating Systems (employees of Microsoft, IBM & Novell) as well as printing software (employees of Underscore & North Lake.) Not only do these people have a great deal of experience in this area but, despite the IETF's blinders, as representatives of companies developing commercial products, _we_ and our companies are going to have to support this when it hits the field. Are you making a multimillion dollar support committment to the "ipp:" concept? In conjunction with those of us who not only manufacture printers but also provide both Web and non-Web based configuration and management utilities, I think this group has a great understanding of what real-world users want and expect. Oh, and by the way, _we_ all are also computer users generally using the fairly up to date operating system, etc. on a day to day basis. IPP is not a printer manufacturer "railroad." It is a broad-based, printing industry cooperative effort that has reach its conclusion based upon years and years of experience. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Jul 13 08:31:19 1998 Delivery-Date: Mon, 13 Jul 1998 08:31:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA25777 for ; Mon, 13 Jul 1998 08:31:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02682 for ; Mon, 13 Jul 1998 08:31:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA21499 for ; Mon, 13 Jul 1998 08:31:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 08:24:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA20933 for ipp-outgoing; Mon, 13 Jul 1998 08:20:24 -0400 (EDT) Message-ID: <35A9FB99.F123B4F@agranat.com> Date: Mon, 13 Jul 1998 12:20:41 +0000 From: Scott Lawrence Organization: Agranat Systems http://www.agranat.com/ X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.32 i686) MIME-Version: 1.0 To: Ipp@pwg.org CC: Keith Moore Subject: Re: IPP> Re: New IPP Scheme References: <199807122121.AA11663@interlock2.lexmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org don@lexmark.com wrote: > >That's not true. ipp: would appear "on the wire" in all sorts of > >places -- in HTML documents, LDAP responses, ACAP responses, etc. -- > >any time someone needs to refer to a printer. > > > >Keith don@lexmark.com wrote: > Yes, but in all these cases, a human being does not see this raw material. > It is technically irrelevant whether the responses say "ipp:", "http:", or > anything else for that matter. Without taking sides on this debate, it is worth pointing out that the early developers of the web all thought that ordinary users would never deal directly with URLs at all - only HTML authors would ever see them. We all see them every day in mail, TV, newspapers, billboards... -- Scott Lawrence Consulting Engineer Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/ From ipp-owner@pwg.org Mon Jul 13 09:01:16 1998 Delivery-Date: Mon, 13 Jul 1998 09:01:16 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26295 for ; Mon, 13 Jul 1998 09:01:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02816 for ; Mon, 13 Jul 1998 09:01:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA22270 for ; Mon, 13 Jul 1998 09:01:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 08:54:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA21699 for ipp-outgoing; Mon, 13 Jul 1998 08:49:21 -0400 (EDT) From: don@lexmark.com Message-Id: <199807131249.AA05859@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Scott Lawrence Cc: Ipp@pwg.org, Keith Moore Date: Mon, 13 Jul 1998 08:47:37 -0400 Subject: Re: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org My points are: 1. I am not really concerned about cases where "ipp:" is handled under the covers by computers. 2. In cases where people handle URL's, I think the "http:" URL is better from a number of perspectives which I have already described. Some how people seem to figure out business cards that say: Phone: 606-232-4808 Fax: 606-232-6740 even though the phone numbers look very similar to the fax numbers. Equally, I think people can handle quite well (largely because it looks like the familiar web URL they are used to): Web: http://www.lexmark.com Printer: http://printer1.bldg035.lexmark.com ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Scott Lawrence on 07/13/98 08:20:41 AM To: Ipp%Pwg.Org@interlock.lexmark.com cc: Keith Moore (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Re: New IPP Scheme don@lexmark.com wrote: > >That's not true. ipp: would appear "on the wire" in all sorts of > >places -- in HTML documents, LDAP responses, ACAP responses, etc. -- > >any time someone needs to refer to a printer. > > > >Keith don@lexmark.com wrote: > Yes, but in all these cases, a human being does not see this raw material. > It is technically irrelevant whether the responses say "ipp:", "http:", or > anything else for that matter. Without taking sides on this debate, it is worth pointing out that the early developers of the web all thought that ordinary users would never deal directly with URLs at all - only HTML authors would ever see them. We all see them every day in mail, TV, newspapers, billboards... -- Scott Lawrence Consulting Engineer Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/ From ipp-owner@pwg.org Mon Jul 13 09:26:14 1998 Delivery-Date: Mon, 13 Jul 1998 09:26:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26835 for ; Mon, 13 Jul 1998 09:26:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02945 for ; Mon, 13 Jul 1998 09:26:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA23012 for ; Mon, 13 Jul 1998 09:26:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 09:19:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA22431 for ipp-outgoing; Mon, 13 Jul 1998 09:15:17 -0400 (EDT) Message-Id: <199807131315.JAA02267@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: Scott Lawrence , Ipp@pwg.org, Keith Moore , moore@cs.utk.edu Subject: Re: IPP> Re: New IPP Scheme In-reply-to: Your message of "Mon, 13 Jul 1998 08:47:37 EDT." <199807131249.AA05859@interlock2.lexmark.com> Date: Mon, 13 Jul 1998 09:14:59 -0400 Sender: owner-ipp@pwg.org > 2. In cases where people handle URL's, I think the "http:" URL is better > from a number of perspectives which I have already described. Some how > people seem to figure out business cards that say: > > Phone: 606-232-4808 > Fax: 606-232-6740 > It's interesting that you should cite that case. The discussion recently came up on the URI list as to whether there should be a single "E.164" URL type for all phone numbers, or whether there should be separate URL types for voice, fax, etc. The conclusion was that they had to be separate, because the user interfaces for the handling of fax and phone needed to be different, and also because in some cases (e.g. ISDN) the call setup actually needed to know which was being used before the call was placed. The http/ipp argument seems very similar to me, with a similar conclusion. Keith From ipp-owner@pwg.org Mon Jul 13 11:15:03 1998 Delivery-Date: Mon, 13 Jul 1998 11:15:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00374 for ; Mon, 13 Jul 1998 11:15:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03643 for ; Mon, 13 Jul 1998 11:14:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24224 for ; Mon, 13 Jul 1998 11:14:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 11:09:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23628 for ipp-outgoing; Mon, 13 Jul 1998 11:06:27 -0400 (EDT) Message-ID: From: Rich Gray To: "'Keith Moore'" Cc: ipp@pwg.org Subject: RE: IPP> Re: IPP Scheme Date: Mon, 13 Jul 1998 11:05:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Sunday, July 12, 1998 7:39 PM > To: Randy Turner > Cc: moore@cs.utk.edu; ipp@pwg.org; moore@cs.utk.edu > Subject: IPP> Re: IPP Scheme [snips] Keith writes: > > With due respect, the IESG disagrees. The layering of a new protocol > over HTTP, and the proposed reuse of http: URLs, has > generated concerns > about breaking widely-held assumptions - specifically, > firewall policies > and assumptions about what http: means and how it is used. What can one assume about http? That it is the "browsing" application?? Using conventional http/html one can indeed browse a vast "library" of information. Many of us are now quite dependant upon this access. But one can also upload/download files, control routers and other gear (including printers!), cop a peek at a porn site, get news & other information, send and receive e-mail and all sorts of services that imaginative people have managed to implement on these protocols. So it seems to me that the only meaning http: has it that it is Hypertext Transport. One cannot tell what is being transported. It is not possible to infer "application" based upon http:. One would have to dig into the content of the messages (or filter on hosts) to do much effective blocking if one wanted to restrict http to a small set of legitimate applications. So it does not seem like this is much help for the firewall administrator. The barndoor is already pretty wide open. MIME type would seem to provide a most adequate filtering hook for IPP and other protocols which also wish to ride on http. > > Keith > Another $.02, Rich Richard B. Gray, Sr. Software Egr.| Tel: 513/746-8118 ext. 2405 Digital Controls Corporation | Fax: 513/743-8575 305 South Pioneer Blvd. | Net: rich.gray@digital-controls.com Springboro OH 45066-1100, USA | Http://lpplus.digital-controls.com From ipp-owner@pwg.org Mon Jul 13 11:24:14 1998 Delivery-Date: Mon, 13 Jul 1998 11:24:15 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00472 for ; Mon, 13 Jul 1998 11:24:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03737 for ; Mon, 13 Jul 1998 11:24:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24925 for ; Mon, 13 Jul 1998 11:24:13 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 11:20:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA24297 for ipp-outgoing; Mon, 13 Jul 1998 11:15:38 -0400 (EDT) Message-Id: <199807131515.LAA02769@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rich Gray cc: "'Keith Moore'" , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: IPP Scheme In-reply-to: Your message of "Mon, 13 Jul 1998 11:05:33 EDT." Date: Mon, 13 Jul 1998 11:15:17 -0400 Sender: owner-ipp@pwg.org > MIME type would seem to provide a most adequate filtering hook for IPP > and other protocols which also wish to ride on http. Filtering is not the issue with ipp: vs http:. The problem with using http: for printers is that it hides the fact that the resource is a printer. Users then have to keep track of that information separately, while user agents (web clients etc.) are unable to take advantage of the fact that the resource is a printer to improve their user interfaces. Keith From ipp-owner@pwg.org Mon Jul 13 11:54:42 1998 Delivery-Date: Mon, 13 Jul 1998 11:54:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00912 for ; Mon, 13 Jul 1998 11:54:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03953 for ; Mon, 13 Jul 1998 11:54:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA25695 for ; Mon, 13 Jul 1998 11:54:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 11:49:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25115 for ipp-outgoing; Mon, 13 Jul 1998 11:47:48 -0400 (EDT) Message-Id: <199807131550.IAA17620@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 13 Jul 1998 08:43:50 -0700 To: Keith Moore From: Randy Turner Subject: Re: IPP> Re: IPP Scheme Cc: ipp@pwg.org In-Reply-To: <199807131515.LAA02769@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org I can appreciate the need for compromise, given your earlier message, but I'm not sure I completely understand the difference between your compromise, and our "ipp:" URL usage model that we sent out to you. It looks like you're suggesting using the HTTP header part of our proposal, and trying to use "ipp:" URLs within the application/ipp part where appropriate, which is basically what our usage model stated. Could you do a "diff" on our document and your compromise for the DL? Thanks Randy From ipp-owner@pwg.org Mon Jul 13 12:03:56 1998 Delivery-Date: Mon, 13 Jul 1998 12:03:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA01083 for ; Mon, 13 Jul 1998 12:03:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04015 for ; Mon, 13 Jul 1998 12:03:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26375 for ; Mon, 13 Jul 1998 12:03:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 11:59:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25766 for ipp-outgoing; Mon, 13 Jul 1998 11:56:44 -0400 (EDT) Date: 13 Jul 1998 15:53:55 -0000 Message-ID: <19980713155355.22923.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Re: IPP Scheme In-Reply-To: <199807120424.VAA19119@mail.pacifier.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > Some comments on Keith's responses below. > > Randy > > ... > > > >> 6. Compound schemes is a new idea and not well understood in its' > >> ramifications. In the current IANA registry for URL schemes, there > >> are no examples that indicate that scheme "translation" to another > >> scheme is required. > > > >IPP is the first group to try to layer something on top of HTTP. > >So naturally there are no examples for how to do this. That's > >what comes with breaking new ground. > > > >Note that the translation is only required to talk to HTTP proxies. > >The general case is that the IPP client talks directly to the IPP > >server, and there's no URI translation going on at all. > > Your previous comments that say something like "IPP clients will only use > HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP > as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These > generic > web servers will not understand IPP URLs either, and this case of generic > web server extension > could make up a significant set of initial releases of IPP. > I don't agree that using IPP URLs prevents fielding IPP as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. Isn't it true that the web server doesn't need to understand IPP URLs, since they never appear on the wire (outside of the application/ipp body)? The one exceptional case is that in which the client is talking to a proxy server and must transmit the absolute URL in the Request-URI. ----- Original Message: http://www.findmail.com/list/ipp/?start=4078 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Mon Jul 13 12:24:14 1998 Delivery-Date: Mon, 13 Jul 1998 12:24:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA01670 for ; Mon, 13 Jul 1998 12:24:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04094 for ; Mon, 13 Jul 1998 12:24:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27127 for ; Mon, 13 Jul 1998 12:24:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 12:19:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26487 for ipp-outgoing; Mon, 13 Jul 1998 12:11:29 -0400 (EDT) Message-Id: <199807131613.JAA22533@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 13 Jul 1998 09:07:32 -0700 To: "Carl Kugler" , ipp@pwg.org From: Randy Turner Subject: Re: IPP> Re: IPP Scheme In-Reply-To: <19980713155355.22923.qmail@m2.findmail.com> References: <199807120424.VAA19119@mail.pacifier.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Keith was suggesting that, in the absence of a proxy server, that "ipp:" URLs would be used in both HTTP headers and in the application/ipp body part. I believe this would definitely impact generic HTTP 1.1 web servers. Randy At 03:53 PM 7/13/98 +0000, Carl Kugler wrote: >> Some comments on Keith's responses below. >> >> Randy >> >> >... >> > >> >> 6. Compound schemes is a new idea and not well understood in its' >> >> ramifications. In the current IANA registry for URL schemes, there >> >> are no examples that indicate that scheme "translation" to another >> >> scheme is required. >> > >> >IPP is the first group to try to layer something on top of HTTP. >> >So naturally there are no examples for how to do this. That's >> >what comes with breaking new ground. >> > >> >Note that the translation is only required to talk to HTTP proxies. >> >The general case is that the IPP client talks directly to the IPP >> >server, and there's no URI translation going on at all. >> >> Your previous comments that say something like "IPP clients will only use >> HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP >> as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These >> generic >> web servers will not understand IPP URLs either, and this case of generic >> web server extension >> could make up a significant set of initial releases of IPP. >> > >I don't agree that using IPP URLs prevents fielding IPP as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. Isn't it true that the web server doesn't need to understand IPP URLs, since they never appear on the wire (outside of the application/ipp body)? The one exceptional case is that in which the client is talking to a proxy server and must transmit the absolute URL in the Request-URI. > > >----- >Original Message: http://www.findmail.com/list/ipp/?start=4078 >Start a FREE email list at http://www.FindMail.com/ > From ipp-owner@pwg.org Mon Jul 13 12:59:07 1998 Delivery-Date: Mon, 13 Jul 1998 12:59:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA02177 for ; Mon, 13 Jul 1998 12:59:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04248 for ; Mon, 13 Jul 1998 12:59:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27967 for ; Mon, 13 Jul 1998 12:59:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 12:54:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27352 for ipp-outgoing; Mon, 13 Jul 1998 12:51:17 -0400 (EDT) Content-return: allowed Date: Mon, 13 Jul 1998 08:49:53 PDT From: "Bennett, Joel H" Subject: RE: IPP> Re: IPP Scheme To: ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02177 >-----Original Message----- >From: Keith Moore [mailto:moore@cs.utk.edu] > >> MIME type would seem to provide a most adequate filtering hook for IPP >> and other protocols which also wish to ride on http. > >Filtering is not the issue with ipp: vs. http:. > >The problem with using http: for printers is that it hides the fact >that the resource is a printer. Users then have to keep track of >that information separately, while user agents (web clients etc.) >are unable to take advantage of the fact that the resource is a >printer to improve their user interfaces. I'm outside your group, strictly speaking, but I was checking this out because I will be involved in testing the software that XEROX may eventually develop for IPP. I couldn't help but weigh in agreeing with Keith on this one. Even on existing web pages (never mind on my business cards) users DO see URL's, and they (we) do make choices based on them. For instance, when I point at a link that says "MORE HELP" and the status window of my browser says mailto:support@company.com I don't click, because I do NOT want to waste my time, I'm looking for "more help" not an unresponsive support team. Likewise, I would want to see ipp://support.microsoft.com so that I would know that there's no point in clicking unless I've got a complaint/help document I want to send them! Savvy users look for FTP:// instead of HTTP:// when they are trying to upload/download files, because it's faster and easier than http:// (if only because ftp:// calls my special ftp client, just the way you will eventually want ipp:// to load your ipp client?) Web users are used to the idea that http:// is a "viewable" resource. something they want to LOOK at. They don't want to do a search for "color pictures" and get links to http:// sites which are actually printers where they can "print color pictures." In HIS hands,                        Joel H. Bennett mailto:Joel@soon.com http://JBennett.home.ml.org From ipp-owner@pwg.org Mon Jul 13 13:50:01 1998 Delivery-Date: Mon, 13 Jul 1998 13:50:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA03939 for ; Mon, 13 Jul 1998 13:50:01 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04591 for ; Mon, 13 Jul 1998 13:49:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29323 for ; Mon, 13 Jul 1998 13:49:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 13:44:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28708 for ipp-outgoing; Mon, 13 Jul 1998 13:38:43 -0400 (EDT) From: Carl Kugler To: Cc: Subject: Re: IPP> Re: IPP Scheme Message-ID: <5030100023071214000002L042*@MHS> Date: Mon, 13 Jul 1998 13:36:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA03939 But HTTP/1.1 client MUST use the absolute path form for the Request-URI when talking to an origin server. The abs_path part of IPP: and HTTP: URLs are identical. Quote: "The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI..." Or are you discussing HTTP headers other than Request-URI? -Carl rturner@sharplabs.com on 07/13/98 10:12:36 AM Please respond to rturner@sharplabs.com To: ipp@pwg.org, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> Re: IPP Scheme Keith was suggesting that, in the absence of a proxy server, that "ipp:" URLs would be used in both HTTP headers and in the application/ipp body part. I believe this would definitely impact generic HTTP 1.1 web servers. Randy At 03:53 PM 7/13/98 +0000, Carl Kugler wrote: >> Some comments on Keith's responses below. >> >> Randy >> >> >... >> > >> >> 6. Compound schemes is a new idea and not well understood in its' >> >> ramifications. In the current IANA registry for URL schemes, there >> >> are no examples that indicate that scheme "translation" to another >> >> scheme is required. >> > >> >IPP is the first group to try to layer something on top of HTTP. >> >So naturally there are no examples for how to do this. That's >> >what comes with breaking new ground. >> > >> >Note that the translation is only required to talk to HTTP proxies. >> >The general case is that the IPP client talks directly to the IPP >> >server, and there's no URI translation going on at all. >> >> Your previous comments that say something like "IPP clients will only use >> HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP >> as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These >> generic >> web servers will not understand IPP URLs either, and this case of generic >> web server extension >> could make up a significant set of initial releases of IPP. >> > >I don't agree that using IPP URLs prevents fielding IPP as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. Isn't it true that the web server doesn't need to understand IPP URLs, since they never appear on the wire (outside of the application/ipp body)? The one exceptional case is that in which the client is talking to a proxy server and must transmit the absolute URL in the Request-URI. > > >----- >Original Message: http://www.findmail.com/list/ipp/?start=4078 >Start a FREE email list at http://www.FindMail.com/ > From ipp-owner@pwg.org Mon Jul 13 13:59:04 1998 Delivery-Date: Mon, 13 Jul 1998 13:59:04 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA04353 for ; Mon, 13 Jul 1998 13:59:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04681 for ; Mon, 13 Jul 1998 13:59:01 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00033 for ; Mon, 13 Jul 1998 13:59:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 13:54:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA29424 for ipp-outgoing; Mon, 13 Jul 1998 13:52:29 -0400 (EDT) Message-Id: <199807131752.NAA03159@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Turner cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: IPP Scheme In-reply-to: Your message of "Mon, 13 Jul 1998 08:43:50 PDT." <199807131550.IAA17620@mail.pacifier.com> Date: Mon, 13 Jul 1998 13:52:06 -0400 Sender: owner-ipp@pwg.org > I can appreciate the need for compromise, given your earlier message, but > I'm not sure I completely understand the difference between your > compromise, and our "ipp:" URL usage model that we sent out to you. It > looks like you're suggesting using the HTTP header part of our proposal, > and trying to use "ipp:" URLs within the application/ipp > part where appropriate, which is basically what our usage model stated. > > Could you do a "diff" on our document and your compromise for the DL? Basically, the difference is that in the compromise proposal, the ipp: stuff never appears at the HTTP layer. So it's not going to break any of the proxies or client APIs or servers. Keith From ipp-owner@pwg.org Mon Jul 13 18:17:55 1998 Delivery-Date: Mon, 13 Jul 1998 18:17:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07499 for ; Mon, 13 Jul 1998 18:17:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06257 for ; Mon, 13 Jul 1998 18:17:51 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA02818 for ; Mon, 13 Jul 1998 18:17:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 18:05:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02159 for ipp-outgoing; Mon, 13 Jul 1998 18:03:05 -0400 (EDT) Content-return: allowed Date: Mon, 13 Jul 1998 12:34:00 PDT From: "Zehler, Peter " Subject: IPP> IPP Implementors contact list To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, Below is a list of all the individuals that have responded to my series of "Who should I talk to for IPP Prototyping and interop testing" email requests. The organizations that are not listed either did not respond or requested that the contact name be confidential or that the contact name only be shared with the subgroup of active IPP implementers. Any IPP implementers organization/contact not listed should be brought to my attention. This list will be made available in our TES directory on the IPP server. I will send out a URL when I generate the pdf file and upload it to the site. I want to give anyone I missed a day or so to let me know. I will be contacting all these people to get a little more information to publish. I would like to identify who has an IPP Client, Printer or Test Suite. I would also like to get an implementations "availability for interop testing" date. (We are talking any type of testing actually.) The goal of this list is to get people together for pair-wise testing of IPP. (another email will address the IPP bake-off that was discussed at the Monterey meeting) Pete ____________________________________________- Allegro Robert Van Andel bva@allegrosoft.com Apple David Pond pond2@apple.com Astart Patrick Powell papowell@astart.com Digital Products Bill Wagner wwagner@digprod.com EFI Jason Chien-Hung Chen Jason.Chen@eng.efi.com Emulex Bob Nixon bob.nixon@emulex.com Novell Hugo Parra hparra@novell.com Ricoh Tetsuya Morita tetsu@spdd.ricoh.co.jp Shinesoft Peter Michalek peterm@shinesoft.com TRCS Rajesh Chawla rajesh@trcs.com Underscore Jay Martin jkm@underscore.com Xerox Peter Zehler peter.zehler@usa.xerox.com Xavier Riley xriley@cp10.es.xerox.com Fuji Xerox Shin Ohtake shin.ohtake@fujixerox.co.jp Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Mon Jul 13 18:33:59 1998 Delivery-Date: Mon, 13 Jul 1998 18:33:59 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07804 for ; Mon, 13 Jul 1998 18:33:58 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06359 for ; Mon, 13 Jul 1998 18:33:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA03611 for ; Mon, 13 Jul 1998 18:33:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 18:29:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA02994 for ipp-outgoing; Mon, 13 Jul 1998 18:24:42 -0400 (EDT) From: don@lexmark.com Message-Id: <199807132221.AA20143@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: "Bennett, Joel H" Cc: Ipp@pwg.org Date: Mon, 13 Jul 1998 18:08:06 -0400 Subject: RE: IPP> Re: IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org >Web users are used to the idea that http:// is a "viewable" resource. Sorry, there are a large number of non-viewable things that already happen when I use http: - java & javascript - management (port 280? 380?) - etc. Perhaps we should have java:, mgmt: URLs? Either we do it for EVERYTHING or NOTHING; it is too confusing otherwise and since there are to many pre-existing cases, I don't think we can change the rules for application/ipp carried on http. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Mon Jul 13 20:04:39 1998 Delivery-Date: Mon, 13 Jul 1998 20:04:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09006 for ; Mon, 13 Jul 1998 20:04:38 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA06690 for ; Mon, 13 Jul 1998 20:04:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA04983 for ; Mon, 13 Jul 1998 20:04:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 19:59:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04363 for ipp-outgoing; Mon, 13 Jul 1998 19:58:09 -0400 (EDT) Message-Id: <199807132357.TAA05008@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Turner cc: "Carl Kugler" , ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IPP Scheme In-reply-to: Your message of "Mon, 13 Jul 1998 09:07:32 PDT." <199807131613.JAA22533@mail.pacifier.com> Date: Mon, 13 Jul 1998 19:57:53 -0400 Sender: owner-ipp@pwg.org > Keith was suggesting that, in the absence of a proxy server, that "ipp:" > URLs would be used in both HTTP headers and in the application/ipp body > part. I believe this would definitely impact generic HTTP 1.1 web servers. yes, and I agree. which is why I proposed that the http: form of the URL could always be used at the HTTP layer. Keith From ipp-owner@pwg.org Mon Jul 13 20:46:45 1998 Delivery-Date: Mon, 13 Jul 1998 20:46:45 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09322 for ; Mon, 13 Jul 1998 20:46:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA06756 for ; Mon, 13 Jul 1998 20:46:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA06262 for ; Mon, 13 Jul 1998 20:46:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 20:39:53 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA05348 for ipp-outgoing; Mon, 13 Jul 1998 20:36:43 -0400 (EDT) Message-Id: <199807140034.UAA05113@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IPP scheme dilemma In-reply-to: Your message of "Sun, 12 Jul 1998 15:25:10 PDT." <3.0.5.32.19980712152510.009ecb20@garfield> Date: Mon, 13 Jul 1998 20:34:46 -0400 Sender: owner-ipp@pwg.org Carl-Uno, Thanks for writing this up; it may help me to better articulate my views. > My understanding of the WGs thinking on this is: > > - We never had any intension to specifically involve or make IPP dependent > on web browsers (apart from the fact that an IPP URL will most certainly be > found on HTML pages - which does not determine which scheme is used). > > - We believed that the "user experience" will initially be a competetive > element among different IPP implementations, after which we might decide > later on whether a standardized behaviour in web browsers or other user > interfaces would be needed. I think we share the above two assumptions. However, even if there were a "standard behavior in web browsers" I don't think this would be the only way that people identified printers. > - We believed further that a user would seldom or never have to actually > see an IPP URL, it would typically be buried somewhere in the IPP client > code, or behind a user friendly name on an HTML page. In writing about "users" I'm including people like system administrators, network administrators, and those who write HTML pages. (The latter includes a lot of "normal users" - I never cease to be amazed at how many nontechnical people have learned to write HTML.) I used to be a system administrator, so I sympathize with their needs. And the current system administrators that I've talked to about this have felt strongly that it's important for them to have the ipp: vs. http: distinction, even if this were less visible to normal users. A number of the IESG and IAB folks are also involved in administration or operations at one level or another, so this may explain why they also feel strongly about this. > - We believed that in the most common case, which is to print from an > application, an IPP printer would look no different to a user than the > proprietary print solution he/she uses today. There could be some > differences in a print manager software, but again user friendly names are > typically used in those for end users. I wouldn't limit this to only printing from applications, but otherwise I agree. I expect that in most environments, "printing to an IPP printer" will work much the same as "printing to a network printer" works today. Today, in Win95 I can do this by going into Control Panel, selecting Printers, selecting Add Printer, selecting "add Network Printer", and typing in \\spot.cs.utk.edu\slug, where spot.cs.utk.edu is the name of my samba server and slug is the name of one of the printer queues on that server. (samba will gateway CIFS printer requests to lpd) Someday I would like to be able to run ipp on my print server and in a similar fashion be able to tell Win95 to print to ipp://spot.cs.utk.edu/slug The point, I suppose, is that even ordinary users will be seeing whatever identifiers are used for printers - at least, if ordinary users ever mess around with Control Panel. Even if there are other ways for users to discover printers - web pages, SRVLOC, ACAP, etc, sometimes people will still be typing in the URLs by hand. > The Area Director / IESG view seems to be: > > - The IPP scheme has to be introduced so that users can distinguish an IPP > printer from any other type of object (by looking at the scheme in the > URL), in directories, web browsers, on HTML pages etc. > > - In order to achieve this, it is neccesarry to introduce the IPP scheme, > even if it has different characterists and behaviour than most other > schemes in use today. I think this is accurate, though IESG would see using "ipp:" as consistent with the established practice that different services get different URL types, rather than a departure from established practice. Keith p.s. one more thing - the convention is that the URL type matches the protocol name. So if you're going to name the URL ipp-http: I think you should rename the protocol "Internet Printing Protocol over HTTP" or some such. But while I prefer ipp: (or even printer:) as a URL prefix, I won't object to ipp-http: From ipp-owner@pwg.org Mon Jul 13 21:45:05 1998 Delivery-Date: Mon, 13 Jul 1998 21:45:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09617 for ; Mon, 13 Jul 1998 21:45:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA06938 for ; Mon, 13 Jul 1998 21:45:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA07477 for ; Mon, 13 Jul 1998 21:44:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 13 Jul 1998 21:40:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06873 for ipp-outgoing; Mon, 13 Jul 1998 21:38:07 -0400 (EDT) From: "Larry Masinter" To: Cc: Subject: RE: IPP> Re: New IPP Scheme Date: Mon, 13 Jul 1998 18:37:36 PDT Message-ID: <002401bdaec7$fa7f17c0$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199807131249.AA05859@interlock2.lexmark.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org are used to): > > Web: http://www.lexmark.com > Printer: http://printer1.bldg035.lexmark.com > Don, your "printer" URL here is broken and it will fail to work, because the default port for ipp is "631", so if you are going to ship a compliant product you will have to write Web: http://www.lexmark.com Printer: http://printer1.bldg035.lexmark.com:631 Be sure to get the port right, OK? If you can't get this little detail right (it's 631, right? Not 632? Are you sure?) then why do you expect your users to? Have you had your "user experience" experts test this concept, since you're making a multi-million-dollar commitment to it? Regards, Larry From ipp-owner@pwg.org Tue Jul 14 00:20:26 1998 Delivery-Date: Tue, 14 Jul 1998 00:20:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA18202 for ; Tue, 14 Jul 1998 00:20:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA07234 for ; Tue, 14 Jul 1998 00:20:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA10722 for ; Tue, 14 Jul 1998 00:20:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 00:15:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA10117 for ipp-outgoing; Tue, 14 Jul 1998 00:12:26 -0400 (EDT) Message-Id: <3.0.5.32.19980713211112.011c1740@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Jul 1998 21:11:12 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: Agenda for IPP Phone Conference 980715 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org FYI, Carl-Uno >X-URI: http://www.cs.utk.edu/~moore/ >From: Keith Moore >To: Carl-Uno Manros >cc: moore@cs.utk.edu >Subject: Re: Agenda for IPP Phone Conference 980715 >Date: Mon, 13 Jul 1998 13:14:21 PDT >Sender: moore@cs.utk.edu > >Carl-Uno, > >I'll dial in to the conference call on Wednesday. I'll also ask >Patrik if he wants to join in. > >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 From ipp-owner@pwg.org Tue Jul 14 08:03:19 1998 Delivery-Date: Tue, 14 Jul 1998 08:03:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA25778 for ; Tue, 14 Jul 1998 08:02:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA08130 for ; Tue, 14 Jul 1998 08:02:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA26367 for ; Tue, 14 Jul 1998 08:02:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 07:55:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA25808 for ipp-outgoing; Tue, 14 Jul 1998 07:50:45 -0400 (EDT) Message-Id: <35AB44BC.B968910B@dazel.com> Date: Tue, 14 Jul 1998 06:45:00 -0500 From: Jim Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Larry Masinter Cc: don@lexmark.com, ipp@pwg.org Subject: Re: IPP> Re: New IPP Scheme References: <002401bdaec7$fa7f17c0$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Larry Masinter wrote: > > > Web: http://www.lexmark.com > > Printer: http://printer1.bldg035.lexmark.com > > > Don, your "printer" URL here is broken and it will fail to work, > because the default port for ipp is "631", so if you are going to > ship a compliant product you will have to write > > Web: http://www.lexmark.com > Printer: http://printer1.bldg035.lexmark.com:631 > > Be sure to get the port right, OK? > > If you can't get this little detail right (it's 631, right? Not 632? > Are you sure?) then why do you expect your users to? > > ... yada yada yada ... But, Larry, you forget that 631 is just a *default* port. There is absolutely nothing that says a conforming implementation can't allow usage on other ports (just as a web server allows usage of ports other than 80). So, Don's example is completely legitimate and accurate. His administrator (you do have your private sysadmin, don't you Don ;-) simply chose to configure his IPP printer to run on port 80. so there... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-owner@pwg.org Tue Jul 14 12:45:23 1998 Delivery-Date: Tue, 14 Jul 1998 12:45:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05492 for ; Tue, 14 Jul 1998 12:45:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA09897 for ; Tue, 14 Jul 1998 12:45:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA28183 for ; Tue, 14 Jul 1998 12:45:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 12:40:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27636 for ipp-outgoing; Tue, 14 Jul 1998 12:36:39 -0400 (EDT) From: Harry Lewis To: , Subject: IPP> Chicago Message-ID: <5030100023122001000002L012*@MHS> Date: Tue, 14 Jul 1998 12:35:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA05492 >Please look over Keith's reply... Keith would like >to get our reaction by July 15th. >Carl-Uno (7/10) In Monterey, I expressed the urgent need to bring IPP to an agreed to level for implementation. To the extent that the "Monterey Response" to Keith Moore appears to be moving toward compromise and convergence, our team will give consideration to this effort to the point of ratification by the IESG at Chicago, in August. We feel that a timely standard is preferred over the proliferation of independent schemes for Internet printing and have supported the PWG in this effort. We believe that IPP is adequate and that the public will be better served and much more concrete information will be learned from actual experience, at this point, rather than continued debate. We encourage "closure" as the overriding issue. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Tue Jul 14 13:09:22 1998 Delivery-Date: Tue, 14 Jul 1998 13:09:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA06115 for ; Tue, 14 Jul 1998 13:09:22 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA10019 for ; Tue, 14 Jul 1998 13:09:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA28852 for ; Tue, 14 Jul 1998 13:09:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 13:04:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28290 for ipp-outgoing; Tue, 14 Jul 1998 13:01:16 -0400 (EDT) From: don@lexmark.com Message-Id: <199807141659.AA02191@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Keith Moore Cc: Rich Gray , "'Keith Moore'" , Ipp@pwg.org, Moore@cs.utk.edu Date: Tue, 14 Jul 1998 12:46:55 -0400 Subject: Re: IPP> Re: IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Keith Moore said: >The problem with using http: for printers is that it hides the fact >that the resource is a printer. ... and the problem with "ipp:" is that it hides the fact that the protocol is really HTTP!!! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Jul 14 14:51:11 1998 Delivery-Date: Tue, 14 Jul 1998 14:51:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08618 for ; Tue, 14 Jul 1998 14:51:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA10635 for ; Tue, 14 Jul 1998 14:51:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29956 for ; Tue, 14 Jul 1998 14:50:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 14:45:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29420 for ipp-outgoing; Tue, 14 Jul 1998 14:40:22 -0400 (EDT) From: don@lexmark.com Message-Id: <199807141840.AA07798@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: "Larry Masinter" Cc: Ipp@pwg.org Date: Tue, 14 Jul 1998 13:18:39 -0400 Subject: RE: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Larry Masinter said: >Don, your "printer" URL here is broken and it will fail to work, >because the default port for ipp is "631" Sorry Larry, but my printer isn't on the default IPP port of 631. Mine is on 80 so my URL is exactly right. Not all implementations MUST be on 631. That is simply the default for IPP. I could have also chosen to publish my printer as: Printer: http://printer1.bldg035.lexmark.com:444 which would have also be correct if my printer was on port 444. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Tue Jul 14 15:09:10 1998 Delivery-Date: Tue, 14 Jul 1998 15:09:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09096 for ; Tue, 14 Jul 1998 15:09:09 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10767 for ; Tue, 14 Jul 1998 15:09:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00665 for ; Tue, 14 Jul 1998 15:09:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 15:05:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00057 for ipp-outgoing; Tue, 14 Jul 1998 15:01:41 -0400 (EDT) Message-Id: <199807141900.PAA10692@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: Keith Moore , Rich Gray , Ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: IPP Scheme In-reply-to: Your message of "Tue, 14 Jul 1998 12:46:55 EDT." <199807141659.AA02191@interlock2.lexmark.com> Date: Tue, 14 Jul 1998 15:00:37 -0400 Sender: owner-ipp@pwg.org > >The problem with using http: for printers is that it hides the fact > >that the resource is a printer. > > ... and the problem with "ipp:" is that it hides the fact that > the protocol is really HTTP!!! I guess I consider it more important for the URL to describe the end resource that it's providing, than for it to describe the underlying protocol(s). We don't have tcp: or ip: URLs; we have URLs for higher level services. Some URL schemes don't imply a particular protocol. However, for every URL scheme that uses the name of a protocol, the URL names the highest layer protocol on the stack, rather than some lower layer. Keith From ipp-owner@pwg.org Tue Jul 14 15:50:28 1998 Delivery-Date: Tue, 14 Jul 1998 15:50:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA13214 for ; Tue, 14 Jul 1998 15:50:27 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11026 for ; Tue, 14 Jul 1998 15:50:24 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01349 for ; Tue, 14 Jul 1998 15:50:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 15:45:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00783 for ipp-outgoing; Tue, 14 Jul 1998 15:41:49 -0400 (EDT) From: "Larry Masinter" To: Cc: , Subject: RE: IPP> Re: New IPP Scheme Date: Tue, 14 Jul 1998 12:40:56 PDT Message-ID: <003101bdaf5f$5191b760$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <35AB44BC.B968910B@dazel.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org Don: > > Web: http://www.lexmark.com > > Printer: http://printer1.bldg035.lexmark.com me: > compliant product you will have to write > > Web: http://www.lexmark.com > Printer: http://printer1.bldg035.lexmark.com:631 Jim: > But, Larry, you forget that 631 is just a *default* port. There > is absolutely nothing that says a conforming implementation can't > allow usage on other ports (just as a web server allows usage of > ports other than 80). > > So, Don's example is completely legitimate and accurate. His > administrator (you do have your private sysadmin, don't you > Don ;-) simply chose to configure his IPP printer to run on > port 80. Doesn't this just support the assertion that that using the "http" would encourage end-users to reconfigure the printers on their LANs to use the non-standard port 80, merely so that their users can put "http://printer1.bldg35.lexmark.com" on their business cards? Larry From ipp-owner@pwg.org Tue Jul 14 15:56:05 1998 Delivery-Date: Tue, 14 Jul 1998 15:56:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA14167 for ; Tue, 14 Jul 1998 15:55:44 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11072 for ; Tue, 14 Jul 1998 15:55:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01966 for ; Tue, 14 Jul 1998 15:55:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 15:51:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00936 for ipp-outgoing; Tue, 14 Jul 1998 15:46:06 -0400 (EDT) Message-Id: <199807141940.MAA21099@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 14 Jul 1998 12:46:29 -0700 To: Keith Moore , don@lexmark.com From: Robert Herriot Subject: Re: IPP> Re: New IPP Scheme Cc: Scott Lawrence , Ipp@pwg.org, Keith Moore , moore@cs.utk.edu In-Reply-To: <199807131315.JAA02267@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_666159366==_.ALT" Sender: owner-ipp@pwg.org --=====================_666159366==_.ALT Content-Type: text/plain; charset="us-ascii" If there is going to be a separate "E.164" URL type for voice and fax, how does mechanism work for phone numbers that are both voice and fax -- many homes have a system that takes voice messages and faxes. Bob Herriot At 06:14 AM 7/13/98 , Keith Moore wrote: >> 2. In cases where people handle URL's, I think the "http:" URL is better >> from a number of perspectives which I have already described. Some how >> people seem to figure out business cards that say: >> >> Phone: 606-232-4808 >> Fax: 606-232-6740 >> > >It's interesting that you should cite that case. The discussion recently >came up on the URI list as to whether there should be a single "E.164" >URL type for all phone numbers, or whether there should be separate URL >types for voice, fax, etc. > >The conclusion was that they had to be separate, because the user >interfaces for the handling of fax and phone needed to be different, >and also because in some cases (e.g. ISDN) the call setup actually >needed to know which was being used before the call was placed. > >The http/ipp argument seems very similar to me, with a similar conclusion. > >Keith > --=====================_666159366==_.ALT Content-Type: text/html; charset="us-ascii" If there is going to be a separate "E.164" URL type for voice and fax, how
does mechanism work for phone numbers that are both voice and fax -- many
homes have a system that takes voice messages and faxes. 

Bob Herriot


At 06:14 AM 7/13/98 , Keith Moore wrote:
>> 2.  In cases where people handle URL's, I think the "http:" URL is better
>> from a number of perspectives which I have already described.  Some how
>> people seem to figure out business cards that say:
>>
>> Phone: 606-232-4808
>> Fax: 606-232-6740
>>
>
>It's interesting that you should cite that case.  The discussion recently
>came up on the URI list as to whether there should be a single "E.164"
>URL type for all phone numbers, or whether there should be separate URL
>types for voice, fax, etc.
>
>The conclusion was that they had to be separate, because the user
>interfaces for the handling of fax and phone needed to be different,
>and also because in some cases (e.g. ISDN) the call setup actually
>needed to know which was being used before the call was placed.
>
>The http/ipp argument seems very similar to me, with a similar conclusion.
>
>Keith
>
--=====================_666159366==_.ALT-- From ipp-owner@pwg.org Tue Jul 14 16:09:05 1998 Delivery-Date: Tue, 14 Jul 1998 16:09:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14791 for ; Tue, 14 Jul 1998 16:09:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA11168 for ; Tue, 14 Jul 1998 16:09:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02631 for ; Tue, 14 Jul 1998 16:09:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 16:05:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02059 for ipp-outgoing; Tue, 14 Jul 1998 16:02:04 -0400 (EDT) Message-Id: <199807142001.QAA10950@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Herriot cc: Keith Moore , don@lexmark.com, Scott Lawrence , Ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: New IPP Scheme In-reply-to: Your message of "Tue, 14 Jul 1998 12:46:29 PDT." <199807141940.MAA21099@woden.eng.sun.com> Date: Tue, 14 Jul 1998 16:01:50 -0400 Sender: owner-ipp@pwg.org > If there is going to be a separate "E.164" URL type for voice and fax, how > does mechanism work for phone numbers that are both voice and fax -- many > homes have a system that takes voice messages and faxes. There is not going to be a separate E.164 URL type. It was eventually clear to (nearly) everyone that this was the wrong way to go. Voice and fax on the same E.164 number are really no different than multiple services served by the same IP address. In either case, we use a different URL scheme name for each service. Keith From ipp-owner@pwg.org Tue Jul 14 17:05:19 1998 Delivery-Date: Tue, 14 Jul 1998 17:05:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16022 for ; Tue, 14 Jul 1998 17:05:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA11497 for ; Tue, 14 Jul 1998 17:05:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03449 for ; Tue, 14 Jul 1998 17:05:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 17:00:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02878 for ipp-outgoing; Tue, 14 Jul 1998 16:56:01 -0400 (EDT) Message-Id: <199807142050.NAA21208@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 14 Jul 1998 13:56:36 -0700 To: Keith Moore , Robert Herriot From: Robert Herriot Subject: Re: IPP> Re: New IPP Scheme Cc: Keith Moore , don@lexmark.com, Scott Lawrence , Ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <199807142001.QAA10950@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_670366005==_.ALT" Sender: owner-ipp@pwg.org --=====================_670366005==_.ALT Content-Type: text/plain; charset="us-ascii" If there is one URL scheme for a fax telephone number and another for a voice telephone number. What scheme do I use for a telephone number that handles both fax and voice? Is there a third scheme that means "voice or fax"? Bob Herriot At 01:01 PM 7/14/98 , Keith Moore wrote: >> If there is going to be a separate "E.164" URL type for voice and fax, how >> does mechanism work for phone numbers that are both voice and fax -- many >> homes have a system that takes voice messages and faxes. > >There is not going to be a separate E.164 URL type. It was eventually >clear to (nearly) everyone that this was the wrong way to go. > >Voice and fax on the same E.164 number are really no different than >multiple services served by the same IP address. In either case, >we use a different URL scheme name for each service. > >Keith > --=====================_670366005==_.ALT Content-Type: text/html; charset="us-ascii" If there is one URL scheme for a fax telephone number and another for a voice telephone number.  What scheme do I use for a telephone number that handles both fax and voice?  Is there a third scheme that means "voice or fax"?

Bob Herriot


At 01:01 PM 7/14/98 , Keith Moore wrote:
>> If there is going to be a separate "E.164" URL type for voice and fax, how
>> does mechanism work for phone numbers that are both voice and fax -- many
>> homes have a system that takes voice messages and faxes. 
>
>There is not going to be a separate E.164 URL type.  It was eventually
>clear to (nearly) everyone that this was the wrong way to go.
>
>Voice and fax on the same E.164 number are really no different than
>multiple services served by the same IP address.  In either case,
>we use a different URL scheme name for each service.
>
>Keith
>
--=====================_670366005==_.ALT-- From ipp-owner@pwg.org Tue Jul 14 18:15:25 1998 Delivery-Date: Tue, 14 Jul 1998 18:15:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17354 for ; Tue, 14 Jul 1998 18:15:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA11873 for ; Tue, 14 Jul 1998 18:15:21 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04327 for ; Tue, 14 Jul 1998 18:15:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 18:10:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03719 for ipp-outgoing; Tue, 14 Jul 1998 18:04:23 -0400 (EDT) Message-Id: <199807142203.SAA11719@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Herriot cc: Keith Moore , don@lexmark.com, Scott Lawrence , Ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: New IPP Scheme In-reply-to: Your message of "Tue, 14 Jul 1998 13:56:36 PDT." <199807142050.NAA21208@woden.eng.sun.com> Date: Tue, 14 Jul 1998 18:03:36 -0400 Sender: owner-ipp@pwg.org > If there is one URL scheme for a fax telephone number and another for a > voice telephone number. What scheme do I use for a telephone number > that handles both fax and voice? What scheme do you use for an Internet host that handles smtp+pop+imap+http+ftp? Keith From ipp-owner@pwg.org Tue Jul 14 18:20:39 1998 Delivery-Date: Tue, 14 Jul 1998 18:20:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17461 for ; Tue, 14 Jul 1998 18:20:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA11883 for ; Tue, 14 Jul 1998 18:20:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA04950 for ; Tue, 14 Jul 1998 18:20:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 18:16:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03870 for ipp-outgoing; Tue, 14 Jul 1998 18:11:06 -0400 (EDT) Message-ID: From: "Zehler, Peter " To: "IPP Discussion List (E-mail)" Subject: IPP> IPP Bake-Off Ping Date: Tue, 14 Jul 1998 13:46:30 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipp@pwg.org All, This is a ping for organizations that will be willing to participate in face to face IPP interoperability test. The IPP "bake-off" will be held the week of September 14. If you are interested in participating in the "bake-off" please contact me via email. If you wish me to keep your organization confidential please let me know. It would also be helpful to include if you are an IPP Printer, Client or Test Suite. I will publish a count of the implementations that will be ready by mid-September. I will also list any organizations that do not mind. The details of the test will be worked out at the next step of this process. I will have an IPP Printer implementation available for the IPP "bake-off". I do not wish to keep this information private. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Tue Jul 14 18:34:08 1998 Delivery-Date: Tue, 14 Jul 1998 18:34:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17711 for ; Tue, 14 Jul 1998 18:34:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA11959 for ; Tue, 14 Jul 1998 18:34:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA05638 for ; Tue, 14 Jul 1998 18:34:04 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 18:30:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05052 for ipp-outgoing; Tue, 14 Jul 1998 18:27:11 -0400 (EDT) Message-ID: From: Kris Schoff To: "'moore@cs.utk.edu'" , "'ipp@pwg.org'" Subject: IPP> A response to Keith Date: Tue, 14 Jul 1998 16:26:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Keith- I am IN favor of you recruiting different people to respond to helping address the issues of security and scheme problems. This ratification process has taken a VERY long time and any knowledge that may help speed up the process would be welcome. I am also interested in hearing the final opinion (concerns and compliments) of IESG regarding the latest IPP proposals. Kris Schoff Hewlett-Packard > > My proposal: > > The IPP documents will not be approved as a Proposed Standard until > they are fixed to use ipp: URLs instead of http: URLs. > > With an eye toward making them acceptable to IESG while addressing > the IPP group's concerns: > > - I will recruit a team of experts from the HTTP working group > and ask them to quickly review the ipp: scheme proposal for potential > interoperability problems with proxies. > > - I will recruit experts from the web and TLS communities to design > appropriate URL parameters for use with TLS, which can be shared > by other URL schemes besides ipp:. > > The IPP documents have been submitted for IESG ballot, and may be > on IESG's agenda for discussion as early as July 16th. I would > therefore like a decision from IPP by July 15th as to whether > the IPP working group is willing to pursue this course of action. > > Note that there may still be other IESG concerns with this protocol, > particularly on security. We won't know about those until the IESG > finishes its ballot. > > Keith From ipp-owner@pwg.org Tue Jul 14 22:24:35 1998 Delivery-Date: Tue, 14 Jul 1998 22:24:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA21961 for ; Tue, 14 Jul 1998 22:24:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA12535 for ; Tue, 14 Jul 1998 22:24:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA07002 for ; Tue, 14 Jul 1998 22:24:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 22:15:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA06394 for ipp-outgoing; Tue, 14 Jul 1998 22:12:25 -0400 (EDT) Message-Id: <199807150207.TAA21443@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 14 Jul 1998 19:13:30 -0700 To: Keith Moore , ipp@pwg.org From: Robert Herriot Subject: Re: IPP> possible compromise? Cc: moore@cs.utk.edu In-Reply-To: <199807122347.TAA28324@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_13432224==_.ALT" Sender: owner-ipp@pwg.org --=====================_13432224==_.ALT Content-Type: text/plain; charset="us-ascii" After reading the email between Keith Moore and various members of the IPP working group, I see much agreement, and some remaining points of disagreement based on Keith's July 12th email "possible compromise?" (enclosed below). I will suggest a slightly different compromise. Keith and the IPP working group are in agreement: 1) Clients send only 'http' schemes in the HTTP Request-Line 2) Servers support the reception only of 'http' schemes in the HTTP Request-Line Keith and the IPP working group are in disagreement about: 1) the scheme in the value of IPP attributes, such as "printer-uri". Keith wants 'ipp'. The IPP working group wants 'http'. 2) the scheme in external notation for printer URL's. Keith wants 'ipp'. The IPP working group wants 'http'. The IPP working group wants an 'http' scheme for issue #1 because they believe it is the cleanest design and avoids the mapping issue for clients that never expose a URL to a user. We don't understand the virtue of having an 'ipp' scheme in a block of data that a client must process, but that neither a user nor networking software ever see. The 'http' choice (with its lack of mapping) also allows a print server to use an 'https' scheme in an IPP attribute without any mapping issues. Although 'https' is not a part of IPP, most vendors will probably support it for pragmatic reasons. Keith's solution creates a mapping problem for clients while giving no apparent benefit to the client. If there is a benefit at the client level, we have been unable to understand what it is. If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal makes the wrong partitioning of 'ipp' and 'http'. The partitioning should occur between client and user interface and not between the sending and receiving portions of the client. I might support a requirement that users refer to a printer with an 'ipp' scheme (issue #2), even though such a requirement seems to be beyond a protocol standard. But before giving such support, I would like to understand why the IETF wants a scheme to specify the type of service. I would also like to see an IETF document that describes the intent and goals of this differentiation of schemes, as well as the infrastructure needed to support it. I would like to know how a protocol designer decides if a new service is different enough to warrant a new scheme. I would like to know if someone has thought about how to avoid the "new area code" problem as each new scheme is introduced. Without a such information, I am left wondering if the requirement of a new scheme for each new service will turn out to be a good idea. Finally, I wonder how long it would have taken faxes to be deployed if someone had required a special fax number instead of a standard phone number. Bob Herriot At 04:47 PM 7/12/98 , Keith Moore wrote: >I was thinking about the problem where using ipp: URLs in >the HTTP POST operation potentially makes IPP incompatible >with existing servers, and came up with the following possible >compromise solution. I'm willing to defend this to IESG if >the IPP group buys into it. > >1. use the http: form of the URL in HTTP protocol elements > >if you're talking to a proxy, do > >POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 > >if you're talking to an origin server, you should really do > >POST /myprinter/myqueue HTTP/1.1 >Host: myhost.com:631 > >but origin servers are *also* expected to accept > >POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 > >just as in vanilla HTTP 1.1. > >This way, the HTTP layer never has to see ipp: at all. >This should preserve compatibility with HTTP servers >and HTTP client libraries. > >2. use the ipp: form of the URL in IPP protocol elements >that refer to printer objects > >3. define ipp: URLs as a standard external notation for >referring to printers - and the IPP protocol document describes >how to take an ipp: URL and generate the appropriate HTTP/1.1 >POST request. Printer clients are expected to be able to >do this. > >That way, the ipp: URL can be used when it's useful to >expose the fact that the named object is a printer. > >The IPP server is free to respond to a GET on the its >printer URL, and return HTML that describes the printer, >how to talk to it, etc. And users are free to export >this URL as an http: URL if they want to do so and >their printers support it. > >But users and clients should be cautioned to not assume >that the "GET URL" is the same as the "print URL". > >Keith > --=====================_13432224==_.ALT Content-Type: text/html; charset="us-ascii" After reading the email between Keith Moore and various members of the IPP
working group, I see much agreement, and some remaining points of
disagreement based on Keith's July 12th email "possible compromise?"
(enclosed below).

I will suggest a slightly different compromise.

Keith and the IPP working group are in agreement:

    1) Clients send only 'http' schemes in the HTTP Request-Line
    2) Servers support the reception only of 'http' schemes in the HTTP Request-Line


Keith and the IPP working group are in disagreement about:
   1)  the scheme in the value of  IPP attributes, such as "printer-uri".
        Keith wants 'ipp'. The IPP working group wants 'http'.
   2)  the scheme in external notation for printer URL's. Keith wants 'ipp'.
        The IPP working group wants 'http'.

The IPP working group wants an 'http' scheme for issue #1 because they
believe it is the cleanest design and avoids the mapping issue for clients
that never expose a URL to a user. We don't understand the virtue of having
an 'ipp' scheme in a block of data that a client must process, but that
neither a user nor networking software ever see. The 'http' choice (with its
lack of mapping) also allows a print server to use an 'https' scheme in an
IPP attribute without any mapping issues.   Although 'https' is not a part
of  IPP, most vendors will probably support it for pragmatic reasons.

Keith's solution creates a mapping problem for clients while giving no
apparent benefit to the client.  If there is a benefit at the client  level,
we have been unable to understand what it is.

If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal
makes the wrong partitioning of 'ipp' and 'http'.  The partitioning should
occur between client and user interface and not between the sending and
receiving portions of the client.

I might support a requirement that users refer to a printer with an 'ipp'
scheme (issue #2), even though such a requirement seems to be beyond a
protocol standard.

But before giving such support, I would like to understand why the IETF
wants a scheme to specify the type of service.  I would also like to see an
IETF document that describes the intent and goals of this differentiation of
schemes, as well as the infrastructure needed to support it.  I would like
to know how a protocol designer decides if a new service is different enough
to warrant a new scheme. I would like to know if someone has thought about
how to avoid the "new area code" problem as each new scheme is introduced.
Without a such information, I am left wondering if the requirement of a  new
scheme for each new service will turn out to be a good idea.

Finally, I wonder how long it would have taken faxes to be deployed if
someone had required a special fax number instead of a standard phone number. 


Bob Herriot




At 04:47 PM 7/12/98 , Keith Moore wrote:
>I was thinking about the problem where using ipp: URLs in
>the HTTP POST operation potentially makes IPP incompatible
>with existing servers, and came up with the following possible
>compromise solution.  I'm willing to defend this to IESG if
>the IPP group buys into it.
>
>1. use the http: form of the URL in HTTP protocol elements
>
>if you're talking to a proxy, do
>
>POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
>
>if you're talking to an origin server, you should really do
>
>POST /myprinter/myqueue HTTP/1.1
>Host: myhost.com:631
>
>but origin servers are *also* expected to accept
>
>POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
>
>just as in vanilla HTTP 1.1.
>
>This way, the HTTP layer never has to see ipp: at all.
>This should preserve compatibility with HTTP servers
>and HTTP client libraries.
>
>2. use the ipp: form of the URL in IPP protocol elements
>that refer to printer objects
>
>3. define ipp: URLs as a standard external notation for
>referring to printers - and the IPP protocol document describes
>how to take an ipp: URL and generate the appropriate HTTP/1.1
>POST request.  Printer clients are expected to be able to
>do this. 
>
>That way, the ipp: URL can be used when it's useful to
>expose the fact that the named object is a printer.
>
>The IPP server is free to respond to a GET on the its
>printer URL, and return HTML that describes the printer,
>how to talk to it, etc.  And users are free to export
>this URL as an http: URL if they want to do so and
>their printers support it.
>
>But users and clients should be cautioned to not assume
>that the "GET URL" is the same as the "print URL".
>
>Keith
>
--=====================_13432224==_.ALT-- From ipp-owner@pwg.org Tue Jul 14 23:55:57 1998 Delivery-Date: Tue, 14 Jul 1998 23:55:58 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA00954 for ; Tue, 14 Jul 1998 23:55:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA12787 for ; Tue, 14 Jul 1998 23:55:55 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA07981 for ; Tue, 14 Jul 1998 23:55:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Jul 1998 23:50:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA07346 for ipp-outgoing; Tue, 14 Jul 1998 23:43:50 -0400 (EDT) Message-Id: <199807150343.XAA12627@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Herriot cc: Keith Moore , ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> possible compromise? In-reply-to: Your message of "Tue, 14 Jul 1998 19:13:30 PDT." <199807150207.TAA21443@woden.eng.sun.com> Date: Tue, 14 Jul 1998 23:43:36 -0400 Sender: owner-ipp@pwg.org > Keith and the IPP working group are in agreement: > > 1) Clients send only 'http' schemes in the HTTP Request-Line > 2) Servers support the reception only of 'http' schemes in the HTTP > Request-Line > > > Keith and the IPP working group are in disagreement about: > 1) the scheme in the value of IPP attributes, such as "printer-uri". > Keith wants 'ipp'. The IPP working group wants 'http'. > 2) the scheme in external notation for printer URL's. Keith wants 'ipp'. > The IPP working group wants 'http'. > > The IPP working group wants an 'http' scheme for issue #1 because they > believe it is the cleanest design and avoids the mapping issue for clients > that never expose a URL to a user. We don't understand the virtue of having > an 'ipp' scheme in a block of data that a client must process, but that > neither a user nor networking software ever see. The 'http' choice (with its > lack of mapping) also allows a print server to use an 'https' scheme in an > IPP attribute without any mapping issues. Although 'https' is not a part > of IPP, most vendors will probably support it for pragmatic reasons. This had occurred to me. What worries me about the idea is that it's going down the slippery slope toward having http: visible to users. My experience is that users will see the ipp protocol elements; they will not entirely be hidden. Having them at the HTTP protocol level is confusing enough, but it seemed like a reasonable compromise to make for the sake of code reusability. As long as the client has to be able to deal with ipp: URLs from users anyway, I don't see how having ipp: URLs in IPP protocol elements places any more hardship on the client. It seems like this conversion in the client only needs to be done in one place - in the code that interfaces to the HTTP layer. Everywhere else, the client should deal with URLs in ipp: format. As for the use of https: in IPP attributes, I don't think IESG will be very sympathetic. To me at least, the http:/https: distinction seems insufficient for the purpose at hand, and I suspect that the security ADs will agree. But whatever they decide about http/https, I'll defer to their judgement on that one. > Keith's solution creates a mapping problem for clients while giving no > apparent benefit to the client. If there is a benefit at the client level, > we have been unable to understand what it is. There is definitely a benefit for clients that have plugins for different URL types. A new ipp: URL type can be accomodated with an ipp plugin, while the behavior for http: is either wired-in, or changing it to support ipp incurs the possibility of changing the behavior for ordinary http access. (and it gets worse if there are more than two protocols that want to layer over http and use the http URL...whose plugin gets used -- the ipp+http one or the xyz+http one?) > If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal > makes the wrong partitioning of 'ipp' and 'http'. The partitioning should > occur between client and user interface and not between the sending and > receiving portions of the client. I don't see the partition between sending and receiving portions of the client. The partition I see is between the sending portion of the client and its http module. It seems like a clean translation to me, especially because it only needs to be done in the ipp->http direction. What am I missing? > I might support a requirement that users refer to a printer with an 'ipp' > scheme (issue #2), even though such a requirement seems to be beyond a > protocol standard. > > But before giving such support, I would like to understand why the IETF > wants a scheme to specify the type of service. I would also like to see an > IETF document that describes the intent and goals of this differentiation of > schemes, as well as the infrastructure needed to support it. I would like > to know how a protocol designer decides if a new service is different enough > to warrant a new scheme. Some thinking has been done about this. A draft document that discusses all of these is being circulated internally by IESG and IAB, and being commented on. > I would like to know if someone has thought about how to avoid the "new > area code" problem as each new scheme is introduced. Without a such > information, I am left wondering if the requirement of a new > scheme for each new service will turn out to be a good idea. I'm not sure I follow the area code analogy. To me the new area code problem is that existing phone numbers have to change. That doesn't happen when a new URL scheme is introduced, because it's naming new services that didn't exist in the past. The closest analogous problem that comes to mind is where you have a service on protocol A named by an A: URL, and you want to offer the service using (faster, cheaper, better) protocol B for those cases that the client also supports B. This can be done with URI resolution techniques that are being worked on, but they're not yet ready for prime time. My guess is that the upcoming http-ng work might well push this along, because nobody wants to change all of those http: URLs that are out there for the sake of supporting http-ng. > Finally, I wonder how long it would have taken faxes to be deployed if > someone had required a special fax number instead of a standard phone number. I don't think it's a valid analogy. Faxes benefited from use of voice lines - in most cases you didn't need a special phone line for faxes. (and if you had needed a special fax line, the phone companies would have tried to charge you more money for them.) But if there had been phone lines and fax lines available at the same price, it would have been a convenience - not a burden - for phone numbers to look slightly different than fax numbers. Nobody would have ever gotten the two confused; nobody would have ever dialed a wrong number and gotten a fax machine instead of a voice, or vice versa. As it is, ISDN does distinguish voice from fax from data. The distinction didn't have to be in the phone number - it's another parameter in call setup. That's like saying that we don't require the distinction between ipp and http to be in the domain name of the server host - it should be in the URL prefix for consistency with other URLs. Keith From ipp-owner@pwg.org Wed Jul 15 00:35:25 1998 Delivery-Date: Wed, 15 Jul 1998 00:35:30 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01612 for ; Wed, 15 Jul 1998 00:35:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA12855 for ; Wed, 15 Jul 1998 00:35:19 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA08739 for ; Wed, 15 Jul 1998 00:35:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 00:30:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA08171 for ipp-outgoing; Wed, 15 Jul 1998 00:24:53 -0400 (EDT) Message-Id: <1.5.4.32.19980715042120.00752a6c@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, 14 Jul 1998 21:21:20 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Where do we stand in the debate? Sender: owner-ipp@pwg.org All, I have been asked by some of the people on the DL to try to summarize where we are and what is still under debate. Here my attempt: On the use of an "ipp:" scheme ------------------------------ Keith liked the "ipp:" scenario which we developed in Monterey (and shot down due to a number of concerns). After debate with Randy and others, Keith came up with a compromise proposal which modifies the "ipp:" scenario to state that "ipp:" will NEVER be used on the HTTP layer. This includes proxies and any other variations of communication on the HTTP layer. The compromise proposal still requires that "ipp:" be used in the IPP objects references within the application/ipp MIME object, as well as on all user interfaces, including directories, service location etc. I have still not seen any consensus within the IPP WG whether the members are prepared to accept the suggested compromise. I would also like to have verified whether the IPP members have accepted Keith's responses to the issues list in the Monterey document. Reading through the email messages, I think that there are still some answers outstanding or further clarifications needed. On security service negotiation ------------------------------- This issue is still a big question mark. Keith has suggested to bring in expertise on security and on URL parameters to help resolve this problem, which does not seem to be unique to IPP. We are not any closer to a resolution to this issue then we were earlier. --- Let us see what the discussion of these subjects brings in tomorrow's phone conference. Carl-Uno From ipp-owner@pwg.org Wed Jul 15 05:16:52 1998 Delivery-Date: Wed, 15 Jul 1998 05:16:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA08850 for ; Wed, 15 Jul 1998 05:16:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA13316 for ; Wed, 15 Jul 1998 05:16:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA17038 for ; Wed, 15 Jul 1998 05:16:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 05:10:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA16022 for ipp-outgoing; Wed, 15 Jul 1998 05:05:47 -0400 (EDT) From: "Larry Masinter" To: "Robert Herriot" , "Keith Moore" , Cc: Subject: RE: IPP> possible compromise? Date: Wed, 15 Jul 1998 02:05:09 PDT Message-ID: <000c01bdafcf$ab0ba4c0$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199807150207.TAA21443@woden.eng.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipp@pwg.org Robert, Herriot wrote: # I would also like to see an IETF document that describes the intent # and goals of this differentiation of schemes, as well as the infrastructure # needed to support it. primarily: draft-ietf-urlreg-guide-02.txt but also: RFC 1630 (URI in WWW) RFC 1738 (URL) draft-fielding-uri-syntax-03.txt RFC 2068 (HTTP) The first document that describes the intent and goals of schemes was RFC 1630 "Universal Resource Identifiers in WWW". This is an Informational document, which was then followed by RFC 1738, "Uniform Resource Locators" Soon after that document was released, there was a lengthy debate over the issue of the use of the 'gopher:' URL scheme for implementing the 'finger' protocol, and a belief that -- even though you could think of 'finger' being a gopher call on a different port, and restricted to a subset of gopher syntax -- that it was an inappropriate use, and that finger should have its own scheme. After the publication of RFC 1738, a set of guidelines for registration of new schemes arose in notes on the URI mailing list and a web page maintained by Harald Alvestraad. Eventually, we formed a working group (URLREG), which is developing guidelines for new URL schemes; draft-ietf-urlreg-guide-02.txt is the latest document. The document is primarily focused on the converse issue to that at hand in IPP: the problem of people trying to register schemes that are inappropriate, rather than that of people trying to use existing schemes inappropriately. But, for example, section 2.2.5 seems to allude to the fact that the "http" scheme is mostly used as a mechanism to access a data resource. In general, if a URL scheme is registered for one purpose, a new standards track document should not (without review) usurp that scheme for a different purpose. # I would like to know how a protocol designer decides if a new service # is different enough to warrant a new scheme. There are guidelines, and then there is process. We can write better guidelines, I hope, but coming up with a deterministic process may be hard. Giving an effective decision procedure for when new schemes are appropriate has been a thorny problem for the URL registration group, and the converse (when is a new scheme REQUIRED) is likely to have the same difficulties. In the end, it is a matter of judgement. The current process is that the IESG is the authority for that judgement, and that IESG approval is required for new registered schemes. One might imagine that the converse would hold: that IESG judgement is required ultimately to decide on when it is appropriate to reuse an old scheme for a new purpose. Larry From ipp-owner@pwg.org Wed Jul 15 08:24:35 1998 Delivery-Date: Wed, 15 Jul 1998 08:24:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA12516 for ; Wed, 15 Jul 1998 08:24:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA13860 for ; Wed, 15 Jul 1998 08:24:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA22976 for ; Wed, 15 Jul 1998 08:24:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 08:15:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA22393 for ipp-outgoing; Wed, 15 Jul 1998 08:11:02 -0400 (EDT) Content-return: allowed Date: Wed, 15 Jul 1998 05:09:57 PDT From: "Bennett, Joel H" Subject: RE: IPP> Re: IPP Scheme To: don@lexmark.com Cc: Ipp@pwg.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org So I suppose, if I follow this argument, that the problem with HTTP: is that it hides the fact that this is really TCP/IP? And perhaps, the problem with ftp: and mailto: URL's as well? why to we even need one at all? why not just have them all be "/www.xerox.com/mypage.html" and "/printers.xerox.com/myprinter" and "/ftp.xerox.com/myfilestorage" ;-) >-----Original Message----- > > >> >The problem with using http: for printers is that it hides the fact >> >that the resource is a printer. >> >> ... and the problem with "ipp:" is that it hides the fact that >> the protocol is really HTTP!!! > >I guess I consider it more important for the URL to describe the >end resource that it's providing, than for it to describe the >underlying protocol(s). We don't have tcp: or ip: URLs; we have >URLs for higher level services. Some URL schemes don't imply a >particular protocol. However, for every URL scheme that uses the >name of a protocol, the URL names the highest layer protocol >on the stack, rather than some lower layer. > >Keith As always, in HIS hands, Joel H. Bennett mail web -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- QOTD: All charming people, I fancy, are spoiled. It is the secret of their attraction., -- Oscar Wilde: 1854-1900, Irish writer From ipp-owner@pwg.org Wed Jul 15 11:10:57 1998 Delivery-Date: Wed, 15 Jul 1998 11:10:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17004 for ; Wed, 15 Jul 1998 11:10:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15122 for ; Wed, 15 Jul 1998 11:10:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24128 for ; Wed, 15 Jul 1998 11:10:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 11:05:13 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23563 for ipp-outgoing; Wed, 15 Jul 1998 11:03:45 -0400 (EDT) From: Harry Lewis To: Cc: Subject: Re: IPP> Where do we stand in the debate? Message-ID: <5030100023168486000002L062*@MHS> Date: Wed, 15 Jul 1998 11:02:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17004 Carl-Uno. thank you very much for the summary. This is quite helpful. I would like to seek even further clarification. >"ipp:" will NEVER be used on the HTTP layer. Is this the same as saying that (by example) ipp://my.printer.com will ALWAYS mean http://my.printer.com:631 and (by further example) ipp://my.printer.com:444 will mean http://my.printer.com:444? Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Jul 15 11:34:42 1998 Delivery-Date: Wed, 15 Jul 1998 11:34:42 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17952 for ; Wed, 15 Jul 1998 11:34:41 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15326 for ; Wed, 15 Jul 1998 11:34:38 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA24881 for ; Wed, 15 Jul 1998 11:34:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 11:30:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA24308 for ipp-outgoing; Wed, 15 Jul 1998 11:27:55 -0400 (EDT) From: Harry Lewis To: Cc: Subject: Re: IPP> possible compromise? Message-ID: <5030100023169840000002L002*@MHS> Date: Wed, 15 Jul 1998 11:26:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17952 Keith, I am trying very hard to follow this discussion to some form of bedrock. I'm not so adamant about the URL scheme... as long as I can base my initial implementation on existing, off-the-shelf HTTP servers, which I think we have safely agreed upon. What I do need, however, is a timely end to the development process for this standards specification. I suspect you would agree - none of us have inexhaustible resources. To this end, security appears to be a real "monkey wrench". Your statement represents a basic "open loop" in my estimation. >As for the use of https: in IPP attributes, I don't think IESG >will be very sympathetic. To me at least, the http:/https: >distinction seems insufficient for the purpose at hand, and I >suspect that the security ADs will agree. But whatever they >decide about http/https, I'll defer to their judgement on that >one. It is insufficient, at this point, to be in the position of taking a proposal to the IESG which we know will fail to ratify and which is completely "Catch22" in context. We can't have security because it's not there yet... yet we can't use the security which is there. Unless there is some certainty of a very near term resolution of the security issue which will satisfy the IESG, I claim we MUST focus (and adjust, if appropriate) the IPP effort on utilization of a viable interim security method. Harry Lewis - IBM Printing Systems owner-ipp@pwg.org on 07/14/98 09:57:40 PM Please respond to owner-ipp@pwg.org To: robert.herriot@Eng.Sun.COM cc: moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> possible compromise? > Keith and the IPP working group are in agreement: > > 1) Clients send only 'http' schemes in the HTTP Request-Line > 2) Servers support the reception only of 'http' schemes in the HTTP > Request-Line > > > Keith and the IPP working group are in disagreement about: > 1) the scheme in the value of IPP attributes, such as "printer-uri". > Keith wants 'ipp'. The IPP working group wants 'http'. > 2) the scheme in external notation for printer URL's. Keith wants 'ipp'. > The IPP working group wants 'http'. > > The IPP working group wants an 'http' scheme for issue #1 because they > believe it is the cleanest design and avoids the mapping issue for clients > that never expose a URL to a user. We don't understand the virtue of having > an 'ipp' scheme in a block of data that a client must process, but that > neither a user nor networking software ever see. The 'http' choice (with its > lack of mapping) also allows a print server to use an 'https' scheme in an > IPP attribute without any mapping issues. Although 'https' is not a part > of IPP, most vendors will probably support it for pragmatic reasons. This had occurred to me. What worries me about the idea is that it's going down the slippery slope toward having http: visible to users. My experience is that users will see the ipp protocol elements; they will not entirely be hidden. Having them at the HTTP protocol level is confusing enough, but it seemed like a reasonable compromise to make for the sake of code reusability. As long as the client has to be able to deal with ipp: URLs from users anyway, I don't see how having ipp: URLs in IPP protocol elements places any more hardship on the client. It seems like this conversion in the client only needs to be done in one place - in the code that interfaces to the HTTP layer. Everywhere else, the client should deal with URLs in ipp: format. As for the use of https: in IPP attributes, I don't think IESG will be very sympathetic. To me at least, the http:/https: distinction seems insufficient for the purpose at hand, and I suspect that the security ADs will agree. But whatever they decide about http/https, I'll defer to their judgement on that one. > Keith's solution creates a mapping problem for clients while giving no > apparent benefit to the client. If there is a benefit at the client level, > we have been unable to understand what it is. There is definitely a benefit for clients that have plugins for different URL types. A new ipp: URL type can be accomodated with an ipp plugin, while the behavior for http: is either wired-in, or changing it to support ipp incurs the possibility of changing the behavior for ordinary http access. (and it gets worse if there are more than two protocols that want to layer over http and use the http URL...whose plugin gets used -- the ipp+http one or the xyz+http one?) > If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal > makes the wrong partitioning of 'ipp' and 'http'. The partitioning should > occur between client and user interface and not between the sending and > receiving portions of the client. I don't see the partition between sending and receiving portions of the client. The partition I see is between the sending portion of the client and its http module. It seems like a clean translation to me, especially because it only needs to be done in the ipp->http direction. What am I missing? > I might support a requirement that users refer to a printer with an 'ipp' > scheme (issue #2), even though such a requirement seems to be beyond a > protocol standard. > > But before giving such support, I would like to understand why the IETF > wants a scheme to specify the type of service. I would also like to see an > IETF document that describes the intent and goals of this differentiation of > schemes, as well as the infrastructure needed to support it. I would like > to know how a protocol designer decides if a new service is different enough > to warrant a new scheme. Some thinking has been done about this. A draft document that discusses all of these is being circulated internally by IESG and IAB, and being commented on. > I would like to know if someone has thought about how to avoid the "new > area code" problem as each new scheme is introduced. Without a such > information, I am left wondering if the requirement of a new > scheme for each new service will turn out to be a good idea. I'm not sure I follow the area code analogy. To me the new area code problem is that existing phone numbers have to change. That doesn't happen when a new URL scheme is introduced, because it's naming new services that didn't exist in the past. The closest analogous problem that comes to mind is where you have a service on protocol A named by an A: URL, and you want to offer the service using (faster, cheaper, better) protocol B for those cases that the client also supports B. This can be done with URI resolution techniques that are being worked on, but they're not yet ready for prime time. My guess is that the upcoming http-ng work might well push this along, because nobody wants to change all of those http: URLs that are out there for the sake of supporting http-ng. > Finally, I wonder how long it would have taken faxes to be deployed if > someone had required a special fax number instead of a standard phone number. I don't think it's a valid analogy. Faxes benefited from use of voice lines - in most cases you didn't need a special phone line for faxes. (and if you had needed a special fax line, the phone companies would have tried to charge you more money for them.) But if there had been phone lines and fax lines available at the same price, it would have been a convenience - not a burden - for phone numbers to look slightly different than fax numbers. Nobody would have ever gotten the two confused; nobody would have ever dialed a wrong number and gotten a fax machine instead of a voice, or vice versa. As it is, ISDN does distinguish voice from fax from data. The distinction didn't have to be in the phone number - it's another parameter in call setup. That's like saying that we don't require the distinction between ipp and http to be in the domain name of the server host - it should be in the URL prefix for consistency with other URLs. Keith From ipp-owner@pwg.org Wed Jul 15 12:12:24 1998 Delivery-Date: Wed, 15 Jul 1998 12:12:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA19090 for ; Wed, 15 Jul 1998 12:12:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15524 for ; Wed, 15 Jul 1998 12:12:17 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25809 for ; Wed, 15 Jul 1998 12:12:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:05:18 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25089 for ipp-outgoing; Wed, 15 Jul 1998 12:00:08 -0400 (EDT) Message-Id: <199807151602.JAA06387@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 15 Jul 1998 08:56:20 -0700 To: Harry Lewis From: Randy Turner Subject: Re: IPP> Where do we stand in the debate? Cc: ipp@pwg.org In-Reply-To: <5030100023168486000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 11:02 AM 7/15/98 -0400, you wrote: >Carl-Uno. thank you very much for the summary. This is quite helpful. I would >like to seek even further clarification. > >>"ipp:" will NEVER be used on the HTTP layer. > >Is this the same as saying that (by example) >ipp://my.printer.com will ALWAYS mean >http://my.printer.com:631 >and (by further example) >ipp://my.printer.com:444 will mean >http://my.printer.com:444? > > >Harry Lewis - IBM Printing Systems > I don't think that's what the compromise says. The quick take is, 1. "Published" URLs (that users and administrators will see) will be "ipp:" URLs. 2. Within application/ipp body parts, "ipp:" URLs will be used to reference IPP printer and job objects. 3. But you will never see "ipp:" URLs in HTTP 1.1 request headers. This is very close to our usage model published last week at Monterey. Randy From ipp-owner@pwg.org Wed Jul 15 12:16:04 1998 Delivery-Date: Wed, 15 Jul 1998 12:16:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA19134 for ; Wed, 15 Jul 1998 12:16:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15539 for ; Wed, 15 Jul 1998 12:15:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26302 for ; Wed, 15 Jul 1998 12:15:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:10:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25365 for ipp-outgoing; Wed, 15 Jul 1998 12:07:28 -0400 (EDT) Message-Id: <199807151607.MAA16598@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harry Lewis cc: ipp@pwg.org, moore@cs.utk.edu, moore@cs.utk.edu Subject: Re: IPP> possible compromise? In-reply-to: Your message of "Wed, 15 Jul 1998 11:28:58 EDT." <5030050015552513000002L532*@MHS> Date: Wed, 15 Jul 1998 12:07:05 -0400 Sender: owner-ipp@pwg.org > Keith, I am trying very hard to follow this discussion to some form = > of bedrock. I'm not so adamant about the URL scheme... as long as > I can base my initial implementation on existing, off-the-shelf HTTP > servers, which I think we have safely agreed upon. > > What I do need, however, is a timely end to the development process > for this standards specification. I suspect you would agree - none of > us have inexhaustible resources. > > To this end, security appears to be a real "monkey wrench". Your > statement represents a basic "open loop" in my estimation. > > It is insufficient, at this point, to be in the position of taking a > proposal to the IESG which we know will fail to ratify and which is > completely "Catch22" in context. We can't have security because it's > not there yet... yet we can't use the security which is there. > Unless there is some certainty of a very near term resolution of > the security issue which will satisfy the IESG, I claim we MUST > focus (and adjust, if appropriate) the IPP effort on utilization > of a viable interim security method. Harry, I share your concern about the need for a timely end to the development process. While I do have doubts about the viability of IPP security for some of the scenarios that IPP has envisioned, I also recognize that my expertise is limited in this area. I would rather leave it to the security ADs to evaluate the adequacy of IPP security. If it's okay with them, it will be okay with me. Even if the security ADs share my concerns, I will push to get the Proposed Standard versions of the IPP specifications published quickly and with as few changes as possible -- perhaps with some sort of disclaimer about the limitations of the current security setup. The vast majority of printing applications do not need a fully general security solution, and IPP should not be kept waiting until such a solution exists. It may be that IPP needs additional work to define URL parameters and/or profiles for how TLS should be used in some of the scenarios, but even if this is necessary I believe that most of the work can be done in separate documents that aren't in the critical path for the main IPP set. I am pushing for the IESG review to be complete by the end of July, though there is some chance that the review will take two weeks longer than that. But I am hopeful that IESG can get the feedback to IPP by end July, and complete IESG approval of any revisions before the Chicago IETF. Keith From ipp-owner@pwg.org Wed Jul 15 12:59:41 1998 Delivery-Date: Wed, 15 Jul 1998 12:59:41 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20114 for ; Wed, 15 Jul 1998 12:59:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15798 for ; Wed, 15 Jul 1998 12:59:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA27139 for ; Wed, 15 Jul 1998 12:59:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:55:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26547 for ipp-outgoing; Wed, 15 Jul 1998 12:51:30 -0400 (EDT) Date: Wed, 15 Jul 1998 09:31:52 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9807151631.AA02673@snorkel.eso.mc.xerox.com> To: harryl@us.ibm.com, moore@cs.utk.edu Subject: Re: IPP> possible compromise? Cc: ipp@pwg.org Sender: owner-ipp@pwg.org Hi Keith and Harry, I think it's useful to note that even LDAPv3 has recently been permitted to publish standards track RFCs WITHOUT any security mechanism (and a rather naive note that suggests read-only implementations). I maintain that even a read-only implementation of LDAPv3 without any security (for read) is a good deal more dangerous in the business liability and exposure sense that an implementation of IPP without any security in some printers is. Cheers, - Ira McDonald (High North Inc) ------------------------------------------------------------------------ [Keith and Harry's notes] >From ipp-owner@pwg.org Wed Jul 15 12:25:40 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA02665; Wed, 15 Jul 98 12:25:39 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA15090; Wed, 15 Jul 98 12:18:22 EDT Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <55042(2)>; Wed, 15 Jul 1998 09:18:20 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26143 for ; Wed, 15 Jul 1998 12:14:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:10:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25365 for ipp-outgoing; Wed, 15 Jul 1998 12:07:28 -0400 (EDT) Message-Id: <199807151607.MAA16598@spot.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harry Lewis Cc: ipp@pwg.org, moore@cs.utk.edu, moore@cs.utk.edu Subject: Re: IPP> possible compromise? In-Reply-To: Your message of "Wed, 15 Jul 1998 11:28:58 EDT." <5030050015552513000002L532*@MHS> Date: Wed, 15 Jul 1998 09:07:05 PDT Sender: owner-ipp@pwg.org Status: R > Keith, I am trying very hard to follow this discussion to some form = > of bedrock. I'm not so adamant about the URL scheme... as long as > I can base my initial implementation on existing, off-the-shelf HTTP > servers, which I think we have safely agreed upon. > > What I do need, however, is a timely end to the development process > for this standards specification. I suspect you would agree - none of > us have inexhaustible resources. > > To this end, security appears to be a real "monkey wrench". Your > statement represents a basic "open loop" in my estimation. > > It is insufficient, at this point, to be in the position of taking a > proposal to the IESG which we know will fail to ratify and which is > completely "Catch22" in context. We can't have security because it's > not there yet... yet we can't use the security which is there. > Unless there is some certainty of a very near term resolution of > the security issue which will satisfy the IESG, I claim we MUST > focus (and adjust, if appropriate) the IPP effort on utilization > of a viable interim security method. Harry, I share your concern about the need for a timely end to the development process. While I do have doubts about the viability of IPP security for some of the scenarios that IPP has envisioned, I also recognize that my expertise is limited in this area. I would rather leave it to the security ADs to evaluate the adequacy of IPP security. If it's okay with them, it will be okay with me. Even if the security ADs share my concerns, I will push to get the Proposed Standard versions of the IPP specifications published quickly and with as few changes as possible -- perhaps with some sort of disclaimer about the limitations of the current security setup. The vast majority of printing applications do not need a fully general security solution, and IPP should not be kept waiting until such a solution exists. It may be that IPP needs additional work to define URL parameters and/or profiles for how TLS should be used in some of the scenarios, but even if this is necessary I believe that most of the work can be done in separate documents that aren't in the critical path for the main IPP set. I am pushing for the IESG review to be complete by the end of July, though there is some chance that the review will take two weeks longer than that. But I am hopeful that IESG can get the feedback to IPP by end July, and complete IESG approval of any revisions before the Chicago IETF. Keith From ipp-owner@pwg.org Wed Jul 15 13:30:27 1998 Delivery-Date: Wed, 15 Jul 1998 13:30:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20842 for ; Wed, 15 Jul 1998 13:30:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA15996 for ; Wed, 15 Jul 1998 13:30:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA27895 for ; Wed, 15 Jul 1998 13:30:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 13:25:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA27311 for ipp-outgoing; Wed, 15 Jul 1998 13:19:42 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> ipp: / http: in the UI Date: Wed, 15 Jul 1998 10:19:33 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Anybody who beleives that ipp: in the UI is less confusing that http: has clearly never met a real user. A real user sees "blah-blah-blah-ya-da-ya-da-ya-da" when the see a URL. They have no idea what any of it means; they dont care. The vast majority of users dont even get "directory/filename" An IPP client will probably allow people to type in "megacorp.com/printer1" without any IPP: or HTTP: or port number. Nobody is going to click on an IPP URL in a browser - i.e. the URL used to actually send print to it. What would that mean? If they do access it via a browser they will click on something that switches them to a client ('printto:megacorp.com/printer1'), downloads a driver ('http:...../selfextrcat.exe') or opens a web page from the printer explaining what they should do. (Actually I quite like 'printto:' - what do others think). Saying that IPP lets me know that its a printer is an excuse for bad design. Any UI that expects people to differentiate by hovering over the link and looking at the status bar is broken. Nobody is going to put printer URLs on their business cards. From ipp-owner@pwg.org Wed Jul 15 13:50:50 1998 Delivery-Date: Wed, 15 Jul 1998 13:50:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21200 for ; Wed, 15 Jul 1998 13:50:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA16155 for ; Wed, 15 Jul 1998 13:50:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29256 for ; Wed, 15 Jul 1998 13:50:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 13:46:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28045 for ipp-outgoing; Wed, 15 Jul 1998 13:40:23 -0400 (EDT) Message-ID: <35ACE97A.F639573B@underscore.com> Date: Wed, 15 Jul 1998 13:40:10 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Moore CC: "'ipp@pwg.org'" Subject: Re: IPP> ipp: / http: in the UI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Paul, > (Actually I quite like 'printto:' - what do others think). Glad you brought this up. If the final resolution of this whole scheme issue results in something *other* than "http:", then I'd prefer Keith's suggestion of "print:" as a scheme as opposed to your "printto:", since the "to" suffix is both unnecessary and counter-intuitive (given that the PDU can very well contain requests that are not job submissions). > Saying that IPP lets me know that its a printer is an excuse for bad design. > Any UI that expects people to differentiate by hovering over the link and > looking at the status bar is broken. Perhaps you're right that the UI should *not* expect this "hovering" behavior, but nonetheless it is quite prevalent from what I've experienced. That is, I don't think we should discount the frequency and value of hovering as part of a positive user experience. > Nobody is going to put printer URLs on their business cards. Do you really believe this? I mean, an aweful lot of IPP proponents (in the PWG) clearly believe that one of the greatest values of IPP is its use as a fax-alike mechanism. I honestly don't think such a capability is nearly as powerful a potential as some of these people seem to believe, but there will be some who actually implement this, 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 -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jul 15 14:19:27 1998 Delivery-Date: Wed, 15 Jul 1998 14:19:28 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21662 for ; Wed, 15 Jul 1998 14:19:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA16352 for ; Wed, 15 Jul 1998 14:19:23 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00034 for ; Wed, 15 Jul 1998 14:19:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 14:15:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29455 for ipp-outgoing; Wed, 15 Jul 1998 14:13:12 -0400 (EDT) Message-ID: From: Paul Moore To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> ipp: / http: in the UI Date: Wed, 15 Jul 1998 11:13:01 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org You misunderstand my suggestion. I mean that printto: is like mailto: - it loads a client and passes in the destination address. It has nothing to do with the protocol that gets used to send the print. > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Wednesday, July 15, 1998 10:40 AM > To: Paul Moore > Cc: 'ipp@pwg.org' > Subject: Re: IPP> ipp: / http: in the UI > > Paul, > > > (Actually I quite like 'printto:' - what do others think). > > Glad you brought this up. If the final resolution of this whole > scheme issue results in something *other* than "http:", then > I'd prefer Keith's suggestion of "print:" as a scheme as opposed > to your "printto:", since the "to" suffix is both unnecessary > and counter-intuitive (given that the PDU can very well contain > requests that are not job submissions). > > > > Saying that IPP lets me know that its a printer is an excuse for bad > design. > > Any UI that expects people to differentiate by hovering over the link > and > > looking at the status bar is broken. > > Perhaps you're right that the UI should *not* expect this > "hovering" behavior, but nonetheless it is quite prevalent > from what I've experienced. That is, I don't think we should > discount the frequency and value of hovering as part of a > positive user experience. > > > > Nobody is going to put printer URLs on their business cards. > > Do you really believe this? I mean, an aweful lot of IPP > proponents (in the PWG) clearly believe that one of the greatest > values of IPP is its use as a fax-alike mechanism. I honestly > don't think such a capability is nearly as powerful a potential > as some of these people seem to believe, but there will be some > who actually implement this, 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 -- > ---------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jul 15 15:42:01 1998 Delivery-Date: Wed, 15 Jul 1998 15:42:01 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23542 for ; Wed, 15 Jul 1998 15:41:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA16875 for ; Wed, 15 Jul 1998 15:41:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00906 for ; Wed, 15 Jul 1998 15:41:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 15:35:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00333 for ipp-outgoing; Wed, 15 Jul 1998 15:30:05 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 15 Jul 1998 12:18:17 -0700 Message-ID: <00050D76.@kyocera.com> From: Stuart.Rowley@kyocera.com (Stuart Rowley) Subject: IPP> Question about Job Template attributes To: IPP@pwg.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipp@pwg.org For each job template attribute there is the associated default and supported values. I have a question about the xxx-supported values. Imagine a printer that say supports binding which may be controlled by various PDL commands, but does not support controlling binding via the IPP finishings job template attribute. Should the printer response to finishings-supported include binding or not? I assume that it should not include binding as this would give the idea to the client that binding can be controlled with the finishings attribute. Thus, xxx-supported is not intended to indicate printer capabilities, but rather support for the IPP attributes. Is this correct? Thanks, Stuart Rowley --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 stuart.rowley@kyocera.com Lafayette, CA 94549 925 299-7206 Fax: 925 299-2489 --------------------------------------------------------------------- From ipp-owner@pwg.org Wed Jul 15 15:46:06 1998 Delivery-Date: Wed, 15 Jul 1998 15:46:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23614 for ; Wed, 15 Jul 1998 15:45:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA16905 for ; Wed, 15 Jul 1998 15:45:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA01514 for ; Wed, 15 Jul 1998 15:45:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 15:41:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA00343 for ipp-outgoing; Wed, 15 Jul 1998 15:33:05 -0400 (EDT) Message-Id: <199807151930.PAA17234@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) cc: harryl@us.ibm.com, moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> possible compromise? In-reply-to: Your message of "Wed, 15 Jul 1998 09:31:52 PDT." <9807151631.AA02673@snorkel.eso.mc.xerox.com> Date: Wed, 15 Jul 1998 15:30:50 -0400 Sender: owner-ipp@pwg.org > I think it's useful to note that even LDAPv3 has recently been > permitted to publish standards track RFCs WITHOUT any security > mechanism (and a rather naive note that suggests read-only > implementations). The LDAPv3 case was a little odd. LDAPv2 was already out there without any useful security. For various reasons, we wanted to encourage people to move to LDAPv3, and LDAPv3 wasn't any worse security-wise than LDAPv2. The IESG note was the carrot part of the compromise that was worked out. The stick was that the LDAP folks were supposed to do security before anything else. It didn't work very well; they drug their feet about security. > I maintain that even a read-only implementation of LDAPv3 without > any security (for read) is a good deal more dangerous in the > business liability and exposure sense that an implementation > of IPP without any security in some printers is. Obviously it depends on what information you're making available through LDAPv3, and whether you're just doing so within your enterprise vs. exporting it to the rest of the world. Keith From ipp-owner@pwg.org Wed Jul 15 16:07:45 1998 Delivery-Date: Wed, 15 Jul 1998 16:07:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24259 for ; Wed, 15 Jul 1998 16:07:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA17080 for ; Wed, 15 Jul 1998 16:07:42 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02170 for ; Wed, 15 Jul 1998 16:07:43 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 16:03:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA01608 for ipp-outgoing; Wed, 15 Jul 1998 15:52:22 -0400 (EDT) Content-return: allowed Date: Wed, 15 Jul 1998 11:34:32 PDT From: "Bennett, Joel H" Subject: RE: IPP> ipp: / http: in the UI To: "'Paul Moore'" , "'Jay Martin'" Cc: "'ipp@pwg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA24259 I'm just beginning to get a handle on this, but do most of you envision this "ipp://printer" or "http://printer:633" or "printo:printer" being handled by the users web client (ie netscape)? I had assumed that most companies would want to develope their own clients, and that in the future users would be able to choose any company's client they preffered, or even a free/share-ware solution. IF you ARE talking about the necesity of developing specialized internet print clients (as opposed to a java client that loads from a web page or some-such), then it seems to me that you would want to settle on a scheme such as "printto:" or "printer:" which would in fact call up a seperate client. How are most of you planning on this being implemented? (do you really want to trust your printer's interface to the MS/Netscape war?) Original Message: _____ From: Paul Moore [mailto:paulmo@microsoft.com] You misunderstand my suggestion. I mean that printto: is like mailto: - it loads a client and passes in the destination address. It has nothing to do with the protocol that gets used to send the print. As always, in HIS hands,                    Joel H. Bennett _____ QOTD: Dictatorship (n): a form of government under which everything which is not prohibited is compulsory. _____ From ipp-owner@pwg.org Wed Jul 15 16:17:16 1998 Delivery-Date: Wed, 15 Jul 1998 16:17:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24488 for ; Wed, 15 Jul 1998 16:17:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA17142 for ; Wed, 15 Jul 1998 16:17:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA02838 for ; Wed, 15 Jul 1998 16:17:14 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 16:10:23 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02210 for ipp-outgoing; Wed, 15 Jul 1998 16:08:02 -0400 (EDT) From: Harry Lewis To: Cc: , Subject: Re: IPP> possible compromise? Message-ID: <5030100023184031000002L012*@MHS> Date: Wed, 15 Jul 1998 16:04:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA24488 I like the tune (different words) ... LPR was already out there... the IETF wants to encourage a more interoperable standard... IPP isn't any worse, security wise than LPR. I hope we can forgo the carrot and stick and concentrate on the lettuce... as in let us do it ;-) Harry Lewis - IBM Printing Systems moore@cs.utk.edu on 07/15/98 01:38:27 PM Please respond to moore@cs.utk.edu To: imcdonal@eso.mc.xerox.com cc: moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu, Harry Lewis/Boulder/IBM@ibmus Subject: Re: IPP> possible compromise? > I think it's useful to note that even LDAPv3 has recently been > permitted to publish standards track RFCs WITHOUT any security > mechanism (and a rather naive note that suggests read-only > implementations). The LDAPv3 case was a little odd. LDAPv2 was already out there without any useful security. For various reasons, we wanted to encourage people to move to LDAPv3, and LDAPv3 wasn't any worse security-wise than LDAPv2. The IESG note was the carrot part of the compromise that was worked out. The stick was that the LDAP folks were supposed to do security before anything else. It didn't work very well; they drug their feet about security. > I maintain that even a read-only implementation of LDAPv3 without > any security (for read) is a good deal more dangerous in the > business liability and exposure sense that an implementation > of IPP without any security in some printers is. Obviously it depends on what information you're making available through LDAPv3, and whether you're just doing so within your enterprise vs. exporting it to the rest of the world. Keith From ipp-owner@pwg.org Wed Jul 15 17:05:10 1998 Delivery-Date: Wed, 15 Jul 1998 17:05:10 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA25744 for ; Wed, 15 Jul 1998 17:05:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17447 for ; Wed, 15 Jul 1998 17:05:08 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA03539 for ; Wed, 15 Jul 1998 17:05:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 17:00:20 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA02988 for ipp-outgoing; Wed, 15 Jul 1998 16:58:01 -0400 (EDT) From: Harry Lewis To: Cc: , , Subject: RE: IPP> ipp: / http: in the UI Message-ID: <5030100023186717000002L072*@MHS> Date: Wed, 15 Jul 1998 16:51:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25744 It's not necessarily either/or, in my mind. OS support is paramount so good thing we have Microsoft, Novell, Apple and IBM on the team! They will provide the infrastructure upon which integrated clients may be developed. Also, there will be clients which evolve as elements of higher order print and print management software solutions, I'm sure. But none of this precludes the possibility of recognition by generic web clients or commonplace web infrastructure (i.e. Netscape as you put it). Today, (for example) if I'm checking the weather in Boulder at http://www.atd.ucar.edu/cgi-bin/flabweatherE and I want to contact the weather station manager, placing my cursor over his e-mail link results in the URL mailto:cook@atd.edu in my browser command line. When I click, my mail composition client (of choice) is launched and Mr. Cook's address is automatically filled out for me. There is no reason why, tomorrow, I couldn't (hope to) be viewing a white paper on the WEB which has a "printto", "print" or "ipp" link that behaves in a similar manner whereby clicking invokes the native IPP client, or client of choice, merrily helping me launch my print job From ipp-owner@pwg.org Wed Jul 15 21:51:02 1998 Delivery-Date: Wed, 15 Jul 1998 21:51:02 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28993 for ; Wed, 15 Jul 1998 21:50:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA18443 for ; Wed, 15 Jul 1998 21:50:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA04525 for ; Wed, 15 Jul 1998 21:50:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 21:45:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03977 for ipp-outgoing; Wed, 15 Jul 1998 21:40:28 -0400 (EDT) Message-Id: <199807160135.SAA22438@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 15 Jul 1998 18:41:27 -0700 To: Keith Moore From: Robert Herriot Subject: Re: IPP> Re: New IPP Scheme Cc: ipp@pwg.org In-Reply-To: <199807142203.SAA11719@spot.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_97913321==_.ALT" Sender: owner-ipp@pwg.org --=====================_97913321==_.ALT Content-Type: text/plain; charset="us-ascii" Action item from Robert Herriot and Tom Hastings: The IPP working group reached an agreement with Keith Moore in this morning's teleconference. This document is our best understanding of the details of this agreement. Summary: The quick summary is that IPP should support a new scheme 'ipp', which clients and servers use in IPP attributes. Such attributes are in a message body whose Content-Type is application/ipp. A client maps 'ipp' URLs to 'http' URLs, and then follows the HTTP/1.1 rules for constructing a Request-Line and HTTP headers. The IPP document will not prohibit implementations from supporting other schemes in IPP attributes, but such support is not defined by this document. Now for the details. A client and an IPP object (i.e. the server) SHOULD support the 'ipp' scheme in the following IPP attributes. Each of these attributes identifies a printer or job object. The 'ipp' scheme is not intended for use in 'uri' valued attributes not in this list. job attributes - job-uri job-printer-uri printer attributes - printer-uri-supported operation attributes - job-uri printer-uri If the scheme of the target URL in a request (i.e. the value of "printer-uri" or "job-uri" operation attribute) is some scheme 'x', other than 'ipp', the behavior of the IPP object is not defined by this document. However, it is RECOMMENDED that if an operation on an IPP object creates a new value for any of the above attributes, that attribute has the same scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the seven attributes above in the response, that the IPP object returns those URL values as is, regardless of the scheme of the target URL. If the client obtains a target URL from a directory service, the scheme of the target URL SHOULD be 'ipp'. If the scheme is not 'ipp', the behavior of the client is not defined by this document, but it is RECOMMENDED that the client use the URL as is as the target URL. Although user interfaces are beyond the scope of this document, it is RECOMMENDED that if software exposes the URL values of any of the above seven attributes to a human user, that the human see the URL as is. When a client sends a request, it MUST convert an 'ipp' target URL to an 'http' target URL for use in the HTTP Request-Line and HTTP headers as specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the value of the "printer-uri" or "job-uri" attribute in the message body. If the scheme of the target URL is not 'ipp', the behavior of the client is not defined by this document, but it is RECOMMENDED that the client use the target URL as is in the Request-Line and HTTP headers. A client converts an 'ipp' URL to an 'http' URL by 1) replacing the 'ipp' scheme by 'http' 2) adding an explicit port 631 if the URL does not contain an explicit port. When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection to some port (this example uses the IPP default port 631) on some host (“myhost.com” in this example) with the following headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ... When an IPP client sends a request via a proxy, such as “myproxy.com”, to an ‘ipp’ URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection to some port (8080 in this example) on some proxy (“myproxy.com” in this example) with the following headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:8080 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ... The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above. --=====================_97913321==_.ALT Content-Type: text/html; charset="us-ascii" Action item from Robert Herriot and Tom Hastings:

The IPP working group reached an agreement with Keith Moore in this
morning's teleconference. This document is our best understanding of the
details of this agreement.

Summary:

The quick summary is that IPP should support a new scheme 'ipp', which
clients and servers use in IPP attributes. Such attributes are in a message
body whose Content-Type is application/ipp.  A client maps 'ipp' URLs to
'http' URLs, and then follows the HTTP/1.1 rules for constructing a
Request-Line and HTTP headers. The IPP document will not prohibit
implementations from supporting other schemes in IPP attributes, but such
support is not defined by this document. 

Now for the details.

A client and an IPP object (i.e. the server) SHOULD support the 'ipp' scheme
in the following IPP attributes.  Each of these attributes identifies a
printer or job object. The 'ipp' scheme is not intended for use in 'uri'
valued attributes not in this list.

     job attributes -
        job-uri
        job-printer-uri
    printer attributes -
        printer-uri-supported
    operation attributes -
        job-uri
        printer-uri

If the scheme of the target URL in a request (i.e. the value of 
"printer-uri" or "job-uri" operation attribute) is some scheme 'x', other
than 'ipp', the behavior of the IPP object is not defined by this document. 
However, it is RECOMMENDED that if an operation on an IPP object creates a
new value for any of the above attributes, that attribute has the same
scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the
seven attributes above in the response, that the IPP object returns those
URL values as is, regardless of the scheme of the target URL.

If the client obtains a target URL from a directory service, the scheme of
the target URL SHOULD be 'ipp'.  If the scheme is not 'ipp', the behavior of
the client is not defined by this document, but it is RECOMMENDED that the
client use the URL as is as the target URL.

Although user interfaces are beyond the scope of this document, it is
RECOMMENDED that if software exposes the URL values of any of the above
seven attributes to a human user, that the human see the URL as is. 

When a client sends a request, it MUST convert an 'ipp' target URL to an
'http' target URL for use in the HTTP Request-Line and HTTP headers as
specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the
value of the "printer-uri" or "job-uri" attribute in the message body.  If
the scheme of the target URL is not 'ipp', the behavior of the client is not
defined by this document, but it is RECOMMENDED that the client use the
target URL as is in the Request-Line and HTTP headers.

A client converts an 'ipp' URL to an 'http' URL by
    1) replacing the 'ipp' scheme by 'http'
    2) adding an explicit port 631 if the URL does not contain an explicit  port.

When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL
such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection
to some port (this example uses the IPP default port 631) on some host
(“myhost.com” in this example) with the following headers:

POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...

When an IPP client sends a request via a proxy, such as “myproxy.com”, to an
‘ipp’  URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP
connection to some port (8080 in this example) on some proxy (“myproxy.com”
in this example) with the following headers:


POST http://myhost.com:631/myprinter/myqueue   HTTP/1.1
Host: myproxy.com:8080
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...

The proxy then connects to the IPP origin server with headers that are the
same as the "no-proxy" example above.


--=====================_97913321==_.ALT-- From ipp-owner@pwg.org Thu Jul 16 00:51:38 1998 Delivery-Date: Thu, 16 Jul 1998 00:51:39 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07768 for ; Thu, 16 Jul 1998 00:51:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA18875 for ; Thu, 16 Jul 1998 00:51:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id AAA05319 for ; Thu, 16 Jul 1998 00:51:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 00:45:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA04766 for ipp-outgoing; Thu, 16 Jul 1998 00:42:05 -0400 (EDT) Message-Id: <199807160444.VAA23643@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 15 Jul 1998 21:38:06 -0700 To: Robert Herriot From: Randy Turner Subject: Re: IPP> Re: New IPP Scheme Cc: ipp@pwg.org In-Reply-To: <199807160135.SAA22438@woden.eng.sun.com> References: <199807142203.SAA11719@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA07768 I read the action items below and it appears very close to our previous usage model. Except below, this version says the IPP server "SHOULD" accept "ipp:" URLs wherein I would think this would be a "MUST", since later on it mentions that this document does not discuss what a server does with any other URL scheme it sees. (?) Randy At 06:41 PM 7/15/98 -0700, Robert Herriot wrote: > > Action item from Robert Herriot and Tom Hastings: > > The IPP working group reached an agreement with Keith Moore in this > morning's teleconference. This document is our best understanding of the > details of this agreement. > > Summary: > > The quick summary is that IPP should support a new scheme 'ipp', which > clients and servers use in IPP attributes. Such attributes are in a message > body whose Content-Type is application/ipp.  A client maps 'ipp' URLs to > 'http' URLs, and then follows the HTTP/1.1 rules for constructing a > Request-Line and HTTP headers. The IPP document will not prohibit > implementations from supporting other schemes in IPP attributes, but such > support is not defined by this document.  > > Now for the details. > > A client and an IPP object (i.e. the server) SHOULD support the 'ipp' scheme > in the following IPP attributes.  Each of these attributes identifies a > printer or job object. The 'ipp' scheme is not intended for use in 'uri' > valued attributes not in this list. > >      job attributes - > job-uri > job-printer-uri >     printer attributes - > printer-uri-supported >     operation attributes - > job-uri > printer-uri > > If the scheme of the target URL in a request (i.e. the value of  > "printer-uri" or "job-uri" operation attribute) is some scheme 'x', other > than 'ipp', the behavior of the IPP object is not defined by this document.  > However, it is RECOMMENDED that if an operation on an IPP object creates a > new value for any of the above attributes, that attribute has the same > scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the > seven attributes above in the response, that the IPP object returns those > URL values as is, regardless of the scheme of the target URL. > > If the client obtains a target URL from a directory service, the scheme of > the target URL SHOULD be 'ipp'.  If the scheme is not 'ipp', the behavior of > the client is not defined by this document, but it is RECOMMENDED that the > client use the URL as is as the target URL. > > Although user interfaces are beyond the scope of this document, it is > RECOMMENDED that if software exposes the URL values of any of the above > seven attributes to a human user, that the human see the URL as is.  > > When a client sends a request, it MUST convert an 'ipp' target URL to an > 'http' target URL for use in the HTTP Request-Line and HTTP headers as > specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the > value of the "printer-uri" or "job-uri" attribute in the message body.  If > the scheme of the target URL is not 'ipp', the behavior of the client is not > defined by this document, but it is RECOMMENDED that the client use the > target URL as is in the Request-Line and HTTP headers. > > A client converts an 'ipp' URL to an 'http' URL by >     1) replacing the 'ipp' scheme by 'http' >     2) adding an explicit port 631 if the URL does not contain an explicit  > port. > > When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL > such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection > to some port (this example uses the IPP default port 631) on some host > (“myhost.com” in this example) with the following headers: > > POST /myprinter/myqueue HTTP/1.1 > Host: myhost.com:631 > Content-type: application/ipp > Transfer-Encoding: chunked > ... > "printer-uri" "ipp://myhost.com/myprinter/myqueue" > (encoded in application/ipp message body) > ... > > When an IPP client sends a request via a proxy, such as “myproxy.com”, to an > ‘ipp’  URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP > connection to some port (8080 in this example) on some proxy (“myproxy.com” > in this example) with the following headers: > > > POST > http://myhost.com:631/myprinter/m > yqueue   HTTP/1.1 > Host: myproxy.com:8080 > Content-type: application/ipp > Transfer-Encoding: chunked > ... > "printer-uri" "ipp://myhost.com/myprinter/myqueue" > (encoded in application/ipp message body) > ... > > The proxy then connects to the IPP origin server with headers that are the > same as the "no-proxy" example above. > > From cclark Thu Jul 16 10:20:09 1998 Delivery-Date: Thu, 16 Jul 1998 10:32:44 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA15098 for ietf-outbound.10@ietf.org; Thu, 16 Jul 1998 10:20:02 -0400 (EDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15072 for ; Thu, 16 Jul 1998 10:19:45 -0400 (EDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.9.1/8.9.1) with ESMTP id KAA26194; Thu, 16 Jul 1998 10:19:42 -0400 Message-Id: <199807161419.KAA26194@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Simon Spero Cc: ietf@ietf.org Subject: Re: address portability *and* Originator-Info In-Reply-To: Your message of "Wed, 15 Jul 1998 22:40:47 EDT." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_572434952P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 16 Jul 1998 10:19:41 -0400 --==_Exmh_572434952P Content-Type: text/plain; charset=us-ascii On Wed, 15 Jul 1998 22:40:47 EDT, Simon Spero said: > If no-one has any objection, I will setup a daemon to automically post > random postings from the big-internet archive until we all travel > sufficiently far back in time that we can prevent the spice girls from > meeting. What a *wonderful* idea. I'll volunteer to re-post the just-send-8bit flamefest from the original MIME/SMTP Extensions discussions - that seems relevant to the discussion of the Originator-Info: draft.. ;) Of course, there's a down side = I'm sure within 2 weeks, some newcomer will ask why, if IPv6 supports variable length addresses, there's no length field. ;) The biggest problem with dead-and-buried ideas is that you have to re-exhume the corpse every 18 to 24 months and re-conduct the autopsy for the people who weren't here last time..... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_572434952P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNa4L+9QBOOoptg9JAQE3MwP+P5+/pVviP/s6pw2F/8DzOXgYiRuUHg92 P0bRRsMf1dDknhhc2rZHEZW03juTu+u8jtCtneSsWyq7bOq271HzUkbeHCc0uboi UqnmA3uq1HyWJNxrIF01nCLp5oDYERDqtfR8d1ZI+dbKncSwezoi1hIIIZcb+B36 kuh7RJnKvZw= =d9Yr -----END PGP MESSAGE----- --==_Exmh_572434952P-- From ipp-owner@pwg.org Thu Jul 16 12:36:07 1998 Delivery-Date: Thu, 16 Jul 1998 12:36:07 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17494 for ; Thu, 16 Jul 1998 12:36:03 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21254 for ; Thu, 16 Jul 1998 12:35:53 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18833 for ; Thu, 16 Jul 1998 12:35:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 12:25:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17793 for ipp-outgoing; Thu, 16 Jul 1998 12:23:44 -0400 (EDT) Date: 16 Jul 1998 16:22:55 -0000 Message-ID: <19980716162255.22304.qmail@m2.findmail.com> From: "Carl Kugler" Subject: IPP> A client MUST NOT expect a response from an IPP server until after the client has sent the entire response. To: ipp@pwg.org Sender: owner-ipp@pwg.org ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630.doc says "A client MUST NOT expect a response from an IPP server until after the client has sent the entire response." What about "100 Continue" responses (and related HTTP Expect headers)? From ipp-owner@pwg.org Thu Jul 16 12:37:12 1998 Delivery-Date: Thu, 16 Jul 1998 12:37:12 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17516 for ; Thu, 16 Jul 1998 12:37:11 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21266 for ; Thu, 16 Jul 1998 12:37:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA18988 for ; Thu, 16 Jul 1998 12:37:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 12:31:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17768 for ipp-outgoing; Thu, 16 Jul 1998 12:19:24 -0400 (EDT) Date: 16 Jul 1998 16:18:26 -0000 Message-ID: <19980716161826.21898.qmail@m2.findmail.com> From: "Carl Kugler" Subject: RE: IPP> Re: New IPP Scheme In-Reply-To: <199807141840.AA07798@interlock2.lexmark.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org ... > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine is > on 80 so my URL is exactly right. Not all implementations MUST be on 631. ... That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 It says "It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631...". Therefore, a conforming implementation MUST be on 631, although it might also be on some other port simultaneously. ----- Original Message: http://www.findmail.com/list/ipp/?start=4106 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 13:05:13 1998 Delivery-Date: Thu, 16 Jul 1998 13:05:13 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA17917 for ; Thu, 16 Jul 1998 13:05:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21433 for ; Thu, 16 Jul 1998 13:05:07 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19808 for ; Thu, 16 Jul 1998 13:05:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 13:00:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA19192 for ipp-outgoing; Thu, 16 Jul 1998 12:55:44 -0400 (EDT) From: don@lexmark.com Message-Id: <199807161655.AA25353@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: "Carl Kugler" Cc: Ipp@pwg.org Date: Thu, 16 Jul 1998 12:55:00 -0400 Subject: RE: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Carl: The implementation MUST support port 631 however, mine is administratively set to only OPERATE on port 80. The code is compliant. Don "Carl Kugler" on 07/16/98 12:18:26 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: RE: IPP> Re: New IPP Scheme ... > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine is > on 80 so my URL is exactly right. Not all implementations MUST be on 631. ... That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 It says "It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631...". Therefore, a conforming implementation MUST be on 631, although it might also be on some other port simultaneously. ----- Original Message: http://www.findmail.com/list/ipp/?start=4106 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 13:24:56 1998 Delivery-Date: Thu, 16 Jul 1998 13:24:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA18253 for ; Thu, 16 Jul 1998 13:24:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21547 for ; Thu, 16 Jul 1998 13:24:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA20525 for ; Thu, 16 Jul 1998 13:24:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 13:20:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19934 for ipp-outgoing; Thu, 16 Jul 1998 13:18:26 -0400 (EDT) Date: 16 Jul 1998 17:17:32 -0000 Message-ID: <19980716171732.29673.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> I-D ACTION:draft-ietf-ipp-protocol-06.txt In-Reply-To: <199807081325.JAA04072@ietf.org> To: ipp@pwg.org Sender: owner-ipp@pwg.org > 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: Encoding and Transport > Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore > Filename : draft-ietf-ipp-protocol-06.txt > Pages : 33 > Date : 06-Jul-98 > ... > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-protocol-06.txt > This document says: >3. The URI in the HTTP layer is either relative or absolute and is used by the HTTP server to route the HTTP request to the correct resource relative to that HTTP server. This "resource" is either an IPP Printer or a Job, right? >The HTTP server need not be aware of the URI within the operation request. >4. Once the HTTP server resource begins to process the HTTP request, it might get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URLs) or from the URI within the operation request; the choice is up to the implementation. Once the Printer or Job ("the HTTP server resource") has begun to process the job, why would it need a reference to an appropriate IPP Printer object? Implementation question: the server is REQUIRED to check for the presence of target URI operation attributes in every request (and respond with client-error-bad-request if not found) but is otherwise free to ignore target op. atts.? The Request-URI and target URLs might not be literally identical although they MUST both reference the same IPP object; however the server isn't required to verify this? - Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=4062 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 13:36:19 1998 Delivery-Date: Thu, 16 Jul 1998 13:36:19 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA18521 for ; Thu, 16 Jul 1998 13:36:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA21636 for ; Thu, 16 Jul 1998 13:36:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA21184 for ; Thu, 16 Jul 1998 13:36:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 13:30:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20557 for ipp-outgoing; Thu, 16 Jul 1998 13:25:10 -0400 (EDT) Date: 16 Jul 1998 17:24:17 -0000 Message-ID: <19980716172417.30767.qmail@m2.findmail.com> From: "Carl Kugler" Subject: RE: IPP> Re: New IPP Scheme In-Reply-To: <199807161655.AA25353@interlock2.lexmark.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org Carl: > > The implementation MUST support port 631 however, mine is administratively > set to only OPERATE on port 80. The code is compliant. > > Don > > Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands. Here's another quote: "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port." So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"? -Carl > > > "Carl Kugler" on 07/16/98 > 12:18:26 PM > > To: ipp%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright) > bcc: Don Wright > Subject: RE: IPP> Re: New IPP Scheme > > > > > ... > > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine > is > > on 80 so my URL is exactly right. Not all implementations MUST be on > 631. > ... > That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > It says "It is REQUIRED that a printer implementation support HTTP over the > IANA assigned Well Known Port 631...". Therefore, a conforming > implementation MUST be on 631, although it might also be on some other port > simultaneously. > > ----- > Original Message: http://www.findmail.com/list/ipp/?start=4106 > Start a FREE email list at http://www.FindMail.com/ > > > > > > ----- Original Message: http://www.findmail.com/list/ipp/?start=4138 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 14:14:56 1998 Delivery-Date: Thu, 16 Jul 1998 14:14:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA19237 for ; Thu, 16 Jul 1998 14:14:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21877 for ; Thu, 16 Jul 1998 14:14:50 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA21976 for ; Thu, 16 Jul 1998 14:14:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 14:10:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21383 for ipp-outgoing; Thu, 16 Jul 1998 14:08:56 -0400 (EDT) Message-ID: <35AE41AE.B1FB6971@underscore.com> Date: Thu, 16 Jul 1998 14:08:46 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> Re: New IPP Scheme References: <19980716172417.30767.qmail@m2.findmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org I believe that if a product offers compliant operation--but also offers configuration options to disable compliant operation--that the product is still considered compliant. Letting the customer do what the CUSTOMER wants should be ok, right? ...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 Kugler wrote: > > Carl: > > > > The implementation MUST support port 631 however, mine is administratively > > set to only OPERATE on port 80. The code is compliant. > > > > Don > > > > > Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands. Here's another quote: "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port." > > So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"? > > -Carl > > > > > > > "Carl Kugler" on 07/16/98 > > 12:18:26 PM > > > > To: ipp%pwg.org@interlock.lexmark.com > > cc: (bcc: Don Wright) > > bcc: Don Wright > > Subject: RE: IPP> Re: New IPP Scheme > > > > > > > > > > ... > > > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine > > is > > > on 80 so my URL is exactly right. Not all implementations MUST be on > > 631. > > ... > > That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > > > It says "It is REQUIRED that a printer implementation support HTTP over the > > IANA assigned Well Known Port 631...". Therefore, a conforming > > implementation MUST be on 631, although it might also be on some other port > > simultaneously. > > > > ----- > > Original Message: http://www.findmail.com/list/ipp/?start=4106 > > Start a FREE email list at http://www.FindMail.com/ > > > > > > > > > > > > > > ----- > Original Message: http://www.findmail.com/list/ipp/?start=4138 > Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 14:35:07 1998 Delivery-Date: Thu, 16 Jul 1998 14:35:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA19607 for ; Thu, 16 Jul 1998 14:35:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA21971 for ; Thu, 16 Jul 1998 14:34:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA22701 for ; Thu, 16 Jul 1998 14:35:01 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 14:30:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22101 for ipp-outgoing; Thu, 16 Jul 1998 14:27:51 -0400 (EDT) From: Roger K Debry To: Subject: Re: IPP> Re: New IPP Scheme Message-ID: <5030100023233684000002L042*@MHS> Date: Thu, 16 Jul 1998 14:25:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA19607 I suppose in Don's case it depends on what he means by "administratively set". It almost sounded like port 80 was hard wired in. Can an adminsitrator choose to use a different port Don? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 07/16/98 12:12:08 PM Please respond to owner-ipp@pwg.org To: Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org Subject: Re: IPP> Re: New IPP Scheme I believe that if a product offers compliant operation--but also offers configuration options to disable compliant operation--that the product is still considered compliant. Letting the customer do what the CUSTOMER wants should be ok, right? ...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 Kugler wrote: > > Carl: > > > > The implementation MUST support port 631 however, mine is administratively > > set to only OPERATE on port 80. The code is compliant. > > > > Don > > > > > Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands. Here's another quote: "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port." > > So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"? > > -Carl > > > > > > > "Carl Kugler" on 07/16/98 > > 12:18:26 PM > > > > To: ipp%pwg.org@interlock.lexmark.com > > cc: (bcc: Don Wright) > > bcc: Don Wright > > Subject: RE: IPP> Re: New IPP Scheme > > > > > > > > > > ... > > > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine > > is > > > on 80 so my URL is exactly right. Not all implementations MUST be on > > 631. > > ... > > That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > > > It says "It is REQUIRED that a printer implementation support HTTP over the > > IANA assigned Well Known Port 631...". Therefore, a conforming > > implementation MUST be on 631, although it might also be on some other port > > simultaneously. > > > > ----- > > Original Message: http://www.findmail.com/list/ipp/?start=4106 > > Start a FREE email list at http://www.FindMail.com/ > > > > > > > > > > > > > > ----- > Original Message: http://www.findmail.com/list/ipp/?start=4138 > Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 14:46:25 1998 Delivery-Date: Thu, 16 Jul 1998 14:46:26 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA19807 for ; Thu, 16 Jul 1998 14:46:25 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22046 for ; Thu, 16 Jul 1998 14:46:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA23360 for ; Thu, 16 Jul 1998 14:46:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 14:40:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22702 for ipp-outgoing; Thu, 16 Jul 1998 14:35:03 -0400 (EDT) From: don@lexmark.com Message-Id: <199807161834.AA02678@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Roger K Debry Cc: Ipp@pwg.org Date: Thu, 16 Jul 1998 14:34:07 -0400 Subject: Re: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org Roger and all: I am speaking rather theoretically about an example from an e-mail (what seems like a long time ago) where the administrator wanted to offer print services on port 80. In this theoretical product, it's "out of the box" configuration is port 631 put that can be changed when the product is installed. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Roger K Debry on 07/16/98 02:25:54 PM To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: Re: IPP> Re: New IPP Scheme I suppose in Don's case it depends on what he means by "administratively set". It almost sounded like port 80 was hard wired in. Can an adminsitrator choose to use a different port Don? Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 owner-ipp@pwg.org on 07/16/98 12:12:08 PM Please respond to owner-ipp@pwg.org To: Carl Kugler/Boulder/IBM@ibmus cc: ipp@pwg.org Subject: Re: IPP> Re: New IPP Scheme I believe that if a product offers compliant operation--but also offers configuration options to disable compliant operation--that the product is still considered compliant. Letting the customer do what the CUSTOMER wants should be ok, right? ...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 Kugler wrote: > > Carl: > > > > The implementation MUST support port 631 however, mine is administratively > > set to only OPERATE on port 80. The code is compliant. > > > > Don > > > > > Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands. Here's another quote: "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port." > > So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"? > > -Carl > > > > > > > "Carl Kugler" on 07/16/98 > > 12:18:26 PM > > > > To: ipp%pwg.org@interlock.lexmark.com > > cc: (bcc: Don Wright) > > bcc: Don Wright > > Subject: RE: IPP> Re: New IPP Scheme > > > > > > > > > > ... > > > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine > > is > > > on 80 so my URL is exactly right. Not all implementations MUST be on > > 631. > > ... > > That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > > > It says "It is REQUIRED that a printer implementation support HTTP over the > > IANA assigned Well Known Port 631...". Therefore, a conforming > > implementation MUST be on 631, although it might also be on some other port > > simultaneously. > > > > ----- > > Original Message: http://www.findmail.com/list/ipp/?start=4106 > > Start a FREE email list at http://www.FindMail.com/ > > > > > > > > > > > > > > ----- > Original Message: http://www.findmail.com/list/ipp/?start=4138 > Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 15:16:31 1998 Delivery-Date: Thu, 16 Jul 1998 15:16:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA20406 for ; Thu, 16 Jul 1998 15:16:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA22281 for ; Thu, 16 Jul 1998 15:16:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24099 for ; Thu, 16 Jul 1998 15:16:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 15:10:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23522 for ipp-outgoing; Thu, 16 Jul 1998 15:08:55 -0400 (EDT) Message-Id: <199807161903.MAA23105@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 16 Jul 1998 12:09:49 -0700 To: "Carl Kugler" , ipp@pwg.org From: Robert Herriot Subject: RE: IPP> Re: New IPP Scheme In-Reply-To: <19980716172417.30767.qmail@m2.findmail.com> References: <199807161655.AA25353@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_160811464==_.ALT" Sender: owner-ipp@pwg.org --=====================_160811464==_.ALT Content-Type: text/plain; charset="us-ascii" I wrote the sentences that you are asking about. I tried to pick words that would be unambiguous. The intention is that IPP software must be able to listen on port 631 and may be able to listen on other ports. If such software allows an administrator to configure the ports, then such an adminstrator may be able to have IPP software listen other ports, such as port 80 and might make it be the only port that the IPP server listens on. The customer has the right to do what he wants, even if we don't think it is the wisest choice. Bob Herriot At 10:24 AM 7/16/98 , Carl Kugler wrote: >Carl: >> >> The implementation MUST support port 631 however, mine is administratively >> set to only OPERATE on port 80. The code is compliant. >> >> Don >> >> >Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands. Here's another quote: "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port." > >So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"? > > -Carl > >> >> >> "Carl Kugler" on 07/16/98 >> 12:18:26 PM >> >> To: ipp%pwg.org@interlock.lexmark.com >> cc: (bcc: Don Wright) >> bcc: Don Wright >> Subject: RE: IPP> Re: New IPP Scheme >> >> >> >> >> ... >> > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine >> is >> > on 80 so my URL is exactly right. Not all implementations MUST be on >> 631. >> ... >> That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 >> >> It says "It is REQUIRED that a printer implementation support HTTP over the >> IANA assigned Well Known Port 631...". Therefore, a conforming >> implementation MUST be on 631, although it might also be on some other port >> simultaneously. >> >> ----- >> Original Message: http://www.findmail.com/list/ipp/?start=4106 >> Start a FREE email list at http://www.FindMail.com/ >> >> >> >> >> >> > > > >----- >Original Message: http://www.findmail.com/list/ipp/?start=4138 >Start a FREE email list at http://www.FindMail.com/ > --=====================_160811464==_.ALT Content-Type: text/html; charset="us-ascii" I wrote the sentences that you are asking about.  I tried to pick words that
would be unambiguous.

The intention is that IPP software must be able to listen on port 631 and
may be able to listen on other ports.
If such software allows an administrator to configure the ports, then such
an adminstrator may be able to have IPP software listen other ports, such as
port 80 and might make it be the only port that the IPP server listens on. 
The customer has the right to do what he wants, even if we don't think it is
the wisest choice.

Bob Herriot


At 10:24 AM 7/16/98 , Carl Kugler wrote:
>Carl:
>>
>> The implementation MUST support port 631 however, mine is administratively
>> set to only OPERATE on port 80.  The code is compliant.
>>
>> Don
>>
>>
>Hmmm... I think we need some clarification in the wording here, because I think it's ambiguous as it stands.  Here's another quote:  "IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port."
>
>So you read "suport" and "offer IPP services" to mean "can be configured to listen on" rather than "is required to listen on"?
>
>    -Carl
>
>>
>>
>> "Carl Kugler" <kugler%us.ibm.com@interlock.lexmark.com> on 07/16/98
>> 12:18:26 PM
>>
>> To:   ipp%pwg.org@interlock.lexmark.com
>> cc:    (bcc: Don Wright)
>> bcc:  Don Wright
>> Subject:  RE: IPP> Re: New IPP Scheme
>>
>>
>>
>>
>> ...
>> > Sorry Larry, but my printer isn't on the default IPP port of 631.  Mine
>> is
>> > on 80 so my URL is exactly right.  Not all implementations MUST be on
>> 631.
>> ...
>> That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630
>>
>> It says "It is REQUIRED that a printer implementation support HTTP over the
>> IANA assigned Well Known Port 631...".  Therefore, a conforming
>> implementation MUST be on 631, although it might also be on some other port
>> simultaneously.
>>
>> -----
>> Original Message: http://www.findmail.com/list/ipp/?start=4106
>> Start a FREE email list at http://www.FindMail.com/
>>
>>
>>
>>
>>
>>
>
>
>
>-----
>Original Message: http://www.findmail.com/list/ipp/?start=4138
>Start a FREE email list at http://www.FindMail.com/
>
--=====================_160811464==_.ALT-- From ipp-owner@pwg.org Thu Jul 16 15:50:19 1998 Delivery-Date: Thu, 16 Jul 1998 15:50:20 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21002 for ; Thu, 16 Jul 1998 15:50:19 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA22550 for ; Thu, 16 Jul 1998 15:50:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA24851 for ; Thu, 16 Jul 1998 15:50:17 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 15:45:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24280 for ipp-outgoing; Thu, 16 Jul 1998 15:42:29 -0400 (EDT) Message-Id: <199807161942.PAA26063@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipp@pwg.org Subject: IPP> report from IESG telechat cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 16 Jul 1998 15:42:21 -0400 Sender: owner-ipp@pwg.org 1. Several members of the IESG requested more time to review the IPP documents. They will be discussed again at the next IESG meeting, which should take place on 30 July. 2. With regard to the use of http: URLs at the HTTP layer, and ipp: used everywhere else: Nobody on IESG had a problem with this. Keith From ipp-owner@pwg.org Thu Jul 16 17:22:09 1998 Delivery-Date: Thu, 16 Jul 1998 17:22:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22353 for ; Thu, 16 Jul 1998 17:22:08 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23223 for ; Thu, 16 Jul 1998 17:22:02 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA25799 for ; Thu, 16 Jul 1998 17:22:06 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 17:15:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25214 for ipp-outgoing; Thu, 16 Jul 1998 17:10:30 -0400 (EDT) Date: 16 Jul 1998 21:09:37 -0000 Message-ID: <19980716210937.29015.qmail@m2.findmail.com> From: "Carl Kugler" Subject: RE: IPP> Re: New IPP Scheme In-Reply-To: <199807161903.MAA23105@woden.eng.sun.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org --=====================_160811464==_.ALT > Content-Type: text/plain; charset="us-ascii" > > I wrote the sentences that you are asking about. I tried to pick words that > would be unambiguous. > > The intention is that IPP software must be able to listen on port 631 and > may be able to listen on other ports. > If such software allows an administrator to configure the ports, then such > an adminstrator may be able to have IPP software listen other ports, such as > port 80 and might make it be the only port that the IPP server listens on. > The customer has the right to do what he wants, even if we don't think it is > the wisest choice. > > Bob Herriot > What I find ambiguous, then, are the words "in addition to" and "as well" in these sentences: "IPP server implementations may support other ports, in addition to this port." "It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over port some other port as well." Maybe it should say: "It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may be configured to listen on some other port instead." -Carl > > At 10:24 AM 7/16/98 , Carl Kugler wrote: > >Carl: > >> > >> The implementation MUST support port 631 however, mine is administratively > >> set to only OPERATE on port 80. The code is compliant. > >> > >> Don > >> > >> > >Hmmm... I think we need some clarification in the wording here, because I > think it's ambiguous as it stands. Here's another quote: "IPP server > implementations MUST offer IPP services using HTTP over the IANA assigned Well > Known Port 631 (the IPP default port). IPP server implementations may support > other ports, in addition to this port." > > > >So you read "suport" and "offer IPP services" to mean "can be configured to > listen on" rather than "is required to listen on"? > > > > -Carl > > > >> > >> > >> "Carl Kugler" on 07/16/98 > >> 12:18:26 PM > >> > >> To: ipp%pwg.org@interlock.lexmark.com > >> cc: (bcc: Don Wright) > >> bcc: Don Wright > >> Subject: RE: IPP> Re: New IPP Scheme > >> > >> > >> > >> > >> ... > >> > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine > >> is > >> > on 80 so my URL is exactly right. Not all implementations MUST be on > >> 631. > >> ... > >> That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > >> > >> It says "It is REQUIRED that a printer implementation support HTTP over the > >> IANA assigned Well Known Port 631...". Therefore, a conforming > >> implementation MUST be on 631, although it might also be on some other port > >> simultaneously. > >> > >> ----- > >> Original Message: http://www.findmail.com/list/ipp/?start=4106 > >> Start a FREE email list at http://www.FindMail.com/ > >> > >> > >> > >> > >> > >> > > > > > > > >----- > >Original Message: http://www.findmail.com/list/ipp/?start=4138 > >Start a FREE email list at http://www.FindMail.com/ > > > > --=====================_160811464==_.ALT > Content-Type: text/html; charset="us-ascii" > > > I wrote the sentences that you are asking about.  I > tried to pick words that
> would be unambiguous.
>
> The intention is that IPP software must be able to listen on port 631 and >
> may be able to listen on other ports.
> If such software allows an administrator to configure the ports, then > such
> an adminstrator may be able to have IPP software listen other ports, such > as
> port 80 and might make it be the only port that the IPP server listens > on. 
> The customer has the right to do what he wants, even if we don't think it > is
> the wisest choice.
>
> Bob Herriot
>
>
> At 10:24 AM 7/16/98 , Carl Kugler wrote:
> >Carl:
> >>
> >> The implementation MUST support port 631 however, mine is > administratively
> >> set to only OPERATE on port 80.  The code is > compliant.
> >>
> >> Don
> >>
> >>
> >Hmmm... I think we need some clarification in the wording here, > because I think it's ambiguous as it stands.  Here's another > quote:  "IPP server implementations MUST offer IPP services > using HTTP over the IANA assigned Well Known Port 631 (the IPP default > port). IPP server implementations may support other ports, in addition to > this port."
> >
> >So you read "suport" and "offer IPP services" to > mean "can be configured to listen on" rather than "is > required to listen on"?
> >
> >    -Carl
> >
> >>
> >>
> >> "Carl Kugler" > <kugler%us.ibm.com@interlock.lexmark.com> on 07/16/98
> >> 12:18:26 PM
> >>
> >> To:   ipp%pwg.org@interlock.lexmark.com
> >> cc:    (bcc: Don Wright)
> >> bcc:  Don Wright
> >> Subject:  RE: IPP> Re: New IPP Scheme
> >>
> >>
> >>
> >>
> >> ...
> >> > Sorry Larry, but my printer isn't on the default IPP port > of 631.  Mine
> >> is
> >> > on 80 so my URL is exactly right.  Not all > implementations MUST be on
> >> 631.
> >> ...
> >> That's not how I read > ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630
> >>
> >> It says "It is REQUIRED that a printer implementation > support HTTP over the
> >> IANA assigned Well Known Port 631...".  Therefore, a > conforming
> >> implementation MUST be on 631, although it might also be on some > other port
> >> simultaneously.
> >>
> >> -----
> >> Original Message: > http://www.findmail.com/list/ipp/?start=4106
> >> Start a FREE email list at > http://www.FindMail.com/
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >-----
> >Original Message: > http://www.findmail.com/list/ipp/?start=4138
> >Start a FREE email list at > http://www.FindMail.com/
> >
> > > --=====================_160811464==_.ALT-- > > > ----- Original Message: http://www.findmail.com/list/ipp/?start=4144 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Thu Jul 16 17:39:36 1998 Delivery-Date: Thu, 16 Jul 1998 17:39:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22486 for ; Thu, 16 Jul 1998 17:39:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23346 for ; Thu, 16 Jul 1998 17:39:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA26496 for ; Thu, 16 Jul 1998 17:39:34 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 17:35:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25911 for ipp-outgoing; Thu, 16 Jul 1998 17:30:06 -0400 (EDT) Message-ID: <35AE70CD.B05B5DD7@underscore.com> Date: Thu, 16 Jul 1998 17:29:49 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl Kugler CC: ipp@pwg.org Subject: Re: IPP> Re: New IPP Scheme References: <19980716210937.29015.qmail@m2.findmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org > Maybe it should say: > > "It is REQUIRED that a printer implementation support HTTP over > the IANA assigned Well Known Port 631 (the IPP default port), though > a printer implementation may be configured to listen on some other port > instead." Or perhaps: "...may be configured to listen on one or more ports instead." ^^^^^^^^^^^ ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-owner@pwg.org Thu Jul 16 17:49:31 1998 Delivery-Date: Thu, 16 Jul 1998 17:49:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22630 for ; Thu, 16 Jul 1998 17:49:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23406 for ; Thu, 16 Jul 1998 17:49:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA27177 for ; Thu, 16 Jul 1998 17:49:30 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 17:45:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26578 for ipp-outgoing; Thu, 16 Jul 1998 17:42:12 -0400 (EDT) Message-Id: <199807162141.RAA27176@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Carl Kugler" cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: New IPP Scheme In-reply-to: Your message of "16 Jul 1998 16:18:26 -0000." <19980716161826.21898.qmail@m2.findmail.com> Date: Thu, 16 Jul 1998 17:41:51 -0400 Sender: owner-ipp@pwg.org > > Sorry Larry, but my printer isn't on the default IPP port of 631. Mine is > > on 80 so my URL is exactly right. Not all implementations MUST be on 631. > ... > That's not how I read ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > It says "It is REQUIRED that a printer implementation support HTTP over the > IANA assigned Well Known Port 631...". Therefore, a conforming > implementation MUST be on 631, although it might also be on some other > port simultaneously. No, I don't think so. Implementations should default to port 631, but people who buy these things should be able to change that default to anything they want. Here's how I would say this: 1. Implementations MUST support the ability to accept IPP requests on port 631. 2. Implementations MAY support the ability to accept IPP requests on other ports instead of, or in addition to, port 631, but only if explicitly configured to do so by the printer administrator. Keith From ipp-owner@pwg.org Thu Jul 16 19:35:45 1998 Delivery-Date: Thu, 16 Jul 1998 19:36:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23710 for ; Thu, 16 Jul 1998 19:35:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA23833 for ; Thu, 16 Jul 1998 19:35:18 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA28134 for ; Thu, 16 Jul 1998 19:35:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 19:30:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA27555 for ipp-outgoing; Thu, 16 Jul 1998 19:25:09 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C40@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'Keith Moore'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> report from IESG telechat Date: Thu, 16 Jul 1998 16:22:12 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Keith, Thanks for the update. This sets an end to further discussions about IF and WHY we should have an ipp: scheme. We can now concentrate any further discussion on the details on HOW to implement ipp: (sorry Don and Paul) Carl-Uno > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, July 16, 1998 12:42 PM > To: ipp@pwg.org > Cc: moore@cs.utk.edu > Subject: IPP> report from IESG telechat > > > 1. Several members of the IESG requested more time to review the IPP > documents. They will be discussed again at the next IESG meeting, > which should take place on 30 July. > > 2. With regard to the use of http: URLs at the HTTP layer, and > ipp: used everywhere else: Nobody on IESG had a problem with this. > > Keith > From ipp-owner@pwg.org Thu Jul 16 21:48:32 1998 Delivery-Date: Thu, 16 Jul 1998 21:48:33 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA24961 for ; Thu, 16 Jul 1998 21:48:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24188 for ; Thu, 16 Jul 1998 21:48:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29197 for ; Thu, 16 Jul 1998 21:48:07 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 21:40:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA28607 for ipp-outgoing; Thu, 16 Jul 1998 21:34:45 -0400 (EDT) Message-ID: From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> Comments on MIB access document Date: Thu, 16 Jul 1998 18:34:27 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org This document proposed many extremely significant changes to IPP. They are so radical that I do not thing that they can be accepted simply as an optional extension to 1.0. Many of the issue it tries to solve are very valid - but this is not the right way to address them. 1. The current model is very strong on hiding the physical details of fanning out. The only thing exposed is a logical printer - the fact that this may represent multiple devices is deliberatly not exposed. This proposal turns this 180 degrees and explicitly exposes this. No comment on whether this is good or bad - I merely point out that this is a BIG change to slip in via an optional extension for accessing MIBs. Note that this is done for some non-MIB attributes as well. 2. The device is described as being an 'object'. This challenges the whole concept of an object in IPP. Everywhere else an Object can receive operations and has a URI; the device does neither. Having said that, a model that does expose 'devices' and 'objects' but that does not represent such a fundamental construct (device) as a object seems very strange. 3. This scheme introduces a structured namespace. No comment on whether this is good or bad - I merely point out that this is a BIG change from the flat list in the main model. 4. The printer MIB is given a special place in this scheme. What about the job mib or the finisher mib. 5. The MIB query is optional but is overloaded on the get attributes operation. I cannot find out if a printer supports it without trying and failing. Normally such big pieces of functionality would be a separate operation. 6. What is the relationship between the information I obtain via the MIb query and the data I obtain via the other queries? Will the result of querying the job mib be the same as the result of doing a getjobs? What about printer-status and the MIB status? 7. If I dont say what device I want it will go to the 'first' one. What does first mean? Is it guaranteed to be the same always? How do I support intelligent pools (If I send a PS file there is a choice of two printers, if I send PCL there is a choice of 4. Only 2 printers are available for large jobs, but if i send a small job there is a choice of 4). What should the device list return? What happens if a device is turned off? 8. You state that for non-printer MIB things you dont have to say what the device is because this is implicit in the OID. There is a level shift here. The devices enumerated by the proposed IPP device list is not the same as the device list in each printer. A printer will have a printer device, a disk, some RAM, etc. 9. You do not say what must happen if I send a valid query but the result is empty. I.e. read the alert table. From ipp-owner@pwg.org Fri Jul 17 09:06:56 1998 Delivery-Date: Fri, 17 Jul 1998 09:06:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA08620 for ; Fri, 17 Jul 1998 09:06:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA25679 for ; Fri, 17 Jul 1998 09:06:47 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA13513 for ; Fri, 17 Jul 1998 09:06:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 08:55:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA12915 for ipp-outgoing; Fri, 17 Jul 1998 08:50:15 -0400 (EDT) From: don@lexmark.com Message-Id: <199807171249.AA07051@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Robert Herriot Cc: Keith Moore , Ipp@pwg.org Date: Fri, 17 Jul 1998 08:49:16 -0400 Subject: Re: IPP> Re: New IPP Scheme Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org I'm confused... In Bob Herriot's summary of the telecon agreement, he said: > job attributes - > job-uri > job-printer-uri > printer attributes - > printer-uri-supported > operation attributes - > job-uri > printer-uri > >If the scheme of the target URL in a request (i.e. the value of >"printer-uri" or "job-uri" operation attribute) is some scheme 'x', other >than 'ipp', the behavior of the IPP object is not defined by this document. >However, it is RECOMMENDED that if an operation on an IPP object creates a >new value for any of the above attributes, that attribute has the same >scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the >seven attributes above in the response, that the IPP object returns those >URL values as is, regardless of the scheme of the target URL. 1) In the sentence that starts out "However, it is RECOMMENDED..." what does "that attribute has the same scheme 'x'" mean? Has the same scheme as what?? 2) The last sentence says "...any of the seven attributes above..." Yet there are only five attributes listed above. I don't think there are attributes missing so should that be "...any of the five attributes above..."???? 3) What does "as is" later in the same sentence mean? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Fri Jul 17 10:30:37 1998 Delivery-Date: Fri, 17 Jul 1998 10:30:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA10052 for ; Fri, 17 Jul 1998 10:30:32 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA26129 for ; Fri, 17 Jul 1998 10:30:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA14364 for ; Fri, 17 Jul 1998 10:30:28 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 10:25:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13790 for ipp-outgoing; Fri, 17 Jul 1998 10:19:59 -0400 (EDT) Date: Fri, 17 Jul 1998 07:31:56 -0700 (PDT) From: papowell@astart.com Message-Id: <199807171431.HAA12705@astart4.astart.com> To: moore@cs.utk.edu, robert.herriot@Eng.Sun.COM Subject: Re: IPP> Re: New IPP Scheme Cc: ipp@pwg.org Sender: owner-ipp@pwg.org This appears to be a reasonable approach to this problem. I note carefully that there are still some nasty problems lurking with proxies, etc., but nothing that would be serious for a skilled person in dealing with nasty problems with proxies. Patrick Powell > From ipp-owner@pwg.org Wed Jul 15 19:01:11 1998 > Date: Wed, 15 Jul 1998 18:41:27 -0700 > To: Keith Moore > From: Robert Herriot > Subject: Re: IPP> Re: New IPP Scheme > Cc: ipp@pwg.org > > --=====================_97913321==_.ALT > Content-Type: text/plain; charset="us-ascii" > > Action item from Robert Herriot and Tom Hastings: > > The IPP working group reached an agreement with Keith Moore in this > morning's teleconference. This document is our best understanding of the > details of this agreement. > > Summary: > > The quick summary is that IPP should support a new scheme 'ipp', which > clients and servers use in IPP attributes. Such attributes are in a message > body whose Content-Type is application/ipp. A client maps 'ipp' URLs to > 'http' URLs, and then follows the HTTP/1.1 rules for constructing a > Request-Line and HTTP headers. The IPP document will not prohibit > implementations from supporting other schemes in IPP attributes, but such > support is not defined by this document. From ipp-owner@pwg.org Fri Jul 17 12:01:58 1998 Delivery-Date: Fri, 17 Jul 1998 12:02:03 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11303 for ; Fri, 17 Jul 1998 12:01:57 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA26703 for ; Fri, 17 Jul 1998 12:01:54 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA15370 for ; Fri, 17 Jul 1998 12:01:53 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 11:55:52 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14722 for ipp-outgoing; Fri, 17 Jul 1998 11:50:03 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C45@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'ipp@pwg.org'" Subject: IPP> FW: I-D ACTION:draft-fielding-uri-syntax-04.txt Date: Fri, 17 Jul 1998 08:18:39 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDB196.2D33A714" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDB196.2D33A714 Content-Type: text/plain FYI, Carl-Uno -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, July 17, 1998 4:20 AM To: IETF-Announce Subject: I-D ACTION:draft-fielding-uri-syntax-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Uniform Resource Identifiers (URI): Generic Syntax Author(s) : T. Berners-Lee, R. Fielding, L. Masinter Filename : draft-fielding-uri-syntax-04.txt Pages : 15 Date : 16-Jul-98 A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. 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-fielding-uri-syntax-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-syntax-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fielding-uri-syntax-04.txt". NOTE: The mail server at ietf.org 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_000_01BDB196.2D33A714 Content-Type: message/rfc822 To: Subject: Date: Fri, 17 Jul 1998 08:18:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDB196.2D33A714" ------ =_NextPart_002_01BDB196.2D33A714 Content-Type: text/plain ------ =_NextPart_002_01BDB196.2D33A714 Content-Type: application/octet-stream; name="ATT07147.txt" Content-Disposition: attachment; filename="ATT07147.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980716095424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fielding-uri-syntax-04.txt ------ =_NextPart_002_01BDB196.2D33A714 Content-Type: message/external-body; site="internet-drafts"; dir="draft-fielding-uri-syntax-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDB196.2D33A714-- ------ =_NextPart_000_01BDB196.2D33A714-- From ipp-owner@pwg.org Fri Jul 17 12:06:37 1998 Delivery-Date: Fri, 17 Jul 1998 12:06:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11371 for ; Fri, 17 Jul 1998 12:06:36 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA26742 for ; Fri, 17 Jul 1998 12:06:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16007 for ; Fri, 17 Jul 1998 12:06:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 12:01:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14752 for ipp-outgoing; Fri, 17 Jul 1998 11:54:37 -0400 (EDT) Date: Fri, 17 Jul 1998 09:06:26 -0700 (PDT) From: papowell@astart.com Message-Id: <199807171606.JAA14745@astart4.astart.com> To: ipp@pwg.org, kugler@us.ibm.com Subject: RE: IPP> Re: New IPP Scheme Sender: owner-ipp@pwg.org Make this port or ports - you can listen on multiple ports... Patrick i.e. - It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may be configured to listen on some other port(s) instead." > > -Carl > From ipp-owner@pwg.org Fri Jul 17 12:54:43 1998 Delivery-Date: Fri, 17 Jul 1998 12:54:43 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11829 for ; Fri, 17 Jul 1998 12:54:42 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA26994 for ; Fri, 17 Jul 1998 12:54:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA16803 for ; Fri, 17 Jul 1998 12:54:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 12:50:48 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16242 for ipp-outgoing; Fri, 17 Jul 1998 12:46:08 -0400 (EDT) Date: 17 Jul 1998 16:45:04 -0000 Message-ID: <19980717164504.32419.qmail@m2.findmail.com> From: "Carl Kugler" Subject: RE: IPP> Re: New IPP Scheme In-Reply-To: <199807171606.JAA14745@astart4.astart.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > Make this port or ports - you can listen on multiple ports... > > Patrick > > i.e. - > > It is REQUIRED that a printer implementation support HTTP over > the IANA assigned Well Known Port 631 (the IPP default port), > though a printer implementation may be configured to listen > on some other port(s) instead." > Still not quite right: the "other" seems exclusive of 631, but in the multiple ports case, 631 might be included. > > > > -Carl > > Here's another try: Replace: It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over port some other port as well. In addition, a printer may have to support another port for privacy (See Section 5 “Security Considerations”. Note: even though port 631 is the IPP default, port 80 remains the default for an HTTP URI. Thus a URI for a printer using port 631 MUST contain an explicit port, e.g. "http://forest:631/pinetree". with: IANA has assigned Well Known Port 631 to the default IPP port number. An IPP server listens on port 631 unless explicitly configured to listen on one or more ports instead of, or in addition to, port 631. If the port is empty or not given in an "ipp" schemed URL, port 631 is assumed. -Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=4154 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Fri Jul 17 13:29:34 1998 Delivery-Date: Fri, 17 Jul 1998 13:29:34 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA12102 for ; Fri, 17 Jul 1998 13:29:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA27113 for ; Fri, 17 Jul 1998 13:29:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA17456 for ; Fri, 17 Jul 1998 13:12:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 13:05:45 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16893 for ipp-outgoing; Fri, 17 Jul 1998 13:01:27 -0400 (EDT) From: don@lexmark.com Message-Id: <199807171701.AA26390@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 17 Jul 1998 13:00:49 -0400 Subject: IPP> IETF Process Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipp@pwg.org What is the process for confirming consensus after substantial changes have been made to a standard? In the IEEE and other recognized standards bodies, if non-editoral changes are made, the final version is re-ballotted. Considering the substantial changes made since the WG had consensus in and shortly after the January meeting in Maui, once we have updated all the document with what we believe to be the last changes (i.e. before IESG approval), I believe we should make sure the WG is still in consensus. Thoughts?? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-owner@pwg.org Fri Jul 17 13:55:05 1998 Delivery-Date: Fri, 17 Jul 1998 13:55:05 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA12407 for ; Fri, 17 Jul 1998 13:55:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA27241 for ; Fri, 17 Jul 1998 13:55:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA18725 for ; Fri, 17 Jul 1998 13:55:00 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 13:51:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18087 for ipp-outgoing; Fri, 17 Jul 1998 13:48:12 -0400 (EDT) Message-ID: <35AF8E26.8E194888@us.ibm.com> Date: Fri, 17 Jul 1998 13:47:18 -0400 From: Jeff Schnitzer X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> IETF Process Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Interesting question .... Given that the IESG is in the process of reviewing IPP, what happens if they approve it, and a subsequent PWG ballot disapproves it because of changes made to get it past the IESG??? I'd say its better left alone. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 From ipp-owner@pwg.org Fri Jul 17 14:01:48 1998 Delivery-Date: Fri, 17 Jul 1998 14:01:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA12481 for ; Fri, 17 Jul 1998 14:01:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA27294 for ; Fri, 17 Jul 1998 14:01:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA19361 for ; Fri, 17 Jul 1998 14:01:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 13:57:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18145 for ipp-outgoing; Fri, 17 Jul 1998 13:48:47 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C4A@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'Carl Kugler'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Re: New IPP Scheme Date: Fri, 17 Jul 1998 10:45:41 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Carl, I think we should take the text suggested by Keith yesterday. Carl-Uno > -----Original Message----- > From: Carl Kugler [mailto:kugler@us.ibm.com] > Sent: Friday, July 17, 1998 9:45 AM > To: cmanros@cp10.es.xerox.com > Subject: RE: IPP> Re: New IPP Scheme > > > True! > > How about this instead: > > IANA has assigned Well Known Port 631 to the default IPP port > number. An IPP > server listens on port 631 unless explicitly configured to > listen on one or > more ports instead of, or in addition to, port 631. If the > port is empty or > not given in an "ipp" schemed URL, port 631 is assumed. > > -Carl > > > > cmanros@cp10.es.xerox.com on 07/16/98 05:30:00 PM > Please respond to cmanros@cp10.es.xerox.com > To: Carl Kugler/Boulder/IBM@ibmus > cc: > Subject: RE: IPP> Re: New IPP Scheme > > > Carl, > > Your proposal isn't quite right either. An IPP server can > also listen to > several ports e.g port 631 and port 80. > > Carl-Uno > > > -----Original Message----- > > From: Carl Kugler [mailto:kugler@us.ibm.com] > > Sent: Thursday, July 16, 1998 2:10 PM > > To: ipp@pwg.org > > Subject: RE: IPP> Re: New IPP Scheme > > > > > > --=====================_160811464==_.ALT > > > Content-Type: text/plain; charset="us-ascii" > > > > > > I wrote the sentences that you are asking about. I tried > > to pick words that > > > would be unambiguous. > > > > > > The intention is that IPP software must be able to listen > > on port 631 and > > > may be able to listen on other ports. > > > If such software allows an administrator to configure the > > ports, then such > > > an adminstrator may be able to have IPP software listen > > other ports, such as > > > port 80 and might make it be the only port that the IPP > > server listens on. > > > The customer has the right to do what he wants, even if we > > don't think it is > > > the wisest choice. > > > > > > Bob Herriot > > > > > > > What I find ambiguous, then, are the words "in addition to" > > and "as well" in these sentences: > > > > "IPP server implementations may support other ports, in > > addition to this port." > > > > "It is REQUIRED that a printer implementation support > > HTTP over the IANA assigned Well Known Port 631 (the IPP > > default port), though a printer implementation may support > > HTTP over port some other port as well." > > > > Maybe it should say: > > > > "It is REQUIRED that a printer implementation support > > HTTP over the IANA assigned Well Known Port 631 (the IPP > > default port), though a printer implementation may be > > configured to listen on some other port instead." > > > > -Carl > > > > > > > > At 10:24 AM 7/16/98 , Carl Kugler wrote: > > > >Carl: > > > >> > > > >> The implementation MUST support port 631 however, mine > > is administratively > > > >> set to only OPERATE on port 80. The code is compliant. > > > >> > > > >> Don > > > >> > > > >> > > > >Hmmm... I think we need some clarification in the wording > > here, because I > > > think it's ambiguous as it stands. Here's another quote: > > "IPP server > > > implementations MUST offer IPP services using HTTP over the > > IANA assigned Well > > > Known Port 631 (the IPP default port). IPP server > > implementations may support > > > other ports, in addition to this port." > > > > > > > >So you read "suport" and "offer IPP services" to mean "can > > be configured to > > > listen on" rather than "is required to listen on"? > > > > > > > > -Carl > > > > > > > >> > > > >> > > > >> "Carl Kugler" > > on 07/16/98 > > > >> 12:18:26 PM > > > >> > > > >> To: ipp%pwg.org@interlock.lexmark.com > > > >> cc: (bcc: Don Wright) > > > >> bcc: Don Wright > > > >> Subject: RE: IPP> Re: New IPP Scheme > > > >> > > > >> > > > >> > > > >> > > > >> ... > > > >> > Sorry Larry, but my printer isn't on the default IPP > > port of 631. Mine > > > >> is > > > >> > on 80 so my URL is exactly right. Not all > > implementations MUST be on > > > >> 631. > > > >> ... > > > >> That's not how I read > > ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630 > > > >> > > > >> It says "It is REQUIRED that a printer implementation > > support HTTP over the > > > >> IANA assigned Well Known Port 631...". Therefore, a conforming > > > >> implementation MUST be on 631, although it might also be > > on some other port > > > >> simultaneously. > > > >> > > > >> ----- > > > >> Original Message: http://www.findmail.com/list/ipp/?start=4106 > > > >> Start a FREE email list at http://www.FindMail.com/ > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > >----- > > > >Original Message: http://www.findmail.com/list/ipp/?start=4138 > > > >Start a FREE email list at http://www.FindMail.com/ > > > > > > > > > > --=====================_160811464==_.ALT > > > Content-Type: text/html; charset="us-ascii" > > > > > > > > > I wrote the sentences that you are asking > > about.  I > > > tried to pick words that
> > > would be unambiguous.
> > >
> > > The intention is that IPP software must be able to listen > > on port 631 and > > >
> > > may be able to listen on other ports.
> > > If such software allows an administrator to configure the > > ports, then > > > such
> > > an adminstrator may be able to have IPP software listen > > other ports, such > > > as
> > > port 80 and might make it be the only port that the IPP > > server listens > > > on. 
> > > The customer has the right to do what he wants, even if we > > don't think it > > > is
> > > the wisest choice.
> > >
> > > Bob Herriot
> > >
> > >
> > > At 10:24 AM 7/16/98 , Carl Kugler wrote:
> > > >Carl:
> > > >>
> > > >> The implementation MUST support port 631 however, mine is > > > administratively
> > > >> set to only OPERATE on port 80.  The code is > > > compliant.
> > > >>
> > > >> Don
> > > >>
> > > >>
> > > >Hmmm... I think we need some clarification in the > wording here, > > > because I think it's ambiguous as it stands.  Here's another > > > quote:  "IPP server implementations MUST offer > > IPP services > > > using HTTP over the IANA assigned Well Known Port 631 (the > > IPP default > > > port). IPP server implementations may support other ports, > > in addition to > > > this port."
> > > >
> > > >So you read "suport" and "offer IPP > > services" to > > > mean "can be configured to listen on" rather > than "is > > > required to listen on"?
> > > >
> > > >    -Carl
> > > >
> > > >>
> > > >>
> > > >> "Carl Kugler" > > > <kugler%us.ibm.com@interlock.lexmark.com> on 07/16/98
> > > >> 12:18:26 PM
> > > >>
> > > >> To:   ipp%pwg.org@interlock.lexmark.com
> > > >> cc:    (bcc: Don Wright)
> > > >> bcc:  Don Wright
> > > >> Subject:  RE: IPP> Re: New IPP Scheme
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ...
> > > >> > Sorry Larry, but my printer isn't on the > > default IPP port > > > of 631.  Mine
> > > >> is
> > > >> > on 80 so my URL is exactly right.  Not all > > > implementations MUST be on
> > > >> 631.
> > > >> ...
> > > >> That's not how I read > > > > href="ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630" > > eudora="autourl"> > size=3>ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980630
> > > >>
> > > >> It says "It is REQUIRED that a printer > implementation > > > support HTTP over the
> > > >> IANA assigned Well Known Port 631...".  > > Therefore, a > > > conforming
> > > >> implementation MUST be on 631, although it might > > also be on some > > > other port
> > > >> simultaneously.
> > > >>
> > > >> -----
> > > >> Original Message: > > > > eudora="autourl"> > size=3>http://www.findmail.com/list/ipp/?start=4106
> > > >> Start a FREE email list at > > > > size=3>http://www.FindMail.com/
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >-----
> > > >Original Message: > > > > eudora="autourl"> > size=3>http://www.findmail.com/list/ipp/?start=4138
> > > >Start a FREE email list at > > > > size=3>http://www.FindMail.com/
> > > >
> > > > > > > > > --=====================_160811464==_.ALT-- > > > > > > > > > > > > > > > > > ----- > > Original Message: http://www.findmail.com/list/ipp/?start=4144 > > Start a FREE email list at http://www.FindMail.com/ > > > > > > From ipp-owner@pwg.org Fri Jul 17 14:15:49 1998 Delivery-Date: Fri, 17 Jul 1998 14:15:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA12629 for ; Fri, 17 Jul 1998 14:15:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA27379 for ; Fri, 17 Jul 1998 14:15:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA20298 for ; Fri, 17 Jul 1998 14:15:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 14:11:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18840 for ipp-outgoing; Fri, 17 Jul 1998 13:57:30 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C4B@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'don@lexmark.com'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> IETF Process Date: Fri, 17 Jul 1998 10:54:29 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Don, I have checked this with Keith earlier. The IETF process does not call for a formal Last Call either in the WG or in the IESG, once the IESG approval process is underway. However, it is still appropriate to check the level of WG consensus after we have the final texts. In the end, the IESG has the final say. You can dispute an IESG decision by taking it to the IAB, but I doubt that it would bring much in our case. If nothing else, that would ensure that the standard gets delayed even further. Carl-Uno > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Friday, July 17, 1998 10:01 AM > To: ipp@pwg.org > Subject: IPP> IETF Process > > > What is the process for confirming consensus after > substantial changes have > been made to a standard? In the IEEE and other recognized standards > bodies, if non-editoral changes are made, the final version is > re-ballotted. Considering the substantial changes made since > the WG had > consensus in and shortly after the January meeting in Maui, > once we have > updated all the document with what we believe to be the last > changes (i.e. > before IESG approval), I believe we should make sure the WG > is still in > consensus. > > Thoughts?? > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > From ipp-owner@pwg.org Fri Jul 17 16:50:51 1998 Delivery-Date: Fri, 17 Jul 1998 16:50:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14456 for ; Fri, 17 Jul 1998 16:50:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA28294 for ; Fri, 17 Jul 1998 16:50:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22232 for ; Fri, 17 Jul 1998 16:50:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 16:45:57 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21672 for ipp-outgoing; Fri, 17 Jul 1998 16:39:39 -0400 (EDT) Message-Id: <199807172034.NAA24599@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 17 Jul 1998 13:40:28 -0700 To: don@lexmark.com, Robert Herriot From: Robert Herriot Subject: Re: IPP> Re: New IPP Scheme Cc: Keith Moore , Ipp@pwg.org In-Reply-To: <199807171249.AA07051@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_252653586==_.ALT" Sender: owner-ipp@pwg.org --=====================_252653586==_.ALT Content-Type: text/plain; charset="us-ascii" Comments are below. At 05:49 AM 7/17/98 , don@lexmark.com wrote: >I'm confused... > >In Bob Herriot's summary of the telecon agreement, he said: > >> job attributes - >> job-uri >> job-printer-uri >> printer attributes - >> printer-uri-supported >> operation attributes - >> job-uri >> printer-uri >> >>If the scheme of the target URL in a request (i.e. the value of >>"printer-uri" or "job-uri" operation attribute) is some scheme 'x', other >>than 'ipp', the behavior of the IPP object is not defined by this >document. >>However, it is RECOMMENDED that if an operation on an IPP object creates a >>new value for any of the above attributes, that attribute has the same >>scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of >the >>seven attributes above in the response, that the IPP object returns those >>URL values as is, regardless of the scheme of the target URL. > >1) In the sentence that starts out "However, it is RECOMMENDED..." what >does "that attribute has the same scheme 'x'" mean? Has the same scheme as >what?? What I meant was that if a Printer receives a Create-Job operation with "ipp://foo.com/printers/Foo" as the value of the "printer-uri" attribute, then the Printer creates a "job-uri" attribute with an "ipp" scheme, e.g. "ipp://foo.com/printers/Foo/123". Likewise, if a Printer receives a Create-Job operation with "http://foo.com:631/printers/Foo" as the value of the "printer-uri" attribute, then the Printer creates a "job-uri" attribute with an "http" scheme, e.g. "http://foo.com:631/printers/Foo/123". > >2) The last sentence says "...any of the seven attributes above..." Yet >there are only five attributes listed above. I don't think there are >attributes missing so should that be "...any of the five attributes >above..."???? I guess I can't count. > >3) What does "as is" later in the same sentence mean? If you are referring to the user interface paragraph, I was trying to say that the software doesn't change a URL in any way. If a user can see a URL, it will be the same as the one passed in one of the five attributes. That is, if the attribute value is "ipp://foo.com/printers/Foo", that is what the user sees, and if the value is "http://foo.com:631/printers/Foo", that is what the user sees. > > > >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > --=====================_252653586==_.ALT Content-Type: text/html; charset="us-ascii" Comments are below.

At 05:49 AM 7/17/98 , don@lexmark.com wrote:
>I'm confused...
>
>In Bob Herriot's summary of the telecon agreement, he said:
>
>>     job attributes -
>>        job-uri
>>        job-printer-uri
>>    printer attributes -
>>        printer-uri-supported
>>    operation attributes -
>>        job-uri
>>        printer-uri
>>
>>If the scheme of the target URL in a request (i.e. the value of
>>"printer-uri" or "job-uri" operation attribute) is some scheme 'x', other
>>than 'ipp', the behavior of the IPP object is not defined by this
>document.
>>However, it is RECOMMENDED that if an operation on an IPP object creates a
>>new value for any of the above attributes, that attribute has the same
>>scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of
>the
>>seven attributes above in the response, that the IPP object returns those
>>URL values as is, regardless of the scheme of the target URL.
>
>1) In the sentence that starts out "However, it is RECOMMENDED..." what
>does "that attribute has the same scheme 'x'" mean?  Has the same scheme as
>what??

What I meant was that if a Printer receives a Create-Job operation with
"ipp://foo.com/printers/Foo" as the value of the "printer-uri" attribute,
then the Printer creates a "job-uri" attribute with an "ipp" scheme, e.g.
"ipp://foo.com/printers/Foo/123". Likewise, if a Printer receives a
Create-Job operation with "http://foo.com:631/printers/Foo" as the value of
the "printer-uri" attribute, then the Printer creates a "job-uri" attribute
with an "http" scheme, e.g. "http://foo.com:631/printers/Foo/123".

>
>2) The last sentence says "...any of the seven attributes above..."  Yet
>there are only five attributes listed above.  I don't think there are
>attributes missing so should that be "...any of the five attributes
>above..."????

I guess I can't count.
>
>3) What does "as is" later in the same sentence mean?

If you are referring to the user interface paragraph, I was trying to say
that the software doesn't change a URL in any way.  If a user can see a URL,
it will be the same as the one passed in one of the five attributes. That
is, if the attribute value is "ipp://foo.com/printers/Foo", that is what the
user sees, and if the value is "http://foo.com:631/printers/Foo", that is
what the user sees.


>
>
>
>**********************************************
>* Don Wright                 don@lexmark.com *
>* Product Manager, Strategic Alliances       *
>* Lexmark International                      *
>* 740 New Circle Rd                          *
>* Lexington, Ky 40550                        *
>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>**********************************************
>
--=====================_252653586==_.ALT-- From ipp-owner@pwg.org Fri Jul 17 17:41:25 1998 Delivery-Date: Fri, 17 Jul 1998 17:41:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA15133 for ; Fri, 17 Jul 1998 17:41:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA28546 for ; Fri, 17 Jul 1998 17:41:20 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA22940 for ; Fri, 17 Jul 1998 17:41:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 17:35:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22372 for ipp-outgoing; Fri, 17 Jul 1998 17:31:49 -0400 (EDT) Message-Id: <199807172131.RAA05024@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: don@lexmark.com cc: ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IETF Process In-reply-to: Your message of "Fri, 17 Jul 1998 13:00:49 EDT." <199807171701.AA26390@interlock2.lexmark.com> Date: Fri, 17 Jul 1998 17:31:38 -0400 Sender: owner-ipp@pwg.org > What is the process for confirming consensus after substantial changes have > been made to a standard? In the IEEE and other recognized standards > bodies, if non-editoral changes are made, the final version is > re-ballotted. Considering the substantial changes made since the WG had > consensus in and shortly after the January meeting in Maui, once we have > updated all the document with what we believe to be the last changes (i.e. > before IESG approval), I believe we should make sure the WG is still in > consensus. Three things: 1. In general, the chair determines whether the working group has reached consensus. So if changes have been made since the working group last reached consensus, the chair decides whether/when there is still consensus within the working group on the revised document. 2. The responsible AD determines whether an additional Last Call is needed, if changes have been made since the previous Last Call. 3. When IESG is balloting a document action, and the result is to require changes to a document, the IESG also decides whether the changes needed by a document are significant enough to warrant another IESG ballot once revisions are made, or whether the document can be accepted immediately once a designated member of the IESG declares that revisions are made. Keith From ipp-owner@pwg.org Fri Jul 17 19:20:35 1998 Delivery-Date: Fri, 17 Jul 1998 19:20:35 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA16765 for ; Fri, 17 Jul 1998 19:20:34 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA28941 for ; Fri, 17 Jul 1998 19:20:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA24464 for ; Fri, 17 Jul 1998 19:20:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 17 Jul 1998 19:15:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23914 for ipp-outgoing; Fri, 17 Jul 1998 19:12:45 -0400 (EDT) Date: 17 Jul 1998 23:11:39 -0000 Message-ID: <19980717231139.17786.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> MOD> Printer attributes specialized by "document-format" In-Reply-To: <19980610212811.15889.qmail@m2.findmail.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org It looks like the problem discusssed in Re: MOD> "document-format-supported" [MOD needs clarification], http://www.findmail.com/list/ipp/showthread.html?num=3864 was addressed in the new MOD, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt June 30, 1998. The new words say: "If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes: - Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2), - "pdl-override-supported", - "compression-supported", - "job-k-octets-supported", - "job-impressions-supported, - "job-media-sheets-supported" - "printer-driver-installer", - "color-supported", and - "reference-uri-schemes-supported" "The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.2). While this new wording gets around the problem, I think it presents a poor model. It blatantly violates Second Normal Form, in that some Printer attributes depend on the (Printer identifier, document-format) tuple, while others depend only on the Printer identifier. The model says that all these attributes, including those that vary with document-format (e.g., number-up), are attributes of the Printer class of objects. But the implication is that each real-wold printer maps to a whole set of Printer object instances, selected by document-format. Attributes (e.g. printer-name) which don't vary with document-format are redundantly stored in each instance. Updates to attributes that don't vary with document-format (e.g. printer-state) require visiting all the instances. A better model would split the existing Printer into two classes of objects: 1) a new, reduced Printer, and 2)something else that could be called "Interpreter". Then the attributes can be normalized between these two new classes. Attributes that don't vary with document-format are assigned to the Printer. Each real-world printer maps to one instance of Printer. Attributes that do vary with document-format are assigned to Interpreter. Each Printer instance contains one or more Interpreter instances, selected by document-format. I know that IPP doesn't claim to be truly object-oriented. But I think considerations like this are important for a few reasons: - IPP looks object-oriented, with terms like Object, and attribute, and Operation bandied about. It will lead to confusion if the IPP model is anti-object-oriented. Let's not call Printer an object if it represents something other than what an object is commonly understood to be. - Many implementors are likely to use OO methods. (How about a poll of current implementors?) It would sure be nice if the IPP model could map easily to an OO design and implementation. - Although an implementor's design could split up these classes internally and still meet the existing spec, there is some value in having the implemenation, the design, and the model trace cleanly back to the real world. -Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=3867 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Tue Jul 21 09:20:19 1998 Delivery-Date: Tue, 21 Jul 1998 09:20:24 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04135 for ; Tue, 21 Jul 1998 09:20:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA09373 for ; Tue, 21 Jul 1998 09:20:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id JAA16051 for ; Tue, 21 Jul 1998 09:19:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 09:06:44 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA15505 for ipp-outgoing; Tue, 21 Jul 1998 09:00:32 -0400 (EDT) Date: 21 Jul 1998 13:00:21 -0000 Message-ID: <19980721130021.2730.qmail@m2.findmail.com> From: "Rajesh Chawla" Subject: IPP> Question about Job Template Attributes To: ipp@pwg.org Sender: owner-ipp@pwg.org Hi folks, In the Job Template Attributes there are attributes that can be a type3 keyword or a name (job-hold-until, job-sheets, and media). As I read the spec, these attributes are usually type3 keywords but can optionally be changed at the printer to a name type. Is this correct or did I miss something in the spec? My question is how does an IPP client know which type to send? If the wrong type is sent, what should the expected reply be? Regards, Rajesh From ipp-owner@pwg.org Tue Jul 21 11:31:32 1998 Delivery-Date: Tue, 21 Jul 1998 11:31:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA05229 for ; Tue, 21 Jul 1998 11:31:31 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10353 for ; Tue, 21 Jul 1998 11:31:25 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA16792 for ; Tue, 21 Jul 1998 11:31:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 11:26:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA16235 for ipp-outgoing; Tue, 21 Jul 1998 11:23:33 -0400 (EDT) Date: 21 Jul 1998 15:23:28 -0000 Message-ID: <19980721152328.26817.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: IPP> Question about Job Template Attributes In-Reply-To: <19980721130021.2730.qmail@m2.findmail.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org > Hi folks, > > In the Job Template Attributes there are attributes > that can be a type3 keyword or a name (job-hold-until, > job-sheets, and media). As I read the spec, these > attributes are usually type3 keywords but can optionally > be changed at the printer to a name type. Is this > correct or did I miss something in the spec? My understanding, based on my reading of the spec and questions I've asked here in the past: Those attributes can be typed, and tagged as any of the following: 0x36 nameWithLanguage 0x42 nameWithoutLanguage 0x44 keyword In general, an IPP Object may send any one of the three types, and must accept any one of the three. However, for any 'name' attribute in the request that is in a different natural language than the value supplied in the "attributes-natural-language", the sender must use the nameWithLanguage form. Type 3 keywords have standard, registered values. If the wrong type is sent in a request, according to MOD section 16.4.3, the response should be 'client-error-request-value-too-long'. Quote: "IF NOT any single 'keyword' or 'name' value less than or equal to 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.") > My question is how does an IPP client know which > type to send? If the wrong type is sent, what should > the expected reply be? > > Regards, > Rajesh > > > -Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=4166 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Tue Jul 21 14:14:23 1998 Delivery-Date: Tue, 21 Jul 1998 14:14:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01082 for ; Tue, 21 Jul 1998 14:14:18 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00617 for ; Tue, 21 Jul 1998 14:13:52 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA17810 for ; Tue, 21 Jul 1998 14:13:50 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 14:06:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17216 for ipp-outgoing; Tue, 21 Jul 1998 14:00:34 -0400 (EDT) Content-return: allowed Date: Tue, 21 Jul 1998 09:53:46 PDT From: "Zehler, Peter " Subject: IPP> IPP Bake-off: Date, Location and attendees (preliminary) To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, The target date for the IPP bake-off is the week of September 14th. (We will pin down the details in one of our IPP phone conferences) Microsoft has offered to host the event. They have offered: 1. A large room with power and a LAN (say 20 taps). 2. A DHCP server (if needed ?) 3. Food 4. A visit to the company store 5. September sunshine (if we get lucky) For no charge The organizations that have publicly announced their intention to participate in the IPP bake-off are: Auco IBM Lexmark Microsoft Novell Sun TRCS Xerox Any organizations that might be able to participate in the September IPP bake-off please contact me. We need to get the official participation count to Microsoft so they may arrange the appropriate size facilities We will have multiple clients, printers and test suites. I will be updating the IPP test plan and soliciting input from individuals known to be engaged in pair-wise testing. Pete Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Tue Jul 21 14:40:47 1998 Delivery-Date: Tue, 21 Jul 1998 14:40:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01316 for ; Tue, 21 Jul 1998 14:40:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA00837 for ; Tue, 21 Jul 1998 14:40:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA18535 for ; Tue, 21 Jul 1998 14:40:38 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 14:36:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17960 for ipp-outgoing; Tue, 21 Jul 1998 14:31:30 -0400 (EDT) Content-return: allowed Date: Tue, 21 Jul 1998 10:31:57 PDT From: "Zehler, Peter " Subject: IPP> Official IPP Implementers Contact List To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, Here is the list of contacts for IPP implementations at various organizations. Please let me know if I have overlooked someone or made a mistake. This table is also available from our PWG server at ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Implementers-contact-list.pdf Pete Company Contact Email Allegro Robert Van Andel bva@allegrosoft.com Apple David Pond pond2@apple.com Astart Patrick Powell papowell@astart.com Auco Peter Michalek peterm@shinesoft.com Digital Products Bill Wagner wwagner@digprod.com EFI Jason Chien-Hung Chen Jason.Chen@eng.efi.com Emulex Bob Nixon bob.nixon@emulex.com IBM Steve Gebert stevegeb@us.ibm.com Carl Kugler kugler@us.ibm.com Novell Hugo Parra hparra@novell.com Ricoh Tetsuya Morita tetsu@spdd.ricoh.co.jp TRCS Rajesh Chawla rajesh@trcs.com Underscore Jay Martin jkm@underscore.com Xerox Peter Zehler peter.zehler@usa.xerox.com Xavier Riley xriley@cp10.es.xerox.com Fuji Xerox Shin Ohtake shin.ohtake@fujixerox.co.jp Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Tue Jul 21 16:16:05 1998 Delivery-Date: Tue, 21 Jul 1998 16:16:09 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02772 for ; Tue, 21 Jul 1998 16:16:04 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA01507 for ; Tue, 21 Jul 1998 16:15:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA20260 for ; Tue, 21 Jul 1998 16:15:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 16:11:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19688 for ipp-outgoing; Tue, 21 Jul 1998 16:05:10 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C58@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'ipp@pwg.org'" Subject: IPP> ADM - No phone conference this week Date: Tue, 21 Jul 1998 13:02:15 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org All, There does not seem to be any real hot subjects to discuss just now, so I decided not hold a phone conference this week. I expect that we will have reason to hold one next week to discuss further details about the bake-off. Further feedback from the IESG will not happen until after their July 30 phone meeting. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Jul 21 18:37:43 1998 Delivery-Date: Tue, 21 Jul 1998 18:37:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA03770 for ; Tue, 21 Jul 1998 18:37:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA02276 for ; Tue, 21 Jul 1998 18:37:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA21384 for ; Tue, 21 Jul 1998 18:37:37 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 21 Jul 1998 18:31:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA20796 for ipp-outgoing; Tue, 21 Jul 1998 18:20:36 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C5F@X-CRT-ES-MS1> From: "Manros, Carl-Uno B" To: "'ipp@pwg.org'" Subject: IPP> ADM - Minutes from PWG PP Meeting in Monterey - July 8-9, 1998 Date: Tue, 21 Jul 1998 15:17:33 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03770 1 Internet Printing Protocol - July 8-9, 1998 2 Attendees David Pond Apple Lee Farrell Canon Information Systems Ron Bergman Data Products Shivaun Albright Hewlett Packard Brian Batchelder Hewlett Packard Alan Berkema Hewlett Packard Sandra Matts Hewlett Packard Ken Oakeson Hewlett Packard Kris Schoff Hewlett Packard Harry Lewis IBM Yuji Sasaki Japan Computer Industry Stuart Rowley Kyocera Don Wright(4) Lexmark Paul Moore Microsoft Hugo Parra Novell William Wagner Osicom Charles Quan Kong Panasonic Atsushi Uchino Seiko Epson Randy Turner Sharp Anthony Fung ST Microelectronics Tom Hastings Xerox Carl-Uno Manros Xerox Xavier Riley Xerox Rick Yardumian Xerox Pete Zehler Xerox 3 Administrivia Don Wright provided details for the next PWG meeting: · August 17-21 · Toronto Marriott at Eaton Centre · 525 Bay Street · Toronto, Ontario, Canada M5G 2L2 · $175CN (about $120 US) · Deadline is July 24, 1998 Future PWG meeting schedules will have the following structure: · MIB meetings on Tuesday evenings (if needed) · PWG Plenary on Wednesday mornings · IPP meetings on Wednesday afternoon and Thursday morning · SDP meetings on Thursday afternoon · UPD meetings on Friday The PWG meeting calendar for 1999 will be discussed at the next meeting in Toronto. A first draft of dates and locations will be generated for review and evaluation. Carl Uno-Manros opened the IPP meeting. He presented the meeting goals and proposed agenda topics: · Discuss Keith Moore's (IETF Application Area Director) comments on IPP draft documents · Reactivate us on the registration of Printer MIB document types as MIME types · Microsoft's proposal to register IPP extra operations · Discuss plans for IPP interoperability testing · Agenda for August IETF Plenary · Discuss Implementor's Guide activities for IPP · Discuss a question from the IFAX group: Would the IPP group be prepared to write a mapping document for IPP to IFAX? · MIB access over IPP · IPP Notifications Carl-Uno noted that it is unlikely that we will be able to address all the above topics. The first item is the most important (and will probably occupy most-if not all-of the meeting.) 4 IESG Obstacles on IPP drafts It was suggested that the PWG group needs to consider their position on the IPP standards independently of the IETF views and opinions. It was noted that the PWG members seem to have reached agreement - only the IETF/IESG has any objections to the latest draft documents. One person raised the question about whether the group would consider moving forward with the IPP standard without IETF support. "What does it take to determine when the IPP v1.0 effort will be completed?" Someone voiced his frustration with the IETF and strongly suggested that the PWG group split from IETF control. [A lively discussion ensued, accompanied by a free flow of ideas and opinions.] During the discussion, Randy Turner said that he has received a private e-mail that suggests there will be another objection to the IPP documents with regard to security. He was not willing to provide more details. He believes that there might be a minimal security requirement that may be raised. Shivaun Albright pointed out that the IETF has provided useful technical guidance. She is concerned about the possible negative press that would result from the PWG splitting from the IETF. The group is very concerned that the IETF process (and possible additional objections by the IESG) may delay the process much more. Carl-Uno believes that the IESG will formally review the documents in the next three weeks. As a result of that meeting, he believes that they will provide a complete list of the outstanding problems. "Why can't we just get to the stage of Proposed (Draft) Standard, and choose to implement them as written?" (And not wait for total agreement from the IETF/IESG.) How about if we just put the word "SHOULD" for including the ipp:// scheme in the specification, and agree not to implement it? Carl-Uno suggested that people should write to Keith Moore and explain that they have implemented the current set of documents. Perhaps this will help to persuade him (and the IESG) to accept the documents as is. Three alternatives were identified: · split with the IETF · wait for the full IETF process · implement what we have now, and wait for the process to continue - decide later to change if necessary An attempt was made to obtain a consensus opinion on which decision the group wants to follow. Although a formal vote was not taken, it seemed that several people feel that we should still abide by the IETF/IESG decisions. The group agreed that no one should implement the ipp:// scheme until agreement has been reached within the IETF. The group then decided to spend the afternoon drafting a response to Keith Moore. It was suggested that we develop a document that includes the requested changes from Keith Moore, but also explains why the PWG members disagree with them. 5 IPP Scheme Carl-Uno provided a summary of what he understands that Keith Moore requires for the use of the ipp scheme. Whenever a URL is viewed or used by a user, it should be "ipp://" to refer to a printer. Also, the ipp scheme should be used for the MIME content type. However, Carl-Uno believes that we can use http:// when communicating to the server. The group reviewed a proposal from Randy Turner that was sent to the e-mail list on June 16. Various changes were suggested and will be included in an updated proposal response to Keith Moore. There were several comments speculating on exactly what Keith Moore believes. (Unfortunately, he was not present to explain his position.) An e-mail excerpt from Keith Moore was referenced to help clarify his position: There was much concern about the apparent contradiction of requiring that servers support "a full IPP URL" even though no client implementation is allowed to use them. There was repeated discussion about whether this is a reasonable concern. Two individuals strongly suggested that this requirement should be removed. As a compromise, it was left as a SHOULD instead of a MUST. 6 IPP Scheme in the Body Keith Moore also says that any URL in the body content that references an IPP Printer should use the ipp:// scheme. 7 Security What happens for translating ipp:// to http:// if security is desired? How does the new scheme for ipp indicate security? How will a process determine if an IPP URL should be mapped to http:// or https://? If it is mandated that ipp:// is used, how can an IPP Printer indicate that it should be contacted using https://? No clear conclusion was reached for any of these issues. Randy said that the IETF would be very happy if IPP included SASL. Carl-Uno said that if we did, it would further delay things by a few months. [More heated exchange of opinions.] --- "Cooling-off" break --- Paul Moore summarized an informal conversation that was held during the break: Several people feel that a "half-way, pseudo-scheme compromise" (as currently considered in the modified proposal) will encounter many problems as we dig deeper into the details. We really need to choose to use a "pure" ipp:// scheme or a "pure" http:// scheme-not the proposed "compound" scheme. By convincing the IESG that a compound scheme is not practical, the group believes that the IESG will agree to using http:// rather than forcing us to start all over and develop a completely new scheme. The group again agreed that we should continue to develop a document that addresses the requested changes from Keith Moore, but also explains why the PWG members believe it will not work. The group believes that this approach will be useful to prove that we did our "due diligence" in attempting to meet the suggestions from Keith Moore. However, after serious consideration, the group has found that the suggestions do not produce a viable solution for achieving the protocol. The group generated a list of several problems with the proposal (included at the end of the modified proposal-see below.) 8 Proposal Update - continued The next day, the group participated in a review of some modifications to the proposal that Randy had made the night before. There was much debate about Randy's proposal for including a security parameter in a URL scheme. Several attendees were concerned that the IESG would not accept a parameterized URL scheme. No one was aware of any precedent for this concept, and a few people suggested that defining such a parameterized scheme should be done outside the IPP WG. Additional modifications to the proposal resulted in the following document: IPP Working Group Analysis of Proposed IPP URL Scheme ---------------------------------------------------------------------- Introduction The IETF Applications Area Director has proposed that the IPP working group consider creating a new URL scheme, "ipp:", to reference IPP objects, as defined in the IPP Model Document. The IPP working group has created a usage model of how a potential IPP URL would be used, if implemented and deployed. This usage model is included in this document analysis, for completeness. A subsequent analysis of the usage model for this new scheme has exposed some critical issues and concerns that the IPP working group has with the proposed "ipp:" scheme. Considering the impact of these issues, the working group feels that the integration of a new URL scheme into the IPP model and protocol specifications is not feasible at this time. Usage Model for "ipp" Scheme ----------------------------------------------------------------------- In its current definition, IPP uses HTTP 1.1 as a transport protocol, and hence uses the existing "http:" URL scheme, in which URL path names and MIME types are used to multiplex and demultiplex IPP from the HTTP protocol data stream. The conventional model for the introduction of a new protocol scheme assumes that the URL scheme maps directly to an application protocol, network transport protocol and default transport "port number". Typically, this transport protocol includes a multiplexing/demultiplexing capability based on the idea of a port number (e.g., TCP, UDP). The working group considered using the "ipp:" URL scheme using the conventional model, but the current HTTP infrastructure (existing HTTP 1.1 servers and proxies) does not understand "ipp:" URLs, and would not reliably transport HTTP messages containing headers that reference "ipp:" URLs. We finally considered a "compound" URL scheme, wherein a translation from "ipp:" to "http:" URL schemes is performed. The syntax for the new IPP scheme is identical to the existing "http" scheme except for the scheme name itself. The similarity is maintained to ease the IPP-to-HTTP translation burden: ipp://host[:port]/ Associated with this new IPP scheme is an IANA-assigned TCP port number, 631, which is the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. The implementation impact of using the new scheme on the existing specifications is divided into two key areas: HTTP headers and the application/ipp MIME body part. ------------------------------------------------------ HTTP Header Usage ------------------------------------------------------ When an IPP client obtains an IPP URL, the interpretation (translation) of this URL by the client can take one of two forms, depending upon whether the client is configured to use an HTTP 1.1 proxy server. IPP Client Configured with no proxy server ------------------------------------------------------ When an IPP client (no proxy configured) obtains an "ipp:" URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... IPP Client Configured for Proxy Service ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:8080 Content-type: application/ipp Transfer-Encoding: chunked ... Existing proxies will not understand IPP URLs, so the RequestURI MUST use the HTTP form of the URL. After proxy processing, the proxy would connect to the IPP origin server with headers that are the same as the "no-proxy" example above. IPP/HTTP Server Implications ------------------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP origin servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers MUST accept "full" URLs as well, so IPP servers MUST also be able to accept a requestURI as specified in #2 as well. Also, IPP servers SHOULD be able to accept a full requestURI as specified in #3 below. Servers MUST interpret all of the forms below as equivalent. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) NOTE: Example #3 is included to support the possible future deployment of IPP services that utilize full IPP requestURIs. Currently, this specification does not allow clients to generate full IPP requestURIs. In all forms of "ipp" URL translation, if an explicit port number is specified then this port number MUST be used by the clients and proxies to initiate connections to IPP/HTTP origin servers. ------------------------------------------------- application/ipp MIME body ------------------------------------------------- Printer and job URI attributes in the protocol MUST utilize the "ipp" scheme. The application/ipp body part contains the following URI components that are affected: job attributes - job-uri job-printer-uri printer attributes - printer-uri-supported operation attributes - job-uri printer-uri Other URI attributes in the protocol can contain any number of different URL schemes, e.g., document-uri, printer-more-info, and are not affected by the "ipp" scheme. ------------------------------------------------------------------- Summary Conclusions ------------------------------------------------------------------- The IPP working group has serious concerns regarding integrating a new "ipp:" URL into our specifications. The following issues have been raised with regards to usage of the "ipp:" scheme. 1. There is currently no defined way for a single "ipp:" URL to indicate whether or not a particular IPP server offers "secure" connections. Throughout the IPP model document, numerous assumptions are made with regards to our usage of the "http:" URL to reference IPP objects, chief among these assumptions is that IPP clients treat URL syntax beyond the "host" part of an HTTP URL as opaque. The IPP working group feels that any specification for security parameters within URL syntax should be a "standard" solution and not specifically a "one-off" or one-time only solution for IPP. The effort required to put together a group or effort to accomplish this is out-of-scope for our current charter. 2. There is no straightforward way to configure HTTP client proxy capability for "proxying" IPP. Currently, there are specific proxy configuration options for HTTP clients, such as FTP, GOPHER, HTTP, WAIS, etc. There is no option for proxying "ipp:" URLs and this deficiency could lead to confusion for the end user. Also, to correctly configure a proxy service for IPP, the user will have to "know" that IPP actually uses HTTP, and that for IPP proxy service the user must configure an HTTP proxy. 3. Similar to the end-user configuration problem in #2 above, there is currently no proxy configuration option for IPP proxy in existing proxy server software. IPP will be a "special case" wherein the administrator will have to know the special relationship between IPP URLs and HTTP URLs. 4. Future use of the "ipp" scheme is compromised by using the new "ipp" scheme in the translated form implied by the proposed "ipp:" scheme. The IPP working group would like to reserve use of the "ipp" scheme for a pure IPP client/server protocol implementation in the future (one that does not require utilization of an existing HTTP infrastructure). In this environment, it seems appropriate to attach the "ipp" URL to this future protocol, rather than the initial IPP protocol that is just carried in a MIME type within HTTP. For example, in a future implementation of an IPP scheme that does not utilize HTTP, existing IPP clients would still attempt to translate the "ipp:" scheme into an "http:" scheme, and would do so incorrectly, since the future "ipp:" scheme protocol might not use HTTP as a transport. 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme and transparently translating it to an "http:" scheme An initial concern was the fact that there was no way to tell that IPP was actually being used by looking at an HTTP URL. However, publishing and using only IPP URLs to the user and administrator community might hide the fact that IPP is actually using HTTP. 6. Compound schemes is a new idea and not well understood in its' ramifications. In the current IANA registry for URL schemes, there are no examples that indicate that scheme "translation" to another scheme is required. 7. All applications that include URI/URL recognition features will have to be updated to include support for the new "ipp:" URL. 8. Existing network infrastructure tools and utilities would need to be modified in order to understand the "special" relationship between IPP and HTTP URLs. The working group considers IPP printing an "HTTP application", and therefore the usage of an "ipp:" URL scheme must maintain a special relationship with "http:" URLs. The definition of such a "compound" URL scheme, wherein an "ipp:" scheme is layered or translated to an "http:" scheme, is somewhat unusual, and the impact of such a definition on the protocol design and deployment is not generally well understood. This analysis document has identified a partial list of issues regarding the integration of the new "ipp:" scheme. It is anticipated that other unforeseen issues exist, since this technique has not been prototyped. If the usage model described herein were adopted, these issues raised in this analysis pose a significant negative impact on the implementation and deployment of current IPP specifications, as well as potential interoperability with future revisions of the protocol. This document will be forwarded to the IESG. 9 Interoperability Testing Pete Zehler announced that 13 companies (of 35 companies contacted) have said they are willing to make an announcement about their current status with regard IPP development. The other companies either have not responded, or prefer to keep their status private. Connectivity issues and bugs in implementations seem to be the major activity being addressed in the pair-wise testing that is currently occurring. More testing has occurred, but the participants continue to guard their activity results. Pete believes that an interoperability "bake-off" might be achievable some time in September, or later in the year. A major concern is having sufficient test tools to support such an effort. It was suggested that a poll should be taken to see which vendors are ready (or would be willing) to participate in an interoperability test within the next several weeks. Xerox, IBM, Microsoft, and Lexmark all said that they are willing and able to participate in a bake-off on September 15. Pete will send out a list of company status and contact points. He will also send out a request for additional participants for a September 15 bake-off. All implementations will be based on the June 30 specification documents. It was estimated that the bake-off would last three days. 10 IETF Plenary Meeting Agenda Carl-Uno asked what should be planned for the IPP session during the next IETF Plenary in August. After a short discussion, the following topics were suggested: · Status review · Implementation progress · Discussion of open issues based on IESG feedback 11 Implementers Guide Several participants agreed that we should document clarifications and "lessons learned" from IPP implementation efforts. Carl-Uno volunteered to collect material for this document. He also said that he would update the FAQ document. 12 A Mapping Document for IPP to IFAX Carl-Uno asked if anyone would be willing to write a mapping document from IPP to IFAX. One suggestion was that Larry Masinter (who made the request) should provide more information on what he envisions. Harry Lewis said that he would be interested in talking with Larry about this. IPP Meeting adjourned --- My cincere thanks to Lee Farrell for taking the notes. Please note that later discussion with Keith Moore seems to make it quite clear that there is an ipp:// scheme in IPP's future. Further feedback expected from the IESG after their July 30 meeting. Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jul 22 14:57:46 1998 Delivery-Date: Wed, 22 Jul 1998 14:57:47 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17705 for ; Wed, 22 Jul 1998 14:57:45 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA06942 for ; Wed, 22 Jul 1998 14:57:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA29642 for ; Wed, 22 Jul 1998 14:57:35 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Jul 1998 14:47:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29047 for ipp-outgoing; Wed, 22 Jul 1998 14:43:39 -0400 (EDT) Date: Wed, 22 Jul 1998 11:55:52 -0700 (PDT) From: papowell@astart.com Message-Id: <199807221855.LAA09981@astart4.astart.com> To: IPP@pwg.org, Peter.Zehler@usa.xerox.com Subject: Re: IPP> IPP Bake-off: Date, Location and attendees (preliminary) Sender: owner-ipp@pwg.org > From ipp-owner@pwg.org Tue Jul 21 11:22:41 1998 > Date: Tue, 21 Jul 1998 09:53:46 PDT > From: "Zehler, Peter " > Subject: IPP> IPP Bake-off: Date, Location and attendees (preliminary) > To: "IPP Discussion List (E-mail)" > > All, > The target date for the IPP bake-off is the week of September 14th. (We > will pin down the details in one of our IPP phone conferences) > Microsoft has offered to host the event. They have offered: > 1. A large room with power and a LAN (say 20 taps). > 2. A DHCP server (if needed ?) > 3. Food > 4. A visit to the company store > 5. September sunshine (if we get lucky) > For no charge Just where is this place? > > The organizations that have publicly announced their intention to > participate in the IPP bake-off are: > Auco > IBM > Lexmark > Microsoft > Novell > Sun > TRCS > Xerox > Any organizations that might be able to participate in the September IPP > bake-off please contact me. We need to get the official participation count > to Microsoft so they may arrange the appropriate size facilities > > We will have multiple clients, printers and test suites. > I will be updating the IPP test plan and soliciting input from individuals > known to be engaged in pair-wise testing. > > Pete > > > > Peter Zehler > XEROX > Networked Products Business Unit > Email: Peter.Zehler@usa.xerox.com > Voice: (716) 265-8755 > FAX: (716) 265-8792 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 111-02J > Webster NY, 14580-9701 > > > From ipp-owner@pwg.org Wed Jul 22 18:08:07 1998 Delivery-Date: Wed, 22 Jul 1998 18:08:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA20518 for ; Wed, 22 Jul 1998 18:08:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA08162 for ; Wed, 22 Jul 1998 18:07:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA00740 for ; Wed, 22 Jul 1998 18:08:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Jul 1998 18:02:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA00152 for ipp-outgoing; Wed, 22 Jul 1998 17:56:26 -0400 (EDT) Message-ID: From: Paul Moore To: "'papowell@astart.com'" , IPP@pwg.org, Peter.Zehler@usa.xerox.com Subject: RE: IPP> IPP Bake-off: Date, Location and attendees (preliminary) Date: Wed, 22 Jul 1998 14:50:51 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org Redmond, WA > -----Original Message----- > From: papowell@astart.com [SMTP:papowell@astart.com] > Sent: Wednesday, July 22, 1998 11:56 AM > To: IPP@pwg.org; Peter.Zehler@usa.xerox.com > Subject: Re: IPP> IPP Bake-off: Date, Location and attendees > (preliminary) > > > From ipp-owner@pwg.org Tue Jul 21 11:22:41 1998 > > Date: Tue, 21 Jul 1998 09:53:46 PDT > > From: "Zehler, Peter " > > Subject: IPP> IPP Bake-off: Date, Location and attendees (preliminary) > > To: "IPP Discussion List (E-mail)" > > > > All, > > The target date for the IPP bake-off is the week of September 14th. (We > > will pin down the details in one of our IPP phone conferences) > > Microsoft has offered to host the event. They have offered: > > 1. A large room with power and a LAN (say 20 taps). > > 2. A DHCP server (if needed ?) > > 3. Food > > 4. A visit to the company store > > 5. September sunshine (if we get lucky) > > For no charge > > Just where is this place? > > > > > The organizations that have publicly announced their intention to > > participate in the IPP bake-off are: > > Auco > > IBM > > Lexmark > > Microsoft > > Novell > > Sun > > TRCS > > Xerox > > Any organizations that might be able to participate in the September IPP > > bake-off please contact me. We need to get the official participation > count > > to Microsoft so they may arrange the appropriate size facilities > > > > We will have multiple clients, printers and test suites. > > I will be updating the IPP test plan and soliciting input from > individuals > > known to be engaged in pair-wise testing. > > > > Pete > > > > > > > > Peter Zehler > > XEROX > > Networked Products Business Unit > > Email: Peter.Zehler@usa.xerox.com > > Voice: (716) 265-8755 > > FAX: (716) 265-8792 > > US Mail: Peter Zehler > > Xerox Corp. > > 800 Phillips Rd. > > M/S 111-02J > > Webster NY, 14580-9701 > > > > > > From ipp-owner@pwg.org Wed Jul 22 18:50:49 1998 Delivery-Date: Wed, 22 Jul 1998 18:50:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA20841 for ; Wed, 22 Jul 1998 18:50:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA08345 for ; Wed, 22 Jul 1998 18:50:39 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01438 for ; Wed, 22 Jul 1998 18:50:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 22 Jul 1998 18:47:01 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00889 for ipp-outgoing; Wed, 22 Jul 1998 18:41:45 -0400 (EDT) Content-return: allowed Date: Wed, 22 Jul 1998 11:17:26 PDT From: "Zehler, Peter " Subject: IPP> IPP Bake-off update and a good rule To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, There is a problem getting facilities the week of September 14 for the IPP Bake-off. The date has been moved to September 7, 8, and 9 at Microsoft in Redmond WA. Don has also pointed out a basic rule from the printer MIB Bake-off. That rule is: "If you don't show me yours, you can't see mine." meaning that only those companies that are bringing products to be tested will be allowed to attend the bake-off. I assume this rule will also be used for the IPP Bake-off. Peter Zehler XEROX Networked Products Business Unit Email: Peter.Zehler@usa.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 111-02J Webster NY, 14580-9701 From ipp-owner@pwg.org Fri Jul 24 13:03:57 1998 Delivery-Date: Fri, 24 Jul 1998 13:03:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21701 for ; Fri, 24 Jul 1998 13:03:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18072 for ; Fri, 24 Jul 1998 13:03:46 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA29845 for ; Fri, 24 Jul 1998 13:03:55 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 12:57:35 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA29287 for ipp-outgoing; Fri, 24 Jul 1998 12:52:54 -0400 (EDT) Date: 24 Jul 1998 16:51:43 -0000 Message-ID: <19980724165143.21038.qmail@m2.findmail.com> From: "Carl Kugler" Subject: IPP> Implementation question re.: chunking To: ipp@pwg.org Sender: owner-ipp@pwg.org draft-ietf-ipp-protocol-06.txt says the client and server MUST support the "chunked" transfer encoding when receiving. My question is: Can we count on this? I.e., if our client always transmits requests using the "chunked" transfer encoding, will we be able to interoperate with the vast majority of IPP server implementations? -Carl From ipp-owner@pwg.org Fri Jul 24 13:16:44 1998 Delivery-Date: Fri, 24 Jul 1998 13:16:44 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21824 for ; Fri, 24 Jul 1998 13:16:43 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18166 for ; Fri, 24 Jul 1998 13:16:33 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA00987 for ; Fri, 24 Jul 1998 13:16:40 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 13:12:38 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00115 for ipp-outgoing; Fri, 24 Jul 1998 13:09:12 -0400 (EDT) Message-Id: <199807241713.KAA07045@mail.pacifier.com> X-Sender: rturner@webmail.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 24 Jul 1998 10:05:26 -0700 To: "Carl Kugler" From: Randy Turner Subject: Re: IPP> Implementation question re.: chunking Cc: ipp@pwg.org In-Reply-To: <19980724165143.21038.qmail@m2.findmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org At 04:51 PM 7/24/98 +0000, you wrote: >draft-ietf-ipp-protocol-06.txt says the client and server MUST support the "chunked" transfer encoding when receiving. My question is: Can we count on this? I.e., if our client always transmits requests using the "chunked" transfer encoding, will we be able to interoperate with the vast majority of IPP server implementations? > > -Carl There are no vast majority of IPP server implementations (yet). I think the only worry is if someone plans to deploy IPP behind a generic web server that doesn't support chunking. However, Apache and most other of the more popular HTTP/1.1 servers will support this. It should definitely be a bullet item (checkoff item) at the upcoming bake-off, however. Randy > From ipp-owner@pwg.org Fri Jul 24 13:27:25 1998 Delivery-Date: Fri, 24 Jul 1998 13:27:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21908 for ; Fri, 24 Jul 1998 13:27:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18289 for ; Fri, 24 Jul 1998 13:27:14 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA01652 for ; Fri, 24 Jul 1998 13:27:22 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 13:22:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00995 for ipp-outgoing; Fri, 24 Jul 1998 13:16:45 -0400 (EDT) Message-ID: <194C28463877D111A2A100805F15CE85409C87@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: "'Carl Kugler'" , ipp@pwg.org Subject: RE: IPP> Implementation question re.: chunking Date: Fri, 24 Jul 1998 10:13:44 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Carl, I think this is a good example of the things that we need to put in an Implementor's Guide document. Formally, as we are referencing IETF's HTTP 1.1, all IPP implementations MUST support "chunking". However, I think it would be smart for an actual implementation to also support using HTTP 1.0 to allow for maximum interoperability. E.g. in Xerox we have had to base our current client code (written in Java) on HTTP 1.0, as the JavaSoft libraries do not yet support some of the HTTP 1.1 features. These problems will disappear over time, but we also need to get things working short term. Carl-Uno > -----Original Message----- > From: Carl Kugler [mailto:kugler@us.ibm.com] > Sent: Friday, July 24, 1998 9:52 AM > To: ipp@pwg.org > Subject: IPP> Implementation question re.: chunking > > > draft-ietf-ipp-protocol-06.txt says the client and server > MUST support the "chunked" transfer encoding when receiving. > My question is: Can we count on this? I.e., if our client > always transmits requests using the "chunked" transfer > encoding, will we be able to interoperate with the vast > majority of IPP server implementations? > > -Carl > From ipp-owner@pwg.org Fri Jul 24 13:32:46 1998 Delivery-Date: Fri, 24 Jul 1998 13:32:46 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA21951 for ; Fri, 24 Jul 1998 13:32:46 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18317 for ; Fri, 24 Jul 1998 13:32:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA02267 for ; Fri, 24 Jul 1998 13:32:42 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 13:28:37 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01417 for ipp-outgoing; Fri, 24 Jul 1998 13:25:12 -0400 (EDT) Message-ID: From: Paul Moore To: "'Randy Turner'" , Carl Kugler Cc: ipp@pwg.org Subject: RE: IPP> Implementation question re.: chunking Date: Fri, 24 Jul 1998 10:24:54 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org You might find that some implementations dont support chunking. > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Friday, July 24, 1998 10:05 AM > To: Carl Kugler > Cc: ipp@pwg.org > Subject: Re: IPP> Implementation question re.: chunking > > At 04:51 PM 7/24/98 +0000, you wrote: > >draft-ietf-ipp-protocol-06.txt says the client and server MUST support > the > "chunked" transfer encoding when receiving. My question is: Can we count > on this? I.e., if our client always transmits requests using the > "chunked" > transfer encoding, will we be able to interoperate with the vast majority > of IPP server implementations? > > > > -Carl > > > There are no vast majority of IPP server implementations (yet). I think > the > only worry is if someone plans to deploy IPP behind a generic web server > that doesn't support chunking. However, Apache and most other of the more > popular HTTP/1.1 servers will support this. It should definitely be a > bullet item (checkoff item) at the upcoming bake-off, however. > > Randy > > > From ipp-owner@pwg.org Fri Jul 24 13:58:14 1998 Delivery-Date: Fri, 24 Jul 1998 13:58:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22113 for ; Fri, 24 Jul 1998 13:58:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA18454 for ; Fri, 24 Jul 1998 13:58:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA04180 for ; Fri, 24 Jul 1998 13:57:59 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 13:54:00 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03221 for ipp-outgoing; Fri, 24 Jul 1998 13:49:43 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Implementation question re.: chunking Date: Fri, 24 Jul 1998 10:48:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Well, I'm assuming since we "last-call'd" these documents in the WG, that everybody is in agreement that an implementation that doesn't support chunking isn't compliant. Randy -----Original Message----- From: Paul Moore [mailto:paulmo@microsoft.com] Sent: Friday, July 24, 1998 10:25 AM To: 'Randy Turner'; Carl Kugler Cc: ipp@pwg.org Subject: RE: IPP> Implementation question re.: chunking You might find that some implementations dont support chunking. > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Friday, July 24, 1998 10:05 AM > To: Carl Kugler > Cc: ipp@pwg.org > Subject: Re: IPP> Implementation question re.: chunking > > At 04:51 PM 7/24/98 +0000, you wrote: > >draft-ietf-ipp-protocol-06.txt says the client and server MUST support > the > "chunked" transfer encoding when receiving. My question is: Can we count > on this? I.e., if our client always transmits requests using the > "chunked" > transfer encoding, will we be able to interoperate with the vast majority > of IPP server implementations? > > > > -Carl > > > There are no vast majority of IPP server implementations (yet). I think > the > only worry is if someone plans to deploy IPP behind a generic web server > that doesn't support chunking. However, Apache and most other of the more > popular HTTP/1.1 servers will support this. It should definitely be a > bullet item (checkoff item) at the upcoming bake-off, however. > > Randy > > > From ipp-owner@pwg.org Fri Jul 24 14:42:21 1998 Delivery-Date: Fri, 24 Jul 1998 14:42:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23045 for ; Fri, 24 Jul 1998 14:42:20 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA18738 for ; Fri, 24 Jul 1998 14:42:11 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA04892 for ; Fri, 24 Jul 1998 14:42:18 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 14:37:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04327 for ipp-outgoing; Fri, 24 Jul 1998 14:33:32 -0400 (EDT) Message-ID: From: Paul Moore To: "'Turner, Randy'" , "'ipp@pwg.org'" Subject: RE: IPP> Implementation question re.: chunking Date: Fri, 24 Jul 1998 11:33:19 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org I dont see where it says that a server must support chunking. It says I must support 1.1. Maybe I am reading it wrong (I guess thats why we have bake-offs) > -----Original Message----- > From: Turner, Randy [SMTP:rturner@sharplabs.com] > Sent: Friday, July 24, 1998 10:48 AM > To: 'ipp@pwg.org' > Subject: RE: IPP> Implementation question re.: chunking > > > Well, I'm assuming since we "last-call'd" these documents in the WG, > that everybody is in agreement that an implementation that doesn't > support chunking isn't compliant. > > Randy > > > -----Original Message----- > From: Paul Moore [mailto:paulmo@microsoft.com] > Sent: Friday, July 24, 1998 10:25 AM > To: 'Randy Turner'; Carl Kugler > Cc: ipp@pwg.org > Subject: RE: IPP> Implementation question re.: > chunking > > You might find that some implementations dont support > chunking. > > > -----Original Message----- > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > Sent: Friday, July 24, 1998 10:05 AM > > To: Carl Kugler > > Cc: ipp@pwg.org > > Subject: Re: IPP> Implementation question re.: > chunking > > > > At 04:51 PM 7/24/98 +0000, you wrote: > > >draft-ietf-ipp-protocol-06.txt says the client and > server MUST support > > the > > "chunked" transfer encoding when receiving. My > question is: Can we count > > on this? I.e., if our client always transmits > requests using the > > "chunked" > > transfer encoding, will we be able to interoperate > with the vast majority > > of IPP server implementations? > > > > > > -Carl > > > > > > There are no vast majority of IPP server > implementations (yet). I think > > the > > only worry is if someone plans to deploy IPP behind a > generic web server > > that doesn't support chunking. However, Apache and > most other of the more > > popular HTTP/1.1 servers will support this. It should > definitely be a > > bullet item (checkoff item) at the upcoming bake-off, > however. > > > > Randy > > > > > From ipp-owner@pwg.org Fri Jul 24 15:16:37 1998 Delivery-Date: Fri, 24 Jul 1998 15:16:37 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24193 for ; Fri, 24 Jul 1998 15:16:37 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18977 for ; Fri, 24 Jul 1998 15:16:27 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA05570 for ; Fri, 24 Jul 1998 15:16:36 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 15:12:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04995 for ipp-outgoing; Fri, 24 Jul 1998 15:03:34 -0400 (EDT) Date: 24 Jul 1998 19:02:39 -0000 Message-ID: <19980724190239.9548.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Implementation question re.: chunking In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org Okay, as a practical matter it looks like we need to be able to support HTTP/1.0 in addition to HTTP/1.1, and "Content-Length" in addition to "Transfer-Encoding: chunked" whether sending or receiving. This leads me to my next question: What is the transition sequence for the cases in which an HTTP/1.1 client that normally uses chunking wants to make a request of a server that is HTTP/1.0 and/or doesn't understand chunking? Does this scenario look correct?: 1. Client requests HTTP/1.1, Transfer-Encoding: chunked 2. Server responds HTTP/1.0 501 (Unimplemented), and closes the connection 3. Client opens new connection and requests HTTP/1.0, Content-Length Also, don't some HTTP/1.0 implementations understand Transfer-Encoding as an extension? We have some client situations where we can't avoid chunking, so it would be nice if even the HTTP/1.0 servers understood chunked transfer coding. (Presumably all HTTP/1.1 applications are able to receive and decode the “chunked” transfer coding.) -Carl >You might find that some implementations dont support chunking. > > > -----Original Message----- > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > Sent: Friday, July 24, 1998 10:05 AM > > To: Carl Kugler > > Cc: ipp@pwg.org > > Subject: Re: IPP> Implementation question re.: chunking > > > > At 04:51 PM 7/24/98 +0000, you wrote: > > >draft-ietf-ipp-protocol-06.txt says the client and server MUST support > > the > > "chunked" transfer encoding when receiving. My question is: Can we count > > on this? I.e., if our client always transmits requests using the > > "chunked" > > transfer encoding, will we be able to interoperate with the vast majority > > of IPP server implementations? > > > > > > -Carl > > > > > > There are no vast majority of IPP server implementations (yet). I think > > the > > only worry is if someone plans to deploy IPP behind a generic web server > > that doesn't support chunking. However, Apache and most other of the more > > popular HTTP/1.1 servers will support this. It should definitely be a > > bullet item (checkoff item) at the upcoming bake-off, however. > > > > Randy > > > > > > > ----- Original Message: http://www.findmail.com/list/ipp/?start=4179 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Fri Jul 24 15:36:24 1998 Delivery-Date: Fri, 24 Jul 1998 15:36:25 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24738 for ; Fri, 24 Jul 1998 15:36:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19114 for ; Fri, 24 Jul 1998 15:36:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA06226 for ; Fri, 24 Jul 1998 15:36:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 15:32:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05668 for ipp-outgoing; Fri, 24 Jul 1998 15:30:16 -0400 (EDT) Date: 24 Jul 1998 19:29:18 -0000 Message-ID: <19980724192918.13710.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: IPP> Implementation question re.: chunking In-Reply-To: To: ipp@pwg.org Sender: owner-ipp@pwg.org HTTP/1.1 imlies chunking. Quote: draft-ietf-http-v11-spec-rev-03, "Hypertext Transfer Protocol -- HTTP/1.1", section 3.6.1, "Chunked Transfer Coding": "All HTTP/1.1 applications MUST be able to receive and decode the “chunked” transfer coding..." -Carl >I dont see where it says that a server must support chunking. It says I must > support 1.1. Maybe I am reading it wrong (I guess thats why we have > bake-offs) > > > -----Original Message----- > > From: Turner, Randy [SMTP:rturner@sharplabs.com] > > Sent: Friday, July 24, 1998 10:48 AM > > To: 'ipp@pwg.org' > > Subject: RE: IPP> Implementation question re.: chunking > > > > > > Well, I'm assuming since we "last-call'd" these documents in the WG, > > that everybody is in agreement that an implementation that doesn't > > support chunking isn't compliant. > > > > Randy > > > > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Friday, July 24, 1998 10:25 AM > > To: 'Randy Turner'; Carl Kugler > > Cc: ipp@pwg.org > > Subject: RE: IPP> Implementation question re.: > > chunking > > > > You might find that some implementations dont support > > chunking. > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Friday, July 24, 1998 10:05 AM > > > To: Carl Kugler > > > Cc: ipp@pwg.org > > > Subject: Re: IPP> Implementation question re.: > > chunking > > > > > > At 04:51 PM 7/24/98 +0000, you wrote: > > > >draft-ietf-ipp-protocol-06.txt says the client and > > server MUST support > > > the > > > "chunked" transfer encoding when receiving. My > > question is: Can we count > > > on this? I.e., if our client always transmits > > requests using the > > > "chunked" > > > transfer encoding, will we be able to interoperate > > with the vast majority > > > of IPP server implementations? > > > > > > > > -Carl > > > > > > > > > There are no vast majority of IPP server > > implementations (yet). I think > > > the > > > only worry is if someone plans to deploy IPP behind a > > generic web server > > > that doesn't support chunking. However, Apache and > > most other of the more > > > popular HTTP/1.1 servers will support this. It should > > definitely be a > > > bullet item (checkoff item) at the upcoming bake-off, > > however. > > > > > > Randy > > > > > > > > > ----- Original Message: http://www.findmail.com/list/ipp/?start=4181 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Fri Jul 24 17:33:55 1998 Delivery-Date: Fri, 24 Jul 1998 17:33:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA29220 for ; Fri, 24 Jul 1998 17:33:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA19838 for ; Fri, 24 Jul 1998 17:33:40 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07386 for ; Fri, 24 Jul 1998 17:33:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 17:27:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06839 for ipp-outgoing; Fri, 24 Jul 1998 17:24:26 -0400 (EDT) From: "Larry Masinter" To: "Carl Kugler" , Subject: RE: RE: IPP> Implementation question re.: chunking Date: Fri, 24 Jul 1998 14:23:56 PDT Message-ID: <002001bdb749$5dc180a0$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <19980724190239.9548.qmail@m2.findmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ipp@pwg.org > Okay, as a practical matter it looks like we need to be able to > support HTTP/1.0 in addition to HTTP/1.1, and "Content-Length" in > addition to "Transfer-Encoding: chunked" whether sending or receiving. > > This leads me to my next question: What is the transition sequence > for the cases in which an HTTP/1.1 client that normally uses chunking > wants to make a request of a server that is HTTP/1.0 and/or doesn't > understand chunking? There is no 'installed base' of IPP clients and servers which do not support HTTP/1.1. As a practical matter, it seems unreasonable to posit one or to create one. From owner-tcp-over-satellite@achtung.sp.trw.com Sun Jul 26 19:24:25 1998 Delivery-Date: Sun, 26 Jul 1998 19:24:26 -0400 Return-Path: owner-tcp-over-satellite@achtung.sp.trw.com Received: from achtung.sp.trw.com (achtung.sp.TRW.COM [129.4.53.140]) by ietf.org (8.8.5/8.8.7a) with SMTP id TAA03531 for ; Sun, 26 Jul 1998 19:24:24 -0400 (EDT) Received: by achtung.sp.trw.com (4.1/SMI-4.1) id AA04781; Sun, 26 Jul 98 15:10:48 PDT Received: from mail-relay2.trw.com by achtung.sp.trw.com (4.1/SMI-4.1) id AA04776; Sun, 26 Jul 98 15:10:41 PDT Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by mail-relay2.trw.com (8.8.8/8.8.8) with ESMTP id PAA17558 for ; Sun, 26 Jul 1998 15:17:05 -0700 (PDT) Received: from chbailey-pc.cisco.com ([171.70.211.34]) by mailman.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.SERVER.1.2) with SMTP id PAA08304; Sun, 26 Jul 1998 15:09:09 -0700 (PDT) Reply-To: From: "Chase Bailey" To: , , , , , , , , , , , , , , , , , , , Subject: Hot Interconnects VI Date: Sun, 26 Jul 1998 15:07:49 -0700 Message-Id: <005601bdb8e1$d3d2c580$22d346ab@chbailey-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcp-over-satellite@achtung.sp.trw.com Precedence: bulk *Sorry for any duplications* ******************************************************************** HOT INTERCONNECTS 6 August 13-15, 1998 Memorial Auditorium, Stanford University, Stanford, California For registration and up to date information visit Symposium web site at www.hoti.org A Symposium on High Performance Interconnects, from system buses and interfaces to networks. HOT Interconnects 6 brings together designers and architects of high-performance chips, software, and systems. Presentations focus on up-to-the-minutes real developments. This symposium is a forum for engineers and researchers to highlight their leading-edge designs. Three days of tutorials and techincal sessions will keep you on top of the industry. *************************************** Technical Program Thursday, August 13 7:30 am: Registration 9:00-10:00 am: Keynote - Challenges for Networking Companies in the 21st Century: A Business Perspective Charles Giancarlo, Vice President of Global Alliances at Cisco Systems Charles Giancarlo is Vice President of Global Alliances at Cisco Systems. Prior to joining Cisco, Mr. Giancarlo was Vice President, responsible for product marketing and corporate development for Kalpana, Inc. Mr. Giancarlo is widely recognized for his contributions in the ATM and LAN switching marketplace. Prior to Kalpana, Mr. Giancarlo served as the Vice President of Marketing for Adaptive Corporation, which developed the industry's first Asynchronous Transfer Mode (ATM) product for the LAN market. During his four-year tenure at Adaptive, Mr. Giancarlo co-founded the ATM Forum, an international consortium of more than 350 vendors and users, where he served on the Board of Directors for three years. While at Adaptive, Mr. Giancarlo developed and patented many industry firsts, including ATM LAN Emulation, Virtual LAN Technology, ATM Ratebased Flow Control and the industry's first ATM SAR chipset. As co-founder of O'Dowd Communications, Giancarlo designed and patented the first cell switch used for data communications. He also holds a patent for the first fully digital commercial codec-filter, which he developed when employed as a lead engineer for Siemens AG. He holds an M.B.A. from Harvard University and a M.S. and B.S. in Electrical Engineering from University of California, Berkeley, and Brown University respectively. 10:00 - 10:30 am: Break 10:30 am-12:00 pm : Fast Routers and Lookups Chair : Nick McKeown, Stanford University Building Fast Routers - G. Varghese, Washington University IP Address Lookup - A. Moestedt, Swedish Institute of Computer Science Architecture of the Avici Terabit Switch - B. Dally, Stanford University Detour: A Case for a Virtual Internet - Tom Anderson, University of Washington 12:00 - 1:30 pm: Lunch 1:30-3:00pm : Twisted Pair and Cable Chair : Chase Bailey, Cisco Systems Moving Towards Friendly DSLs - J. Cioffi, Stanford University Cable Modem Technology - Limb, Georgia Tech What's Wrong with Cable Technology - C. Thacker, Microsoft Simulation Study of Backbone Provisioning - J. Yee, Com21 3:00 - 3:30 pm: Break 3:30-5:00 pm : Switching Chair : Craig Partridge, GTE (BBN) Simultaneous Bi-directional Transceiver Logic - K. Ishibashi, Hitachi Design and Implementation of a Fast Crossbar Scheduler - Pankaj Gupta, Cisco Systems Implementation of Atlas I: A Single Chip - Katevenis, FORTH T-Cross Point Switch Architecture - Larson, UC San Diego 5:00-7:00 pm : Dinner Reception 7:00-8:30 pm : Panel - What I Love to Hate Chair: Steve Deering, Cisco Systems Panelists: Steve Deering, Cisco Systems; Hemant Kanakia, Torrent Systems; Chuck Thacker, Microsoft *************************************** Friday, August 14 9:00-10:00 am : Keynote - Grand Challenges of the Internet Van Jacobson, Group Leader for the Network Research Group, Lawrence Berkeley National Laboratory 10:00 - 10:30 am: Break 10:30-11:15 am : Server Interconnects Chair : Bill Dally Using NUMA Interconnects - S. Kleiman, Network Appliances The NCR Worldmark Family BYNET MPP - R. McMillen, NCR 11:15 am-12:00 pm : Network Interfaces Chair : Randy Rettberg StarT-X; A one year exercise in Network Interface Engineering - J. Hoe, MIT Architecture Considerations for High Performance - S. Muller, Sun 12:00 - 1:30 pm: Lunch 1:30-3:00 pm : Potpourri Chair : Charles Thacker Interference Detection and Avoidance Techniques for Wireless Infrastructure - N. Furukawa, GTE ACTIVE Interconnects - J. Smith, University of Penn Design Considerations for 1000BaseT - R. Paripatyadar, ControlNet 3:00 - 3:30 pm: Break 3:30-4:15 pm : Fast Links Chair : Martin Izzard Serial Link Backplanes - M. Laor, Cisco Systems System Applications of Parallel Optics - L. Buckman, Hewlett Packard *************************************** Saturday, August 15 Tutorial Sessions 8:30 am to 12:00 pm: Morning Tutorial Voice Over IP Systems Dave Oran, Cisco Systems This tutorial provides a system-level understanding of Voice-over-IP systems and provides a basic understanding of all the components necessary to have a toll-quality telephony service using the technology. The tutorial covers: Audio endpoint design, including coding and voice compression basics, echo cancellation, packetization, and more advanced techniques such as FEC, mixing, and adaptive jitter buffer algorithms. Network design, including voice transport protocols (RTP/RTCP), and quality of service mechanisms (RED, WFQ, RSVP, TOS etc.) applicable to large scale voice transport. Call control and signaling methodologies, including H.323, SIP, SGCP in the IP world, and legacy PSTN signaling including ISDN PRI and SS7. David Oran is a Distinguished Engineer at Cisco System, responsible primarily for the architecture and overall design of Cisco's VoIP products. He also consults on a variety of other areas at Cisco, including backbone network design, routing protocols, and quality of service methods. Prior to joining Cisco Mr. Oran was a Senior Consulting engineer at Digital Equipment Corporation, where he was Technical Director for the Mobile Software Business. Mr Oran's main interests lie in the area of the design and implementation of distributed algorithms for computer networks. He was a member of the DECnet architecture group and contributed to the design of key elements of DECnet through 3 iterations of its evolution. He was the designer of the DNA Naming Service, a highly advanced distributed directory system which was adopted by the Open Software Foundation as the local directory component of its comprehensive Distributed Computing Environment product set. Mr. Oran holds a number of patents and patents pending for his work on distributed algorithms. In the area of networking standards, Mr. Oran was the head of the routing standards group in ISO and was editor for a number of important packet-switching and routing standards, including the OSI Routing Framework, the ESIS Protocol, and the Intra-domain ISIS Protocol. He also is group leader for the Integrated Services over Slow Links group of the IETF, and served on the routing and addressing group of the Internet Activities Board, which developed technical alternatives for enhancing the Internet protocol suite to deal with the explosive growth of the system. Mr. Oran was the editor the journal Computer Communication Review from 1991-95. He is the author a a number of technical articles and papers in the areas of protocol design and distributed systems architecture. He also serves on peer review panels for the USA National Science Foundation program in computer networking, and on the program committees of a number of technical conferences, including the SIGCOMM and Hot Interconnects conferences. Mr. Oran holds a B.A. in Physics and English from Haverford College, and has graduate level training in Magnetospheric Geophysics. 1:30 pm to 5:00 pm Afternoon Tutorial Design of High-Speed I/O Interfaces Mark Horowitz, Chih-Kong Ken Yang, Stefanos Sidiropoulos : Stanford Universtity This tutorial will examine the basic components needed to build high-speed electrical links including driver, receiver and phase-locked loop components. Example CMOS implementations will be presented, and limitations of these circuits will also be discussed. Mark Horowitz is the Yahoo Founder's Professor of Electrical Engineering and Computer Science at Stanford University. He received his BS and MS in Electrical Engineering from MIT in 1978, and his Ph.D. from Stanford in 1984. Dr. Horowitz is the recipient of a 1985 Presidential Young Investigator Award, and an IBM Faculty development award, as well as the 1993 best paper award at the International Solid State Circuits Conference. Dr Horowitz's research area is in digital system design, and he has lead a number of processor designs including MIPS-X, one of the first processors to include an on-chip instruction cache, TORCH, a statically-scheduled, superscalar processor that supported speculative execution, and FLASH, a flexible DSM machine. He has also worked in a number of other chip design areas including high-speed, and low-power memory design, high-bandwidth interfaces, and fast floating point. In 1990 he took leave from Stanford to help start Rambus Inc, a company designing high-bandwidth memory interface technology. His current research includes multiprocessor design, low power circuits, memory design, and high-speed links. Chih-Kong Ken Yang received the B.S. and M.S degrees in electrical Engineering from Stanford University, Stanford, in 1992. He is currently pursuing the Ph.D. degree at Stanford University. His research is in the area of circuit design for multi-gigabit links. Mr. Yang is a member of Tau Beta Pi and Phi Beta Kappa. Stefanos Sidiropoulos received the B.S. and M.S. degrees in Computer Science from the University of Crete, Greece, and the Ph.D. degree in Electrical Engineering from Stanford, CA in 1998. He has worked on circuit design and CAD tools at DEC, IIT, SGI He is currently with Rambus Inc, where he is designing DRAM interface circuits. His interests are in high-speed circuit design, and CAD tools. *************************************** Organizing Committee General Chair - Hasan S. Alkhatib, TTC of Silicon Valley Vice Chair - Diane Smith, Santa Clara University Program Co-chairs - Nick McKeown, Stanford University, and Chase Bailey, Cisco Systems Treasurer - Qiang Li, Santa Clara University Publicity - Kristina Scott, Visa Tutorials - Weijia Shang, Santa Clara University Local Arrangements - Edin Hodzic, AT&T Labs & Kersten Barney, Stanford University Proceedings - Vikki Wei, Auspex Systems Web Master - Bruce Wootton, TTC of Silicon Valley Program Committee Bill Dally, Stanford University Chuck Thacker, Microsoft Craig Partridge, BBN Dan Pitt, Bay Networks Dave Oran, Cisco Systems Greg Chesson, SGI James Luciani, Bay Networks Kathleen Nichols, Bay Networks Mark Horowitz, Stanford University Martin Izzard, Texas Instruments Qiang Li, Santa Clara University Randy Rettberf, Sun Microsystems Steve Deering, Cisco Systems For Registration and other information, please, visit our web site at www.hoti.org /chase Chase Bailey, Principal Technologist, Cisco Systems 408.527.3765, Fax: 408.527.9215, chase@cisco.com From ipp-owner@pwg.org Mon Jul 27 10:22:23 1998 Delivery-Date: Mon, 27 Jul 1998 10:22:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15854 for ; Mon, 27 Jul 1998 10:22:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA03766 for ; Mon, 27 Jul 1998 10:21:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA16174 for ; Mon, 27 Jul 1998 10:22:02 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Jul 1998 10:13:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15442 for ipp-outgoing; Mon, 27 Jul 1998 10:09:22 -0400 (EDT) Reply-To: From: "Carl-Uno Manros" To: Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980729 Date: Mon, 27 Jul 1998 07:07:22 -0700 Message-ID: <000001bdb967$e06f4300$cba0d7cf@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipp@pwg.org Agenda for PWG IPP Phone Conference 980729 ========================================== We will hold our normal weekly conference on Wednesday. Main agenda point this week is to discuss about the upcoming bake-off in September. If you have already registered for participation, or plan to still do so, this a chance to give input at the planning stage. Here is the dial-in information: Time: July 29, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno From ipp-owner@pwg.org Mon Jul 27 13:09:40 1998 Delivery-Date: Mon, 27 Jul 1998 13:09:40 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19455 for ; Mon, 27 Jul 1998 13:09:40 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA05163 for ; Mon, 27 Jul 1998 13:09:26 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19385 for ; Mon, 27 Jul 1998 13:09:32 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Jul 1998 13:03:14 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18772 for ipp-outgoing; Mon, 27 Jul 1998 13:00:25 -0400 (EDT) Date: 27 Jul 1998 16:59:53 -0000 Message-ID: <19980727165953.31543.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Implementation question re.: chunki In-Reply-To: <002001bdb749$5dc180a0$aa66010d@copper.parc.xerox.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org Larry wrote: > > There is no 'installed base' of IPP clients and servers which do not > support HTTP/1.1. As a practical matter, it seems unreasonable to > posit one or to create one. > Maybe this is something we could discuss at the next telecon. Here is our situation. For reasons beyond the scope of this discussion, we need to build a client-side API that supports an open,write,write...close|cancel paradigm for sending the document data. This is easy to do with chunking. It may be impossible to do with Content-Length (due to buffering limitations). So our client will normally use chunking. We'd really to avoid having to design it to fall-back to Content-Length when it encounters an HTTP/1.0 IPP server, because that would be complicated and expensive, and won't always work. On the other hand, we don't want to paint ourselves into a corner and build a client that relies heavily on chunking, only to find out that many server implementations can't receive and decode the chunked transfer coding. Is it safe to assume that all IPP 1.0 products will support HTTP/1.1 (and therefore chunking), even if prototype implementations don't? -Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=4184 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Mon Jul 27 13:13:59 1998 Delivery-Date: Mon, 27 Jul 1998 13:14:00 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19653 for ; Mon, 27 Jul 1998 13:13:59 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA05195 for ; Mon, 27 Jul 1998 13:13:44 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19958 for ; Mon, 27 Jul 1998 13:13:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Jul 1998 13:08:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18781 for ipp-outgoing; Mon, 27 Jul 1998 13:00:32 -0400 (EDT) Date: 27 Jul 1998 16:59:53 -0000 Message-ID: <19980727165953.31545.qmail@m2.findmail.com> From: "Carl Kugler" Subject: Re: RE: RE: IPP> Implementation question re.: chunki In-Reply-To: <002001bdb749$5dc180a0$aa66010d@copper.parc.xerox.com> To: ipp@pwg.org Sender: owner-ipp@pwg.org Larry wrote: > > There is no 'installed base' of IPP clients and servers which do not > support HTTP/1.1. As a practical matter, it seems unreasonable to > posit one or to create one. > Maybe this is something we could discuss at the next telecon. Here is our situation. For reasons beyond the scope of this discussion, we need to build a client-side API that supports an open,write,write...close|cancel paradigm for sending the document data. This is easy to do with chunking. It may be impossible to do with Content-Length (due to buffering limitations). So our client will normally use chunking. We'd really to avoid having to design it to fall-back to Content-Length when it encounters an HTTP/1.0 IPP server, because that would be complicated and expensive, and won't always work. On the other hand, we don't want to paint ourselves into a corner and build a client that relies heavily on chunking, only to find out that many server implementations can't receive and decode the chunked transfer coding. Is it safe to assume that all IPP 1.0 products will support HTTP/1.1 (and therefore chunking), even if prototype implementations don't? -Carl ----- Original Message: http://www.findmail.com/list/ipp/?start=4184 Start a FREE email list at http://www.FindMail.com/ From ipp-owner@pwg.org Wed Jul 29 13:10:29 1998 Delivery-Date: Wed, 29 Jul 1998 13:10:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA10872 for ; Wed, 29 Jul 1998 13:10:28 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA17328 for ; Wed, 29 Jul 1998 13:10:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA23553 for ; Wed, 29 Jul 1998 13:10:26 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 13:05:49 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22021 for ipp-outgoing; Wed, 29 Jul 1998 12:52:36 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> SEC - FW: I-D ACTION:draft-ietf-bmwg-secperf-04.txt Date: Wed, 29 Jul 1998 09:15:07 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDBB0C.0D716E82" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDBB0C.0D716E82 Content-Type: text/plain For those of you who are still interested in firewall issues, this document contains a lot of useful background info about firewall technology. Carl-Uno -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 28, 1998 7:21 AM To: IETF-Announce Cc: bmwg@baynetworks.com Subject: I-D ACTION:draft-ietf-bmwg-secperf-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Terminology for Firewall Performance Author(s) : D. Newman Filename : draft-ietf-bmwg-secperf-04.txt Pages : 22 Date : 27-Jul-98 This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches and adds terminology specific to firewalls. The primary metrics used in this document are bit forwarding rate and connections. 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-bmwg-secperf-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bmwg-secperf-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-secperf-04.txt". NOTE: The mail server at ietf.org 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_000_01BDBB0C.0D716E82 Content-Type: message/rfc822 To: Subject: Date: Tue, 28 Jul 1998 09:12:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDBB0C.0D716E82" ------ =_NextPart_002_01BDBB0C.0D716E82 Content-Type: text/plain ------ =_NextPart_002_01BDBB0C.0D716E82 Content-Type: application/octet-stream; name="ATT03718.txt" Content-Disposition: attachment; filename="ATT03718.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980727141713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-secperf-04.txt ------ =_NextPart_002_01BDBB0C.0D716E82 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-bmwg-secperf-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDBB0C.0D716E82-- ------ =_NextPart_000_01BDBB0C.0D716E82-- From ipp-owner@pwg.org Wed Jul 29 16:15:30 1998 Delivery-Date: Wed, 29 Jul 1998 16:15:31 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA12986 for ; Wed, 29 Jul 1998 16:15:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18580 for ; Wed, 29 Jul 1998 16:14:56 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA24446 for ; Wed, 29 Jul 1998 16:15:05 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 16:08:34 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23802 for ipp-outgoing; Wed, 29 Jul 1998 16:03:46 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> TES - New dates for the IPP Bake-off September 23-25, 1998 Date: Wed, 29 Jul 1998 11:01:38 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org All, In today's phone conference it was decided that the IPP bake-off will be held in Redmond, WA, hosted by Microsoft, on September 23-25, 1998. So if you plan to attend, please reserve those dates in your calendar right away. Note that you will only be allowed to participate if you bring an IPP implementation along, no spectators. Peter Zehler will send out a message with further details about the bake-off in a few days. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jul 29 16:23:27 1998 Delivery-Date: Wed, 29 Jul 1998 16:23:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13055 for ; Wed, 29 Jul 1998 16:23:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18651 for ; Wed, 29 Jul 1998 16:23:13 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA25232 for ; Wed, 29 Jul 1998 16:23:23 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 16:14:21 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23806 for ipp-outgoing; Wed, 29 Jul 1998 16:03:49 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> ADM - 42nd IETF-CHICAGO, IL: IPP on August 26, 9 - 11:30 am Date: Wed, 29 Jul 1998 12:49:30 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org FYI, Carl-Uno -----Original Message----- From: Marcia Beaulieu [mailto:mbeaulie@ietf.org] Sent: Wednesday, July 29, 1998 12:36 PM To: manros@cp10.es.xerox.com Cc: moore+iesg@cs.utk.edu; paf@swip.net Subject: 42nd IETF-CHICAGO, IL: IPP This is to confirm one session for IPP as follows: Wednesday, August 26 at 0900-1130 other groups scheduled at that time: trade, ipfc, OPS area meeting, smime, diffserv, nat Please submit an agenda (to agenda@ietf.org) for this meeting before 12:00 noon on August 17. Thanks, Marcia ********************************************************************** Marcia Beaulieu Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-620-9071 From ipp-owner@pwg.org Wed Jul 29 16:30:07 1998 Delivery-Date: Wed, 29 Jul 1998 16:30:08 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13111 for ; Wed, 29 Jul 1998 16:30:07 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18684 for ; Wed, 29 Jul 1998 16:29:49 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26139 for ; Wed, 29 Jul 1998 16:29:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 16:20:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23816 for ipp-outgoing; Wed, 29 Jul 1998 16:03:54 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> ADM - FW: I-D ACTION:draft-ietf-conneg-feature-reg-03.txt Date: Wed, 29 Jul 1998 11:06:21 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDBB1B.97B09E4C" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDBB1B.97B09E4C Content-Type: text/plain The CONNEG group has produced a new draft on media. This includes a suggested identification scheme for media such as paper media in a printer. We need to look at this and give our feedback. Carl-Uno -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 29, 1998 6:47 AM To: IETF-Announce Cc: ietf-medfree@imc.org Subject: I-D ACTION:draft-ietf-conneg-feature-reg-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : Media Feature Tag Registration Procedure Author(s) : T. Hardie, K. Holtman, A. Mutz Filename : draft-ietf-conneg-feature-reg-03.txt Pages : 9 Date : 28-Jul-98 Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. 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-conneg-feature-reg-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-reg-03.txt". NOTE: The mail server at ietf.org 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_000_01BDBB1B.97B09E4C Content-Type: message/rfc822 To: Subject: Date: Wed, 29 Jul 1998 10:58:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDBB1B.97B09E4C" ------ =_NextPart_002_01BDBB1B.97B09E4C Content-Type: text/plain ------ =_NextPart_002_01BDBB1B.97B09E4C Content-Type: application/octet-stream; name="ATT01242.txt" Content-Disposition: attachment; filename="ATT01242.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980728154541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-reg-03.txt ------ =_NextPart_002_01BDBB1B.97B09E4C Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-conneg-feature-reg-03.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDBB1B.97B09E4C-- ------ =_NextPart_000_01BDBB1B.97B09E4C-- From ipp-owner@pwg.org Wed Jul 29 16:30:50 1998 Delivery-Date: Wed, 29 Jul 1998 16:30:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13117 for ; Wed, 29 Jul 1998 16:30:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18687 for ; Wed, 29 Jul 1998 16:30:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26273 for ; Wed, 29 Jul 1998 16:30:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 16:21:42 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23824 for ipp-outgoing; Wed, 29 Jul 1998 16:04:03 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> MOD & PRO - Latest text on ipp scheme Date: Wed, 29 Jul 1998 11:48:54 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDBB21.8986E1B8" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDBB21.8986E1B8 Content-Type: text/plain During today's phone conference it turned out that some people were unclear about the latest draft version of the ipp scheme proposal. It turns out that it was included as part of a message sent out by Bob Herriot. To make it a bit easier, I have now put that text into a separate TXT document, which is attached to this message. I will also put it up on the server, but it seems to be inaccessible right now. 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 ------ =_NextPart_000_01BDBB21.8986E1B8 Content-Type: text/plain; name="IPPSchemePostMonterey.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IPPSchemePostMonterey.txt" Post-Monterey Proposal for an ipp scheme after discussion with Keith = Moore July 1998 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Summary: The quick summary is that IPP should support a new scheme 'ipp', which=20 clients and servers use in IPP attributes. Such attributes are in a = message=20 body whose Content-Type is application/ipp. A client maps 'ipp' URLs = to=20 'http' URLs, and then follows the HTTP/1.1 rules for constructing a=20 Request-Line and HTTP headers. The IPP document will not prohibit=20 implementations from supporting other schemes in IPP attributes, but = such=20 support is not defined by this document. =20 Now for the details. A client and an IPP object (i.e. the server) SHOULD support the 'ipp' = scheme=20 in the following IPP attributes. Each of these attributes identifies a = printer or job object. The 'ipp' scheme is not intended for use in = 'uri'=20 valued attributes not in this list. job attributes -=20 job-uri=20 job-printer-uri printer attributes -=20 printer-uri-supported operation attributes -=20 job-uri=20 printer-uri If the scheme of the target URL in a request (i.e. the value of =20 "printer-uri" or "job-uri" operation attribute) is some scheme 'x', = other=20 than 'ipp', the behavior of the IPP object is not defined by this = document. =20 However, it is RECOMMENDED that if an operation on an IPP object = creates a=20 new value for any of the above attributes, that attribute has the same=20 scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of = the=20 seven attributes above in the response, that the IPP object returns = those=20 URL values as is, regardless of the scheme of the target URL. If the client obtains a target URL from a directory service, the scheme = of=20 the target URL SHOULD be 'ipp'. If the scheme is not 'ipp', the = behavior of=20 the client is not defined by this document, but it is RECOMMENDED that = the=20 client use the URL as is as the target URL. Although user interfaces are beyond the scope of this document, it is=20 RECOMMENDED that if software exposes the URL values of any of the above = seven attributes to a human user, that the human see the URL as is. =20 When a client sends a request, it MUST convert an 'ipp' target URL to = an=20 'http' target URL for use in the HTTP Request-Line and HTTP headers as=20 specified by HTTP/1.1. However, the 'ipp' target URL remains as is for = the=20 value of the "printer-uri" or "job-uri" attribute in the message body. = If=20 the scheme of the target URL is not 'ipp', the behavior of the client = is not=20 defined by this document, but it is RECOMMENDED that the client use the = target URL as is in the Request-Line and HTTP headers. A client converts an 'ipp' URL to an 'http' URL by=20 1) replacing the 'ipp' scheme by 'http'=20 2) adding an explicit port 631 if the URL does not contain an = explicit port. When an IPP client sends a request directly (i.e. no proxy) to an = =91ipp=92 URL=20 such as "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP = connection=20 to some port (this example uses the IPP default port 631) on some host=20 ("myhost.com" in this example) with the following headers: POST /myprinter/myqueue HTTP/1.1=20 Host: myhost.com:631=20 Content-type: application/ipp=20 Transfer-Encoding: chunked=20 ... "printer-uri" "ipp://myhost.com/myprinter/myqueue"=20 (encoded in application/ipp message body)=20 ... When an IPP client sends a request via a proxy, such as "myproxy.com", = to an=20 =91ipp=92 URL, such as "ipp://myhost.com/myprinter/myqueue", it MUST = open a TCP=20 connection to some port (8080 in this example) on some proxy = ("myproxy.com"=20 in this example) with the following headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1=20 Host: myproxy.com:8080=20 Content-type: application/ipp=20 Transfer-Encoding: chunked=20 ... "printer-uri" "ipp://myhost.com/myprinter/myqueue"=20 (encoded in application/ipp message body)=20 ... The proxy then connects to the IPP origin server with headers that are = the=20 same as the "no-proxy" example above. ------ =_NextPart_000_01BDBB21.8986E1B8-- From ipp-owner@pwg.org Wed Jul 29 16:37:11 1998 Delivery-Date: Wed, 29 Jul 1998 16:37:11 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13205 for ; Wed, 29 Jul 1998 16:37:10 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18713 for ; Wed, 29 Jul 1998 16:36:57 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA26958 for ; Wed, 29 Jul 1998 16:37:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 16:33:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25400 for ipp-outgoing; Wed, 29 Jul 1998 16:24:39 -0400 (EDT) Message-ID: <35BF84EE.EAC6C0AC@agranat.com> Date: Wed, 29 Jul 1998 20:24:14 +0000 From: Scott Lawrence Organization: Agranat Systems http://www.agranat.com/ X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.32 i686) MIME-Version: 1.0 To: Jeff Wiederholt , Nick Moradian CC: Barry Charton , IPP List Subject: IPP> HP is OK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org Dave I. just relayed a message to me from Zami @ HP that my fix did in fact fix the Zbuf problem. She had some questions about file sizes - I tried to return her call but she didn't answer so I left her a message with my number here. -- Scott Lawrence Consulting Engineer Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/ From ipp-owner@pwg.org Wed Jul 29 21:14:49 1998 Delivery-Date: Wed, 29 Jul 1998 21:14:49 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA14901 for ; Wed, 29 Jul 1998 21:14:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20039 for ; Wed, 29 Jul 1998 21:14:30 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA27795 for ; Wed, 29 Jul 1998 21:14:31 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 21:08:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27232 for ipp-outgoing; Wed, 29 Jul 1998 21:03:23 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'IETF-IPP'" , "'Johnson, Swen'" Subject: IPP> MOD - Inconsistency Date: Wed, 29 Jul 1998 18:00:12 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Referring to IPP-MOD 980630, the table in section 4.4 (page 88) says document-format-default is REQUIRED. However, the description of document-format-supported in section 4.4.19 (page 98) does not indicate it as being REQUIRED. We believe that it should be REQUIRED in both cases, and suggest that this needs fixing in 4.4.19 before the document is finalized. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Wed Jul 29 21:19:14 1998 Delivery-Date: Wed, 29 Jul 1998 21:19:14 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA14918 for ; Wed, 29 Jul 1998 21:19:14 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20062 for ; Wed, 29 Jul 1998 21:18:59 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA28404 for ; Wed, 29 Jul 1998 21:19:12 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 21:14:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA27487 for ipp-outgoing; Wed, 29 Jul 1998 21:10:54 -0400 (EDT) Message-Id: <3.0.5.32.19980729181018.00d035d0@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 29 Jul 1998 18:10:18 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - typo: "document-format-default", "document-format-supported" need to be REQUIRED Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The table in Section 4 says that "document-format-default" and "document-format-supported" are REQUIRED, but the descriptions of those attributes in sections 4.4.18 and 4.4.19 do not say REQUIRED. I believe that 4.4.18 and 4.4.19 should be fixed by adding REQUIRED to agree with the table, like the other attributes that are REQUIRED. These two attributes are so fundamental to the description of a Printer object that the fix should NOT be to remove REQUIRED from the table. Tom From ipp-owner@pwg.org Wed Jul 29 21:57:56 1998 Delivery-Date: Wed, 29 Jul 1998 21:57:56 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA15060 for ; Wed, 29 Jul 1998 21:57:55 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20206 for ; Wed, 29 Jul 1998 21:57:35 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29083 for ; Wed, 29 Jul 1998 21:57:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 21:53:41 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA28521 for ipp-outgoing; Wed, 29 Jul 1998 21:47:27 -0400 (EDT) From: Harry Lewis To: Subject: IPP> Chunking Message-ID: <5030100023854285000002L052*@MHS> Date: Wed, 29 Jul 1998 21:45:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipp@pwg.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA15060 It doesn't make sense to require HTTP1.1 which requires eating chunks (not emitting) but write IPP as if eating chunks is optional. Harry Lewis - IBM Printing Systems From ipp-owner@pwg.org Wed Jul 29 22:38:13 1998 Delivery-Date: Wed, 29 Jul 1998 22:38:23 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA16962 for ; Wed, 29 Jul 1998 22:38:13 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA20302 for ; Wed, 29 Jul 1998 22:37:58 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA29775 for ; Wed, 29 Jul 1998 22:38:11 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 22:33:40 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29198 for ipp-outgoing; Wed, 29 Jul 1998 22:28:12 -0400 (EDT) Message-ID: From: "Manros, Carl-Uno B" To: "'Harry Lewis'" , "'IETF-IPP'" Subject: RE: IPP> Chunking Date: Wed, 29 Jul 1998 19:25:09 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Harry, I agree that we should all be eating chunks when we roll out products. The problem is that some do not have it in the prototypes right now. Let us check this out in our bake-off and see how much of a problem it really is. Come September, there may be more chunk eaters... Carl-Uno > -----Original Message----- > From: Harry Lewis [mailto:harryl@us.ibm.com] > Sent: Wednesday, July 29, 1998 6:46 PM > To: ipp@pwg.org > Subject: IPP> Chunking > > > It doesn't make sense to require HTTP1.1 which requires > eating chunks (not > emitting) but write IPP as if eating chunks is optional. > > Harry Lewis - IBM Printing Systems > From ipp-owner@pwg.org Wed Jul 29 22:43:52 1998 Delivery-Date: Wed, 29 Jul 1998 22:43:52 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA16975 for ; Wed, 29 Jul 1998 22:43:51 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA20323 for ; Wed, 29 Jul 1998 22:43:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id WAA00434 for ; Wed, 29 Jul 1998 22:43:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 29 Jul 1998 22:39:51 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29593 for ipp-outgoing; Wed, 29 Jul 1998 22:36:41 -0400 (EDT) Message-Id: <3.0.5.32.19980729193512.00b8be80@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 29 Jul 1998 19:35:12 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> OPS - 7 Proposed New IPP Operations: Set 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Paul Moore, Bob Herriot, Ron Bergman, and I have incorporated the agreements from the Monterey meeting on the new operations proposed by Paul Moore. I have posted the files in a new sub-directory: new_OPS The URLs are: ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.txt I've posted the older files on this subject there also. We would like to discuss this updated proposal at the upcoming IPP telecon, Wednesday, August 5, 1-3 EDT (10-12 PDT). Its written in the form of an Internet-Draft, but is named as just a PWG draft for now. Is it ready to be sent as an Internet-Draft? Here is the Abstract: Abstract This document specifies seven OPTIONAL operations for use with the Internet Printing Protocol/1.0 (IPP) [ipp-mod, ipp-pro]. The defined Set 1 operations are: Hold-Job Release-Job Restart-Job Reprocess-Job Pause-Printer Resume-Printer Purge-Jobs Send any comments to the IPP mailing list with the Subject line prefix: "OPS" Thanks, Tom, Ron, Paul, and Bob From ipp-owner@pwg.org Thu Jul 30 12:37:49 1998 Delivery-Date: Thu, 30 Jul 1998 12:37:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA01506 for ; Thu, 30 Jul 1998 12:37:48 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA23227 for ; Thu, 30 Jul 1998 12:37:31 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA14253 for ; Thu, 30 Jul 1998 12:37:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Jul 1998 12:28:58 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13649 for ipp-outgoing; Thu, 30 Jul 1998 12:22:24 -0400 (EDT) Message-ID: <35C09DB9.67E29DE6@underscore.com> Date: Thu, 30 Jul 1998 12:22:17 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Tom Hastings Subject: Re: IPP> OPS - 7 Proposed New IPP Operations: Set 1 References: <3.0.5.32.19980729193512.00b8be80@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org All files referenced by Tom's message (below) have been moved into the new "new_OPS" subdirectory, as originally intended, including the previously posted Microsoft drafts. ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > Paul Moore, Bob Herriot, Ron Bergman, and I have incorporated the agreements > from the Monterey meeting on the new operations proposed by Paul Moore. > > I have posted the files in a new sub-directory: new_OPS > > The URLs are: > > ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.doc > ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.pdf > ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-pwg-ipp-ops-set1-00-980727.txt > > I've posted the older files on this subject there also. > > We would like to discuss this updated proposal at the upcoming IPP > telecon, Wednesday, August 5, 1-3 EDT (10-12 PDT). > > Its written in the form of an Internet-Draft, but is named as just a > PWG draft for now. Is it ready to be sent as an Internet-Draft? > > Here is the Abstract: > > Abstract > > This document specifies seven OPTIONAL operations for use with the Internet > Printing Protocol/1.0 (IPP) [ipp-mod, ipp-pro]. The defined Set 1 > operations are: > > Hold-Job > Release-Job > Restart-Job > Reprocess-Job > Pause-Printer > Resume-Printer > Purge-Jobs > > Send any comments to the IPP mailing list with the Subject line prefix: "OPS" > > Thanks, > Tom, Ron, Paul, and Bob From ipp-owner@pwg.org Thu Jul 30 21:08:35 1998 Delivery-Date: Thu, 30 Jul 1998 21:08:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA07845 for ; Thu, 30 Jul 1998 21:08:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA26070 for ; Thu, 30 Jul 1998 21:08:16 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA15274 for ; Thu, 30 Jul 1998 21:08:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Jul 1998 21:03:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14713 for ipp-outgoing; Thu, 30 Jul 1998 20:59:38 -0400 (EDT) Message-Id: <3.0.5.32.19980730175909.009d3ea0@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 30 Jul 1998 17:59:09 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> SEC - How could IPP work over firewalls? Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipp@pwg.org Times New RomanWe have held a meeting with some firewall and proxy experts today to get their views on how IPP could work over firewalls. Here is a short description of the scenario that came out of those discussions: When a print request (or other IPP request) comes in to the domain, in which the IPP Printer is located, it goes through the following steps: 1) The firewall inspects the request on the TCP layer and typically checks the host address and the port number. If it finds that this matches, it redirects the request to a particular proxy server. This is standard firewall software. The proxy server may be dedicated to handle only HTTP/IPP, or could handle several application level protocols. 2) The proxy server includes an IPP specific application process, which would check that the request is a valid IPP request, e.g. that it is an HTTP POST and that it contains the MIME type "application/ipp". This software will need to be tailored and written to handle IPP. 3) If TLS is used, the proxy server can also perform the authentication and decryption services. 4) The proxy server then redirects the request to the IPP server inside the domain. Note that the previous steps are performed before the request is accepted into the domain. There are various configuration alternatives, e.g. the firewall and proxy server may be integrated in the same box. A couple of other observations and bits of advice: - If you want unlimited access to an IPP printer, simply put it outside the firewall, or on the domain border, so it can be accessed from both outside and inside the domain. - If you want to let requests come in through your firewall at all, you will probably *always* use TLS for requests from outside the domain. If you let the proxy server handle authentication and encryption, there is no real need to use TLS between the proxy server and the IPP server. This means that clients from inside the domain do not need to use TLS, when accessing the IPP server. Comments? Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jul 31 11:48:50 1998 Delivery-Date: Fri, 31 Jul 1998 11:48:50 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22287 for ; Fri, 31 Jul 1998 11:48:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA28565 for ; Fri, 31 Jul 1998 11:48:34 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA01513 for ; Fri, 31 Jul 1998 11:48:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Jul 1998 11:39:06 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00953 for ipp-outgoing; Fri, 31 Jul 1998 11:33:28 -0400 (EDT) Message-ID: From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Subject: RE: IPP> SEC - How could IPP work over firewalls? Date: Fri, 31 Jul 1998 08:33:18 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipp@pwg.org Step 2 - Inbound proxies are unusual - I have never heard of one. Does anybody have a product names for one. > -----Original Message----- > From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com] > Sent: Thursday, July 30, 1998 5:59 PM > To: ipp@pwg.org > Subject: IPP> SEC - How could IPP work over firewalls? > > We have held a meeting with some firewall and proxy experts today to get > their views on how IPP could work over firewalls. Here is a short > description of the scenario that came out of those discussions: > > When a print request (or other IPP request) comes in to the domain, in > which the IPP Printer is located, it goes through the following steps: > > 1) The firewall inspects the request on the TCP layer and typically checks > the host address and the port number. If it finds that this matches, it > redirects the request to a particular proxy server. This is standard > firewall software. The proxy server may be dedicated to handle only > HTTP/IPP, or could handle several application level protocols. > > 2) The proxy server includes an IPP specific application process, which > would check that the request is a valid IPP request, e.g. that it is an > HTTP POST and that it contains the MIME type "application/ipp". This > software will need to be tailored and written to handle IPP. > > 3) If TLS is used, the proxy server can also perform the authentication > and decryption services. > > 4) The proxy server then redirects the request to the IPP server inside > the domain. Note that the previous steps are performed before the request > is accepted into the domain. > > There are various configuration alternatives, e.g. the firewall and proxy > server may be integrated in the same box. > > A couple of other observations and bits of advice: > > - If you want unlimited access to an IPP printer, simply put it outside > the firewall, or on the domain border, so it can be accessed from both > outside and inside the domain. > > - If you want to let requests come in through your firewall at all, you > will probably *always* use TLS for requests from outside the domain. If > you let the proxy server handle authentication and encryption, there is no > real need to use TLS between the proxy server and the IPP server. This > means that clients from inside the domain do not need to use TLS, when > accessing the IPP server. > > Comments? > > Carl-Uno > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Fri Jul 31 12:18:31 1998 Delivery-Date: Fri, 31 Jul 1998 12:18:32 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23547 for ; Fri, 31 Jul 1998 12:18:30 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA28914 for ; Fri, 31 Jul 1998 12:18:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA02201 for ; Fri, 31 Jul 1998 12:18:25 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Jul 1998 12:14:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01636 for ipp-outgoing; Fri, 31 Jul 1998 12:10:59 -0400 (EDT) Message-ID: <3683AF7E2328D211A2BA00805F15CE8505CC32@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: "'IETF-IPP'" Subject: IPP> FW: I-D ACTION:draft-ietf-http-v11-spec-rev-04.txt Date: Fri, 31 Jul 1998 09:07:50 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDBC9D.5E02DC18" Sender: owner-ipp@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDBC9D.5E02DC18 Content-Type: text/plain FYI, This text for HTTP 1.1 is likely to soon replace RFC 2068. Carl-Uno -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, July 30, 1998 6:47 AM To: IETF-Announce Cc: http-wg@cuckoo.hpl.hp.com Subject: I-D ACTION:draft-ietf-http-v11-spec-rev-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Title : Hypertext Transfer Protocol -- HTTP/1.1 Author(s) : J. Mogul, T. Berners-Lee, L. Masinter, P. Leach, R. Fielding, H. Nielsen, J. Gettys Filename : draft-ietf-http-v11-spec-rev-04.txt Pages : 155 Date : 29-Jul-98 The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as 'HTTP/1.1', and is an update to RFC2068 [33]. At the time of submission, there were no remaining outstanding issues after a working group last call. The HTTP/1.1 issues list can be found at http://www.w3.org/Protocols/HTTP/Issues/. Linked from this page are also Postscript and Microsoft Word versions (with versions with change bars) of this document which are easier to review than this text document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-v11-spec-rev-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-http-v11-spec-rev-04.txt". NOTE: The mail server at ietf.org 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_000_01BDBC9D.5E02DC18 Content-Type: message/rfc822 To: Subject: Date: Fri, 31 Jul 1998 08:33:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDBC9D.5E02DC18" ------ =_NextPart_002_01BDBC9D.5E02DC18 Content-Type: text/plain ------ =_NextPart_002_01BDBC9D.5E02DC18 Content-Type: application/octet-stream; name="ATT01830.txt" Content-Disposition: attachment; filename="ATT01830.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980729123623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-v11-spec-rev-04.txt ------ =_NextPart_002_01BDBC9D.5E02DC18 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-http-v11-spec-rev-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDBC9D.5E02DC18-- ------ =_NextPart_000_01BDBC9D.5E02DC18-- From ipp-owner@pwg.org Fri Jul 31 12:35:56 1998 Delivery-Date: Fri, 31 Jul 1998 12:35:57 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24225 for ; Fri, 31 Jul 1998 12:35:56 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA29063 for ; Fri, 31 Jul 1998 12:35:32 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA03278 for ; Fri, 31 Jul 1998 12:35:45 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Jul 1998 12:27:31 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA02278 for ipp-outgoing; Fri, 31 Jul 1998 12:21:18 -0400 (EDT) Message-ID: <3683AF7E2328D211A2BA00805F15CE8505CC33@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: ipp@pwg.org Subject: RE: IPP> SEC - How could IPP work over firewalls? Date: Fri, 31 Jul 1998 09:16:48 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipp@pwg.org Paul, You are right. This is a new piece of software that you cannot get from stock. This is why I stated: "This software will need to be tailored and written to handle IPP". Carl-Uno > -----Original Message----- > From: Paul Moore [mailto:paulmo@microsoft.com] > Sent: Friday, July 31, 1998 8:33 AM > To: 'Carl-Uno Manros'; ipp@pwg.org > Subject: RE: IPP> SEC - How could IPP work over firewalls? > > > Step 2 - Inbound proxies are unusual - I have never heard of one. Does > anybody have a product names for one. > > > -----Original Message----- > > From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com] > > Sent: Thursday, July 30, 1998 5:59 PM > > To: ipp@pwg.org > > Subject: IPP> SEC - How could IPP work over firewalls? > > > > We have held a meeting with some firewall and proxy experts > today to get > > their views on how IPP could work over firewalls. Here is a short > > description of the scenario that came out of those discussions: > > > > When a print request (or other IPP request) comes in to the > domain, in > > which the IPP Printer is located, it goes through the > following steps: > > > > 1) The firewall inspects the request on the TCP layer and > typically checks > > the host address and the port number. If it finds that this > matches, it > > redirects the request to a particular proxy server. This is standard > > firewall software. The proxy server may be dedicated to handle only > > HTTP/IPP, or could handle several application level protocols. > > > > 2) The proxy server includes an IPP specific application > process, which > > would check that the request is a valid IPP request, e.g. > that it is an > > HTTP POST and that it contains the MIME type "application/ipp". This > > software will need to be tailored and written to handle IPP. > > > > 3) If TLS is used, the proxy server can also perform the > authentication > > and decryption services. > > > > 4) The proxy server then redirects the request to the IPP > server inside > > the domain. Note that the previous steps are performed > before the request > > is accepted into the domain. > > > > There are various configuration alternatives, e.g. the > firewall and proxy > > server may be integrated in the same box. > > > > A couple of other observations and bits of advice: > > > > - If you want unlimited access to an IPP printer, simply > put it outside > > the firewall, or on the domain border, so it can be > accessed from both > > outside and inside the domain. > > > > - If you want to let requests come in through your firewall > at all, you > > will probably *always* use TLS for requests from outside > the domain. If > > you let the proxy server handle authentication and > encryption, there is no > > real need to use TLS between the proxy server and the IPP > server. This > > means that clients from inside the domain do not need to > use TLS, when > > accessing the IPP server. > > > > Comments? > > > > Carl-Uno > > > > Carl-Uno Manros > > Principal Engineer - Advanced Printing Standards - Xerox > Corporation > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > Email: manros@cp10.es.xerox.com > From ipp-owner@pwg.org Mon Aug 3 18:44:35 1998 Delivery-Date: Mon, 03 Aug 1998 18:44:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01236 for ; Mon, 3 Aug 1998 18:44:35 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06617 for ; Mon, 3 Aug 1998 18:44:12 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA14248 for ; Mon, 3 Aug 1998 18:44:27 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Aug 1998 18:34:56 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA13689 for ipp-outgoing; Mon, 3 Aug 1998 18:33:03 -0400 (EDT) Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2D2C4@red-msg-45.dns.microsoft.com> From: Josh Cohen To: "'Manros, Carl-Uno B'" , ipp@pwg.org Subject: RE: IPP> SEC - How could IPP work over firewalls? Date: Mon, 3 Aug 1998 15:32:38 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipp@pwg.org I disagree, there is nothing different in the products 'inbound' or 'outbound' proxy. The only thing that makes it inbound or outbound is the access policy set by the administrator. Typically, firewalls/proxies are liberal with outbound and strict with inbound. HTTP proxies have no problem allowing inbound access. Other firewalls/proxies are common for SMTP mail, NNTP news feeds, etc.. > -----Original Message----- > From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] > Sent: Friday, July 31, 1998 9:17 AM > To: ipp@pwg.org > Subject: RE: IPP> SEC - How could IPP work over firewalls? > > > Paul, > > You are right. This is a new piece of software that you > cannot get from > stock. > This is why I stated: "This software will need to be tailored and > written to handle IPP". > > Carl-Uno > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Friday, July 31, 1998 8:33 AM > > To: 'Carl-Uno Manros'; ipp@pwg.org > > Subject: RE: IPP> SEC - How could IPP work over firewalls? > > > > > > Step 2 - Inbound proxies are unusual - I have never heard > of one. Does > > anybody have a product names for one. > > > > > -----Original Message----- > > > From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com] > > > Sent: Thursday, July 30, 1998 5:59 PM > > > To: ipp@pwg.org > > > Subject: IPP> SEC - How could IPP work over firewalls? > > > > > > We have held a meeting with some firewall and proxy experts > > today to get > > > their views on how IPP could work over firewalls. Here is a short > > > description of the scenario that came out of those discussions: > > > > > > When a print request (or other IPP request) comes in to the > > domain, in > > > which the IPP Printer is located, it goes through the > > following steps: > > > > > > 1) The firewall inspects the request on the TCP layer and > > typically checks > > > the host address and the port number. If it finds that this > > matches, it > > > redirects the request to a particular proxy server. This > is standard > > > firewall software. The proxy server may be dedicated to > handle only > > > HTTP/IPP, or could handle several application level protocols. > > > > > > 2) The proxy server includes an IPP specific application > > process, which > > > would check that the request is a valid IPP request, e.g. > > that it is an > > > HTTP POST and that it contains the MIME type > "application/ipp". This > > > software will need to be tailored and written to handle IPP. > > > > > > 3) If TLS is used, the proxy server can also perform the > > authentication > > > and decryption services. > > > > > > 4) The proxy server then redirects the request to the IPP > > server inside > > > the domain. Note that the previous steps are performed > > before the request > > > is accepted into the domain. > > > > > > There are various configuration alternatives, e.g. the > > firewall and proxy > > > server may be integrated in the same box. > > > > > > A couple of other observations and bits of advice: > > > > > > - If you want unlimited access to an IPP printer, simply > > put it outside > > > the firewall, or on the domain border, so it can be > > accessed from both > > > outside and inside the domain. > > > > > > - If you want to let requests come in through your firewall > > at all, you > > > will probably *always* use TLS for requests from outside > > the domain. If > > > you let the proxy server handle authentication and > > encryption, there is no > > > real need to use TLS between the proxy server and the IPP > > server. This > > > means that clients from inside the domain do not need to > > use TLS, when > > > accessing the IPP server. > > > > > > Comments? > > > > > > Carl-Uno > > > > > > Carl-Uno Manros > > > Principal Engineer - Advanced Printing Standards - Xerox > > Corporation > > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > > > Phone +1-310-333 8273, Fax +1-310-333 5514 > > > Email: manros@cp10.es.xerox.com > > > From ipp-owner@pwg.org Mon Aug 3 21:02:36 1998 Delivery-Date: Mon, 03 Aug 1998 21:02:36 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02006 for ; Mon, 3 Aug 1998 21:02:06 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA07075 for ; Mon, 3 Aug 1998 21:01:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA15049 for ; Mon, 3 Aug 1998 21:01:54 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 3 Aug 1998 20:54:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14492 for ipp-outgoing; Mon, 3 Aug 1998 20:48:47 -0400 (EDT) Message-Id: <3.0.5.32.19980803174817.00c07c20@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 3 Aug 1998 17:48:17 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980805 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Agenda for PWG IPP Phone Conference 980805 ========================================== We will hold our normal weekly conference on Wednesday. I was hoping to get some further news from Keith about the IESG process, but it is apparently not yet finished. The deadline for new I-Ds to Chicago is already this Friday, so we are in a hurry to get anything we want in for that finished over the next couple of days. We should discuss the new draft on the additional operations and decide if we want to introduce the current draft from Tom et al as an I-D. We should check if there is any news on the bake-off preparations, and we need to firm up on the agendas for both Toronto and Chicago. Here is the dial-in information: Time: August 5, 10:00 - 12:00 PDT (1:00 - 3:00 EDT) Phone: 1-800-857 5607 Passcode: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Aug 4 08:54:05 1998 Delivery-Date: Tue, 04 Aug 1998 08:54:06 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA15664 for ; Tue, 4 Aug 1998 08:54:05 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA08505 for ; Tue, 4 Aug 1998 08:53:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id IAA28591 for ; Tue, 4 Aug 1998 08:54:03 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Aug 1998 08:50:04 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA28016 for ipp-outgoing; Tue, 4 Aug 1998 08:47:10 -0400 (EDT) Content-return: allowed Date: Tue, 4 Aug 1998 05:46:16 PDT From: "Zehler, Peter " Subject: IPP> TES Important IPP Bake-off information To: "IPP Discussion List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain Sender: owner-ipp@pwg.org All, Sorry for the delay but it is summertime afterall. Here is a summary of the points raised at last weeks phone conference. The first 4 points are very important. 1) The target date for the IPP bake-off is September 23, 24 & 25. 2) Microsoft has offered to host the event. They have offered: 1. A large room with power and a LAN (about 3 taps/organization 10baseT) 2. A DHCP server 3. Food 4. A visit to the company store 5. September sunshine (if we get lucky) For no charge 3) The cut off date for registration for the bake-off is August 21. All registration will be made by sending email to " "peter.zehler@usa.xerox.com". The final participant list will be posted to the IPP list on August 24. I would like to know what IPP component will be brought to the bake off(e.g. Client, Printer, Printer Test Suite, Client Test Suite). 4) Only organizations actively participating in the bake-off may attend. 5) Test tools should be onsite modifiable. It is desirable to tailor the tools to meet our testing needs and insure their accuracy. Having the test tool author present would be beneficial. 6) The capability to fix client/server code is also desirable. 7) Participants are encouraged to bring network monitoring tools. 8) IPP and SNMP/MIB corelation testing is out of scope for this bake-off. 9) I will update the current test plan(ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/IPP-Test-Plan-980216.pdf) and sent out notification when the new version is available. The updates will reflect the 6/30 document set. I will also include a first draft of a "top 25" list. The list will be used to capture scenarios that have caused problems in interoperability testing. Initially it will just be some common scenarios to get the list started. 10) After the test the results will be sent to all participants in a mutually agreeable anonimity form. 11) A sanatized summary will be circulated to the whole IPP group. The format will be discussed. 12) Time should be set aside at the Toronto meeting and/or subsequent phone conferences to discuss the following issues. 1) Clarify the HTTP 1.0/1.1 issue. (my current understanding is they both must be supported) 2) Chunked encoding of IPP. How will we test it? 3) Anonimity of bake-off results 4) Sanatized summary of bake-off results format 13) The organizations that have publicly announced their intention to participate in the IPP bake-off are: 1) Auco 2) IBM 3) Lexmark 4) Microsoft 5) Novell 6) Sun 7) TRCS 8) Xerox Pete From ipp-owner@pwg.org Tue Aug 4 17:39:51 1998 Delivery-Date: Tue, 04 Aug 1998 17:39:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA17483 for ; Tue, 4 Aug 1998 17:39:47 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12123 for ; Tue, 4 Aug 1998 17:39:28 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA00782 for ; Tue, 4 Aug 1998 17:39:46 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Aug 1998 17:30:07 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA00202 for ipp-outgoing; Tue, 4 Aug 1998 17:26:45 -0400 (EDT) From: Van Dang Message-Id: <199808042126.OAA12738@gaia.ecs.csus.edu> Subject: IPP> conflicting "attributes-charset" To: ipp@pwg.org Date: Tue, 4 Aug 98 14:26:20 PDT Mailer: Elm [revision: 70.85] Sender: owner-ipp@pwg.org How should the server handle the situation where the "attributes-charset" of the response itself is "us-ascii", but one or more attributes in that response is in the "utf-8" format? Consider a case where a client sends a Print-Job request with "utf-8" as the value of "attributes-charset" and with the "job-name" attribute supplied. Later another client sends a Get-Job-Attribute or Get-Jobs request. This second request contains the "attributes-charset" with value "us-ascii" and "requested-attributes" attribute with exactly one value "job-name". According to the IPP-Mod document (section 3.1.4.2), the value of the "attributes-charset" for the response of the second request must be "us-ascii" since that is the charset specified in the request. The "job-name" value, however, is in "utf-8" format. Should the request be rejected even though both "utf-8" and "us-ascii" charsets are supported by the server? or should the "job-name" value be converted to "us-ascii" and return "successful-ok-conflicting-attributes" (0x0002) as the status code? From ipp-owner@pwg.org Tue Aug 4 19:05:17 1998 Delivery-Date: Tue, 04 Aug 1998 19:05:17 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA18174 for ; Tue, 4 Aug 1998 19:04:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12578 for ; Tue, 4 Aug 1998 19:04:04 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA01462 for ; Tue, 4 Aug 1998 19:04:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Aug 1998 19:00:05 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00905 for ipp-outgoing; Tue, 4 Aug 1998 18:56:46 -0400 (EDT) Message-Id: <3.0.5.32.19980804155518.009d8260@garfield> X-Sender: cmanros@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 4 Aug 1998 15:55:18 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> TES - Xerox IPP Prototype Client and IPP Test Tool Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org All, Now the Xerox IPP Prototype Client and the IPP Test Tool are available for you to download from our web site. The official release is tomorrow. If you want to beat the crowd, download today. The URL is: http://www.xerox.com/research/ipp/ If you do not have the Java JDK and JFC loaded, you will need about 60 MB of free disk space. For any questions contact: xerox-ipp-tools@cp10.es.xerox.com Enjoy, Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-owner@pwg.org Tue Aug 4 21:51:51 1998 Delivery-Date: Tue, 04 Aug 1998 21:51:51 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA20699 for ; Tue, 4 Aug 1998 21:51:50 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA12982 for ; Tue, 4 Aug 1998 21:51:29 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA02194 for ; Tue, 4 Aug 1998 21:51:48 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Aug 1998 21:45:03 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA01649 for ipp-outgoing; Tue, 4 Aug 1998 21:40:10 -0400 (EDT) Message-Id: <3.0.5.32.19980804183932.01f1c980@garfield> X-Sender: hastings@garfield X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 4 Aug 1998 18:39:32 PDT To: Paul Moore From: Tom Hastings Subject: Re: IPP> Comments on MIB access document Cc: "'ipp@pwg.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org Paul, You ask some good questions. Yes, it is true that the MIB access proposal is not exactly the same as the current attribute of the Printer and Job objects in IPP/1.0. Here are my replies. Several ISSUES are indicated that need to be resolved. Thanks, Tom At 18:34 07/16/98 PDT, Paul Moore wrote: >This document proposed many extremely significant changes to IPP. They are >so radical that I do not thing that they can be accepted simply as an >optional extension to 1.0. Many of the issue it tries to solve are very >valid - but this is not the right way to address them. Do you have an alternative. The goal was to leverage the implementation of Printer MIB agents that are in many network printers today. So that an IPP printer implementation that chooses to support the MIB access extension would be able to do so with minimal extra code in the printer. The IPP Printer object implementation would pass the MIB attribute requests to the SNMP agent, either through the front door using SNMP or through the back door using internal calls. In either approach, the access to the SNMP agent would use the Get and GetNext semantics to access the objects in a subtree. > >1. > >The current model is very strong on hiding the physical details of fanning >out. The only thing exposed is a logical printer - the fact that this may >represent multiple devices is deliberatly not exposed. This proposal turns >this 180 degrees and explicitly exposes this. No comment on whether this is >good or bad - I merely point out that this is a BIG change to slip in via an >optional extension for accessing MIBs. Yes, it is a change. But it is a natural kind of changes, since the IPP Printer is a logical printer and the MIB is a physical concept. This is a time-honored approach to system design. Some things you want to hide and some things you don't. However, even IPP/1.0 does have the 'stopped-partly' concept to reflect the state of an IPP Printer that has some devices stopped and some not. So the concept of multiple devices is already present in IPP 1.0. See the figures in section 1.1 and 2.1 which both show multiple devices for a single IPP Printer object. Also for the simplest (and most likely) implementation, one IPP Printer controls one device. So the difference between the logical and physical disappears. There is no way to think of the Printer MIB as representing several devices at once, so we couldn't keep the Printer MIB attributes at the same level as the IPP Printer. > >Note that this is done for some non-MIB attributes as well. Yes, in just the same way as the IPP/1.0 "document-format" input parameter specializes certain Printer attribute values to the specified document format, so that the Printer attribute isn't representing the union across multiple document formats. > >2. > >The device is described as being an 'object'. This challenges the whole >concept of an object in IPP. Everywhere else an Object can receive >operations and has a URI; the device does neither. Having said that, a model >that does expose 'devices' and 'objects' but that does not represent such a >fundamental construct (device) as a object seems very strange. Perhaps we should not call it an object, unless we have operations that have a device as a target. We could be more vague, same as we have done for documents, which are not described as objects. See section 2.2. ISSUE: Should we change the description of a device so that it is not an object? > >3. > >This scheme introduces a structured namespace. No comment on whether this is >good or bad - I merely point out that this is a BIG change from the flat >list in the main model. Agreed. The name space is structured to achieve the goal of simple implementation without complex mapping tables from attribute keyword names in English to Printer MIB objects. On the other hand, these structured names are really "attribute group names" like we have in IPP/1.0. In IPP/1.0, we have the attribute group names that can be supplied in a Get-Printer-Attributes operation: 'printer-description' 'job-template' 'all' that return more than one attribute in the response. > >4. > >The printer MIB is given a special place in this scheme. What about the job >mib or the finisher mib. I suggest that the Finisher MIB will add four structured attributes, since it is an extension to the Printer MIB. However, for any Job MIB attributes that we want to have access to via IPP, we should add as real IPP attributes with U.S. English keywords. There is a lot more overlap between Job MIB attributes and IPP job attributes already (on purpose). > >5. > >The MIB query is optional but is overloaded on the get attributes operation. >I cannot find out if a printer supports it without trying and failing. >Normally such big pieces of functionality would be a separate operation. As with any Get-Printer-Attributes query, any supported Operation attribute that is supplied with unsupported attribute values is ignored and does not return an error. Instead, the IPP Printer returns the "requested-attributes" operation attribute in the Unsupported Attributes group [2] with only the values that are unsupported, i.e., with the keyword names of the unsupported attributes as the values. So an application could supply unsupported MIB attributes along with supported other attributes and still get back a response. If we made it a separate operation, so that it could be queried as a value in the Printer's "operations-supported" attribute, you would still need to make a query if you wanted to find out. Instead, you can query a required MIB object, such as 'prt-att-5-1' (prtGeneralConfigChanges) to see if it comes back as an attribute with a value, or you get back no attributes. ISSUE: Should we add a note at to this method for testing as to whether the MIB access feature is supported? > >6. > >What is the relationship between the information I obtain via the MIb query >and the data I obtain via the other queries? Will the result of querying the >job mib be the same as the result of doing a getjobs? What about >printer-status and the MIB status? Certainly the Job MIB should return both IPP jobs and non-IPP jobs, i.e., jobs submitted to the printer via some other job submission protocol. Whether an IPP Get-Jobs operation also returns non-IPP jobs, would be up to implementation. NOTE that if non-IPP jobs were returned, there might not be a "job-uri" attribute, even though there is a "job-id". On the other hand, there is no reason why an IPP Get-Jobs operation couldn't manufacture a "job-uri" for each non-IPP job, as long as it produced the same value for a job on successive queries. ISSUE: Should we RECOMMEND that non-IPP jobs be accessible via Get-Jobs, Cancel-Job, and Get-Job-Attributes? Should we REQUIRE it? > >7. > >If I dont say what device I want it will go to the 'first' one. What does >first mean? The first value in the corresponding IPP Printer object's "devices-supported" attribute. See lines 451-452. > Is it guaranteed to be the same always? The same unless the system is reconfigured. >How do I support intelligent pools (If I send a PS file there is a choice of >two printers, if I send PCL there is a choice of 4. Only 2 printers are >available for large jobs, but if i send a small job there is a choice of 4). ISSUE: Should the "document-format" input parameter affect which devices are returned or not? If it MAY, then the first device in the "devices-supported" might depend on which document-format value was supplied (and that the implementation supports the "document-format" specializing the returned attributes). My suggestion is that "document-format" NOT affect which devices are returned. This is simpler and conforms to the definition that the "document-format" input parameter only reflects what the IPP Printer object uses to validate jobs which are all "xxx-supported" attribtes. None of the Printer MIB attributes are of the form "xxx-supported". >What should the device list return? I suggest that the "devices-supported" Printer attribute not be affected by the "document-format" input parameter, if supplied and if supported. >What happens if a device is turned off? ISSUE: Good question. I suggest that the IPP Printer return the IPP out-of-band 'unknown' value for each attribute for a device that is turned off. It should return real values for any other attributes. OK? If the first device is the device turned off, then a Get-Printer-Attributes with no "which-device" supplied may get back 'unknown' for each attribute, same as if a particular "which-device" was supplied that was turned off. > >8. > >You state that for non-printer MIB things you dont have to say what the >device is because this is implicit in the OID. There is a level shift here. >The devices enumerated by the proposed IPP device list is not the same as >the device list in each printer. A printer will have a printer device, a >disk, some RAM, etc. Yes, it is a level shift on purpose, because the "devices-supported" and the "which-device" only apply to the attribute group names that start with 'prt-'. The "devices-supported" and "which-devices" (being printers only) have no meaning when accessing attribute group names that start 'mib-'. ISSUE: How about saying that the list of devices supported by the "devices-supported" Printer attribute is the subset of the hrDeviceTable list of devices that are printers. For consistency with MIB walks using the 'mib-att-xxx' group name, we should also specify that the order of the printer devices in the hrDeviceTable be the same order as in the "devices-supported". > >9. > >You do not say what must happen if I send a valid query but the result is >empty. I.e. read the alert table. ISSUE: Good point. What should be returned with each SNMPv2 error? We suggest the following mapping of SNMPv2 out-of-band values for SNMP objects to IPP out-of-band value for attributes: SNMPv2 out of band value IPP out-of-band value or action ------------------------ ------------------------------- noSuchInstance 'no-value' noSuchObject ignore the requested attribute and return the "requested-attributes" operation attribute with only the unsupported values in the Unsupported Attributes Group [2]. So if requesting the alert table and there are no entries, return: 'prt-tab-18' = 'no-value' We suggest the following mapping of SNMPv2 errors to IPP out-of-band attribute values. An error cannot be returned, since other valid attributes may be requested in the same request. SNMP error SNMP version action or attribute value returned ---------- ------------ ---------------------------------- noError(0) v1 return the requested value of the object tooBig(1) v1 make repeated requests of smaller amounts or chunk the responses back to the client MUST not return an error noSuchName(2) v1 compat only ignore the requested attribute and return the "requested-attributes" operation attribute with only the unsupported values in the Unsupported Attributes Group [2]. badValue(3) v1 only set can't happen readOnly(4) v1 only set can't happen genErr(5) v2 deprecated return 'server-error-internal-error' noAccess(6) v2 return 'client-error-not-authorized wrongType(7) v2 only set can't happen wrongLength(8) v2 only set can't happen wrongEncoding(9) v2 only set can't happen wrongValue(10) v2 only set can't happen noCreation(11) v2 only set can't happen inconsistentValue(12) v2 only set can't happen resourceUnavailable(13) v2 only set can't happen commitFailed(14) v2 only set can't happen undoFailed(15) v2 only set can't happen From ipp-owner@pwg.org Tue Aug 4 23:08:21 1998 Delivery-Date: Tue, 04 Aug 1998 23:08:22 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA28536 for ; Tue, 4 Aug 1998 23:08:21 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA13159 for ; Tue, 4 Aug 1998 23:08:00 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA03299 for ; Tue, 4 Aug 1998 23:08:15 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 4 Aug 1998 23:00:08 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA02756 for ipp-outgoing; Tue, 4 Aug 1998 22:57:31 -0400 (EDT) Message-ID: From: Paul Moore To: "'Tom Hastings'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Comments on MIB access document Date: Tue, 4 Aug 1998 19:57:14 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipp@pwg.org > >8. > >You state that for non-printer MIB things you dont have to say what the >device is because this is implicit in the OID. There is a level shift here. >The devices enumerated by the proposed IPP device list is not the same as >the device list in each printer. A printer will have a printer device, a >disk, some RAM, etc. Yes, it is a level shift on purpose, because the "devices-supported" and the "which-device" only apply to the attribute group names that start with 'prt-'. The "devices-supported" and "which-devices" (being printers only) have no meaning when accessing attribute group names that start 'mib-'. So which IPP fan-out device gets queried when I do a get attributes for non-prt MIB OIDS. > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com] > Sent: Tuesday, August 04, 1998 6:40 PM > To: Paul Moore > Cc: 'ipp@pwg.org' > Subject: Re: IPP> Comments on MIB access document > > Paul, > > You ask some good questions. Yes, it is true that the MIB access > proposal is not exactly the same as the current attribute of the > Printer and Job objects in IPP/1.0. > > Here are my replies. > > Several ISSUES are indicated that need to be resolved. > > Thanks, > Tom > > At 18:34 07/16/98 PDT, Paul Moore wrote: > >This document proposed many extremely significant changes to IPP. They > are > >so radical that I do not thing that they can be accepted simply as an > >optional extension to 1.0. Many of the issue it tries to solve are very > >valid - but this is not the right way to address them. > > Do you have an alternative. The goal was to leverage the implementation > of Printer MIB agents that are in many network printers today. So that > an IPP printer implementation that chooses to support the MIB access > extension would be able to do so with minimal extra code in the printer. > The IPP Printer object implementation would pass the MIB attribute > requests > to the SNMP agent, either through the front door using SNMP or through > the back door using internal calls. In either approach, the access to the > SNMP agent would use the Get and GetNext semantics to access the objects > in a subtree. > > > > >1. > > > >The current model is very strong on hiding the physical details of > fanning > >out. The only thing exposed is a logical printer - the fact that this may > >represent multiple devices is deliberatly not exposed. This proposal > turns > >this 180 degrees and explicitly exposes this. No comment on whether this > is > >good or bad - I merely point out that this is a BIG change to slip in via > an > >optional extension for accessing MIBs. > > Yes, it is a change. But it is a natural kind of changes, since the > IPP Printer is a logical printer and the MIB is a physical concept. > This is a time-honored approach to system design. Some things you > want to hide and some things you don't. > > However, even IPP/1.0 does have the 'stopped-partly' concept to reflect > the state of an IPP Printer that has some devices stopped and some not. > So the concept of multiple devices is already present in IPP 1.0. > See the figures in section 1.1 and 2.1 which both show multiple devices > for a single IPP Printer object. > > Also for the simplest (and most likely) implementation, one IPP Printer > controls one device. So the difference between the logical and physical > disappears. > > There is no way to think of the Printer MIB as representing several > devices at once, so we couldn't keep the Printer MIB attributes at the > same level as the IPP Printer. > > > > >Note that this is done for some non-MIB attributes as well. > > Yes, in just the same way as the IPP/1.0 "document-format" input parameter > > specializes certain Printer attribute values to the specified document > format, so that the Printer attribute isn't representing the > union across multiple document formats. > > > > >2. > > > >The device is described as being an 'object'. This challenges the whole > >concept of an object in IPP. Everywhere else an Object can receive > >operations and has a URI; the device does neither. Having said that, a > model > >that does expose 'devices' and 'objects' but that does not represent such > a > >fundamental construct (device) as a object seems very strange. > > Perhaps we should not call it an object, unless we have operations that > have a device as a target. We could be more vague, same as we have done > for documents, which are not described as objects. See section 2.2. > > ISSUE: Should we change the description of a device so that it is not > an object? > > > > > >3. > > > >This scheme introduces a structured namespace. No comment on whether this > is > >good or bad - I merely point out that this is a BIG change from the flat > >list in the main model. > > Agreed. The name space is structured to achieve the goal of simple > implementation without complex mapping tables from attribute keyword > names in English to Printer MIB objects. On the other hand, these > structured names are really "attribute group names" like we have > in IPP/1.0. In IPP/1.0, we have the attribute group names that can > be supplied in a Get-Printer-Attributes operation: > > 'printer-description' > 'job-template' > 'all' > > that return more than one attribute in the response. > > > > >4. > > > >The printer MIB is given a special place in this scheme. What about the > job > >mib or the finisher mib. > > I suggest that the Finisher MIB will add four structured attributes, > since it is an extension to the Printer MIB. > > However, for any Job MIB attributes that we want to have access > to via IPP, we should add as real IPP attributes with U.S. English > keywords. > There is a lot more overlap between Job MIB attributes and IPP job > attributes > already (on purpose). > > > > >5. > > > >The MIB query is optional but is overloaded on the get attributes > operation. > >I cannot find out if a printer supports it without trying and failing. > >Normally such big pieces of functionality would be a separate operation. > > As with any Get-Printer-Attributes query, any supported Operation > attribute > that is supplied with unsupported attribute values is ignored and does not > > return an error. Instead, the IPP Printer returns > the "requested-attributes" operation attribute in the Unsupported > Attributes group [2] with only the values that are unsupported, i.e., > with the keyword names of the unsupported attributes as the values. > > So an application could supply unsupported MIB attributes along with > supported other attributes and still get back a response. > > If we made it a separate operation, so that it could be queried as a value > in the Printer's "operations-supported" attribute, you would still need > to make a query if you wanted to find out. Instead, you can query > a required MIB object, such as 'prt-att-5-1' (prtGeneralConfigChanges) > to see if it comes back as an attribute with a value, or you get back > no attributes. > > ISSUE: Should we add a note at to this method for testing as to whether > the MIB access feature is supported? > > > > >6. > > > >What is the relationship between the information I obtain via the MIb > query > >and the data I obtain via the other queries? Will the result of querying > the > >job mib be the same as the result of doing a getjobs? What about > >printer-status and the MIB status? > > Certainly the Job MIB should return both IPP jobs and non-IPP jobs, i.e., > jobs submitted to the printer via some other job submission protocol. > Whether an IPP Get-Jobs operation also returns non-IPP jobs, would be > up to implementation. NOTE that if non-IPP jobs were returned, there > might > not be a "job-uri" attribute, even though there is a "job-id". On the > other > hand, there is no reason why an IPP Get-Jobs operation couldn't > manufacture a "job-uri" for each non-IPP job, as long as it produced > the same value for a job on successive queries. > > ISSUE: Should we RECOMMEND that non-IPP jobs be accessible via Get-Jobs, > Cancel-Job, and Get-Job-Attributes? Should we REQUIRE it? > > > > >7. > > > >If I dont say what device I want it will go to the 'first' one. What does > >first mean? > > The first value in the corresponding IPP Printer object's > "devices-supported" > attribute. See lines 451-452. > > > Is it guaranteed to be the same always? > > The same unless the system is reconfigured. > > >How do I support intelligent pools (If I send a PS file there is a choice > of > >two printers, if I send PCL there is a choice of 4. Only 2 printers are > >available for large jobs, but if i send a small job there is a choice of > 4). > > ISSUE: Should the "document-format" input parameter affect which devices > are returned or not? If it MAY, then the first device in the > "devices-supported" might depend on which document-format value was > supplied > (and that the implementation supports the "document-format" specializing > the returned attributes). > > My suggestion is that "document-format" NOT affect which devices are > returned. This is simpler and conforms to the definition that the > "document-format" input parameter only reflects what the IPP Printer > object uses to validate jobs which are all "xxx-supported" attribtes. > None of the Printer MIB attributes are of the form "xxx-supported". > > >What should the device list return? > > I suggest that the "devices-supported" Printer attribute not be affected > by the "document-format" input parameter, if supplied and if supported. > > >What happens if a device is turned off? > > ISSUE: Good question. I suggest that the IPP Printer return the > IPP out-of-band 'unknown' value for each attribute for a device that > is turned off. It should return real values for any other attributes. > OK? > > If the first device is the device turned off, then a > Get-Printer-Attributes with no "which-device" supplied may get back > 'unknown' for each attribute, same as if a particular "which-device" > was supplied that was turned off. > > > > > >8. > > > >You state that for non-printer MIB things you dont have to say what the > >device is because this is implicit in the OID. There is a level shift > here. > >The devices enumerated by the proposed IPP device list is not the same as > >the device list in each printer. A printer will have a printer device, a > >disk, some RAM, etc. > > Yes, it is a level shift on purpose, because the "devices-supported" and > the > "which-device" only apply to the attribute group names that start > with 'prt-'. The "devices-supported" and "which-devices" (being printers > only) have no meaning when accessing attribute group names that start > 'mib-'. > > ISSUE: How about saying that the list of devices supported by the > "devices-supported" Printer attribute is the subset > of the hrDeviceTable list of devices that are printers. For consistency > with MIB walks using the 'mib-att-xxx' group name, we should also specify > that the order of the printer devices in the hrDeviceTable be the same > order > as in the "devices-supported". > > > > >9. > > > >You do not say what must happen if I send a valid query but the result is > >empty. I.e. read the alert table. > > ISSUE: Good point. What should be returned with each SNMPv2 error? > > We suggest the following mapping of SNMPv2 out-of-band values for SNMP > objects > to IPP out-of-band value for attributes: > > SNMPv2 out of band value IPP out-of-band value or action > ------------------------ ------------------------------- > noSuchInstance 'no-value' > noSuchObject ignore the requested attribute and return > the > "requested-attributes" operation attribute > with > only the unsupported values in the > Unsupported > Attributes Group [2]. > > So if requesting the alert table and there are no entries, return: > > 'prt-tab-18' = 'no-value' > > We suggest the following mapping of SNMPv2 errors to IPP out-of-band > attribute values. An error cannot be returned, since other valid > attributes may be requested in the same request. > > SNMP error SNMP version action or attribute value returned > ---------- ------------ ---------------------------------- > noError(0) v1 return the requested value of the object > tooBig(1) v1 make repeated requests of smaller amounts > or chunk the responses back to the client > MUST not return an error > noSuchName(2) v1 compat only ignore the requested attribute and return > the > "requested-attributes" operation attribute > with > only the unsupported values in the > Unsupported > Attributes Group [2]. > badValue(3) v1 only set can't happen > readOnly(4) v1 only set can't happen > genErr(5) v2 deprecated return 'server-error-internal-error' > noAccess(6) v2 return 'client-error-not-authorized > wrongType(7) v2 only set can't happen > wrongLength(8) v2 only set can't happen > wrongEncoding(9) v2 only set can't happen > wrongValue(10) v2 only set can't happen > noCreation(11) v2 only set can't happen > inconsistentValue(12) v2 only set can't happen > resourceUnavailable(13) v2 only set can't happen > commitFailed(14) v2 only set can't happen > undoFailed(15) v2 only set can't happen